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

Jonathan Hoyland <jonathan.hoyland@gmail.com> Tue, 09 November 2021 18:03 UTC

Return-Path: <jonathan.hoyland@gmail.com>
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 06D4A3A0ED6; Tue, 9 Nov 2021 10:03:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 31rYzdzRnVX0; Tue, 9 Nov 2021 10:03:44 -0800 (PST)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6425D3A0ED2; Tue, 9 Nov 2021 10:03:44 -0800 (PST)
Received: by mail-qk1-x72a.google.com with SMTP id de30so5476693qkb.0; Tue, 09 Nov 2021 10:03:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H5vm0sMtHg3J3GIOTHn20jmu6w7WH8EXAsCcU4OLvQ4=; b=I1UaIxnffyXvJkLoeR2qf7vtavyAFXxGiyPG0Jt1sc3V7PooxpeBg/jgl1XEmvLB27 CVFbekykBxts1q5N2SQKIWiaCgb/J/UEugPHBtAlQAq1mKPhziWKAv02MYE3zvoKSOt2 9ZGtOIBR97gX8EQQd5FEZAUPHr3jE4ifGll1Teo4vCSIanC6TRPDjLV1zbXKWhLGw1tD t4fMI671z155xWq9IvFdf/ZYOS0jRTtizpabiNhTM+/7+zSzY0dSjhueAH/IZ8VMVj2T yfzuU7Os/mDKPbeXew9zs/PUeOEjApcuhr0GRHPN/XbV3XMB5NqfMI2nPGXLGhy0LCtd rB7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H5vm0sMtHg3J3GIOTHn20jmu6w7WH8EXAsCcU4OLvQ4=; b=STr4nqSjOCTnZeAQc97I+fTGlpQpH2fPivkEgXvq/7TBCHR0ObUgSW0h3eGdjYnCOT wpmqmRLn9n2hfiKBifJufmgFD0bi3UZ1xRumeO5YvKqbJE7+M6fDl4AauGkK3nPQ9JHK VtRRWwIDvv7sGUBa3ByBzAjjxCwli+SOrCCbrUEJsqJkXmrCB04Yk4kIAGd7NFXousmQ CRCb5kIQ5lVl+2hctcjSwx8flb6BYghujzlLuSUtfbIo/hiqNnJgxA8pEksqI/LNYTYm kR7CKNFxkDT94XcZ1gzDCyUPhMShi3znFbnB17X3dIlOXrbzzaPUglv56zq4nej74cuL 1bpw==
X-Gm-Message-State: AOAM531/J40Z80LPFphu8E+z4lg0IDQjETHouDNz4rVM2novC/9OtQy0 xNibSkJqI0iPfHUs9o1L61obhW2hq8IA+lOWz7s=
X-Google-Smtp-Source: ABdhPJxzNawU7e/p2skhieI4Kbf2L7BLRrpQhq50BCQHNwj/BVh4BhpQsvMoXYPOmf0wIcpBY6UjZFoyn94ezqYszfI=
X-Received: by 2002:a37:b2c2:: with SMTP id b185mr7607775qkf.272.1636481021481; Tue, 09 Nov 2021 10:03:41 -0800 (PST)
MIME-Version: 1.0
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> <CAKHUCzw=_QRTdOovSBwV0VeN1M-7b9fSXonTyfF_oo4_VAGaBQ@mail.gmail.com>
In-Reply-To: <CAKHUCzw=_QRTdOovSBwV0VeN1M-7b9fSXonTyfF_oo4_VAGaBQ@mail.gmail.com>
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Tue, 09 Nov 2021 18:03:30 +0000
Message-ID: <CACykbs276AwcN=FSfXhZ3X64S8GP268AYVz4c4ksdOSuykm0Ow@mail.gmail.com>
To: Dave Cridland <dave@cridland.net>
Cc: Sam Whited <sam@samwhited.com>, KITTEN Working Group <kitten@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f797b205d05eed1d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/W980M9t-HKEJ5Lk6C0g0ZZwyAE0>
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:03:49 -0000

Hi Dave,

On Tue, 9 Nov 2021 at 16:13, Dave Cridland <dave@cridland.net> wrote:

> On Tue, 9 Nov 2021 at 16:01, Jonathan Hoyland
> <jonathan.hoyland@gmail.com> wrote:
> >
> > Hi All,
> >
> > My specific solution is to simply include a different fixed string for
> each variant of SCRAM and GSS-API, and ideally a nonce.
>
> I think you may mean SASL and GSS-API, but more probably I think you
> need to decide what it is you mean.
>
>
I meant what I wrote.

SCRAM *already* includes a nonce in its hash calculations. Your
> proposal is to include another, to avoid an unspecified attack.
>
>
Firstly, the proposal under question is *NOT* just for SCRAM, it is for an
arbitrary number of unspecified protocols. And the nonce is to prevent
messages being moved between runs of an upper level protocol over a single
TLS channel.


> > Given that applications will have to update their stacks anyway to
> accommodate the new fixed string in the current proposal I don't see that
> as a hugely difficult proposition.
> >
> > The goal of labels in material that is used to derive keys (yes,
> material that is used to derive keys is necessarily secret, yes material
> derived from keys is not necessarily secret), is to exclude classes of
> attack.
> > It is good protocol design.
> >
> > One of the things use of a TLS channel binding gives you is protection
> for the upper level protocol against TLS being MITMed.
> > Using a fixed string for multiple protocols probably gives you that
> protection (assuming the channel binding is correctly agreed by both sides).
> >
> > 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.
> > 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).
> > 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.
> > Yes, you can add unique and clever protections into every sub-protocol,
> but it makes formally proving anything about the security exponentially
> harder (and yes, I mean that in the literal / mathematical sense).
>
> SASL (and GSS-API) are pluggable authentication systems which means
> that if you want a formal proof (or even just a finger-in-the-air
> back-of-the-envelope one) you have to do it against a specific SASL
> (or GSS-API) mechanism.
>

That's correct. If you want to do a proof you have to do it against a
specific mechanism.
The problem is that the analysis has to include all sources of protocol
messages from the same key space (yes, again. I know that channel bindings
are not keys. Yes I know that channel bindings are not required to be
secret.)
With the draft as proposed that is an arbitrary number of protocols,
including any that may be written in future.
Even if you managed to do some huge analysis of anything that falls into
this space, it would immediately be invalidated the moment any new version
or design came along.


> Without knowing the mechanism, it's impossible to perform a formal
> proof, because you don't know how the channel binding is exchanged and
> proven, and so you would be missing an absolutely crucial part of your
> model.
>
>
Firstly, even without knowing the mechanism there are lots of things we can
prove or that we assume.
For example, I assume that an attacker cannot decrypt messages for which it
does not have the key.
Most formal analysis is based on a fairly small set of assumptions and
standard proofs.
One key assumption is that different protocols use unrelated keys. (Yes,
again. I know that channel bindings are not keys. Yes I know that channel
bindings are not required to be secret.)
If you include channel bindings in your key derivation then you cannot
assume that the keys are unrelated.

Now it's totally possible to prove your protocol is universally composable
irrespective of channel bindings, but if you're proving that you might as
well just drop the TLS layer.

Second: The issue isn't about picking a specific mechanism, the issue is
that I can't ignore other mechanisms.

Regards,

Jonathan



> Dave.
>