Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

Michael D'Errico <> Sat, 10 October 2020 17:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7FA33A0CF2; Sat, 10 Oct 2020 10:29:38 -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=hXcWr2vy; dkim=pass (2048-bit key) header.b=rMaI+u1E
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4Y0E_xJZ5QFZ; Sat, 10 Oct 2020 10:29:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EAEA73A0CF0; Sat, 10 Oct 2020 10:29:36 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 6CCB35C00EE; Sat, 10 Oct 2020 13:29:35 -0400 (EDT)
Received: from imap21 ([]) by compute4.internal (MEProxy); Sat, 10 Oct 2020 13:29:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=i2A+mfwYiuRX3iZqYhr3tz7FzuBoaDV fLNjofzW8/Xk=; b=hXcWr2vyRrUrozFcASbUmHICtyPq/q6JWCfmlXzBdVD/vmW 1hNJfx+JWQTbhxWNZZOa+CccHIyet46L3sAVUIZPt2EaXnFjCjyV2yrDD/RiVxj3 6CrcG8CV/7c5dZ1Kq/D4FOpZbk9ylVbUnuYemxxHgYYPl0FOGjeB06zh98rZ8L6/ 1pnxJ3kAVO8QUu1M2dBbmfq1uwTfIcRzqXIn9F2iUxQJJ9IuSnoKJI1sTZHZrPe2 u3ItZ3RPyabtjePbuKxuvY5zKyl72fNqR5NFWYcpaII9EDeEUCGYfEnqXG56SPO2 XBuBJhJiwNrpCuRgzNN4rw11aSsFzgvIMjZTPLw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc: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=fm1; bh=i2A+mf wYiuRX3iZqYhr3tz7FzuBoaDVfLNjofzW8/Xk=; b=rMaI+u1ERLVCKG3okHLviR 4yvnggFExMsUwX1uQjwbD0Ai3nmIyFWg1n/nV8NRbQGZZ+XLr4J7z/05QhUYTiVt PXnpw9dToSE0GVzUfYAIQKCaqaMz6pDVfCyuIzHY0zR2txV5+PmuYRzWcA1W3Gow AP5aCoGkixxEsKqFH9rnkkxh0tqSjca18Kt4wBhxkMJWAFuwaNhKzXZDP9DB9fWO TuZaa7AQFZ6m/xqTU4n/PxM+i1LwS5DqCXhGR/NIhxM8jm1mweSA5Vni/y0ZOg3L f7aOxUjnP1+ZT7a+XdktHnRuMqqxAA5DfxZNyiYulkN6YzXuw0EmYU+Ha4zEDRWA ==
X-ME-Sender: <xms:fu-BX505H0Ejpy6T6gRiM5mrEy1JAtCkZoBojc_SfFd0GjMYwh5Clg> <xme:fu-BXwGywFJeJOG_csZnzyuemyd1PfaIfSJBwl8Eoy8sbJYX25jlForJvLrpmXwMu ii0PJjhYvhjAVi9RA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrheefgdduudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfoihgt hhgrvghlucffkdfgrhhrihgtohdfuceomhhikhgvqdhlihhsthesphhosghogidrtghomh eqnecuggftrfgrthhtvghrnhepieejueegheelgfehtddvueetteefuefgffdvkeehteeu tdekffejtedtiefggfdtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhikhgvqdhlihhsthesphhosghogidrtghomh
X-ME-Proxy: <xmx:fu-BX54IRUrybZk83bWJgL4teOEKrx9hOLT3TJh2Na_FR5KI3qwdvA> <xmx:fu-BX20Lrt_-UOk_qIZvYxSF_aYHujdsaFQ2s4jNFPBN3fqhFkTW1A> <xmx:fu-BX8GPHuYysB_74Nz3PVJOnKK2SHhtjHSimpZBF9xtIFHzDSa7hg> <xmx:f--BX2M3oGPsA1WqXB5ksI_gErE3xhkXD-85pMC2jhdcFPQ7ooFprg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id E5792660069; Sat, 10 Oct 2020 13:29:25 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-407-g461656c-fm-20201004.001-g461656c6
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <>
Date: Sat, 10 Oct 2020 13:29:13 -0400
From: Michael D'Errico <>
To: Benjamin Kaduk <>, Achim Kraus <>
Cc:, "" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07
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: Sat, 10 Oct 2020 17:29:39 -0000

On Fri, Oct 9, 2020, at 17:22, Benjamin Kaduk wrote:
> [...]  The behavior we should demand from our cryptographic
> constructions is that the cryptography itself correctly returns
> "valid" or "invalid" based on the input message, provided that
> the application inputs the correct key material.  (It should also
> return "invalid" if incorrect key material is supplied, of course.)
> The ability to produce two different messages for which the
> cryptography returns "valid" violates this principle; even if we
> do not see an obvious path by which a reasonable application
> might supply those inputs to the cryptographic code, it is still
> a flawed construction.


I'd like clarification about this point, where the cryptography
should return values of "valid" or "invalid".  This is a general
question, not specifically about this draft.  (Please read at
least the next 2 paragraphs.)

I remember a long time ago, it may have been the renegotiation
info extension, where there was a lot of calculation being done,
there were two complicated values each side had to compute.
If they were equal, then everything was fine and the handshake
could proceed.  If not, there was an insecure renegotiation
happening.  (Or maybe it was the downgrade protection RFC,
I can't remember now.)  But if the values were not equal, then
something bad was happening and the handshake should not

The problem both Martin Rex and I discovered at nearly the
same time (posts to the mailing list within minutes of each
other) was that both sides could go through all the motions
faithfully calculating all of the values, correctly, and then
forget to compare them to see if the values were actually
the same.  I noticed this because I wrote the code, and it
seemed like an easy thing to overlook.

I remember suggesting that we somehow incorporate the
calculated values into the derivation of the record layer keys
so the MAC would fail, or maybe into the Finished message
calculation so (if you remember to check that?) a failure is
noticed later.  This suggestion was shot down by the author
unilaterally for what I perceived at the time to be petty

I still believe that (D)TLS security should not rely on the
implementer to check whether two values are equal.  This
is too easy to forget to do.  Or you could do this in C:

    if (complex_value_a = complex_value_b) {
        // we're in trouble....

I have not looked at the TLS 1.3 draft beyond the hour or so
I've put in so far to see whether this reliance on checking is
in there too.  I've also not checked whether the security
proof I was referred to has any games where the implementer
forgot to compare values.  Or a game where everybody made
the same error and nobody noticed (forgetting to put the
HelloRetryRequest into the Tramscript-Hash for example).