Re: [TLS] Document Action: 'TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode' to Informational RFC

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

At Fri, 27 Jun 2008 18:16:58 -0400 (EDT),
Dean Anderson wrote:
> 
> That disclosure specifically states that it doesn't apply to any other
> drafts, and this draft isn't listed.  That disclosure doesn't apply to
> this document.
> 
> The failure to disclose is only the first process violation. I count:
> 
> 2. No discussion of non-patented alternatives per RFC3979.

It's not clear what that means in the context of cipher suites.
Recall that TLS has a set of mandatory to implement cipher suites
based on RSA. Those *are* the non-patented (well, patent
expired) alternatives. So, the question is really whether IETF
should issue code points to algorithms which may potentially
be encumbered. The practice of the TLS WG has been historically
to do so, but to issue the RFCs as Informational. The S/MIME
WG appears to have done the same.


> 3. No consensus on WG, despite relationship to prior and future
> standards-track work on TLS.

Again, I'll refer this to Pasi, who ran this WGLC as chair.


> 4. This is a protocol-altering document, altering TLS protocol--it is
> not really an Informational document. Nor indeed is RFC4492 properly
> categorized as informational.  The informational category is being used
> as an end-run around the consensus requirements.

I don't agree with this claim. RFC 4346, which represents the consensus
of the WG, explicitly contemplates that new cipher suite code points
may be defined via Informational documents:

   Section A.5 describes a TLS Cipher Suite Registry to be maintained by
   the IANA, and it defines a number of such cipher suite identifiers.
   Cipher suite values with the first byte in the range 0-191 (decimal)
   inclusive are assigned via RFC 2434 Standards Action.  Values with
   the first byte in the range 192-254 (decimal) are assigned via RFC
   2434 Specification Required.  Values with the first byte 255
   (decimal) are reserved for RFC 2434 Private Use.  The registry will
   initially be populated with the values from Section A.5 of this
   document, [TLSAES], and from Section 3 of [TLSKRB].


Similarly, RFC 4366 explicitly contemplates that new extensions
may be defined by IETF Consensus [RFC 2434]:

   Sections 2.3 and 5 describe a registry of ExtensionType values to be
   maintained by the IANA.  ExtensionType values are to be assigned via
   IETF Consensus as defined in RFC 2434 [IANA].  The initial registry
   corresponds to the definition of "ExtensionType" in Section 2.3.

Informational documents fall squarely within this category.


> The consequence appears to be another submarine-patented standard. I
> don't think this can dismissed as "it just didn't occur to me", after
> TLS-Authz.

I don't really understand this paragraph. What are you suggesting?

-Ekr
_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls