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

Achim Kraus <achimkraus@gmx.net> Sat, 10 October 2020 18:27 UTC

Return-Path: <achimkraus@gmx.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 A48DC3A0D5E; Sat, 10 Oct 2020 11:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.313
X-Spam-Level:
X-Spam-Status: No, score=-2.313 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 Qu7K6iMNJ2KG; Sat, 10 Oct 2020 11:27:33 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780763A0D14; Sat, 10 Oct 2020 11:27:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602354442; bh=KWgZ2TGQce1dI/IgoHqVpGtHAKBS62kZrjEycjd2cf0=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=It5oGGxURya378fgZsFhywmpYZlSkYTLUfgxiIYzcD0YcHVUTc58OGxOHWBwtBmAs 2mI8Waz3sqm/QG6kh3ymmliR7EZkayJGrIJE1wcIjxa0KhAg0ESNrO33TZN0albg+8 vnW9u7Nnu66FQJFaJDzwx7JZvJoxr/gMKOAMD9e4=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.100] ([88.65.148.189]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mr9Bk-1k6mA00naw-00oE8q; Sat, 10 Oct 2020 20:27:22 +0200
To: Michael D'Errico <mike-list@pobox.com>, Benjamin Kaduk <kaduk@mit.edu>
Cc: draft-ietf-tls-dtls-connection-id@ietf.org, "tls@ietf.org" <tls@ietf.org>
References: <0da9b525-ec78-bef5-6ceb-5f377019ade4@gmx.net> <4ca7c2f9-1e9d-0d16-0089-649f013b4565@gmx.net> <20201008233454.GF89563@kduck.mit.edu> <6185242d-8ba8-2d2f-5938-afad46c2e854@gmx.net> <20201009212240.GK89563@kduck.mit.edu> <401a965c-69ee-455a-8c09-12a37f3b89dc@www.fastmail.com>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <1fa15ca1-bfd8-9d56-e50d-31e749b54256@gmx.net>
Date: Sat, 10 Oct 2020 20:27:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <401a965c-69ee-455a-8c09-12a37f3b89dc@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:TkCuwSqnBMSB6eN2h+KlF21pDIbhbyYJ2JGYshqRmOgAd/1sd1r wdB256SKSCwj/4qb+PqsGEsgHeqGBY/yWnKafDXF+YG8XhwUyeen7lON8O1SFu4NKPTtEmi V0CgdXldhniOyvGMTrUiXfCOx8zLaPao2UG/OjRil0rKnyn1h8Jn9M7F+5P3AU/GuylxFwV MX3r1u/mrPNP2SdpSYjPQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:jSF7ACYB+X8=:XNYLYaEesoKpkvAGyfjcXN jaeeSWWEwMYItwAjxMGTBSufPYfZl0ReJPT0HerdgIIASzvUgAvTmi1mkTsm3OLI8G8Q5x9aL 1iKXY4ywiqDiN0H3CfhRzYFpPxJlR4RZMTx5Q/p9z+/di0HyE2nENf1XBoPar046l5xAzxONM xPIQiK9ZYFOsPDErnXb8ZbDhUfs+lPZ0a8jMGnFF250ap6v8zEbVrAiIB2KH0o/2j6BY2Oan8 S0kVrA/upWZLk4vNp7TmUeHeXaLq7Nu5QIGqzmU67kFNjQsb+o/pPr104qYYGw5gbXLI7OlZz szEMF8SKToZjf0RChntRFw9J3dYiw6DIUmr6fc9kjRjuFiGsRwrTrSGX3Q2pFiiUr1F2phJj7 0vQgXVEqYtO6du42ufwm1/Tq3Wee8fnRJaOFBgpAO193EZN13YuuzETgTcI/Ibv2JHB+KR2nL t41X8HGhtp/XdbJwA4VpQ2UbYHve2hWKh4isxwftTj6aYRKYpLW7HWPOAW0486ZefaOr2cDuv zxXmeUlulGTBhdQ+gBP4jy5az0j/9Ko32a12lSY+tVePO3MjhvwZiGST8XkjkN9lCn45PG4v0 X8ARDExm01CiAtm2vwD4BgLT4+AD2B/WAtrjsEcEFsAhjS3uh0W9Da7oQQS4mKu4NNf7VQCjD Oxs9nAcxb5MrtOOCWopG9lRqO01XyGwje+8qw6fFNzbOLN8WpgP8osNPei3HbZ0TKuZhoh+g8 qSy2+cODqw5ejrmo9/UF8KGBjwyNM1vy7xqrUue/KV9rO0+p/Quq/jujkKNtEgaT4uLwuoNGm sm/zg8NM6BtW62nKg+GINs+smBg6HmpsgeMQJxdxucFQ8e5opWhs1njzjBzN/VgUjwP5Tn/j+ VtMse6u8IomoEKJzK1+VOzjaBwtUO3dvzb7NPM+4KZiE5+cU+J0VrAaM0C42nNBMtVz2oae6h UklZqtPEF6lPDf0+t6TlhbsXpExJ4h/oEjElEaS0odRzhE2C3O3P8wBvyoXsuStOpNolz0SBM Be+gp+uiOPNU74iH/8RO59pM5XlUYvviXK/omWc3kZCtrG0OA4DAyqg3XsgcSG4F6BYPeggQm NEuJZJVIj+Vp+rLGJ52Q15XjPlv0EHQ6UYzH5bt62Ebj8Z4pOYfkbLgbypKtUbXRe+kmOzUDS 0JfwkSg7CM3RVHSA9M13lhzNpBzhMhGRA4oqWWyDKW8aiNS/cnDLB08kpa0FCJ2W594o7Tg4J Yc0mDi/q1x46b2BDPiTx8XfG2N1xZo9G5/JuQKQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Si7O1hA7ZY9RlwHTn9PIcibrJAI>
Subject: Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07
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: Sat, 10 Oct 2020 18:27:35 -0000

Hi Mike,

 > in C:
 >
 >      if (complex_value_a = complex_value_b) {
 >          // we're in trouble....
 >      }

That's a pitfall of C ('=' is not '=='). You will be almost in trouble,
if the complex value is not 0.

But the discussion here is more about how often somethings should be
adapted again and again. The point from Ben are all very valid, but they
should have been raised at least 1 year ago. Now, the point is, if
"cryptographic hygiene" without "actual threat" (at least, this was not
explained) should modify the MAC again. If so, the question may be, when
this changes will end.

best regards
Achim Kraus

Am 10.10.20 um 19:29 schrieb Michael D'Errico:
> 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.
>
> Hi,
>
> 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
> proceed.
>
> 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
> reasons.
>
> 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).
>
> Mike
>