On Mon, Jul 04, 2016 at 09:45:38PM +0200, Hannes Tschofenig wrote: > Hi Ilari, > > thanks for your super quick response. > > On 07/04/2016 04:03 PM, Ilari Liusvaara wrote: > > 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)? > > For the record layer TLS 1.3 says that the version field is deprecated > and ignored. I guess the same approach applies to DTLS 1.3. So, it > probably doesn't matter what is really is. In DTLS 1.2 the version value > was 254.253.
Oh, it was that. Then I presume DTLS 1.0 was 254,255 (yup, checked the RFC). > For the client_version and server_version in the handshake I thought it > would be fine to just re-use the TLS 1.3 version number. I think that is not a good idea, and one should follow the pattern (which would give 254,252 for ClientHello/ServerHello). But for record version, reusing previous versions (either 254,255 or 254,253) should be fine. > > - KeyUpdate does not work in DTLS. Might just use epochs for similar > > purpose, and reserve first few epochs for special purposes. > > Could you explain in more detail why you think a key update does not > work with DTLS? That message is not idempotent (nor has it timely ACK). > > - The full handshake protocol is only run once. After that, there's > > only rekeying, new tickets and dynamic reauth. > > How TLS 1.3/DTLS 1.3 is used in specific environments remains to be seen. Well, certainly the main handshake only runs once per connection. > > - 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!) > > Regarding the issue of where to send the cookie in the ClientHello there > are two options. The first option is to use the cookie extension, and > the second option is to use the DTLS 1.2 style where the cookie is > placed in the ClientHello directly (without using an extension). > > My (weak) preference is to use the cookie extension also in the > ClientHello. My main reason was the length mismatch between the DTLS 1.2 > cookie extension (which is now in the legacy_cookie filed) and the > cookie extension. The cookie extension has a max length of 2^16-1 bytes > and the legacy_cookie extension only 2^8-1 bytes long. If the design of > the ClientHello uses the legacy_cookie extension then the server has to > take care that the cookie size does not exceed the 2^8-1 bytes. I think the obvious way is: - Cookies from HelloVerifyRequest go to legacy cookie field. - Cookies from HelloRetryRequest go to extension cookie field. If you don't do the first, you can't downnegotiate successfully. And if you don't do the second, you would have to have special case with cookie sizes (since HRR can transmit >255 byte cookie, which would be too big for legacy cookie). > > - If handshake is rejected using HelloRetryRequest, according to > > the TLS 1.3 rules, the first ClientHello and HelloRetryRequest > > ARE included in handshake hashes. > > Fixed it but I am not sure that's a good idea unless the cookie carries > that state information. With 255 bytes that's going to be difficult... Well, it can be larger than 255 bytes. And barring client sending large 0-RTT context (what are those anyway???), one can fit it into very few bytes (<16 should be possible with blank context). > > - 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... > > Are you referring to the version field? Yeah, CH/SH version field. And DTLS was FEFD... > > - 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. > > That's certainly something to take a closer look at. I haven't > implemented that part yet .... Yeah, I haven't really taken a closer look at it either... > > - The handshake retransmit scheme doesn't seem to work that > > well with post-handshake auth, and even less well with > > session tickets. > Why do you think so? Of course, unreliable transports creates > inconvenience; is it that what you are referring to? DTLS assumes handshake messages are reliable, and that reliability is implemented via handshake messages ACKing one another. - Session tickets have no ACK at all. - CertificateRequest can have very slow ACK. - KeyUpdate has no real ACK (and isn't idempotent either). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
