Re: [TLS] Integrity bounds in DTLS

Martin Thomson <> Mon, 18 May 2020 00:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB44F3A00C9 for <>; Sun, 17 May 2020 17:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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=aVTEPFsX; dkim=pass (2048-bit key) header.b=M0/TSjtf
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F3J6WFCYJKKq for <>; Sun, 17 May 2020 17:47:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8AEB13A00C3 for <>; Sun, 17 May 2020 17:47:10 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id ADBAB5C00D5; Sun, 17 May 2020 20:47:09 -0400 (EDT)
Received: from imap2 ([]) by compute2.internal (MEProxy); Sun, 17 May 2020 20:47:09 -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=WFFFm+2KqbOuEYbVMGVVp2vN+AUAjR8 VOTmQgkOlrRY=; b=aVTEPFsXT6JyoKQiruPNIO6RR9bnVVeEyN1G9ttFLorIbFo JOu/NzDfk4CrjwHz8l9lwCt0i7vagPi64DGOHZhZt/gHrxECtDBsz0qGpf6e7NF5 xHSZHCEQXSr2pVHOqZ4yXtDqh/0QLXmmdinJ+PrvIoDXxHm0LkjU/Mb/SzCcvvDh P6aT0CH94RKjaY8Ky95SSvPm1icdZBlU1fL8M/900C2CFMTWHSx9Bl487IRPam1e 6heeJ+eTNI0RQsqU1PY1GBxx+Nsbsf3qa8a4C86EfYjUKZeA63PLkjc6w3xjAQbl uo/bcOOnTWD5Ib2zt7MO7jARV1I/cM16K5w+OCA==
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=WFFFm+ 2KqbOuEYbVMGVVp2vN+AUAjR8VOTmQgkOlrRY=; b=M0/TSjtfuD2LUnAMFIxNU6 /yLn3x2Hfq/ybtqS4NMLFhYiIdGYzSKysrgcGBZiQiH6D+GTO/GddWZwlkeqqhEG IfBmpETcb/X91OWb7hSzdlTe2rDErfJZraNI19JxUrxdVP83Faj8JNIzDY6O0uzL Z7TR9/tE0YNjwmHPjL6We6Nys+LfWVCjHTXLYmm4RFy7w6qaTRe1cki7QTpSZGp6 Cz62Mk8CEKGAPP4N1XfM87GS4eqoouKIReL4O+BPAVAqlx8YG6CR/gcjGg523yyh juK32t9hOlR6lXBZGqKIBj/EGBRFNg4RLHI//E8hpSiyajD2ZYzf1d953EHQX1Qw ==
X-ME-Sender: <xms:DdvBXv0pjadvGGG0y8Q-Sb9IcP-AGjjQrmEW2gD-5H3Y3wfJqt_xLg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddtgedgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepkeetueeikedtkeelfeekvefhkeffvedvvefgkefgleeugfdvjeej geffieegtdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:DdvBXuFKBo4kLE_ZjzBqV55U9SJmd0jYjNrPAaVgMYH2z0WWWy9EFg> <xmx:DdvBXv5fwDwmLJW1IW0OiRfKIT3yfFCvJz0O01kZ5sl-58RC4J3TtA> <xmx:DdvBXk1_MrsrWxwJfWPthCRVCBW8B4-WpDc9rJAFtQlR1Y7loe972A> <xmx:DdvBXmT3JwdysJpLx1wX1hre11zEyPk4fSdu04u_Ce6CA1vNxkiBmQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 35343E00B3; Sun, 17 May 2020 20:47:09 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 18 May 2020 10:46:51 +1000
From: Martin Thomson <>
To: Thomas Fossati <>, "" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] Integrity bounds 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: Mon, 18 May 2020 00:47:12 -0000

On Fri, May 15, 2020, at 20:29, Thomas Fossati wrote:
> While the specific behaviours might more or less differ, the same
> considerations apply to 1.2.  How do we make sure that the message
> doesn't get ignored?  Would it be worth drafting this separately to
> cover both versions (+ an explicit "Updates: 6347" label)?

We're already marking TLS 1.2 obsolete with this, so I don't think that labels are going to change.

The question is whether it is clear that these limits apply to the use of AEADs in TLS more generally.  I think that is clear enough, but I doubt that people will pay any mind unless they are implementing TLS 1.3.

The problem with TLS 1.2 is that there is no option for key updates, unless you count renegotiation, which is often disabled.  When I added limits to NSS, all I could reliably do was make the connection terminate if the limit was hit (which is why the limits used are larger than advised in the spec).