Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc: redux

Martin Thomson <mt@lowentropy.net> Wed, 05 May 2021 02:53 UTC

Return-Path: <mt@lowentropy.net>
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 BCC2F3A2099 for <tls@ietfa.amsl.com>; Tue, 4 May 2021 19:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=lowentropy.net header.b=gOWgdUqN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mmgdH3uR
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 ddU74ldyo4so for <tls@ietfa.amsl.com>; Tue, 4 May 2021 19:53:13 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7CB3A2096 for <tls@ietf.org>; Tue, 4 May 2021 19:53:13 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7F85E5C00C8 for <tls@ietf.org>; Tue, 4 May 2021 22:53:11 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 04 May 2021 22:53:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=BUaaU CXpJHaReAdIJJyKwRN30xHD3gxR294mnpwSjzU=; b=gOWgdUqNk0xLKtLuYA3vD Ok8qm6iIr9OfRkFevLobfyvd14jRP4r4JbVlwQX5c5T0xrQt5EaYEJRAHovk+qiV wo8B6YQv0ZgaZUw3zAwCBfpAdR+pwyIqVVL88Jft+7lnzhmsKftYZvA0PT9LT5s+ EPErbqIKI9LE9fTfyz4zibS2T8GnZ9H1EBS4qqWbBHqdfI7HTsun76IDhK2iag2z NRZxUqQZu0H73t84tJRBz8BkRx00zoi2wvBT1Hm1NSaBqYjfAfUZJRPayFxHLhxz E3LHJu+8PRGrRxWDUeL184IbIGqu9YjyhEJ9IHwczYQVng47FVLAFYmbCVJXzWMK w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=BUaaUCXpJHaReAdIJJyKwRN30xHD3gxR294mnpwSj zU=; b=mmgdH3uRnXsKVsOz6GkEaQyzezT9D3Ac7Ihf3Oabr5y4bubbOQnWuJ1kN cr7fNxU4Pt524tFlrhNRaWSIlIcaGZ3+8ajt2PZXk1k62jONL2iBj+iOmx0nIgBk +Rq+IjOH5S8TE9HcjWP7ZOQQJ0YVEupdvVeS80pSnkVhkHZR7w8HJtESSoirWvB6 nhfEetHHX68YS9RdMylcnImpJyllkZoU4APtM9/cd/z8zlkb0mkv8j3P39xoPIJO zYsUANhis5O9gfMapuljCH+7i+Eya3/IKf3NLSjA3or6g66YQNTaDuCanePACx05 /ES+5n5zCfS7UOsr5Nzs9hS+UXImg==
X-ME-Sender: <xms:lwiSYH-2Z_oQzAKtX-xflJT9r3Oeu_zrAHMLDSAzyBsyIgcedzlNmQ> <xme:lwiSYDvqKHN_X8CX3yZOc6q--rfOZkugD7yrAa-WuODpRla7jmAuCdUIfHVAI-4i8 qfxGV1XGzK1fOeNaJM>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefjedgheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepffetgfevvdfhtdffhe ejudefhffhveehudefhffgleelteeifeegfefggfelhefgnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:lwiSYFAVodotguYhb2mwhs6vA1AVanVSUjcmkEr2FED6QTTVhWzebw> <xmx:lwiSYDdfXxor90mUic96Y_GGyL3Wz2ajt_Il7AEcqUOcYifXK4e-Ag> <xmx:lwiSYMO4Hp-v90WC8MgijKNA4Dt5DV9UvKsP4ImHNhhS86mlUtbV5g> <xmx:lwiSYCbSYn90ywhk5bYAnUAsSV0RnlYd1CRGB8EG0Z2UV7e4oeiSnw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 13DE04E00C7; Tue, 4 May 2021 22:53:11 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-442-g5daca166b9-fm-20210428.001-g5daca166
Mime-Version: 1.0
Message-Id: <854eeedf-d985-4a34-a9c8-389c40e034ec@www.fastmail.com>
In-Reply-To: <812F61D4-F16F-4AA3-9B7E-C60AAFEBF5A1@vigilsec.com>
References: <38D6F960-5D8D-4D66-AA75-91FA34CB93ED@sn3rd.com> <812F61D4-F16F-4AA3-9B7E-C60AAFEBF5A1@vigilsec.com>
Date: Wed, 05 May 2021 12:52:52 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OHTt9HnhoPMlXM7ty-92wI_3DDc>
Subject: Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc: redux
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: Wed, 05 May 2021 02:53:18 -0000

What Russ said here is important.  However, I don't see any reason that this record should not be protected.

I also think that we can use a content type outside of the scarce range we have for TLS record content types.  This only makes sense for use with DTLS 1.3 and DTLS 1.2 with connection IDs, so we can rely on the content type being encrypted.  That means multiplexing constraints don't apply (they probably wouldn't anyway as this makes no sense for use with ICE).

Finally, I think that the flexible size of the cookie is not necessary.  Pick a fixed size.  Unlike the handshake cookie, there is no reason for this to be stateless.  (I also wouldn't call it a cookie.)

The comments that Martin Duke currently has on the connection ID regarding path validation rules apply more fully here than they do on that draft.  Perhaps we could fix them here.

On Wed, May 5, 2021, at 04:12, Russ Housley wrote:
> This document seems fine to me, but the first paragraph of Section 3 
> needs some work.  This can be sorted out after adoption.
> 
> Section 3 begins with:
> 
>    When a record with CID is received that has the source address of the
>    enclosing UDP datagram different from the one previously associated
>    with that CID, the receiver MUST NOT update its view of the peer's IP
>    address and port number with the source specified in the UDP datagram
>    before cryptographically validating the enclosed record(s) but
>    instead perform a return routability check.
> 
> I agree that the return routability check should be performed before 
> updating the peer's IP address and port number, but I the part about 
> "before cryptographically validating the enclosed record" seems to open 
> up some opportunities for trouble.
> 
> Russ
> 
> 
> > On May 3, 2021, at 11:44 AM, Sean Turner <sean@sn3rd.com> wrote:
> > 
> > Hi!
> > 
> > We would like to re-run the WG adoption call for "Return Routability Check for DTLS 1.2 and DTLS 1.3”. Please state whether you support adoption of this draft as a WG item by posting a message to the TLS list by 2359 UTC 24 May 2021.  Please include any additional information that is helpful in understanding your position.
> > 
> > NOTES:
> > 
> > 1) We are re-running this WG adoption now that DTLS 1.3 [1] and Connection Identifiers for DTLS 1.2 [2] is done.
> > 2) Here is a link to the original WG adoption call [3].
> > 
> > Thanks,
> > Chris, Joe, and Sean
> > 
> > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/
> > [2] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
> > [3] https://mailarchive.ietf.org/arch/msg/tls/IJYqpTmSHsCkiMaUPt_AltvKbe8/
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>