Re: [TLS] DTLS 1.3

[Ilari Liusvaara <[e-mail]>]

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