On Thu, Jul 7, 2016 at 6:44 AM, Hugo Krawczyk <[email protected]> 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. > Here is the promised posted paper http://eprint.iacr.org/2016/711 " A Unilateral-to-Mutual Authentication Compiler for Key Exchange (with Applications to Client Authentication in TLS 1.3) " Its analysis of client authentication is relevant to the different modes of TLS 1.3 and, in particular, to post-handshake authentication. As said above, the results support the use of the application key to encrypt the post-handshake messages, hence avoiding the need to use a dedicated key for this and the consequent need for trial decryption (or related techniques). Comments on and off list are welcome. Hugo > > Hugo > > > On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan < > [email protected]> 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 <[email protected]> wrote: >> >> On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <[email protected]> wrote: >> >>> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <[email protected]> >>> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls >> >> >> >> _______________________________________________ >> TLS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls >> >> >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
