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 <dsteb...@gmail.com> 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 <h...@ee.technion.ac.il> > 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 < > karthik.bharga...@gmail.com> 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 <david...@chromium.org> wrote: > >> > >> On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <e...@rtfm.com> wrote: > >> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <davemgarr...@gmail.com> > 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 > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
