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

[Cas Cremers <[e-mail]>]

Hi,

After several discussions (including the ones Douglas points out) I have
also come round to option 1 as the preferred way forward. For our symbolic
analysis in Tamarin it should not make a big difference anyway.

Best,

Cas


On Thu, Jul 7, 2016 at 8:47 PM, Douglas Stebila <[e-mail]> wrote:

> With Hugo's analysis of the secure channel-like security afforded even
> when the application key is used to encrypt non-application data, and as
> Cédric pointed out to me the application key will be used to encrypt
> non-application data like certain alert messages; so I think option 1 is a
> reasonable choice, and option 3 would not recover the composability
> property we hoped it might.
>
> Douglas
>
>
> > On Jul 7, 2016, at 12:44 PM, Hugo Krawczyk <[e-mail]>
> wrote:
> >
> > I do not have an objection to option 1 if re-phrased as
> > Option 1 - use the same key for protecting both *post*-handshake and
> applications messages..
> >
> > I believe this is what was intended by that option anyway. Let me
> clarify.
> >
> > I understand the question as relating *only* to post-handshake messages
> and not
> > to the main handshake (three initial flights). For the latter we have key
> > separation in the sense that none of these main-handshake messages is
> encrypted
> > under the application key but rather under dedicated handshake keys.
> This should
> > not be changed as it provides key indistinguishability to the
> application key, a
> > desirable design and analysis (=proof) modularity property.
> >
> > On the other hand, for post-handshake messages, and particularly for
> encrypting
> > post-handshake client authentication messages, preserving key
> > indistinguishability is not relevant since at the time of post-handshake
> > client authentication, the application key has already lost its
> indistinguishability
> > by the mere fact that the key was used to encrypt application data. Key
> > indistinguishability is the main reason to insist in key separation and
> this
> > principle does not apply here anymore hence removing the objection to 1.
> >
> > I'd note that the best one could hope for in the post-handshake setting
> is that
> > as a result of post-handshake client authentication the application key
> becomes
> > a secure mutually-authenticated key for providing "secure channels"
> security.
> > As pointed out by others in previous posts I have an analysis showing
> that this
> > delayed mutual authentication guarantee is achieved even if one uses the
> > application key to encrypt the post-handshake messages. I have
> circulated a
> > preliminary version of the  paper among cryptographers working on TLS 1.3
> > and  I will post a public copy next week so this can be scrutinized
> further.
> >
> > Hugo
> >
> >
> > On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan <
> [e-mail]> wrote:
> > If we are left with 1 or 3, the miTLS team would prefer 1.
> >
> > On the cryptographic side, Hugo has a recent (draft) paper that seems to
> provide
> > some more justification for (1), at least for client authentication.
> >
> > 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.
> >
> > Best,
> > -Karthik
> >
> >
> >> 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]> wrote:
> >> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <[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.)
> >>
> >> Recasting all the post-handshake handshake messages as not something
> named "handshake" does make a degree of sense, on its own. (bikeshedding:
> I'd name it something more descriptive like "secondary negotiation"
> messages or something, though.) Even if this doesn't directly help with the
> issue at hand here, does forking these into a new ContentType sound like a
> useful move, in general?
> >>
> >> I'm not sure what this would accomplish.
> >>
> >> 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.
> >>
> >> David
> >> _______________________________________________
> >> TLS mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tls
> >
> >
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> >
> >
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>