Re: [TLS] TLS Export Channel Binding

Sam Whited <sam@samwhited.com> Mon, 04 May 2020 14:40 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 2CDAE3A092F for <tls@ietfa.amsl.com>; Mon, 4 May 2020 07:40:09 -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=XY+NCI0u; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=y4vhGMY/
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 eX0GzB5j3_39 for <tls@ietfa.amsl.com>; Mon, 4 May 2020 07:40:07 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948BE3A092C for <tls@ietf.org>; Mon, 4 May 2020 07:40:07 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 039F55C0132; Mon, 4 May 2020 10:40:07 -0400 (EDT)
Received: from imap34 ([10.202.2.84]) by compute7.internal (MEProxy); Mon, 04 May 2020 10:40:07 -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=Ns zmckDIZbe3sKN34PULfaHD0IUDrYK7Kx7X4CGZ87A=; b=XY+NCI0u5RTStKAgLU SSTauVPMrkT6FC2xd6sGdU+pR+1gGktV81E9dODyzJ0c096XQiEvnrs4cacq/zqp INJYe1PXMB28ucwmJtPWEXLWOiTvcgvw7jKyVxwebK67NEI/Khs7JFRJauWTXWrk hMGl7A7m3HlTP95s5uQvTJxLKGhsXAMLcNOSjf2kM34tYTHjmP39hX2of4C+fywa INnkP7T0CHYSdv2JgB7dhFjJD+quw3Z0VtFP5RnVRPBVVMNH5/pDlyrMbqNGlwJc xVWJ5Oz/4bgQB2iIq5M6wee9s8QcPMXW4FNoM3Pc/jUGN/xrHL5hpmO7LhtsXYU3 srug==
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=NszmckDIZbe3sKN34PULfaHD0IUDrYK7Kx7X4CGZ8 7A=; b=y4vhGMY/etl8GxpST+XrM0Ww2fkp69BNgAnyqXQaixKutONn2PmxtjSqL pk5CPRz7nSnJYDtiHYLhggit9AaI9ZqvwP0/8IMQbghKXbb5yV88atKG0Ef3/z3u X5qlZ1gBjeDGsFfMecEjuTRoroU3Fx+gix27zcbApWVMcXPuXU42rK9dBLPPpijz cqkQ2mUl9KRR+2AXsxnqUF56HY36POwhOJniCSjAW/TiCupOHNeLhXiG03grlvTt 97OOaxU+u5LiAqRnvebfxEJUSvoD49EZDTBHksS9/J1dO4BPzkJGX5bpKQ23mYMP wmOiVHkgBtjCQHru7+DkpSeVtMKYg==
X-ME-Sender: <xms:RimwXkq0U3Pa9HLv9CEy2C9TZxn2pejxos00T_gWfLQJciX7ZUbUOA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeeggdejudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdfurghm ucghhhhithgvugdfuceoshgrmhesshgrmhifhhhithgvugdrtghomheqnecuggftrfgrth htvghrnhepfeduudekkeeuteeuleefgeeuvdeuvdffhedvveeiffeghefhjefftdevveeu vdffnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehsrghmsehsrghmfihhihhtvggurdgtohhm
X-ME-Proxy: <xmx:RimwXp53jNMMyPRByTy6kmLYDQy0Npe3hyFZlEJEl5pKeMNkfuq91w> <xmx:RimwXsDWTao7ZZJPxyzgyczAAI2LLXIReOhbAjYtyIs41Ov-7HUf0A> <xmx:RimwXjbH5met4Guwn3n9e0bI9vDPz-RsGJOi6G0AjWwHZ-jS1UjOSw> <xmx:RimwXnR4Kq7oRgnfWnTya_Cl8wI5wZd8kXFfa0VC0pyzQ6DvP-JoQg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3749C1460061; Mon, 4 May 2020 10:40:05 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: <2621a35e-1731-44d2-9afc-ebdd2b51e2ea@www.fastmail.com>
In-Reply-To: <CACykbs1Cz4aG1WaXpBeNmpdR90b2x-cGsrpnm=MXgFJiif0K2A@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>
Date: Mon, 04 May 2020 10:39:45 -0400
From: "Sam Whited" <sam@samwhited.com>
To: "Jonathan Hoyland" <jonathan.hoyland@gmail.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/voObrckPUHW0nLvl394mkgYdbPg>
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: Mon, 04 May 2020 14:40:09 -0000

On Mon, May 4, 2020, at 09:14, Jonathan Hoyland wrote:
> 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 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.

I had originally written a long-ish reply about why we couldn't make
this SCRAM specific, but I've just realized after going back and
looking at the spec and one of my own implementations that I was
completely wrong.

This is a great idea, and I believe would be secure since the client-first-
message and server-first-message will contain their respective random
nonces. A malicious client or server *could* slip some arbitrary text
into either message, but if I understand TLS exporters security
properties correctly this should not pose a problem and the export data
should still be indistinguishable from random noise to someone without
the TLS master secret (a sanity check by an expert on this statement
would be appreciated).

I have updated the draft with these changes: https://datatracker.ietf.org/doc/draft-whited-tls-channel-bindings-for-tls13/

I'm still not entirely clear if this would be a better draft for the
KITTEN WG or this one. If we update the SCRAM RFCs I think it may be
better to go through KITTEN, but I'm not sure that they'll want to take
that work on. I'll ask. Any advice here would be appreciated since I
know almost nothing about IETF policy or procedures.

Thanks for your feedback!

—Sam