[TLS] Transport Issues in DTLS 1.3

[Martin Duke <[e-mail]>]

Hello all,

The outcome of the telechat was that I agreed to start a thread on how to
fix the significant transport issues with the DTLS 1.3 draft. If I am
correct, there was no early TCPM or TSVWG review. A major protocol with
significant transport-layer functionality would benefit from such review in
the future.

*Who is in this thread*:

For easy reference, here is my DISCUSS, which goes so far as to express a
straw man design that would come closer to addressing the concerns:
https://mailarchive.ietf.org/arch/msg/tls/3g20CQkKWPGX-BAqfuEagR2ppGY/

Besides TLSWG, I've added Lars (RFC8085
<https://datatracker.ietf.org/doc/rfc8085/>), Mark Allman (RFC8961
<https://datatracker.ietf.org/doc/rfc8961/>), and Gorry Fairhurst (also
RFC8085). Mark and Gorry have already sent me private comments that I
invite them to resend here. To summarize briefly, they amplified my
DISCUSS, made the new point that 8085 is directly relevant here, and are
concerned there aren't enough MUSTs

If people think there would be value in advertising this thread to the TCPM
and TSVWG working groups, I can do so, at the risk of introducing more
ancillary document churn.

*Suggested plan:*

Anyway, as a first step perhaps we can have Mark, Gorry, and Lars add
anything they'd like and then invite the draft authors to either make a
proposal or push back. If there are non-kosher things that DTLS 1.2 has
done with no observable problems, that would be an interesting data point:
within limits, introducing a latency regression into DTLS 1.3 would be
perverse.

DTLS is a very important protocol and it is worth the time to get these
things right.

Thanks,
Martin Duke
Transport AD