Subject: [TLS] [Editorial Errata Reported] RFC5246 (3191)

From: RFC Errata System <[email-masked]>
Date: Thu, 12 Apr 2012 12:38:10 -0700 (PDT)

The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=3191

--------------------------------------
Type: Editorial
Reported by: Martin Rex <[email-masked]>

Section: Meta-Data

Original Text
-------------
Obsoletes: 3268, 4346, 4366
Updates: 4492

Corrected Text
--------------
Updates: 4492

Notes
-----
"Obsoletes: 4366" is factually incorrect, because it is impossible to implement TLSv1.1 (rfc4346) or TLSv1.0(rfc2246) from the TLSv1.2 spec alone. (IPv6 does not obsolete IPv4 and HTTP/1.1 does not obsolete HTTP/1.0 either).

"Obsoletes: 4366" is factually incorrect, because some of the TLS extensions defined in rfc4366 do NOT appear in rfc5246 (and were updated by rfc6066).  On top of that, in order to implement TLS extensions for TLSv1.0 or TLSv1.1, rfc4366 is indispensible, because it describes the necessary changes to the TLSv1.0 & TLSv1.1 PDUs, information that would be cumbersome to extract from rfc5246 compared to simply using rfc4366.

"Obsoletes: 3268" is factually incorrect, because 3268 is the document needed to implement the AES ciphersuites in implementations of TLS _prior_ to TLSv1.2,
such as TLSv1.0(rfc2246) and TLSv1.1(rfc4346), i.e. to add support for AES ciphersuites to an existing implementation of TLSv1.0, one would use TLSv1.0(rfc2246) plus rfc3268, rather than TLSv1.0 plus some undefined fragments of rfc5246.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--------------------------------------
Title               : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date    : August 2008
Author(s)           : T. Dierks, E. Rescorla
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Apr 2012 08:01:51 -0700

This errata should be rejected because it is not an errata, it is an objection to the IETF process (how one RFC obsoletes another). It is definitely an interesting process question, but not one that should be dealt with through the errata process.

On Apr 12, 2012, at 12:38 PM, RFC Errata System wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Apr 2012 18:12:46 +0200 (MEST)

Paul Hoffman wrote:
> This errata should be rejected because it is not an errata, it is
> an objection to the IETF process (how one RFC obsoletes another).

You're mistaken, incorrect Meta-Data can be reported as RFC-Errata, see:

 http://www.ietf.org/iesg/statement/rfc-metadata-errata.html

>
> It is definitely an interesting process question, but not one that
> should be dealt with through the errata process.

The condition where the use of Obsoletes: is correct is documented here:

http://tools.ietf.org/html/rfc2223#page-12

  Obsoletes

      To be used to refer to an earlier document that is replaced by
      this document.  This document contains either revised information,
      or else all of the same information plus some new information,
*>    however extensive or brief that new information is; i.e., this
*>    document can be used alone, without reference to the older
*>    document.

So the meta-data of rfc5246 is definitely factually incorrect,
because neither of the stuff that is described by the documents
that rfc5246 claims to obsolete can be implemented from rfc5246 ALONE!

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Apr 2012 09:38:15 -0700

> http://www.ietf.org/iesg/statement/rfc-metadata-errata.html

Of course. And, if you read that document, you will see what you are reporting is not a minor errata for meta-data, but a major disagreement about what "Obsoletes" means.

> that rfc5246 claims to obsolete can be implemented from rfc5246 ALONE!

I can see your point, and think that the IETF might be using "Obsoletes" incorrectly in this and many other cases, given the text you quote here. As I said earlier, that would be an IETF process discussion. That does not mean you can correct it with an errata, as the document you point to above clearly says.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Apr 2012 18:55:32 +0200 (MEST)

Paul Hoffman wrote:
> Martin Rex wrote:
> Of course. And, if you read that document, you will see what you are
> reporting is not a minor errata for meta-data, but a major disagreement
> about what "Obsoletes" means.

What Obsoletes: means *IS* standardized in rfc2223.

The reported errata is actually a minor technical defect.

> I can see your point, and think that the IETF might be using "Obsoletes"
> incorrectly in this and many other cases, given the text you quote here.
> As I said earlier, that would be an IETF process discussion. That does
> not mean you can correct it with an errata, as the document you point
> to above clearly says.

Actually, the above definition of Obsoletes *DESCRIBES* the current IETF
Process.  There may be invalid uses of Obsoletes: headers that may
be accidental on the part of the authors or of the WG, and a few times
that might have even been "political misappropriation".  But just because
noone reported (or objected) to the incorrect Meta-Information on
IETF LC doesn't turn factually incorrect information into facts.

But unless the IETF Process is changed, such uses are technical defects
that only cause confusion to readers of the affected RFCs.  The IETF
process to fix document defects is the Errata system.

