From nobody Thu Mar 25 09:51:42 2021 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A8B3A275F; Thu, 25 Mar 2021 09:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQyugXX2jeWB; Thu, 25 Mar 2021 09:51:35 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAACA3A275A; Thu, 25 Mar 2021 09:51:34 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id d2so2657202ilm.10; Thu, 25 Mar 2021 09:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=mpdT2mwb+HUYOtJtgSwRvJNpkCrZsC1jijL0U1d9ZRc=; b=II+kKcktsKsahR3tvNYa3BA0tBnCOGuqLmJkrEnGkX3dRQsDJP89MI+HbuZlJGjPr1 jXfHcrTJJ8G7aZeBRAii89ZerfCdBO/79OApfXiNwCNLD8SPvTmtAuT70iGx+z1Krq7D ktxEtx3aUkto87z4t1JGDV1QQeG3/mxlYufE507p8aonUreAmDIaC6csL6w/vN+c7pfs mF+pL0PBRChWOFtv3JK7ZNU1dKgeghRXsCQdmrpKhDz7J42RyzVIpP87z6Shgj+h7zOF l08jJPpwhARAa0ofuExbSwjJI/rvqG/BwJVnIqA3Itjx1JNhSfPeIH3bWIUoTL12Aukc v0Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mpdT2mwb+HUYOtJtgSwRvJNpkCrZsC1jijL0U1d9ZRc=; b=TYKAeH+pD0opx8Vjz7qb7J9cFF/Woghcf4y35pSpDOkfXaWXE90mXKSPJ1XQ3iA8wY 9zlP/bXCT1gjjkMLm0Z2Jptxbrb0BIZ8VualjhJukvkiMp/Cc0t/9MJLduv+OC8FGuR4 my0HLrDJcRPWWoc7eJICHSa+I8yKFjRI2+02dqm0t5ErZLmW1LG/4iduv4mBMVyNZgF6 dBtUiBSwRI4/diY+L6/mSbCKliBZ1FdVSfWj+13qXoViIAms3iPwQfN20JXmHvqcN97A 0iiJ0RkZdI8HgclCKwAVRrn7Kj52BHRTYiwUO1eJ8RAUkzwWVA1RJzc9gYh46hgmSj91 MNng== X-Gm-Message-State: AOAM53148KzDy35GWFlLpkWXrK0rlRoD7PfAmLLUYqpGqHjfg4QpI9Et N/nhRvqT5cZLDCdOVnV8p+DOo9m8ZXzjpgVIXw8YFxT7sg2bAQ== X-Google-Smtp-Source: ABdhPJy0gDbCwi21dAzjRRzp4fqOzNicKdjmggO+h1zhG+0pr+3Wh/0XqYkCDUIxGNJXf/JqicduhzdleSllfWo9JyU= X-Received: by 2002:a92:ca4b:: with SMTP id q11mr7570063ilo.272.1616691093283; Thu, 25 Mar 2021 09:51:33 -0700 (PDT) MIME-Version: 1.0 From: Martin Duke Date: Thu, 25 Mar 2021 09:51:23 -0700 Message-ID: To: draft-ietf-tls-dtls13.all@ietf.org, Mark Allman , Lars Eggert , Gorry Fairhurst , "" Content-Type: multipart/alternative; boundary="00000000000053b05b05be5f3a6d" Archived-At: Subject: [TLS] Transport Issues in DTLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 16:51:40 -0000 --00000000000053b05b05be5f3a6d Content-Type: text/plain; charset="UTF-8" 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 ), Mark Allman (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 --00000000000053b05b05be5f3a6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

The outcome of th= e telechat was that I agreed to start a thread on how to fix the significan= t transport issues with the DTLS 1.3 draft. If I am correct, there was no e= arly TCPM or TSVWG review. A major protocol with significant transport-laye= r 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), Mark Allman (<= a href=3D"https://datatracker.ietf.org/doc/rfc8961/">RFC8961), and Gorr= y Fairhurst (also RFC8085).=20 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 advertisi= ng this thread to the TCPM and TSVWG working groups, I can do so, at the ri= sk of introducing more ancillary document churn.

Suggested plan:

Anyway, as a first s= tep 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. I= f there are non-kosher things that DTLS 1.2 has done with no observable pro= blems, 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 t= hese things right.

Thanks,
Martin Du= ke
Transport AD
--00000000000053b05b05be5f3a6d--