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> Wed, 27 October 2021 18:39 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 3DB6B3A1052; Wed, 27 Oct 2021 11:39:39 -0700 (PDT)
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 kujdE5psW-HS; Wed, 27 Oct 2021 11:39:35 -0700 (PDT)
Received: from vex.ruff.mobi (vex.ruff.mobi [IPv6:2a03:4000:6:83fc::a]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 221C03A1051; Wed, 27 Oct 2021 11:39:34 -0700 (PDT)
Received: from pi.ruff.mobi (mx.ruff.mobi [IPv6:2001:470:741b:1::252]) (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 3BCB9149AE6E; Wed, 27 Oct 2021 20:39:29 +0200 (CEST)
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 9AC8413C30; Wed, 27 Oct 2021 20:39:25 +0200 (CEST)
Message-ID: <7e862904cee5f86e4b77fce23c451c2abe0dc720.camel@ruff.mobi>
From: "Ruslan N. Marchenko" <me@ruff.mobi>
To: Jonathan Hoyland <jonathan.hoyland@gmail.com>, "Ruslan N. Marchenko" <rufferson@gmail.com>
Cc: KITTEN Working Group <kitten@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Date: Wed, 27 Oct 2021 20:39:22 +0200
In-Reply-To: <CACykbs3v0FC50WQHNqq-oXwKDE=Jha-o0P=Mgr92OgyeKPS6Ug@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> <e9570c02c4f703780a4e317b26607ac124a3b595.camel@ruff.mobi> <CACykbs3v0FC50WQHNqq-oXwKDE=Jha-o0P=Mgr92OgyeKPS6Ug@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.4
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/y_AMGr8nzzmMAnDtVZPdiMOmMns>
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: Wed, 27 Oct 2021 18:39:39 -0000
Hi Jonathan, Am Mittwoch, dem 27.10.2021 um 18:02 +0100 schrieb Jonathan Hoyland: > Hi Ruslan, > > Without digging into the guts of GSS-API and SCRAM I can't give you a > concrete attack, the issue is that all our assumptions about protocol > security assume that different protocols use totally separate key > material. > For example if I have one protocol that signs arbitrary blobs and > another that requires me to sign a challenge to prove I know a private > key then even if they're both perfectly secure on their own they are > totally broken in composition. > This separation of keys is one of the core reasons for the use of > HKDFs, it lets us take some source randomness and use it to generate > independent keys. > > Designing a channel binding that explicitly suggests people use the > same key material for different things is bad practice and poor > protocol design. > Pretty much every attack is on the table if you have multiple protocols > using the same keys, message forgery, improper authentication, key > leakage, etc. > The reason for separation of keys is to simply rule out this entire > class of vulnerability. Sorry maybe I'm missing something but why would two unrelated protocols have same key? The binding is derived from TLS session key, if two unrelated TLS sessions are having the same key this is the problem by itself, and binding material is not amplifying it, just falling to the same problem bucket. And if they are related (eg resumed) then protocol muxing should perhaps be part of applicaiton stack and it should still be happy with a common security context. > If you don't separate the keys then whenever you make any change to any > protocol you have to consider its security in composition with every > other protocol, including ones that you don't know about or that > haven't been written yet. > > Using different labels for different purposes shouldn't require > anything complicated, as it's just changing the input literals to the > API call. > There's a difference in telling TLS stack "give me binding of that type" - which is pretty much high level abstract call, and asking TLS to perform key derivation (export) for specific label - which requires speaking native TLS implementation api. Now that we have a bunch of TLS implementations and several abstractions and all other binding types are independent of the higher protocol - it may be challenging changing the API to make the binding retrieval context-specific. Not that it is impossible to make such change, but why?
- [kitten] Last Call: <draft-ietf-kitten-tls-channe… The IESG
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Jonathan Hoyland
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Ruslan N. Marchenko
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Jonathan Hoyland
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Ruslan N. Marchenko
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Sam Whited
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Jonathan Hoyland
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Jonathan Hoyland
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Simo Sorce
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Jonathan Hoyland
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Ruslan N. Marchenko
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Alexey Melnikov
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Simon Josefsson
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Dave Cridland
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Jonathan Hoyland
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Dave Cridland
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Jonathan Hoyland
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Ruslan N. Marchenko
- Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-ki… Sam Whited