On Wed, Jul 06, 2016 at 09:25:15PM +0200, Hannes Tschofenig wrote: > > > > Being part of regular handshake is problematic, since those are assumed > > to be tickets, and as such one needs the dynamic PSK key. But the dynamic > > PSK key includes the entiere handshake up to Client Finished. And this > > can't really be changed (or things start going badly wrong). > > > > So the minimum time to send some tickets is 4th flight, whereas normal > > handshake is only 3 flights. > > Was just an idea. The TLS 1.2 ticket mechanism was also transmitted > during the handshake.
The TLS 1.2 ticket mechanism actually did nasty things to forward secrecy. In TLS 1.2, the ticket happens to be in 4th flight after Client Finished, which avoids most of the problems TLS 1.3 would have with tickets in- handshake. > > Certificate requests have context identifiers... > > I was more thinking about including the HandshakeType to distinguish the > ack for a NewSessionTicket from an ack to a CertificateRequest. Oh yes. I posted a rough sketch of such message, it had a corresponding field... > > I don't think this works, because KeyUpdate is not idempotent (causes > > problems if reply is lost) and worse yet, because of potential desyncs > > with the main data flow (IP packet reordering!). > > Maybe it should be made idempotent... You still have packet reordering even if it is idempotent... -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
