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

Nico Williams <nico@cryptonector.com> Tue, 26 May 2015 21:26 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815A11B31ED for <kitten@ietfa.amsl.com>; Tue, 26 May 2015 14:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.233
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hql0IPlgvyvw for <kitten@ietfa.amsl.com>; Tue, 26 May 2015 14:26:53 -0700 (PDT)
Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CFF521B31E4 for <kitten@ietf.org>; Tue, 26 May 2015 14:26:53 -0700 (PDT)
Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 06885161D; Tue, 26 May 2015 14:26:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2Gyakdsg88inMu 1p+f0NI+oETYo=; b=SAMa0MkDYYMooTxcc48HQU6yPGXHLEaAU0KJgjkCr/QTQ+ X3GWRcp6VeqptdQZFBkt8AzvDlwTrBgd8ewhVqJ4JbhXRfriilxbPaRYk4YuPU2I eb1knNELf2Zf79XQzwefMU5o/VrECGSpOmsTfU4FXSPSVLhd6lbt7NFKjo2MA=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (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 <nico@cryptonector.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <20150526212650.GC27628@localhost>
References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <20150523202618.GC2166@localhost> <20150523223946.15ae8c11@latte.josefsson.org> <20150523214351.GD2166@localhost> <20150524004438.5121c26b@latte.josefsson.org> <556105C3.8020303@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <556105C3.8020303@cs.tcd.ie>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/WZAQS9xJTmz30iICki1oJVAFxhw>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 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
   sessions;

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
deployed.

> Cheers,
> S.
> 
> [1] https://www.ietf.org/mail-archive/web/tls/current/msg16231.html

My reply is at

https://www.ietf.org/mail-archive/web/tls/current/msg16335.html

Nico
--