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

[Michael D'Errico <[e-mail]>]

I understand your concern, but the fact is that there is already an
unofficial extension mechanism available.  Simply create a private
cipher suite (first byte 0xFF) and then define your own formats for
ServerKeyExchange and ClientKeyExchange handshake messages to go
along with it.  This won't work if the client needs to send info
to the server first, though.

Mike


[e-mail] wrote:
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
>> ext Simon Josefsson
>> Sent: 06 October, 2009 16:34
>> To: Paul Hoffman
>> Cc: [e-mail]
>> Subject: Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-
>> 00.txt
>>
>> Paul Hoffman <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>