W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2017

Re: Secdir last call review of draft-ietf-httpbis-encryption-encoding-08

From: Robert Sparks <rjsparks@nostrum.com>
Date: Thu, 6 Apr 2017 09:47:08 -0500
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-httpbis-encryption-encoding.all@ietf.org, "ietf@ietf.org" <ietf@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <1f550ddb-a279-ad2b-0599-c9ed2c95da09@nostrum.com>


On 4/5/17 5:32 PM, Martin Thomson wrote:
> On 6 April 2017 at 06:47, Robert Sparks <rjsparks@nostrum.com> wrote:
>> My only concern is that the document suggests it would be ok to use a
>> counter to provide a unique salt value
>> for each message. I suspect that provides the kind of information leak
>> the draft discusses avoiding.
> Hi Robert, can you explain what sort of leakage you are concerned
> about?  I mean, I can understand how you could construct the sequence
> of resources that were encrypted using a counter for the salt, but I
> don't know what that might imply.
Things like these:

- A third party that could see that sequence would know if there were gaps.

- If creation or transmission time can be approximated (perhaps via file 
stats),
   the third party can more quickly assess the rate of creation, and 
have a strong
   idea of when to look for the next one.

Of course for both of those, the 3rd party would need to somehow know the
content came from the same source, but it's easy to see systems built 
using this
that would expose that.
>
> That said, I think that the counter thing can be removed.  We require
> 128 bits of salt, which is a space that is large enough to select
> randomly from in perpetuity.
That would be my personal preference.
Received on Thursday, 6 April 2017 14:47:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC