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

[Nicolas Williams <Nicolas.Williams at sun.com>]

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
feasible).

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.

Nico
--