Re: [TLS] WGLC for draft-ietf-tls-dtls-connection-id-06

"Martin Thomson" <> Wed, 17 July 2019 15:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50BE2120758 for <>; Wed, 17 Jul 2019 08:33:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=eepVbRL7; dkim=pass (2048-bit key) header.b=nLYhP6NQ
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dxoCORqyA_Dv for <>; Wed, 17 Jul 2019 08:33:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 344C612008B for <>; Wed, 17 Jul 2019 08:33:19 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailnew.nyi.internal (Postfix) with ESMTP id 3C1D5231F for <>; Wed, 17 Jul 2019 11:33:10 -0400 (EDT)
Received: from imap2 ([]) by compute1.internal (MEProxy); Wed, 17 Jul 2019 11:33:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=AGMEy8KBqSZoV3+cPqA8sIJPU3QIuwV Ohi2uJarFBxU=; b=eepVbRL7VZeq8/PkbFnIAC15pzkeqBcYKUTqVxz2Tgfw9jb wAYHmHr24Rbtpuw1Z6X4E1reOupex9KKEcPcdmUJZXf/dWxtl2pmDPLJxugBv/Aa IceeoSYms0MSouhlgqB5xrN17YOL+J9hTWbXkBPpzovzNH26te6dAbB1tkuER9ja /w1fqrZ+wnWHctLSk2b37/XPnidhmrJ0DT6AFokjfMKmtWghVsepSiq1zBrXaNRU v/SUOqngpFSnUgcoC0RbF9FRKH7F6YvSL268GWlyz8oVXDIhzIwdKDfQnpasgSiq TA8QZWPrhL6lLN6PyIl18RF1aymmGwR1e+a7yqQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=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=fm3; bh=AGMEy8 KBqSZoV3+cPqA8sIJPU3QIuwVOhi2uJarFBxU=; b=nLYhP6NQG2sjzD8uBXBEQr cSert6XKeedYkRpmtYriQNazPokezVeZp58XxR6V7RJzelPoqL0nCKrsA4HlTzEO m9YbfrNnv0ZFmF/cN80u57uwxlwEFBliY3q2/L8cZGVyr8P+QMRvwt1WI5k7Obv0 oDVRzKBz9U2SBk6AvHphH1xZJuET0sQkF+rTq8Ak97KITF/GkcrittYD9/lsD1+j c+lykHS6TETuoOEzN69cnP/ooKCWuqFwR0YZmNvapZxLzdb6HThKQRGdINDdU/Q8 ov24enntFG2JmDk54LQ8lFer6cVxJjb7PeZX3baEMR67vw93JyB2i4wFjmAa/Lqw ==
X-ME-Sender: <xms:tT8vXUdfQaqFco-JdPd9KBUmPJb094-ooooJgG23EdsgU6Is9MmOSA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrieefgdeiiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt
X-ME-Proxy: <xmx:tT8vXRFltg5C1nj5QgWDxyZykI0yoouTeuT82E-33t2geNa-k4Ytbw> <xmx:tT8vXdUOUW9cE9qT1MTDMRXlKbClyohyvabTB1LJDqufPGJo4wIHYA> <xmx:tT8vXYK8HAl7hO63jH1JkBwhnfYZh9tRtbO23B7xxA5GYJmUstP5PQ> <xmx:tj8vXfOWuacCcKBzWSwsqyl_cPnraCBNaE2cc16LwSP8Tk3WEvKb9Q>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 74115E0432; Wed, 17 Jul 2019 11:33:09 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Wed, 17 Jul 2019 11:33:20 -0400
From: "Martin Thomson" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] WGLC for draft-ietf-tls-dtls-connection-id-06
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, 17 Jul 2019 15:33:21 -0000

These changes look fine.  Mostly.

I'm really concerned about shipping a protocol that enables the sorts of attacks that connection IDs enable.  I think that we should discuss that issue when we meet.  I know that Hannes' new draft is an attempt to tackle this issue, but that's a long way from being done.  If we ship a spec with this hole, it will only be usable in certain narrow contexts, like with ICE, where this really isn't a concern anyway.

This is something we are grappling with in QUIC too.  A good design that handles migration to new network paths is non-trivial.  Adding a connection ID is just the smallest and easiest part.  But it leaves the protocol in the worst possible state.  Functionally, you can move to a new path.  And everything works fine, unless you have an attacker.  But without any further defense, you are completely exposed to that attacker, both to the connection being denied service and to being used for amplification attacks.

Nit: Search for "use the with" in the newly added text.

On Mon, Jul 15, 2019, at 13:19, Joseph Salowey wrote:
> This the working group last call for 
> draft-ietf-tls-dtls-connection-id-06. The diff between the version that 
> was last called (-03) and the current version can be found here: 
> Please focus your review on the changes since the previous last call 
> and send comments to the list by July 22, 2019. 
> Thanks,
> C,S & J
> _______________________________________________
> TLS mailing list