Re: [TLS] tls-unique

Eric Rescorla <ekr@rtfm.com> Thu, 08 October 2015 11:56 UTC

Return-Path: <ekr@rtfm.com>
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 6D3FA1B32B9 for <tls@ietfa.amsl.com>; Thu, 8 Oct 2015 04:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 wLfBy8pPZoHm for <tls@ietfa.amsl.com>; Thu, 8 Oct 2015 04:56:34 -0700 (PDT)
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3C71A876F for <tls@ietf.org>; Thu, 8 Oct 2015 04:56:34 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so24724462wic.0 for <tls@ietf.org>; Thu, 08 Oct 2015 04:56:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=l+KdBdyj3fuCc30p96BaviJWAvJYdh/M6W+qyXGWLcU=; b=VL2oqInqLgSNRatSi0r847ntrUsbBaph8wn9w/NwrbqfWd1Rk6tNa83UrgXwT07ZuX CQ2bd71qFaTYseIoC2QKEuQT2+tmpc6c/jeJ33WillzcGZ0ZE0/a7i2NJ9fPrirC5ivR w3sZtWVQYsrYUmezNsu0/iMb5ML5trV4vYzuJqe48v0nw4UZ6v63GYy2ltGphrykTPvl 2pVDYSMkD3ibG/mttOHOgcsjHOVgJnJcdG5KAAek5uDtnu+sTbOHnF0VACpRsSd3X0Da AaCsqW5Psn3qM5oTmWwnkd9VCE/1EIdH6hjJEE/Z+PpWnInLtOQQECB15c6N7EZgpeo6 OlQw==
X-Gm-Message-State: ALoCoQmEtJ87TeQPDWXXKjNrB7hlSnkqLBfrKl/XQGe5IP3fCie+XckguwHHdAdgLzeLhXhP7wyM
X-Received: by 10.194.238.228 with SMTP id vn4mr7332885wjc.13.1444305392912; Thu, 08 Oct 2015 04:56:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.220.22 with HTTP; Thu, 8 Oct 2015 04:55:53 -0700 (PDT)
In-Reply-To: <20151008132025.68eb7f3a@latte.josefsson.org>
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 8 Oct 2015 13:55:53 +0200
Message-ID: <CABcZeBPg2LK8tRcXUqL93ScW5jOgg5kJLSOaLhMT2Z41oX-AXw@mail.gmail.com>
To: Simon Josefsson <simon@josefsson.org>
Content-Type: multipart/alternative; boundary=001a11c25adce4715d0521968d92
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/CvYyiDoQOAMwik9m0CPsJHj7oPk>
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 11:56:36 -0000

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.


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?

-Ekr

Another approach is to say that if session-hash is in use, it uses a
> simple TLS exporter API call, and if it is not, it has to use TLS
> exporter API on the session_hash value.  This would secure all cases.
>
> > >   But then what is the problem with use of 'tls-unique'?
> >
> > The general consensus is that 96 bits is too short.
>
> I agree -- I used 256 bits.
>
> /Simon
>