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

[Daniel Kahn Gillmor <[e-mail]>]

On Wed 2016-06-15 12:23:38 -0400, Ilari Liusvaara wrote:
> On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote:
>> On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote:
>> 
>> To be clear, we're being asked to trade these things off against each
>> other here, but there are other options which were ruled out in the
>> prior framing of the question which don't rule either of them out.
>> 
>> In particular, if we're willing to pay the cost of a slightly more
>> complex key schedule (and an increased TLS record size), we could have
>> "packet header" keys which protect the content-type itself for all
>> non-cleartext TLS records.  If we do that, these keys might as well also
>> be used to protect the TLS record size itself.  This would result in an
>> opaque data stream (though obviously record size would still leak in
>> DTLS, and timing and framing is still likely to leak the record size in
>> the lowest-latency TLS applications).
>
> Does this need to enlarge TLS record size? Why doesn't encrypting the
> content-type/length and then authenticating those off main MAC work

maybe i'm not understanding your proposal, but if we're encrypting the
record length as well, how do you find (and validate) the main MAC
without knowing the record length?

> I presume problems from header-flipping (tho in TLS that will kill the
> connection if you try...)

I'm not sure what header-flipping is...

> Also, in DTLS, there could be issues switching the encryption on
> (but then, looks like DTLS 1.3 has other unsolved problems
> currently..)

yes, i think that might be the case.

     --dkg