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. 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. > - Length and payload is is described as identical to version (which > seems pretty odd...) Copy-and-paste mistake. Fixed. > - The PR talks about "rehandshake". I believe that concept no longer > exists in TLS 1.3. Updated the text and referred to the KeyUpdate where applicable. > - 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? > - One could allow epochs to wrap (sequence number arithmetic). Won't > cause nonce reuse due to different keys. I have no preference regarding this issue. > - 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). Deleted sentence you mentioned. > - 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. > - 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. > - 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... > - 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? > - 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 .... > - 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? Ciao Hannes > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
