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
