Re: [TLS] tls-unique

Simon Josefsson <simon@josefsson.org> Thu, 08 October 2015 12:36 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF791B3342 for <tls@ietfa.amsl.com>; Thu, 8 Oct 2015 05:36:59 -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 yVROc6nZj_Mm for <tls@ietfa.amsl.com>; Thu, 8 Oct 2015 05:36:58 -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 157981B3344 for <tls@ietf.org>; Thu, 8 Oct 2015 05:36:56 -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 t98Cah30012804 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 8 Oct 2015 14:36:44 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Eric Rescorla <ekr@rtfm.com>
References: <A1F63168-7736-452D-BC1B-23B665D81989@sn3rd.com> <87vbahu2r2.fsf@latte.josefsson.org> <CABcZeBNuSCB8i--TqYouiPyrPu6ZSunNeK40JHaO+DdBEnUL+A@mail.gmail.com> <87612hpsw8.fsf@latte.josefsson.org> <CABcZeBPqJXnOy7RPHZshiJqTrpj=+WbKXUHw9JyFsC1kN7s1gQ@mail.gmail.com> <20151008132025.68eb7f3a@latte.josefsson.org> <CABcZeBPg2LK8tRcXUqL93ScW5jOgg5kJLSOaLhMT2Z41oX-AXw@mail.gmail.com>
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
X-Hashcash: 1:22:151008:tls@ietf.org::dIKM2DIGYPx4xnSQ:Ei2X
X-Hashcash: 1:22:151008:ekr@rtfm.com::T+ATREeNsWKyofp+:KD3M
Date: Thu, 08 Oct 2015 14:36:42 +0200
In-Reply-To: <CABcZeBPg2LK8tRcXUqL93ScW5jOgg5kJLSOaLhMT2Z41oX-AXw@mail.gmail.com> (Eric Rescorla's message of "Thu, 8 Oct 2015 13:55:53 +0200")
Message-ID: <87si5lo7tx.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; 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/tls/gNRt8w5Qf8Hrc_WRDsJER8V1M2s>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] tls-unique
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 08 Oct 2015 12:36:59 -0000

Eric Rescorla <ekr@rtfm.com> writes:

> On Thu, Oct 8, 2015 at 1:20 PM, Simon Josefsson <simon@josefsson.org> wrote:
>
>> > > The introduction says:
>> > >
>> > >    There exists a TLS extension [I-D.ietf-tls-session-hash] that
>> > > modify TLS so that the definition of 'tls-unique' [RFC5929] has the
>> > > intended properties.  If widely implemented and deployed, the
>> > > channel binding type in this document would not offer any
>> > > additional protection.  The purpose of this document is to provide
>> > > an alternative channel binding that offers the intended properties
>> > > without requiring TLS protocol changes.  However, keep in mind that
>> > > TLS implementations needs to offer the appropriate APIs necessary
>> > > to be able to implement the channel binding described in this
>> > > document.
>> > >
>> > > I agree that one alternative is to require session_hash for all
>> > > connections.
>> >
>> >
>> > Given that you need to modify *some* software in any case, it seems
>> > like one ought to adopt session-hash.
>>
>> The problem is if you want to resolve this at the application level and
>> don't have sufficient control over the TLS layer to influence it to
>> negotiate session-hash.  This is the situation for many SASL
>> applications.
>>
>> If universal adoption of session-hash is a prio, then there is no
>> problem.  While RFC 7627 updates 5246 it does not talk a lot about what
>> it actually updates in 5246, or I missed it, and I haven't seen
>> session-hash functionality back-ported to deployed code.
>>
>
> I'm not sure what you mean by "backported", but I believe that BoringSSL
> presently has session-hash, SChannel has it soon or does already, and
> the next version of NSS (3.21) will have it.

If session-hash isn't backported to deployed code, like some other
security fixes has been backported (e.g., secure renegotiation), it will
take years until it is deployed.  Using only an TLS exporter interface
will therefor be insecure meanwhile, as far as I understand, since it
doesn't bind the entire handshake messages.

However, you could have a new TLS channel binding based on the TLS
exporter interface that demands use of session-hash, as you suggest.

>> My current approach works with or without session-hash negotiated, but
>> requires that you can get the session_hash value out of the TLS stack.
>
> I am not aware of a stack which has this function. Are you?

No.  Either the application inspects the handshake or code has to be
added.

/Simon