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

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

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

Nico
--