IETF Logo Mail Archive

Re: [TLS] Martin Duke's Discuss on draft-ietf-tls-dtls13-41: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 01 April 2021 04:38 UTC

Return-Path: <kaduk@mit.edu>
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 4EDF73A4098; Wed, 31 Mar 2021 21:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 qXaXhd8mFVrj; Wed, 31 Mar 2021 21:38:00 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595B53A40AD; Wed, 31 Mar 2021 21:37:56 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1314bnmI029277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 1 Apr 2021 00:37:52 -0400
Date: Wed, 31 Mar 2021 21:37:49 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Martin Duke <martin.h.duke@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tls-dtls13@ietf.org, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org
Message-ID: <20210401043702.GS79563@kduck.mit.edu>
References: <161662211946.14722.10506888699753198221@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <161662211946.14722.10506888699753198221@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/99jsCEmqtaJkR2z8nkA2fbcOfZk>
Subject: Re: [TLS] Martin Duke's Discuss on draft-ietf-tls-dtls13-41: (with DISCUSS and COMMENT)
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2021 04:38:09 -0000

Hi Martin,

Thanks for starting the separate thread to cover the transport topics.

I'll trim heavily to call out one topic that might benefit from some
attention from the working group...

On Wed, Mar 24, 2021 at 02:42:00PM -0700, Martin Duke via Datatracker wrote:
> 
> Finally, a really weird one. Reading this document and references to connection
> ID prompted to me to think how QUIC-LB could apply to DTLS. The result is here:
> https://github.com/quicwg/load-balancers/pull/106/files. Please note the rather
> unfortunate third-to-last paragraph. I'm happy to take the answer that this use
> case doesn't matter, since I made it up today. But if it does, it would be very
> helpful if (1) DTLS 1.3 clients MUST include a connection_id extension in their
> ClientHello, even if zero length, and/or (2) this draft updated 4.1.4 of 8446
> to allow the server to include connection_id in HelloRetryRequest even if the
> client didn't offer it. Thoughts?

(To over-summarize: the proposal to make connection_id mandatory in DTLS
1.3 ClientHello is an attempt to support the case where a single load
balancer fronts for both DTLS 1.3 and QUIC servers and connection IDs are
required.  If the client does not send the extension in this case the
DTLS server is toast and will not get its packets reliably.)

-Ben

v2.23.0 | Report a Bug | By Email