On Mon, Jul 04, 2016 at 12:21:22PM +0200, Hannes Tschofenig wrote: > Hi all, > > I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document > and you can find the result at https://github.com/tlswg/tls13-spec/pull/512 > > I have worked on a prototype implementation of DTLS 1.3 and if someone > else has something working by the time of the Hackathon in Berlin please > let me know.
Taking a look: - The version field is described as identical to TLS 1.3 version field. What value is there actually? FCFE (wasn't that how "DTLS 1.0" was encoded on wire)? - Length and payload is is described as identical to version (which seems pretty odd...) - The PR talks about "rehandshake". I believe that concept no longer exists in TLS 1.3. - KeyUpdate does not work in DTLS. Might just use epochs for similar purpose, and reserve first few epochs for special purposes. - One could allow epochs to wrap (sequence number arithmetic). Won't cause nonce reuse due to different keys. - The PMTU section talks about block padding and compression. Neither exists anymore (there is padding, but the minimum expansion is exactly known, e.g. the 30 bytes for most ciphersuites). - The full handshake protocol is only run once. After that, there's only rekeying, new tickets and dynamic reauth. - There's special case with cookies: DTLS 1.3 ClientHello getting rejected with HelloVerifyRequest. I think the correct reaction is for client to send a DTLS 1.3 ClientHello without 0-RTT data, containing the cookie sent now in legacy cookie field (NOT the extension). - According to TLS 1.3 rules, handshakes rejected using HelloRetryRequest use the Cookie extension for cookie transmitback, not the legacy cookie field (the cookie might not even fit into that field!) - If handshake is rejected using HelloRetryRequest, according to the TLS 1.3 rules, the first ClientHello and HelloRetryRequest ARE included in handshake hashes. - Is the DTLS 1.2 written as 0303 on the wire? I seem to remember it would be FCFC (but I could be wrong about that)? If it is not 0303, then DTLS 1.3 is not going to be 0304... - In DTLS, AFAIK 0-RTT appdata is not reliable (but the 0-RTT handshake messages are). This brings all sorts of "fun" with message reordering and loss. - The handshake retransmit scheme doesn't seem to work that well with post-handshake auth, and even less well with session tickets. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
