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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
