I agree with Simon here that in the minimum, the extension should have
a "type" field to ensure that if the recipient parses the information,
it's using the same format as the sender. (Some other protocols use
the Enterprise Number registry for "vendor specific" payloads, instead
of creating a new FCFS registry.)

However, 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.

The main "feature" of this draft seems to be allowing "interesting"
extensions without going through the IETF process, or even publicly
documenting what you're doing.  I can certainly see that folks at NSA
might be interesting in doing exactly such things, and they could have
(in their opinion) good reasons.  And some other IETF protocols do
indeed allow pretty much unlimited vendor extensibility (by e.g.
allowing "Vendor Specific" payloads anywhere).

But if the WG decides that adding such extensibility to TLS is a good
idea, I would predict that many folks will use this mechanism to
define new TLS extension so that they can avoid the somewhat
time-consuming process of consensus-building and standardization.

Many of the existing TLS extension could have been done by specifying
suitably "structured" PRF inputs: client/server_authz, user_mapping,
trusted_ca_keys, server_name, status_request, etc. (In these cases,
it doesn't really matter if the input gets fed to PRF; the interesting
part is adding a free-form payload to ClientHello/ServerHello without
requiring an extension number from IANA.)

I know sevaral people have occasionally been frustrated that it's very
difficult to extend TLS (since the requirements for IANA allocation
are quite strict). Personally, I view this as a feature, and I think
it has contributed to general interoperability of TLS/SSL -- it's
generally viewed as a protocol that "just works" (compared to some
other protocols which have large numbers of optional extensions, and
it's very difficult to get implementations from different vendors
to interoperate).
 
Best regards,
Pasi 
(not wearing any hats)

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> ext Simon Josefsson
> Sent: 06 October, 2009 16:34
> To: Paul Hoffman
> Cc: tls@ietf.org
> Subject: Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-
> 00.txt
> 
> Paul Hoffman <paul.hoffman@vpnc.org> writes:
> 
> >>http://www.ietf.org/internet-drafts/draft-solinas-tls-additional-prf-
> input-00.txt
> >
> > Greetings again. We would like to hear input on this draft from the
> > TLS community. The basic idea is an extension that would allow the
> two
> > parties to give additional information that is directly mixed into
> the
> > master secret through the PRF.
> 
> The document seems fine to me.
> 
> As far as I can tell, any implementation (including mine) of
> draft-rescorla-tls-opaque-prf-input-00.txt would be compatible with
> draft-solinas-tls-additional-prf-input-00.txt, and that is good.
> 
> The two last examples in section 1.1 doesn't appear fully baked to me.
> Quoting:
> 
>   TLS servers may arrange for their clients to provide authentication
>   data early in the protocol (such as an HMAC value computed over a
>   fresh random value using a shared secret as the key) in order to
>   authenticate the client as a member of a private network or as an
>   additional means of mitigating the impact of a denial-of-service
>   attack.
> 
>   Implementors may want to provide a mechanism for relaying identity
> and
>   version information similar to the "Vendor ID Payload" used in ISAKMP
>   [RFC2408].
> 
> 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:
> 
>      enum {
>          entropy(0), (65535)
>      } AdditionalPRFInputType;
> 
>      struct {
>          AdditionalPRFInputType type;
>          opaque value<0..2^16-1>;
>      } AdditionalPRFInput;
> 
>      AdditionalPRFInput prfinputs<2..2^16-2>;
> 
> The AdditionalPRFInputType could be a FCFS registry.  The intention
> with
> the "entropy" field is that it should contain random data with no
> intended meaning, which appears to be the typical use-case.  Other
> types
> can be allocated to signal the two use-cases in the example if/when
> needed.
> 
> Alternatively, and considering the complexities in my proposed change,
> I
> would suggest that you remove other use cases than the one to provide
> additional entropy to the MS key computation and say that there is only
> one intended use-case for this extension.  If other use-cases of the
> extension are important, they can be described in separate documents.
> 
> Thanks,
> /Simon
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls