DTLS v1.3

[randombit]

Holding ticket

[reneme]

Originally posted here, but this ticket is probably more appropriate.

It turns out we have a use case for DTLS 1.3 and will likely start working on an implementation based on the existing TLS 1.3 code. I did a first read-through of RFC 9147 and below are some scratchy notes on what probably has to be done. At this point, we're not ready to provide an exact time frame for this, but it should be measured in months not in years.

TL;DR: We'll probably need alternative implementations or significant extensions of TLS::Record_Layer, TLS::Handshake_Layer, and TLS::Cipher_State. All the higher layers of the protocol, particularly the implementation of the actual handshake messages and the TLS state machines in TLS::[Client/Server]_Impl_13 can probably stay mostly untouched.

• Record Layer

  • Support demux of DTLS records
  • Handling of Epoch and Sequence Number
  • Deprotection of Epoch/SeqNumber (see here)
  • Replay protection via a sliding window per epoch

• Handshake Layer

  • Fragmentation (additional header values + handling of them)
    Note: Transcript hash is calculated from the TLS marshalling (w/o the additional headers)
  • Timeout and Retransmission
    • Handle the retransmission state machine (see RFC 9147 Section 5.8.1)
    • Example: https://www.rfc-editor.org/rfc/rfc9147.html#section-6
    • Probably Handshake_Layer_13 will need to be able to actively create messages (i.e. ACKs)

• Key Management in Cipher_State

  • Explicit cipher state handling (Epochs)
    Out-of-order messages at epoch boundaries requires keeping multiple sets of keys for some period
  • Adopt DTLS-specific HKDF labels

• Handshake Messages and Extensions

  • ClientHello/HelloRetryRequest

    • Add active support of the Cookie extension for DoS protection in the server implementation.
    • Optionally always enforce Hello Retry Request (see also here)

  • Client Hello

    • additionally contains a legacy_cookie field from DTLS 1.2

  • ACK Message

  • Optional? New Post-Handshake Message: RequestConnectionID

  • Optional? New Post-Handshake Message: NewConnectionID

  • Optional? Connection_ID extension

• Misc

  • DTLS 1.3 does not support TLS 1.3 "compatibility mode"

• Additional User API

  • Callbacks to establish and validate ClientHello Cookies
  • Configuration of estimated Path MTU?
  • Retransmission trigger (avoid having timers within Botan)

[reneme]

@atreiber94 and I are starting to work on this. It'll be some time before anything lands of course. We're planning to introduce a new dtls13 module that allows disabling support for DTLS 1.3 at compile time and to centralize DTLS-variants of the internal TLS structures. If it appears sensible, we might -- at some point -- flag this new module as "experimental" and start opening pull requests for integration even before the full implementation is ready to go.

At this point, we don't expect a fully functional implementation to be ready in time for Botan 3.13 but certainly 3.14 is a reasonable goal.

FYI: @randombit

[randombit]

@reneme Great. FYI I have a WIP branch addressing some issues with DTLS 1.2 handshaking (retransmit logic, etc) I'll try to get that up ASAP to minimize conflicts.