Re: [TLS] Integrity bounds in DTLS

Martin Thomson <mt@lowentropy.net> Thu, 07 May 2020 07:12 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 EFB8E3A097D for <tls@ietfa.amsl.com>; Thu, 7 May 2020 00:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, 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=BL5XipC3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uBfGJeP9
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 xL6yo21c5QDR for <tls@ietfa.amsl.com>; Thu, 7 May 2020 00:12:26 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198553A0936 for <tls@ietf.org>; Thu, 7 May 2020 00:12:25 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6F0395C0134 for <tls@ietf.org>; Thu, 7 May 2020 03:12:24 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Thu, 07 May 2020 03:12:24 -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=duGwq 7GLMVBGCl3SHXXok/zHcZGHmuAf8HdKxKi9uSo=; b=BL5XipC3rgdog+o9Of9cS FjBtdIBuUShq/Qan+3XNE5MQmEKTY7lpaQU99y53gjrApKYgOC1OWCK2n9DBZ3iY XW147VgvU9DcDPshMu2vRL4Cn1trDX0sJLXvhgIVulhbDM56GwqhLxOVYFVZJaFf Hsr0YjJQVxsqcrrpcZ2s1JcgPsh76agBNdilkEdC9vWK22pvrIQBYwXAEW4CK8FR iwQEKJk13lqH8QgPDORHuzB0tZmpsQSR8Zq6xXjJG1hS0Re4Co7qwpNzIPogm+KH Tp7PXj02z2oNbJeIxh31fBAh5hHUENFGprih3uX0Qd9EU2DTZWHUtP6rBsKwV6nx A==
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=duGwq7GLMVBGCl3SHXXok/zHcZGHmuAf8HdKxKi9u So=; b=uBfGJeP9f1qt4MTBUI3LEs0tNDY2WPmp2ZJ0UGfrnHJwXji8t9C1gm9aJ BPtvIGkfIw9QWCyAi+hRszElDcJIXOZ3XWq0wo5L/i/XZRZM1eIAiBSIQTuAaHUY zdq/eUJ5OLBpy6Wyo5jXg8ZBFyz8yiK+J/AwFN9z71JI/BbPqB1pqJ69+ix8yKKw W8wb+MKZB7FHDq9wPtTffA5Cq63Ot3He/L2QpJYgI/v+ooB+kmGN4TxH9MDTB2Ir GtWFegsUEaN84lagIltsbtE8eRcMs9jvp80W+qoyUZQxZFlYDSdjGrwKlmhdwU22 CMyGs+KxIjS+eMn4/GkmgDIBV/WxQ==
X-ME-Sender: <xms:2LSzXhOpNA7UOsT7HCG5j04haoW6Lw5au8KYf6yVHDB0nwS3SiJyRg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeelgdduudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepjefhffelheevudefje efvddvhfdvieetudehueffudevudeugeelfeffffelvdefnecuffhomhgrihhnpehgihht hhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:2LSzXsLLho7Q5m479MM15lUolaf7-CCE0R2jriYd5Em-K1qVAjpHSw> <xmx:2LSzXmL87PKv-lpHD6c5_KGhOnqunD0kFasijr1QhO3imT0iuFsd-Q> <xmx:2LSzXmyA0aIa_fb66IRQyiUrCF3SjD7ueHYcar-xhgmPmCOgozaZUg> <xmx:2LSzXjuwFyM8-q18GzB4cNtlgYcmxy0RINJ5jCPq1HEWMXfZWt8SGg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0B347E00A9; Thu, 7 May 2020 03:12:24 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: <cb6dab6a-54dc-484d-80a4-ec16a25fcdea@www.fastmail.com>
In-Reply-To: <0a9e740f-c20a-4def-9a61-d256cbcbf07c@www.fastmail.com>
References: <0a9e740f-c20a-4def-9a61-d256cbcbf07c@www.fastmail.com>
Date: Thu, 07 May 2020 17:12:04 +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/ffXsrXAwp1LJ5oli65aF-cQ3bBQ>
Subject: Re: [TLS] Integrity bounds 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, 07 May 2020 07:12:29 -0000

On Fri, May 1, 2020, at 14:51, Martin Thomson wrote:
> Thanks to some good work from Felix Günther, Marc Fischlin, Christian 
> Janson, and Kenny Paterson we now have a new result to share about the 
> integrity limits in QUIC.
> 
> There is a long write-up in 
> https://github.com/quicwg/base-drafts/issues/3619, the conclusion of 
> which is that endpoints need to count the number of failed decryptions 
> and stop using keys once a certain limit is reached.  Key updates can 
> be used to avoid this.
> 
> The same concern applies to DTLS.  I believe that the same solution - 
> or at least a similar solution - is therefore necessary for DTLS.
> 
> I know that we're past WGLC, but this is an important result regarding 
> a key distinction between TLS and DTLS.

News here is that we resolved some issues with AEAD_AES_128_CCM.

For TLS, we need to resolve what to do with AEAD_AES_128_CCM_8.  For those who don't want to read a long issue, the number of forgery attempts permitted has to be less than 2^6 to keep the same bounds as other ciphers.  That's not very useful.  TLS_AES_128_CCM_8_SHA256 is already a non-recommended cipher, so we're good there.  But it might still be good to have some parameters for it, even if it is guarded with some warning labels about differences in security margins.