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

Simon Josefsson <simon@josefsson.org> Sat, 23 May 2015 20:40 UTC

Return-Path: <simon@josefsson.org>
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 5BB441A86F0 for <kitten@ietfa.amsl.com>; Sat, 23 May 2015 13:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] 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 gOeUWoH64P8D for <kitten@ietfa.amsl.com>; Sat, 23 May 2015 13:40:11 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1772D1A802D for <kitten@ietf.org>; Sat, 23 May 2015 13:40:10 -0700 (PDT)
Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4NKdlw4000451 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 23 May 2015 22:39:48 +0200
Date: Sat, 23 May 2015 22:39:46 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Nico Williams <nico@cryptonector.com>
Message-ID: <20150523223946.15ae8c11@latte.josefsson.org>
In-Reply-To: <20150523202618.GC2166@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>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/c6CzN8KGdkK2WsV=VSQ308a"; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/5ib6v7nYMQPsgHGgI-kgeIF-DXo>
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: Sat, 23 May 2015 20:40:15 -0000

Den Sat, 23 May 2015 15:26:19 -0500
skrev Re: [kitten] draft-hansen-scram-sha256 and incorporating session
hashing for channel binding:

> On Mon, Mar 02, 2015 at 07:23:36PM +0000, Alexey Melnikov wrote:
> > On 25/02/2015 15:25, Simon Josefsson wrote:
> > >Tony Hansen <tony@att.com> writes:
> > >If people like the tls-session-hash approach (I'm not in that
> > >category, but there may be consensus around it), the proper fix is
> > >to update RFC 5802 and reference tls-session-hash as a normative
> > >reference.  This will take care of the problem, as you could copy
> > >that text into your document.  If you are looking for a text
> > >change here, it would be:
> > >
> > >   To be secure SCRAM-SHA-256-PLUS has to be used over a TLS
> > > channel that MUST have [TLS-SESSION-HASH] negotiated.
> > >
> > >Personally, I would prefer to change to another mandatory channel
> > >binding that is secure for all TLS versions.
> > Before we make the decisions between referencing tls-session-hash
> > versa a new channel binding, can you sketch out how the new channel
> > binding is going to be defined?
> > 
> > (If we choose to define a new channel binding, I think Kitten WG is
> > the right place for doing this work.)
> 
> There is no need to define a new channel binding.  Existing TLS
> implementations need to be fixed regardless.  There's nothing GSS- or
> SASL-mechanism-specific here.

There is, since no GS2 mechanism is secure with tls-unique without
tls-session-hash.  The fault is not GSS/SASL's, but as far as I
understand, it is a fact nonetheless.  Thus a normative reference to
tls-session-hash can be added to documents to resolve the problem, or a
new channel binding can be used.  I don't see any other solution, but
ideas welcome.

As far as I see, the tls-session-hash document does not update earlier
TLS specs to require that tls-session-hash is implemented. Thus, it is
perfectly valid and compliant to implement TLS without tls-session-hash
when used for GSS/SASL since there is no normative reference to
tls-session-hash anywhere.

Finally, I think for the forseeable future there will be widely
deployed TLS stacks without support for tls-session-hash.

/Simon