What _you_ might be looking for instead is a Meta-Data to the effect
"Successor to Protocol: xxxx"

See the correct use of the "Obsoletes:" Meta-Data for the HTTP protocol:

  rfc1945   HTTP/1.0
  rfc2068   HTTP/1.1
  rfc2616   HTTP/1.1  Obsoletes: 2068

document rfc2616 truely obsoletes rfc2068, but neither rfc2068 nor
rfc2616 obsolete rfc1945.

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 17 Apr 2012 08:41:16 +0200

> "The Transport Layer Security (TLS) Protocol Version 1.2".
[...]

> Reported by: Martin Rex <[email-masked]>

It looks like a valid report to me.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Apr 2012 10:17:44 -0700

I don't concur with this report.

> "The Transport Layer Security (TLS) Protocol Version 1.2".

On the other hand, IKEv2 obsoleted IKE.
http://tools.ietf.org/html/rfc4306

So I don't this is as clear cut as you suggest.

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 17 Apr 2012 22:53:41 +0200

> So I don't this is as clear cut as you suggest.

In that case didn't IKEv2 actually made IKE obsolete?
It is pretty different than the TLS case where
TLS 1.0 is in widespread use several years after it
has been marked as obsolete.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Apr 2012 16:56:26 -0400

> has been marked as obsolete.

I'm not sure I understand what you mean. Those markings are
produced at the time the RFC is published, so they're not really
contingent on future deployment results, but rather on the
IETF's intentions.

-Ekr

---

From: Yoav Nir <[email-masked]>
Date: Wed, 18 Apr 2012 00:22:26 +0300

> has been marked as obsolete.

IKEv2 is 7 years old, and IKEv1 is still the rule, while IKEv2 is the exception. It's very similar to TLS 1.1/1.2 vs 1.0, and IPv6 vs v4.

Unless there's a good technical reason to keep using the old protocol, such that it does something that was removed from the new version, I think it's right that new versions will obsolete older versions. There's no reason to implement TLS 1.0/1.1 today except for backward compatibility with existing systems that are out there. The fact that A obsoletes B does not mean that vendors should delete the code that does B.

There is an issue that goes beyond notation, though. When new stuff is defined (like extensions or ciphersuites), it will usually reference the newest RFC. Usually there will be no problem implementing that same extension or ciphersuite with TLS 1.1 or 1.0 (or even SSLv3). So the question is, if we have something new (like SPDY and the NPN extension), does it need to be tied to the latest TLS (1.2 in our case)?

You could argue that for SPDY you need a new client and a new server, so you might as well have them do it only over TLS 1.2, but that is not how Google and Mozilla implemented this. 

Yoav

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Apr 2012 00:10:44 +0200 (MEST)

> So I don't this is as clear cut as you suggest.

The instruction given to RFC authors in rfc2223 page 12 about what Obsoletes
is _supposed_ to convey is IMHO fairly clear cut.

If you want to implement TLSv1.0 (i.e. interoperability with TLS peers
using protocol version { 0x03,0x01 }, the use of rfc2246 is essential
and unavoidable, because rfc5246 is lacking important information).

As it turns out, a few document authors & document shepherds did not pay
attention to the definition and purpose of the Obsoletes Header field
on Page 12 of rfc2223 "Instructions to RFC Authors"
and factually incorrect information got published in headers of some RFCs.

Factually incorrect Obsolete headers have created more than one
discussion and require the IESG to assess when it is OK
and why it might be necessary a to reference RFCs that were marked
"Obsolete" normatively -- something which would not be necessary
if the RFC authors had used the Obsoletes: correcty, as defined
in rfc2223, page-12.

But rather than reiterating Epicycles-like theories to describe such
exceptions, the engineering solution would be to fix the defect and
obviate all of:
confusion, complex exceptions and regular discussions about it.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Apr 2012 00:34:08 +0200 (MEST)

> contingent on future deployment results, but rather on the

The purpose of that Marking is described in a document called
  rfc2223 "Instructions to RFC Authors".

In my ears, your argument sounds somewhat in the direction of:

"I have been entirely ignoring the rfc2223 purpose of meta-data and
 (ab)used the Obsoletes: header to actively promote newer protocol
 versions and over older protocol versions ... and I want to continue
 ignoring rfc2223 and (ab)use the Obsoletes: header in that fashion.
 I do not care how much that (ab)use might confuse other readers
 of the affected RFCs."

... specifically readers that try to parse RFC meta-data
as OFFICIALLY specified by the IETF, i.e. according to rfc2223...
(which currently seems to apply to tools/IDNits and the RFC Editor).

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Apr 2012 15:39:37 -0700

