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

[Paul Hoffman <paul.hoffman at vpnc.org>]

Timing is everything. A few hours before Pasi sent this, I turned in the -01 which addressed Simon's concerns and started to address Pasi's.

At 9:11 AM +0100 10/26/09, <Pasi.Eronen at nokia.com> 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.)

For the -01, I chose a FCFS registry that requires an RFC. Requiring an RFC will increase interop.

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

That is not the only drawback. The whole purpose of this document is to put additional material in the PRF; that is not covered in the TLS Extensions document, nor should it be.

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

No, the main feature is to allow light-weight extensions (that is, ones that just contain content, not directives) to have input to the PRF.

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

This is confusing. Are you saying you *want* the equivalent of IKE's Vendor ID payload as a TLS extension? If so, someone could write such an extension; I see no reason why that material would need to be mixed into the PRF using the mechanism I am proposing here. If you don't want a Vendor ID equivalent, that's fine, and I agree, but I don't understand why you brought it up this way.

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

Note that the registry in -01 is for "any RFC", not "standards track RFC". I'm happy to make it "standards track RFC required" and have it be parallel to the current TLS extensions requirements.

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

It would be quite confusing to modify the current TLS extensions mechanism to have some extensions mix content into the PRF but some not. This is why I am proposing a different mechanism altogether. If you want the two mechanisms to have the same requirements, that's fine.

--Paul Hoffman, Director
--VPN Consortium