Re: [TLS] Banning implicit CIDs in DTLS

Martin Thomson <mt@lowentropy.net> Thu, 21 May 2020 23:49 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 E62073A0D1C for <tls@ietfa.amsl.com>; Thu, 21 May 2020 16:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=CcI6RZv5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OyfCHVSj
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 SowaJjnuCHPZ for <tls@ietfa.amsl.com>; Thu, 21 May 2020 16:49:34 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026AA3A0D1A for <tls@ietf.org>; Thu, 21 May 2020 16:49:33 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 015705C00E7 for <tls@ietf.org>; Thu, 21 May 2020 19:49:33 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Thu, 21 May 2020 19:49:33 -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; 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= messagingengine.com; 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: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-487-g38013f6-fm-20200519.001-g38013f6c
Mime-Version: 1.0
Message-Id: <c54e40c9-38a6-4870-8513-312d8fbe37d3@www.fastmail.com>
In-Reply-To: <df70e06b-ffdf-4402-b640-d99b2aafac6b@www.fastmail.com>
References: <df70e06b-ffdf-4402-b640-d99b2aafac6b@www.fastmail.com>
Date: Fri, 22 May 2020 09:49:14 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/r4fUGVEYxYCvl-xak8H6TJhb5MI>
Subject: Re: [TLS] Banning implicit CIDs in DTLS
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: 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.