DTLS concerns

[thomwiggers]

Ilari writes:

Reading the draft, it occurs to me that adapting it to work on DTLS (or unreliable CTLS) might require major and very challenging changes to DTLS 1.3. Especially with client authentication.

And 0-RTT client auth probably can not work in DTLS at all, since DTLS has no reliability for 0-RTT, unlike other handshake, which is reliable.

[thomwiggers]

From another message by Ilari:

Actually, the changes might not be quite so nasty:

• The DTLS epoch numbering needs to be changed: If AuthKEM is used,
  then epoch 3 needs to be autheticated_handshake epoch instead of
  application_0 epoch, which is pushed to epoch 4 and then that pushes
  other application epoch one number forward.

• Fortunately even if there are 5 active epochs during handshake,
  the 2 bits in DTLS header are still enough, because one of those is
  plaintext, and can be recognized from record types used.

• There actually might be chance to make the early auth work. However,
  there are subtle details:

  • The certificate being a message, it is subject to acknowledgements.
    However, server hello must be logically before it. This is required
    to meet the acknowledgment epoch rule.
  • The server flight needs to be broken into two just before server
    Finished, first part being unordered with certificate, and second
    being the next flight. This is required to have the certificate
    available for computing finished, and to meet the implicit
    acknowledgment rule.