Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding

Nico Williams <> Tue, 26 May 2015 21:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 815A11B31ED for <>; Tue, 26 May 2015 14:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.233
X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hql0IPlgvyvw for <>; Tue, 26 May 2015 14:26:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CFF521B31E4 for <>; Tue, 26 May 2015 14:26:53 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 06885161D; Tue, 26 May 2015 14:26:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=2Gyakdsg88inMu 1p+f0NI+oETYo=; b=SAMa0MkDYYMooTxcc48HQU6yPGXHLEaAU0KJgjkCr/QTQ+ X3GWRcp6VeqptdQZFBkt8AzvDlwTrBgd8ewhVqJ4JbhXRfriilxbPaRYk4YuPU2I eb1knNELf2Zf79XQzwefMU5o/VrECGSpOmsTfU4FXSPSVLhd6lbt7NFKjo2MA=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id EDBB81612; Tue, 26 May 2015 14:26:51 -0700 (PDT)
Date: Tue, 26 May 2015 16:26:50 -0500
From: Nico Williams <>
To: Stephen Farrell <>
Message-ID: <20150526212650.GC27628@localhost>
References: <> <> <> <> <> <20150523202618.GC2166@localhost> <> <20150523214351.GD2166@localhost> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Cc: "" <>
Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 May 2015 21:26:55 -0000

On Sat, May 23, 2015 at 11:57:07PM +0100, Stephen Farrell wrote:
> On 23/05/15 23:44, Simon Josefsson wrote:
> > Perhaps this is a question for the TLS WG -- whether they intend
> > tls-session-hash to apply as a mandatory fix to all TLS versions or
> > not.  The document does not say anything about updates now, which means
> > "TLS needs fixing" won't necessarily happen.
> So this may be helpful or not depending on how much one
> considers IETF minutae important...

We've discussed this in the TLS WG.  There was no consensus call as
such, so... I don't know what the status is.

Regardless, it's not really appropriate for a SASL/GSS mechanism to
introduce a new TLS channel binding.  Nor is it necessary assuming that
TLS is fixed to use the session hash.

It would be appropriate to:

a) add security considerations text about the dangers of using
   tls-unique with an unpatched TLS implementation with resumed

b) separately pursue a new TLS channel binding, though perhaps having
   an informative references from any new SASL/GSS mech(s) on the new
   TLS channel binding.

   Normative references would belong in the _application_ protocols, not
   the SASL/GSS mechanism.

There isn't consensus for (b) yet.  I'm not against it, but I note that
it shouldn't be necessary.  The TLS session hash fix has to get
deployed, full stop.

> During IESG evaluation we agreed to have the session hash
> document be an update of 5246. The start of that thread is

It should probably also update RFC5929.  I made a comment as to that on
the DISCUSS.  There was no further discussion.

> at [1] and the resolution is downthread or maybe in some
> other thread but was on the TLS list. The update to the
> draft hasn't yet happened but will shortly.
> The impact is that our formalities then expect any new TLS
> code to include session hash. But that of course does not
> affect already deployed code so make of that what you will.

The same is true for adding new TLS channel bindings, and adding
security considerations text to new SASL/GSS mechanisms about that:
existing TLS stacks and applications won't be using the new TLS CB.

But fixing TLS stacks to use the session hash can be done in a
backwards-compatible way at the API level, and so fixing TLS *is* the
right thing to do, and the only thing that will fix existing apps
without having to change them.

That's why I much prefer focusing on getting the TLS session hash

> Cheers,
> S.
> [1]

My reply is at