Re: [TLS] TLS Export Channel Binding
Sam Whited <sam@samwhited.com> Sat, 09 May 2020 12:34 UTC
Return-Path: <sam@samwhited.com>
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 750583A09DA for <tls@ietfa.amsl.com>; Sat, 9 May 2020 05:34:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=samwhited.com header.b=B84SYJ4N; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FRwOgf6N
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 AKwtVO2SMu8l for <tls@ietfa.amsl.com>; Sat, 9 May 2020 05:34:38 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981AB3A0944 for <tls@ietf.org>; Sat, 9 May 2020 05:34:38 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B6D9D5C00DF; Sat, 9 May 2020 08:34:37 -0400 (EDT)
Received: from imap34 ([10.202.2.84]) by compute7.internal (MEProxy); Sat, 09 May 2020 08:34:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm2; bh=ld /cQUD8EL0c9vmBriyh8muzytXmmgHNC6m8G7RlfMc=; b=B84SYJ4NTZWlJbxwAH pZevecLWRuFZ87jdGjSrxGmm4evxX8yMQqgs9Kf9/3O61k053wUD1uRRKQfeo8bD gOdtIW6NdLNmWl/5nKwe64jsHJq+kGvxZEDNVD9iFXFs06qNHNpOtVdvcJ02LJSl Mh49spWWXn+TG8H3q2QPWhY/blIYchtiYVRM3MlpW2ZWQAszUf4PmCOEtJDp9xxc tuSGKMyLso0MMVzAKw7ObslZmfdZ/Xi6HvuNV0MGrbpT9Rpwvmv2qy7sU9QHuGS3 dthqw1ekIdkZTBip5hrsokn7OIvEHm4nnY4lu9nXxQUFXF0oc1uOuEDpA7IfbhQN EAuQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm2; bh=ld/cQUD8EL0c9vmBriyh8muzytXmmgHNC6m8G7Rlf Mc=; b=FRwOgf6Nu1/0GHnDTeaeO7f/V+QDNODN4Hfqut/8oZxwUd4j1swj1E4T6 IShxQxOGb5C+D3ioOEkUA23XNg4dUnxvZFOaMQCZa80xaKzOvbqBm0QwRk0M7eH7 MRFiU97/mWg3HH3BjTJHHvCzhIASCF/dopZBtQ8x7YLQa78n8a1kkbzgye4D50cV 6bSOjWGZFbalnhIST/XFgBpSOg1nYyr00iGpGJDMdnn9AGbQD8KSQIeEhASR2bnh RFwU1dbvnK25n3A+/6Bp2ZBhhgK3LcZbhP/xkOFobDBRrdDHX2YDlIKbdA70wpb9 TYjCRzHeUCAnaQa33KsWSPmFuNCKw==
X-ME-Sender: <xms:XaO2XtVYc1fkibp6DUwCtwkCEtXtaeO6z-Wn1Ndh4PWABo6yJ7hLag>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkeehgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdfurghm ucghhhhithgvugdfuceoshgrmhesshgrmhifhhhithgvugdrtghomheqnecuggftrfgrth htvghrnhepveegkeefuddtffeuveejteefteelteffudekieejvdehhfduhffhudeugfeh veefnecuffhomhgrihhnpehinhhrihgrrdhfrhenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehsrghmsehsrghmfihhihhtvggurdgtohhm
X-ME-Proxy: <xmx:XaO2XjmoSlHNMpf1FMRSdvP5evcDEbQ4NhYe3_gpfSwp6jvNQ8typA> <xmx:XaO2XkM_OcY_xT9Gm-GQ3HVfcsuZm7dapHfo_khs2A-EFqjiIwGoCg> <xmx:XaO2XjIybAOQu1x4W_EtBl4xetznVniTIeHeiOu0VWV954hyaPXOyg> <xmx:XaO2XlkmUuSqM6oZ00KsT0Bvkgv39-gGdG0x7vUUN63M5lXpRBO56g>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4C31C1460061; Sat, 9 May 2020 08:34:37 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1
Mime-Version: 1.0
Message-Id: <0eed2fcc-3747-40b2-855b-59312b0e23c6@www.fastmail.com>
In-Reply-To: <CACykbs1kn4ivMgkF5yZe9V1HzKW8bMHRZrFVH7Qben_CUEynoA@mail.gmail.com>
References: <0f20d1f6-56c1-4e01-813f-f8b3c57a5c9b@www.fastmail.com> <CACykbs3WDk7a0+0vCSDfCuib1Bex8SUJ-kvtZhjchvvm+5xc0g@mail.gmail.com> <13c2ff5e-f68e-45b5-bd64-085b9bdaf17e@www.fastmail.com> <CACykbs3+G8DCwC3ZrCbmzoygGkz6nRoYWHVxKWw3BvJ8YwAv7Q@mail.gmail.com> <ba8c1b17-6032-4420-8ead-a70c529721aa@www.fastmail.com> <CACykbs1Cz4aG1WaXpBeNmpdR90b2x-cGsrpnm=MXgFJiif0K2A@mail.gmail.com> <dc82ad3c-2806-7be3-c4fc-307d0f5fd482@isode.com> <CACykbs1kn4ivMgkF5yZe9V1HzKW8bMHRZrFVH7Qben_CUEynoA@mail.gmail.com>
Date: Sat, 09 May 2020 08:34:17 -0400
From: Sam Whited <sam@samwhited.com>
To: Jonathan Hoyland <jonathan.hoyland@gmail.com>, Alexey Melnikov <alexey.melnikov@isode.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pcnK8-bZKf4Vh1Lg88vepYdT3Yo>
Subject: Re: [TLS] TLS Export Channel Binding
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, 09 May 2020 12:34:41 -0000
Hi all, After thinking about this a little more, I think we should keep the draft generic and not make it SCRAM specific. While I generally agree with Jonathan's defense-in-depth strategy, there is also value in having a direct replacement for tls-unique that can be substituted in everywhere tls-unique is used to make the upgrade path easier. If we do that, we can always add a SCRAM specific channel binding type later on and slowly start the process of upgrading the n-places that use tls- unique with protocol specific binding types. Thoughts? —Sam On Mon, May 4, 2020, at 12:56, Jonathan Hoyland wrote: > Hi Alexey > > On Mon, 4 May 2020 at 16:23, Alexey Melnikov > <alexey.melnikov@isode.com> wrote: > > Hi Jonathan, > > > > On 04/05/2020 14:14, Jonathan Hoyland wrote: > > > Hi Sam, > > > > > > If you wanted to use a SCRAM based SASL auth then you could pick > > > `p=SCRAM-SHA256-PLUS`, or any other very specific IANA-registered > > > string, and update the SCRAM RFC to require that string with TLS > > > 1.3. You actively don't want for the same channel binding to be > > > an input to multiple different protocols (or even the same > > > protocol but with different parameters) because it opens the > > > door to confusion attacks. > > > > Can you elaborate on what you are trying to protect from? > > > > If two protocols use the same channel binding there is a risk that the > messages from one can be confused with the messages from the other. > This might happen accidentally, or an adversary might be able to forge > one from the other. If you wanted to do a formal analysis of the of > the security of TLS 1.3 > + SCRAM then a generic binding means you have to factor in what every > other possible protocol might do. If you use a unique and specific > channel binding then the analysis is far easier and can be a lot > more robust (this assumes a global coordinator of unique strings, > such as IANA). From an analysis perspective it's easier to rule out > classes of attacks than to consider all possible interactions > between all users of the interface, some of which you won't know > about, or perhaps haven't even been invented yet. > > > Historically channel bindings were constant once TLS negotiation > > was complete (they could change if TLS renegotiation happens). So > > they never depended on what was sent over the protocol above TLS. > > > > Yeah, I think the design in TLS 1.3 is much more robust, especially > from a formal analysis perspective. By constructing channel bindings > based on the parameters negotiated over the top you get a belt-and- > braces design. If you have a contributive channel binding [1] then if > the security of either the underlying protocol (in this case TLS) or > the over-the-top protocol (in this case SCRAM) fails, then the channel > binding guarantees the authentication still happened properly. > Consider the case where an adversary publishes the server's private > key to twitter. If you have a contributive channel binding then if the > SCRAM handshake succeeds you could be sure that you were talking to > the real server, and weren't being MITMed. If you don't base the > channel binding on the parameters agreed in the upper protocol it's > possible (in theory) that an adversary could compute two SCRAM > handshakes that appear to succeed, but that actually agree different > parameters. In this particular case it's not obvious how that could > happen, but it's easy to think up pathological examples, and [1] has a > few concrete examples too. > > > I've only skimmed the SCRAM RFC, but it might make sense to > > > include `client-first-message` and `server-first-message` as > > > context to the exporter interface, because it seems that the > > > channel binding isn't needed until the `client-final-message`. > > > > "the channel binding isn't needed until the `client-final-message`" > > is correct. Can you elaborate on what is problematic with this? > > Sorry if I was unclear, there's nothing problematic with this per se. > It's just that the channel binding can't be dependent on itself, but > including everything that precedes the channel binding just seems like > an easy win, esp. as (in this case) that includes all parameter > negotiation. > > > > > > The idea is to use the transcript to bind the channel binding to > > > the negotiation of SCRAM parameters, and thus allow you to define > > > a single "TLS-SASL-SCRAM" string (or whatever makes sense), > > > rather than have one for each possible set of parameters. > > > Obviously you'd need to think some more about whether that was > > > actually secure, but at first glance it seems like a reasonable > > > approach. > > > > > > Channel bindings that bind both the underlying channel and the > > > higher-level protocol make more sense to me that channel bindings > > > that only identify the underlying channel, because you don't have > > > to worry about the (potentially pathological) behaviours of other > > > users of the binding. > > > > > Best Regards, > > > > Alexey > > > Regards, > > Jonathan > > [1] Bhargavan, Karthikeyan, Antoine Delignat-Lavaud, and Alfredo > Pironti. "Verified Contributive Channel Bindings for Compound > Authentication." *NDSS*. 2015. > https://prosecco.gforge.inria.fr/personal/karthik/pubs/verified-channel-bindings-ndss15.pdf -- Sam Whited
- [TLS] TLS Export Channel Binding Sam Whited
- Re: [TLS] TLS Export Channel Binding Sam Whited
- Re: [TLS] TLS Export Channel Binding Jonathan Hoyland
- Re: [TLS] TLS Export Channel Binding Jonathan Hoyland
- Re: [TLS] TLS Export Channel Binding Sam Whited
- Re: [TLS] TLS Export Channel Binding Jonathan Hoyland
- Re: [TLS] TLS Export Channel Binding Sam Whited
- Re: [TLS] TLS Export Channel Binding Alexey Melnikov
- Re: [TLS] TLS Export Channel Binding Alexey Melnikov
- Re: [TLS] TLS Export Channel Binding Alexey Melnikov
- Re: [TLS] TLS Export Channel Binding Sam Whited
- Re: [TLS] TLS Export Channel Binding Jonathan Hoyland
- Re: [TLS] TLS Export Channel Binding Sam Whited