Re: [TLS] Éric Vyncke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Mon, 19 April 2021 16:33 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 4B3793A39C0; Mon, 19 Apr 2021 09:33:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level:
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[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 YcYjI5c80elv; Mon, 19 Apr 2021 09:32:56 -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 862433A39BB; Mon, 19 Apr 2021 09:32: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 13JGWlCV027621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Apr 2021 12:32:52 -0400
Date: Mon, 19 Apr 2021 09:32:46 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Éric Vyncke <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, tls@ietf.org, joe@salowey.net, draft-ietf-tls-dtls-connection-id@ietf.org, tls-chairs@ietf.org
Message-ID: <20210419163246.GM79563@kduck.mit.edu>
References: <161881847125.7764.5253050405833557836@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <161881847125.7764.5253050405833557836@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FTUNChDaZW8W4juI9WPgel5bF7s>
Subject: Re: [TLS] Éric Vyncke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with 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: Mon, 19 Apr 2021 16:33:01 -0000

Hi Éric,

Trimming heavily, as several other responses have landed already...

On Mon, Apr 19, 2021 at 12:47:51AM -0700, Éric Vyncke via Datatracker wrote:
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> -- Section 3 --
> While I am not a DTLS expert, I find this section quite difficult to understand
> the reasoning behind the specification as little explanations are given about,
> e.g, what is the motivation of "A zero-length value indicates that the server
> will send with the client's CID but does not wish the client to include a CID."

We had a lot of discussion in the WG about zero-length CIDs and the various
edge cases that can arise.  (You might imagine, for example, wanting to use
the new record format and get content-type confidentiality even when a CID
is not needed for routing messages.)  We ended up concluding that it's
simpler and safer to do what's described now -- no CID means the RFC 6347
record format.  But the discussion in the document may not have captured
the full extent of the WG discussion, so we can take a look at whether
there is more to be said.

The short answer is that this is a typical mechanism where each part tells
the other how to contact them, but in order to confirm the negotiation to
use the feature, we need a signal for "I don't need a CID but I support
CIDs", and the zero-length field in the handshake packets plays that role
quite naturally.

-Ben