> (which currently seems to apply to tools/IDNits and the RFC Editor).

I can't speak for what it sounds like in your ears, but that's not what
I'm saying.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Apr 2012 01:31:35 +0200 (MEST)

> I can't speak for what it sounds like in your ears, but that's not what

But I fail to see any difference between what you're _implying_ and
what the message that I'm getting.

Please look at the WHOLE section 12 of rfc2223, that defines the two Headers
Updates: & Obsoletes and their exact purpose:

  https://tools.ietf.org/html/rfc2223#section-12

   12. Relation to other RFCs

   Sometimes an RFC adds information on a topic discussed in a previous
   RFC or completely replaces an earlier RFC.  There are two terms used
   for these cases respectively, Updates and Obsoletes.  A document that
   obsoletes an earlier document can stand on its own.  A document that
   merely updates an earlier document cannot stand on its own; it is
   something that must be added to or inserted into the previously
   existing document, and has limited usefulness independently.  The
   terms Supercedes and Replaces are no longer used.

   Updates

      To be used as a reference from a new item that cannot be used
      alone (i.e., one that supplements a previous document), to refer
      to the previous document.  The newer publication is a part that
      will supplement or be added on to the existing document; e.g., an
      addendum, or separate, extra information that is to be added to
      the original document.

   Obsoletes

      To be used to refer to an earlier document that is replaced by
      this document.  This document contains either revised information,
      or else all of the same information plus some new information,
      however extensive or brief that new information is; i.e., this
      document can be used alone, without reference to the older
      document.

      For example:

         On the Assigned Numbers RFCs the term Obsoletes should be used
         since the new document actually incorporate new information
         (however brief) into the text of existing information and is
         more up-to-date than the older document, and hence, replaces it
         and makes it Obsoletes.

   In lists of RFCs or the RFC-Index (but not on the RFCs themselves)
   the following may be used with early documents to point to later
   documents.

   Obsoleted-by

      To be used to refer to the newer document(s) that replaces the
      older document.

   Updated-by

      To be used to refer to the newer section(s) which are to be added
      to the existing, still used, document.

Unless rfc-5246 *COMPLETELY*REPLACES* a document listed in Obsoletes:
that information is factually wrong.  CLEARLY.

Should that _not_be_clear_ from rfc2223, then the IETF will need to choose
a different language from English to specify standards, because
it would make it impossible to write non-ambiguous technical specifications
in a language where the above _is_not_clear_.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Apr 2012 03:58:40 +0200 (MEST)

Reiterating on the relevant parts of rfc2223 and their meaning.

rfc2223 says it is an Instruction from the RFC Editor to
RFC authors about EDITORIAL issues (and not about technical issues).

Martin Rex wrote:
>    for these cases respectively, Updates and Obsoletes.
>
>      [...]
> 
>    Obsoletes
> 

There is an editorial reference to "the same or revised information" about
the exact same thing, not a technical reference to a new protocol version.

This is meant in the sense of

   SMTP                     rfc821  -> rfc2821
   Internet message format  rfc822  -> rfc2822 
   PKCS#1                   rfc2313 -> rfc2437 -> rfc3447

in that the *new* document "completely replaces" the old document, and
for independently creating an implementation that is fully interoperable
with the installed base, the old document is no longer needed, it has
been completely replaced by the new document.

   IPv4 -> IPv6 is *NOT* an obsoletion in the editorial sense of rfc2223.

And while it _would_have_been_ possible (and IMHO valuable) for newer TLS
protocol specs to fully include all of the previous procotol versions
(greatly facilitating multi-TLS-version implementations), similar to
the three examples above, this was _NOT_ done for rfc5246.  rfc5246
describes TLSv1.2 exclusively, and among the things it lacks are
the TLSv1.0 PRF, the TLSv1.0 ConnectionState, the TLSv1.0 GenericBlockCipher
record PDU, the TLSv1.0 CertificateRequest PDU, and probably a few more
things beyond the changed digitally-signed struct.

If you look at the most recent IESG statement (about moving documents
to "historic" status),

   http://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html

a guidance was added that sponsoring ADs should describe the intended
purpose of any "Obsoletes:" indicater on new documents,
which to _me_ looks like a realizatin that too little attention spent on
such markers in the past, and since not all RFC author followed the editing
guideline provided by the RFC Editor in rfc2223, RFCs might have gotten
published with factually incorrect Obsoletes: headers in them.

So while fixing the Obsoletes: meta-data on a document is a minor and purely
editorial change to that document (and not a technical change),
that marker does (per rfc2223 section 12) result in a technical statement
about "the old document".  The rfc2223 messsage is "The old document has
become completely irrelevant to independent creation of interoperable
implementations, it has been COMPLETELY REPLACED by the new document."

-Martin