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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
