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 > <mailto:e...@rtfm.com>> wrote: > On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <davemgarr...@gmail.com > <mailto: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
