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

[<[e-mail]>]

Russ Housley wrote:

> >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, this very document (a proposal for a TLS extension) is a 
proof that TLS extensions can indeed change what goes into the PRF!

So there's no a priori reason why other TLS extensions cannot
do that, too. New TLS cipher suites routinely change what goes into 
the PRF by defining suitable pre_master_secret formats (e.g. RFC 4279).  
And we've had a proposal for a TLS extension that changed the TLS PRF 
to some other PRF. 

Best regards,
Pasi
(not wearing any hats)