From nobody Tue May 4 19:53:19 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 BCC2F3A2099 for ; 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 ; 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 ; 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 ; 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: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefjedgheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepffetgfevvdfhtdffhe ejudefhffhveehudefhffgleelteeifeegfefggfelhefgnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: 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" To: tls@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wit= h DTLS 1.3 and DTLS 1.2 with connection IDs, so we can rely on the conte= nt type being encrypted. That means multiplexing constraints don't appl= y (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 regardi= ng path validation rules apply more fully here than they do on that draf= t. 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=20= > needs some work. This can be sorted out after adoption. >=20 > Section 3 begins with: >=20 > When a record with CID is received that has the source address of t= he > 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 datagr= am > before cryptographically validating the enclosed record(s) but > instead perform a return routability check. >=20 > I agree that the return routability check should be performed before=20= > updating the peer's IP address and port number, but I the part about=20= > "before cryptographically validating the enclosed record" seems to ope= n=20 > up some opportunities for trouble. >=20 > Russ >=20 >=20 > > On May 3, 2021, at 11:44 AM, Sean Turner wrote: > >=20 > > Hi! > >=20 > > We would like to re-run the WG adoption call for "Return Routability= Check for DTLS 1.2 and DTLS 1.3=E2=80=9D. Please state whether you supp= ort 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. > >=20 > > NOTES: > >=20 > > 1) We are re-running this WG adoption now that DTLS 1.3 [1] and Conn= ection Identifiers for DTLS 1.2 [2] is done. > > 2) Here is a link to the original WG adoption call [3]. > >=20 > > Thanks, > > Chris, Joe, and Sean > >=20 > > [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_Alt= vKbe8/ > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20