Re: [TLS] judging consensus on keys used in handshake and data messages

[Ilari Liusvaara <[e-mail]>]

On Thu, Jul 07, 2016 at 07:10:20AM +0200, Karthikeyan Bhargavan wrote:
> If we are left with 1 or 3, the miTLS team would prefer 1.

Yeah, me too.

> On the cryptographic side, Hugo has a recent (draft) paper that seems
> to provide some more justification for (1), at least for client
> authentication. 

Personally, I would be very surprised if (1) the way it is used in -13
turned out broken, unless the application did very odd things (that
would likely render security of 2 or 3 questionable as well).

But perhaps there is some very nontrivial way to screw up using just
one key, a way that doesn't involve rather obvious mistakes, e.g.

- Encryption failing basic security notions.
- Context-sensitive messages.
- Rather obviously disclosing or leaking keys.
- Broken channel muxing.
- Applications carelessly doing raw read/write.

For the above, either nothing obvious comes up with draft-13 designs
or using multiple keys wouldn't really help.


For DTLS, I noticed that there might be issues with replay of handshake
messages (key separation obivously wouldn't help here). Fortunately,
all messages that are in DTLS seem to be idempotent... As extra safety
measure, one could require handshake messages to be always be replay-
checked (turning replay checking off would only turn it off for appdata
messages and leave it on for handshake messages).

> I know this is a bit off-topic, but the miTLS team would also like
> to get rid of 0-RTT ClientFinished if that is the only message left
> in the 0-RTT encrypted handshake flight. That should remove another
> Handshake/Data key separation from the protocol, leaving only 3 keys:
> 0-RTT data, 1-RTT handshake, and 1-RTT data. 

Oh yeah, that message is sure annoying to handle...

And in (Stream)TLS, it is supposed to provode a MAC. Isn't there going
to be sending at least one encrypted 0-RTT data record (if only warning
alert 1)? Seems like that would provode a MAC.

Things are quite a bit different in DTLS tho: Since there is no
reliability for any appdata, without Finished there might not be a MAC
available even in case of 0-RTT being accepted.

Based on some quick thinking, I don't expect the previous to be a
problem, given that if 0-RTT keys are wrong, all the other keys are
almost certainly (within collision margins) wrong too, triggering an
abort on next encrypted record.

> > On 07 Jul 2016, at 02:49, David Benjamin <[e-mail]> wrote:
> > 
> > On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <[e-mail] <mailto:[e-mail]>> wrote:
> > On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <[e-mail] <mailto:[e-mail]>> wrote:
> > On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote:
> > > I'm also curious which post-handshake messages are the problem.
> > > If we were to rename "post-handshake handshake messages" to
> > > "post-handshake bonus messages" with a distinct bonus_message
> > > record type, where would there still be an issue? (Alerts and
> > > application data share keys and this seems to have been fine.)

That wouldn't really help: It isn't distinction between main-handshake
and post-handshake messages that is the problem (those are key-separated
anyway!), but distinction between post-handshake and appdata messages
(or lack thereof).

> > Me neither. To clarify, I mention this not as a suggestion, but
> > to motivate asking about the type of message. If the only reason
> > the proofs want them in the handshake bucket rather than the
> > application data bucket is that they say "handshake" in them then,
> > sure, let's do an inconsequential re-spelling and move on from this
> > problem.
> > 
> > But presumably something about the messages motivate this key
> > separation issue and I'd like to know what they are.

What I think the issue here actually is:

If you are going to use the encryption key used for application data for
_anything_ else (such as using it to encrypt any sort of "control"
messages) you have to be careful that the uses "don't step on another's
toes". And then when doing security proofs, you need to also prove that
the uses don't interfere with each other.


There has obviously been some very bad communication here, so the above
understanding might not be correct...



-Ilari