Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt

Nicolas Williams <> Mon, 26 October 2009 19:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABF8B28C34F for <>; Mon, 26 Oct 2009 12:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.911
X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TtlLihHommOd for <>; Mon, 26 Oct 2009 12:04:36 -0700 (PDT)
Received: from (brmea-mail-1.Sun.COM []) by (Postfix) with ESMTP id 997FF28C361 for <>; Mon, 26 Oct 2009 12:02:57 -0700 (PDT)
Received: from ([]) by (8.13.6+Sun/8.12.9) with ESMTP id n9QJ3Arx004522 for <>; Mon, 26 Oct 2009 19:03:10 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM []) by (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9QJ3AUa002202 for <>; Mon, 26 Oct 2009 13:03:10 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost []) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9QIpiaR009043; Mon, 26 Oct 2009 13:51:44 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9QIpibr009042; Mon, 26 Oct 2009 13:51:44 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to using -f
Date: Mon, 26 Oct 2009 13:51:43 -0500
From: Nicolas Williams <>
To: Russ Housley <>
Message-ID: <20091026185143.GR892@Sun.COM>
References: <p0624087dc6efe84bcc54@[]> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.7i
Subject: Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Oct 2009 19:04:37 -0000

On Mon, Oct 26, 2009 at 02:41:43PM -0400, Russ Housley wrote:
> Pasi:
> >I'd like to re-iterate my earlier concern about the original
> >draft-rescorla-tls-opaque-prf-input draft: this defines a basically
> >general-purpose extension mechanism to TLS.
> >
> >We already have a well-defined extension mechanism for TLS (TLS
> >extensions), which would allow people to do exactly the sorts of
> >things envisioned in Section 1.1. Its only "drawback" is that it
> >requires going through the IETF process to obtain the IANA allocation,
> >and thus publicly documenting what you're doing.
> I do not think this is a fair characterization.  TLS extensions 
> cannot provide additional PRF inputs.  To my eyes, that is the 
> fundamental difference here.

Well, one could imagine a plethora of extensions each of which says that
you must modify the PRF computation in such and such ways.  But that
gets ugly very quickly.

IMO we need this draft, and IMO it's properly seen as the TLS equivalent
of the GSS-API channel bindings input to GSS_Init/Accept_sec_context():

    An additional PRF input is an octet string that is checked for
    equality in an integrity protected manner that adds no round-trips
    nor half round-trips.  If the equality comparison fails then
    authentication fails.

Whether that facility is used for bonafide channel binding or, more
likely, to provide integrity protection for application data sent out of
band from TLS, is not important.  What's important is: a) that those
semantics are desirable, b) that client and server applications can
agree on what they'll use as additional PRF inputs (e.g., it may be
desirable to support multiple additional inputs, each tagged with a type