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

Nicolas Williams <> Tue, 06 October 2009 23:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 494873A6818 for <>; Tue, 6 Oct 2009 16:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.887
X-Spam-Status: No, score=-5.887 tagged_above=-999 required=5 tests=[AWL=0.159, 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 GWBeUdqjvQwu for <>; Tue, 6 Oct 2009 16:50:22 -0700 (PDT)
Received: from (brmea-mail-4.Sun.COM []) by (Postfix) with ESMTP id B13663A6851 for <>; Tue, 6 Oct 2009 16:50:21 -0700 (PDT)
Received: from ([]) by (8.13.6+Sun/8.12.9) with ESMTP id n96NpxSu008760 for <>; Tue, 6 Oct 2009 23:51:59 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 n96NpxVq007839 for <>; Tue, 6 Oct 2009 17:51:59 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost []) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n96Neixu005334; Tue, 6 Oct 2009 18:40:44 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n96NehvB005333; Tue, 6 Oct 2009 18:40:43 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to using -f
Date: Tue, 06 Oct 2009 18:40:43 -0500
From: Nicolas Williams <>
To: Simon Josefsson <>
Message-ID: <20091006234043.GP887@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
Cc: Paul Hoffman <>,
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: Tue, 06 Oct 2009 23:50:23 -0000

On Tue, Oct 06, 2009 at 03:34:04PM +0200, Simon Josefsson wrote:
> If these use-cases are intended to be realistic use-cases of the
> extension (which doesn't seem clear to me), I believe the document needs
> more work: it should suggest a structure of the PRF data so that servers
> will understand what type of data the client sent.  Compare for example
> how RFC 5077 suggests a format.  The document could even go further and
> mandate a particular format, which would make the use-cases more likely
> to interoperate, such as:

This is effectively a channel binding input to TLS.  Uses of a channel
binding input are not limited to channel binding (which is not likely to
be useful to TLS, even though channel binding to IPsec would clearly be

For example, in SCRAM/GS2 we use GSS-API channel binding in the
construction of a SASL mechanism to protect cleartext sent outside the
GSS-API mechanism's tokens.  A secure audit protocol in OpenSolaris uses
GSS-API channel bindings to protect early application protocol version
negotiation.  And so on.

I think this is likely to be particularly useful to StartTLS-type
applications, as a way of integrity-protecting early application
protocol version negotiation.  I suspect this extension will also be
particularly useful to DTLS applications, for similar reasons.