Re: [TLS] Closing on keys used for handshake and data messages

[Ilari Liusvaara <[e-mail]>]

On Sat, Jun 04, 2016 at 02:26:00AM -0400, Dave Garrett wrote:
> On Friday, June 03, 2016 05:54:53 pm Joseph Salowey wrote:
> > Unfortunately, the TLS record framing is not easily compatible with having
> > multiple keys used simultaneously: because we encrypt the content type, it
> > is not possible to use it to determine which key to use to decrypt. We
> > examined a number of proposals which would allow you to simultaneously have
> > encrypted content types and separate keys, but they all appear to be
> > nonviable for one reason or another:
> > 
> >    - Trial decryption has serious implementation problems
> >    - Double-encrypting handshake messages in both the handshake key and the
> >    application key does not actually provide the required key separation
> >    - Separately encrypting the content type is inefficient in a number of
> >    ways, especially for DTLS (and would need separate security analysis). This
> >    is probably the most viable of the “try to get both” designs.
> 
> Could someone please elaborate on why nested encryption would be a
> problem?

The problem is that nested encryption does not solve the separation
problem (application misusing keys it has[1] in ways that interact
badly with the (late) handshake[2]).

Essentially the difference is "the generated key is safe to use with
any protocol" versus "the generated key is safe to use for TLS 1.3".

And if the first is not true, proving the second is harder (even if
it should be true, barring massive design errors[3] or applications
doing utterly crazy stuff[4]).


[1] Nevermind it REALLY SHOULD NOT actually have those keys, but only
plaintext access to its own mux stream.

[2] In normal TLS operation, the protocol mux/demux prevents such
interference from actually occuring.

[3] Like grossly broken protocol mux.

[4] Stuff applications have absolutely no legimate business of doing
(if I ever see such things, my first assumption about the cause will
be malice).


-Ilari