Re: [TLS] Consensus call for keys used in handshake and data messages

[Dave Garrett <[e-mail]>]

On Monday, June 20, 2016 08:39:11 pm Eric Rescorla wrote:
> Nobody seems super-excited about either Option 1 or Option 2, so it's
> at least worth noting that there's one of the options I claimed was
> rejected earlier, namely separately encrypting the content type in
> roughly the manner suggested by DKG, Ilari, and Kenny. Thanks for
> Doug/Felix for prompting me on this.
> 
> 
> NOTE: I don't promise any of the below is secure, though it probably
> can be made so with enough work. Actually doing so is an exercise
> for the reader.
> 
> 
> The basic idea is as follows:
> 
> 1. In each direction generate a separate "content_type_key"
> 2. Separately encrypt the content type from the rest of the record
>    using the content_type_key.
> 3. On the receiving side, first decrypt the content type and then use
>    that to determine what key to decrypt the record.
> 
> The trivial version of this is just to AEAD encrypt the content type
> separately, but this has unacceptable bandwidth and CPU properties, so
> is probably not viable. However, there are more efficient designs,
> which can get the overhead down to modest levels (<= 1 byte of
> expansion and <=1/16 of a block computation/record).
> 
> The obvious construction is to use the content_type_key to compute a
> per-record masking value (effectively an ad hoc stream cipher) and
> then use that to encrypt the content type (or potentially just a key
> type bit) without integrity (though you might later protect it in the
> additional data block under the main key). This gives you an
> encryption function without expansion. If you have a mask function
> which outputs one block at a time, you can use pieces of the block for
> each record (e.g., for record N you use byte N/16) [1]
> 
> 
> Obvious objections to this:
> 1. This isn't integrity protected. This is probably the most serious
> complaint and has the potential to actually leak information about
> the content type unless you're careful [2], even if you eventually
> integrity protect this information.
> 
> 2. It's odd to just use a piece of the AEAD cipher (the encryption
> function), especially if we ever had a really non-composite cipher.
> This can be alleviated by using HKDF-Expand to produce the stream
> of bits.
> 
> 3. Maybe it doesn't get the whole job done, especially wrt the fact
> that we're not rekeying the app data after client auth.
> 
> 4. It's gross. Yes, yes it is.
> 
> 
> I'm not really in love with this idea, but I did want people to know
> that maybe we don't *have* to choose between option 1 and option 2
> in case that changes people's opinions.

All this complexity for encrypting a single bit seems like way too much of a risk.

An idea for an option 4: Keep typing and keying as it currently is (as of draft 13), but mandate a KeyUpdate immediately following (and/or before) non-application traffic. We already have a mechanism to use different keys in series, which sounds like it might be simpler than trying to figure out a good way to do so in parallel. Is this a viable thought to pursue, or does this still not help enough with our key separation worries? An additional thought might be adding a random to KeyUpdate to make the new key not based entirely on the old entropy.


Dave