Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-kitten-tls-channel-bindings-for-tls13-09.txt> (Channel Bindings for TLS 1.3) to Proposed Standard

"Ruslan N. Marchenko" <me@ruff.mobi> Tue, 09 November 2021 18:17 UTC

Return-Path: <me@ruff.mobi>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5648E3A0F44; Tue, 9 Nov 2021 10:17:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 6Wkc7QTADtMD; Tue, 9 Nov 2021 10:17:01 -0800 (PST)
Received: from vex.ruff.mobi (vex.ruff.mobi [37.120.177.103]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E673A0F41; Tue, 9 Nov 2021 10:17:00 -0800 (PST)
Received: from pi.ruff.mobi (ip-78-45-99-112.net.upcbroadband.cz [78.45.99.112]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "ruff.mobi", Issuer "R3" (not verified)) by vex.ruff.mobi (Postfix) with ESMTPS id 16B4914FD6F9; Tue, 9 Nov 2021 19:16:57 +0100 (CET)
Received: from dei.ruff.mobi (unknown [IPv6:2001:470:741b::6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by pi.ruff.mobi (Postfix) with ESMTPSA id D5C0513A38; Tue, 9 Nov 2021 19:16:54 +0100 (CET)
Message-ID: <6a1c4fc0ad976438d009c254932afc8d56e0d7ac.camel@ruff.mobi>
From: "Ruslan N. Marchenko" <me@ruff.mobi>
To: KITTEN Working Group <kitten@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Date: Tue, 09 Nov 2021 19:16:41 +0100
In-Reply-To: <CACykbs251Tn77jMN_YjcL8RxSax0NcFp8RNRT+oJp1Z=Z+qB2A@mail.gmail.com>
References: <163311243544.13917.11736165165419008870@ietfa.amsl.com> <20211001190002.GC98042@kduck.mit.edu> <CABcZeBPQG82xJdwMrmj4-=9aJymo1xts=D6VZedBW5X9k+34cQ@mail.gmail.com> <92ed26c1-bfde-43c1-93f4-2bbdbd4f6ec1@www.fastmail.com> <CAChr6Sw6Rs42DfS8KgD3qasPcWM_gGZhWN5C4b7W7JsPy0wDzw@mail.gmail.com> <8796f867-12b8-41f8-b124-82b3ab0e2d32@www.fastmail.com> <CAChr6SyKAnBcE9t68coGGXFt9WPLuDuWtVKoCXrK+QrwAVtPXw@mail.gmail.com> <f1bcd676-13ad-49b3-a8e8-8a272e0124e3@www.fastmail.com> <CABcZeBNo0gKjNZOKPYJYraioaw6G=z5ibTqh-o9GkWsDkfDmSQ@mail.gmail.com> <c4d6f2e5-0712-42a6-aef5-0cbada7e149e@www.fastmail.com> <CABcZeBM6y-6ZqaLGZ=8qr+uBnWOOgczhcx=ruy5S=n-YrHweKg@mail.gmail.com> <ca676a77-b2c9-4926-9842-d1d6587206ed@www.fastmail.com> <CACykbs11rHUweXmR1NSU0N2rRjcQ8Sf1S+DY2LO7T+e6cLt+5w@mail.gmail.com> <CAKHUCzz5ErY0xuBXVRuoNeZ3RS-7MwKrGH37kgZ=qwyqb-CgOg@mail.gmail.com> <CACykbs251Tn77jMN_YjcL8RxSax0NcFp8RNRT+oJp1Z=Z+qB2A@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-HYOz3Kk2Nc3CTBdBn6+0"
User-Agent: Evolution 3.40.4
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/xm9_0eSsi7BGyxjYOFX2qRs48XQ>
Subject: Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-kitten-tls-channel-bindings-for-tls13-09.txt> (Channel Bindings for TLS 1.3) to Proposed Standard
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2021 18:17:05 -0000

Hi Jonathan,

Am Dienstag, dem 09.11.2021 um 16:01 +0000 schrieb Jonathan Hoyland:
> Hi All,
> 
> Using a distinct channel binding, even if the upper level protocol is
> not secure, means that if both sides agree on the channel binding
> they agree on the intent of the upper layer protocol, i.e. it gives
> you some level assurance that the client and server agree on what was
> intended.
The binding is just that, a binding. Insecure protocols will remain
insecure but that still does not compromise secure protocols because
they can still bind securely app session to tls session. And again,
revealing binding data is not a leak/security breach.

> This eliminates classes of attack such as message confusion. 
> Adding this protection costs virtually nothing, given that you are
> _already_ commiting to updating this section of code (no code
> currently makes this specific call to the TLS-Exporter interface).
Actually it is already implemented in GnuTLS and GIO-TLS. Introducing
context specific label will require changing API to accept input
context (do something) while now it is simle property retrieval (get
something). Moreover it will stay aside from existing binding interface
which is still "get property".

> Leaving it out means that people like me who do formal analysis can't
> reasonably analyse these designs.
> I build models of protocols and prove they meet certain properties. 
> The only way to keep that analysis viable (we're already talking
> hundreds of hours of work) is to eliminate classes of attack
> wholesale.
There's still no demonstration or even hint of the attack as of now,
therefore I still do not see a justification to change API except "it
is a right thing to do". But I repeat again - it can be done, if there
is a reason for that.

Regards,
RUslan