Subject: Re: [httpwg/http-extensions] Advice on padding strategy (#272)

From: HTTP issue updates <[email-masked]>
Date: Fri, 25 Nov 2016 11:40:47 -0800

ekr requested changes on this pull request.

> @@ -535,6 +535,14 @@ provides.  Alternatively, splitting up content into segments and storing the
 separately might reduce exposure. HTTP/2 {{?RFC7540}} combined with TLS
 {{?RFC5246}} might be used to hide the size of individual messages.
 
+Developing a padding strategy is difficult.  A good padding strategy can depend
+on context.  Common strategies include padding to a small set of fixed lengths,
+padding to multiples of a values, or padding to powers of 2.  Even a good
+strategy can still cause size information to leak if processing activity of a
+recipient can be observed.  This is especially good if the trailing records of
+a message contain only padding.  To minimize this information, non-padding data

I am guessing "good " is not the word you want here. Perhaps "true"?

> @@ -535,6 +535,14 @@ provides.  Alternatively, splitting up content into segments and storing the
 separately might reduce exposure. HTTP/2 {{?RFC7540}} combined with TLS
 {{?RFC5246}} might be used to hide the size of individual messages.
 
+Developing a padding strategy is difficult.  A good padding strategy can depend
+on context.  Common strategies include padding to a small set of fixed lengths,
+padding to multiples of a values, or padding to powers of 2.  Even a good
+strategy can still cause size information to leak if processing activity of a
+recipient can be observed.  This is especially good if the trailing records of
+a message contain only padding.  To minimize this information, non-padding data
+can be evenly distributed between records.

Perhaps something slightly stronger like "should" or "MAY WISH TO" 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/272#pullrequestreview-10198065