We would like to have all comments in on this by Friday, July 7, 2016. Also, to clarify, Hugo's interpretation is correct:
Option 1 - use the same key for protecting both *post*-handshake and applications messages. On Thu, Jul 7, 2016 at 2:44 AM, 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
