Re: [TLS] Banning implicit CIDs in DTLS

Martin Thomson <> Thu, 21 May 2020 23:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E62073A0D1C for <>; Thu, 21 May 2020 16:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=CcI6RZv5; dkim=pass (2048-bit key) header.b=OyfCHVSj
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SowaJjnuCHPZ for <>; Thu, 21 May 2020 16:49:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 026AA3A0D1A for <>; Thu, 21 May 2020 16:49:33 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 015705C00E7 for <>; Thu, 21 May 2020 19:49:33 -0400 (EDT)
Received: from imap2 ([]) by compute2.internal (MEProxy); Thu, 21 May 2020 19:49:33 -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=R6qPBGh3oVIWJ1KWyfDC7c310PPXCw7 vG7M6KMcjqqU=; b=CcI6RZv5wEMaZTxC6BBNzUR+7h41IUm7J13+R0VtSM0VFN2 PrxXRQY6SPLyRbkeJrnPUsDUkFK0QwimWkOLIHvCWD/lOFDCTlDG/Kp3N7qcTBO0 zzxhIDN7qCQSV/TjxRhz1HJwYwFLLG70jm9mv1KnddMIzDaQzkiunjOKAqELCMBM s/hgtGY8UyMVQlUbXZ6xUgm2Y/Wg0yq3/Slz8hUYp8w5UslXOVeDSUZrxOZtR2DR FxgqrUqVPjR+WQmmq9AjTz7IdD3ESjujrUZ4e9YTG8qNBYhUbuVzgLvSEDfLEmhU opKJH4DpeDkwiY7cXHyNZve3ZK3yCa0nnPM6BbQ==
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=fm2; bh=R6qPBG h3oVIWJ1KWyfDC7c310PPXCw7vG7M6KMcjqqU=; b=OyfCHVSjGrRNLnFdpj0Q4u ptr2ATEDomXrgQhm0nPMmtGLTri82eQU4+Q6dBnhEaq03eC06HZlX+uQI2C7gwX6 EsR8UgLdswKD7pPP37D6yUF43ucjXkfCceBI1owa+dPcYqoMmXgJgdlj5yXZ40a/ o4HU+zB28X+vD2sTY9LvUFtw5KhFv/9F48+YQEr0JWJICa3mthFqVOkp/bswu1Yh txUoL/xXmn2pbATQzKkAnqNzCv58GxEDhV6my8Auddl8985F80NRiQfsmqJhAydD s+2oQieqwDCyp5eLA7v4yC4rT+WPGG/BPJPbtB1aIipwdfHpdfg1XHaa7LqmaWSQ ==
X-ME-Sender: <xms:jBPHXltJ4eIksQkHhCN79L_pI3_empl43lscADas_-Anv4bDOOtJgA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudduvddgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht
X-ME-Proxy: <xmx:jBPHXucZrtPywFVp2s4sP7MtsplMGJAJW6pyTe9ZMFRmtcAAhD9uqA> <xmx:jBPHXozpurZKHIQPfH4QPpbxkNQtGUCLVvD82ucLtQsUGZkzb1A66Q> <xmx:jBPHXsOkXLWhP8UTvWoR73hbE8i9881BeLOHVpPvgkTGTQwLPcVRxw> <xmx:jBPHXrf4-23_5tNfQPxDDOQqSkJAEzKvEubAROPi94hM5q4vceKmiA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 696F5E00B3; Thu, 21 May 2020 19:49:32 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-487-g38013f6-fm-20200519.001-g38013f6c
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Fri, 22 May 2020 09:49:14 +1000
From: "Martin Thomson" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] Banning implicit CIDs in DTLS
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: Thu, 21 May 2020 23:49:36 -0000

On Fri, May 22, 2020, at 01:58, Christopher Wood wrote:
> PR #148 

I think that this is the right solution to this problem.

> *One proposal to address this is by extending the AAD to include the 
> pseudo-header. However, the chairs feel this is an unnecessary 
> divergence from QUIC.

I'm not sure that we need to concern ourselves with avoiding divergence.  I would instead point to the advantages of only authenticating what is on the wire: with multiple records in a datagram, having to prepend to the AAD means a performance hit of some kind.  Either because you need to pass AAD in two chunks (one for the extra bit, one for the on-the-wire header), which is not commonly supported in APIs, or you need to move or copy stuff around to create a single contiguous AAD.  The result is a small amount of complexity.

I can probably make a case for not including connection ID in the AAD entirely on the basis of it being analogous to IP or port, but unless that was formally verified, I wouldn't want to rely on that. So #148 WFM.  The number of cases where a connection ID can be omitted are vanishingly small anyway.