Subject: [TLS] Unfortunate current practices for HTTP over TLS

From: Adam Langley <[email-masked]>
Date: Tue, 18 Jan 2011 17:21:11 -0500

The following is presented mostly for the member's enjoyment:

Network Working Group                                         A. Langley
Internet-Draft                                                Google Inc
Expires: July 5, 2011                                           Jan 2011

            Unfortunate current practices for HTTP over TLS
                      draft-agl-tls-oppractices-00

Abstract

   This document describes some of the unfortunate current practices
   which are needed in order to transport HTTP over TLS on the public
   Internet.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 5, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Handshake message fragmentation  . . . . . . . . . . . . . . .  4
   3.  Protocol Fallback  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  More implementation mistakes . . . . . . . . . . . . . . . . .  6
   5.  Certificate Chains . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Insufficient Security  . . . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Changes . . . . . . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.  Introduction

   HTTP [RFC2616] is one of the most common application level protocols
   transported over TLS [RFC5246].  (This combination is commonly known
   as HTTPS based on the URL scheme used to indicate it.)  HTTPS clients
   have to function with a huge range of TLS implementations, some of
   higher quality than others.  This text aims to document some of the
   behaviours of existing HTTPS clients that are designed to ensure
   maximum interoperability.

   This text should not be taken as a recommendation that future HTTPS
   clients adopt these behaviours.  The security implications of each
   need to be carefully considered by each implementation.  However,
   these behaviours are common and the authors consider it better to
   document the state of practice than to simply wish it were otherwise.

2.  Handshake message fragmentation

   Many servers will fail to process a handshake message that spans more
   than one record.  These servers will close the connection when they
   encounter such a handshake message.  HTTPS clients will commonly
   ensure against that by either packing all handshake messages in a
   flow into a single record, or by creating a single record for each
   handshake message.

3.  Protocol Fallback

   Despite it being nearly twelve years since the publication of TLS 1.0
   [RFC2246], around 3% of HTTPS servers will reject a valid TLS
   "ClientHello".  These rejections can take the form of immediately
   closing the connection or a fatal alert.  Intolerance to the
   following has been observed:

      Advertising version TLS 1.0.

      Advertising a TLS version greater than TLS 1.0 (around 2% for 1.1
      or 1.2, around 3% for greater than 1.2).

      Advertising a version greater than 0x03ff (around 65% of servers)

      The presence of any extensions (around 7% of servers)

      The presence of specific extensions ("server_name" and
      "status_request" intolerance has been observed, although in very
      low numbers).

      The presence of any advertised compression algorithms

   Next, some servers will misbehave after processing the "ClientHello"
   message.  Negotiating the use of "DEFLATE" compression can result in
   fatal "bad_record_mac", "decompression_failure" or
   "decryption_failed" alerts.  Notably, OpenSSL prior to version 0.9.8c
   will intermittently fail to process compressed finished messages due
   to a work around of a previous padding bug.

   Lastly, some servers will negotiate the use of SSLv3 but select a
   TLS-only cipher suite.

   In all these cases, HTTPS clients will often enter a fallback mode.
   The connection is retried using only SSLv3 and without advertising
   any compression algorithms.  (This is obviously an easy downgrade
   attack.)  Also, the fallback can be triggered by transient network
   problems, which often manifest as an abruptly closed connection.
   Since SSLv3 does not provide any means of Server Name Indication
   [RFC3546], the fallback connection can use the wrong certificate
   chain, resulting in a very surprising certificate error.

4.  More implementation mistakes

   Non-fatal errors in version negotiation also occur.  Some 0.2% of
   servers use the version from the record header.  Around 0.6% of
   servers require that the version in the "ClientHello" and record
   header match in order to respect the version in the "ClientHello".  A
   very low number of servers echo whatever version the client
   advertises.

   In the event that the client supports a higher protocol version than
   the server, about 0.4% of servers require that the RSA
   "ClientKeyExchange" message include the server's protocol version.

   Some 30% of servers don't check the version in an RSA
   "ClientKeyExchange" at all.

5.  Certificate Chains

   Certificate chains presented by servers will commonly be missing
   intermediate certificates, have certificates in the wrong order and
   will include unrelated, superfluous certificates.  Servers have been
   observed presenting more than ten certificates in what we assume is a
   drive-by shooting approach to including the correct intermediate
   certificate.

   In order to validate chains which are missing certificates, some
   HTTPS clients will collect intermediate certificates from other
   servers.  Clients will commonly put all the presented certificates
   into a set and try to validate a chain assuming only that the first
   certificate is the leaf.

6.  Insufficient Security

   Some 65% of servers support SSLv2 (beyond just supporting the
   handshake in order to upgrade to SSLv3 or TLS).  HTTPS clients will
   typically not support SSLv2, nor send SSLv2 handshakes by default.
   Of those servers, 80% support the export ciphersuites.  (Although
   about 3% of those servers negotiate weak ciphersuites only to show a
   warning.)

   Some servers will choose very small multiplicative group sizes for
   their ephemeral Diffie-Hellman exchange (for example, 256-bits).
   Some HTTPS clients will reject all multiplicative group sizes smaller
   than 512-bits while others will retry after demoting DHE ciphersuites
   in their "ClientHello".

7.  Acknowledgements

   Yngve Pettersen made significant contributions and many of the
   numbers in this document come from his scanning work.  Other numbers
   were taken from Ivan Ristic's SSL Survey.

   Thanks to Wan Teh Chang for reviewing early drafts.

8.  Normative References

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 3546, June 2003.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

---

From: Martin Rex <[email-masked]>
Date: Wed, 19 Jan 2011 00:34:06 +0100 (MET)

Nice collection -- thank you for the effort!.

Do we need a new document category "WCP" (worst current practice)?  :)

>From the SSLv3 draft302 document ("Work in progress" according to rfc5746):

   5.2 Record layer

   The SSL Record Layer receives uninterpreted data from higher layers
   in non-empty blocks of arbitrary size.

   5.2.1 Fragmentation

   The record layer fragments information blocks into SSLPlaintext
   records of 2^14 bytes or less.  Client message boundaries are not
   preserved in the record layer (i.e., multiple client messages of
   the same ContentType may be coalesced into a single SSLPlaintext
   record).

For experimentation I put together a few lines of code for a
simple TCP communication relaying that shreds TLS records containing
handshake messages into pathological fragments (1byte,2byte,3byte,...)
And I'm actually having difficulties find TLS implementations
that can cope with this.

Some (record layer) TLS code I've looked at makes a number of flawed
assumptions about fragmentation, and fixing that code to align with
the _real_ specifiction requires a non-trivial change of the code
modularization of the record layer...

>
> 3.  Protocol Fallback
>
>    Intolerance to the following has been observed:
>

Keep in mind that this is about the first few bytes sent on a
new network connection.  The purpose of the check is a heuristic
to distinguish a real TLS connection attempt (initial ClientHello)
from arbitrary other protocols instead of letting the protocol
parser engine produce a potentially confusing error message about
data that obviously isn't meant to be TLS in the first place.

Servers that tolerate >=4 versions ahead of what is currently
defined SSLv3{0x03,0x00} -> TLSv1.2{0x03,0x03} provide sufficient
slack that they are no problem for the evolution of the TLS protocol.

TLS implementations that are completely agnostic to the version
will AFAIK confuse DTLS and TLS.

>    attack.)

Fallback mode is mostrly restricted to a few Web Browser that are
curiously exploring bleeding-edge TLS extensions.  Most programmatic
clients don't have a fallback mode, because the fallback has to
be performed at the application level over a new network connection,
potentially including proxy traversals.  Programmatic clients are
more likely to send very feature-conservative ClientHellos from
the beginning (no TLS extensions and either TLSv1.0 or SSLv3).

>
>    Also, the fallback can be triggered by transient network

Since a significant fraction of the installed base browsers and
most of the programmatic clients do not send a server name indication
in the first place, the effect is more of a common annoying
certificate error pointing to an inconsiderate/misconfigured server.

The majority where I've encountered such errors, it was with
servers and hostnames belonging to the same organization, so
the problem could be entirely avoided by a sensible admin through
the simple use of adequate TLS server certs, listing all of the servers
alternative hostnames.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 18 Jan 2011 16:02:38 -0800

>    Lastly, some servers will negotiate the use of SSLv3 but select a

Which cipher suites do you consider to be TLS-only?

Mike

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Wed, 19 Jan 2011 01:16:30 +0100

>>     Lastly, some servers will negotiate the use of SSLv3 but select a

The AES suites are AFAIK only defined for TLS 1.0 and higher. And there  
are also other ciphersuites that are defined for specific versions and  
higher, particularly the SHA-256 suites.

See also  
<http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx>

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Wed, 19 Jan 2011 01:16:28 +0100

> slack that they are no problem for the evolution of the TLS protocol.

We are not in this case talking about the *Record* protocol version, we  
are talking about the *Client Hello* version field. Therefore, the server  
would already have decided that the framework was a valid TLS Protocol  
record message before it could process the Client Hello (0x16 <version  
bytes> <record length> <payload or (record length) bytes>), so there is no  
possibility of confusion, unless a protocol started using not just the  
record framing used by TLS, but also the same protocol record identifiers  
for the records and the handshake.

I have no objection to a server refusing to accept a connection from a  
client specifying a Record protocol version higher than it supports; that  
is why the recommendation for that is something like "the lowest/earliest  
version the client knows the server supports".

So a future client that do not want to talk to servers supporting protocol  
version 3.x could send 4.0, for example, and a 3.x server would be  
perfectly justified to send a unsupported version alert (or something  
similar) and shut down the connection.

Most clients today signals 3.1 as the Record Protocol version to the  
server, except when they are in SSLv3-only version rollback mode (and for  
Opera, in the "TLS 1.0 with 3.0 as record protocol"-mode), which is not a  
real problem since only 1% of servers seem to be SSL v3-only, and only a  
very small fraction of those are version intolerant in the 3.x range.

OTOH, servers are required, by all the versions of SSL and TLS, to accept  
that clients sends a higher version than the server supports.

As I have mentioned earlier, the reason the 4.x+ intolerance could be a  
future issue is that it complicates a future migration to the next major  
protocol version, possibly leading a choice between blocking a security  
vulnerabilities and preserving interoperability. Currently 75-80% of  
Renego patched servers have this issue, vs. ~64% for all servers.

> will AFAIK confuse DTLS and TLS.

Given that the record protocol version field should indicate which type of  
TLS the client is attempting to initiate, I doubt there would be any  
confusion, quite aside from the fact that DTLS is AFAIK not intended for  
TCP style connections.

> curiously exploring bleeding-edge TLS extensions.  Most programmatic

Version fallback was implemented long before TLS Extensions were  
implemented, for the simple reason that many SSL v3 servers did not  
tolerate TLS 1.0 being signaled, and there is still a small fraction  
(0.1%) of those servers around.

> the beginning (no TLS extensions and either TLSv1.0 or SSLv3).

That is probably correct, but programmatic clients would probably also be  
used against a limited number of servers, and any intolerances that would  
cause a handshake failures would be diagnosed and fixed quickly.

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 18 Jan 2011 16:34:32 -0800

The SHA-256 cipher suites aren't compatible with SSLv3 since the SSLv3
spec only shows what to do with MD5 and SHA-1.  But there is nothing
about AES which is incompatible with SSLv3, and indeed my server is able
to negotiate non-SHA-256 AES_CBC cipher suites with SSLv3 clients that
offer them.

So my question is now:

     If a client offers AES cipher suites in a ClientHello with a
     version of 0300, why is it wrong to choose one of them?

Mike

Yngve N. Pettersen (Developer Opera Software ASA) wrote:
> On Wed, 19 Jan 2011 01:02:38 +0100, Michael D'Errico 
> <[email-masked]> wrote:
> 
>> Adam Langley wrote:
>>>  3.  Protocol Fallback

---

From: Martin Rex <[email-masked]>
Date: Wed, 19 Jan 2011 02:13:21 +0100 (MET)

>      version of 0300, why is it wrong to choose one of them?

I'm not aware of _any_ reason why the ciphersuites defined in rfc-3268.

In fact, if you look at rfc-3268:

Cipher Usage

   The new ciphersuites proposed here are very similar to the following,
   defined in [TLS]:

   TLS_RSA_WITH_3DES_EDE_CBC_SHA
   TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
   TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
   TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

and then look up these cipher suites in rfc-2246 and then in
SSLv3 draft302.txt, you ought to realize that these "very similar"
cipher suites are really SSLv3 cipher suites.

Using and interoperating AES cipher suites from rfc-3268 with
Firefox and OpenSSL works without any additional thoughts.
(preventing it from working probably require additonal code).

Since AES128 is faster than tripleDES it would be unreasonable
to leave this cipher suite _not_ working with SSLv3.

But I know of at least one TLS implementation shipped by a large vendor
that aborts on the combination of rfc-3268 cipher suites and SSLv3.

-Martin

---

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 18 Jan 2011 17:53:59 -0800

> that aborts on the combination of rfc-3268 cipher suites and SSLv3.

Eric Lawrence explained this in the blog post "AES is not a valid
cipher for SSLv3":
http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx

Wan-Teh

---

From: Tim Dierks <[email-masked]>
Date: Tue, 18 Jan 2011 21:25:18 -0500

He asserted SSL3/AES was not valid, but he didn't explain his rationale.

Given that there is no standards-body ownership of SSL3, the correctness of
AES ciphersuites is a moot point. However, Postel's robustness principle
would tend to indicate that when a server selects such a ciphersuite, it
would be best for a client to play along, correct or not. I can't
immediately see any security reason why you'd be willing to negotiate SSL3,
but turn up your nose at an insufficiently blessed AES ciphersuite.

 - Tim

On Tue, Jan 18, 2011 at 8:53 PM, Wan-Teh Chang <[email-masked]> wrote:

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

---

From: Martin Rex <[email-masked]>
Date: Wed, 19 Jan 2011 20:07:02 +0100 (MET)

> Wan-Teh Chang <[email-masked]> wrote:
> 
> > Martin Rex <[email-masked]> wrote:
> > >

The info in that blog is very disappointing and looks lame to me.

Why didn't they fix this defect after noticing the interop problem?
4 years have passed and this annoying defect has persisted through
2 service packs and a major OS release.

> but turn up your nose at an insufficiently blessed AES ciphersuite.

I assume you're the one listed as "Tim Dirks, Consensus Development"  :)

 as (co)author on the right top here:
        http://tools.ietf.org/html/rfc2246
 and potentially involved in the cipher suite interim registration here:
        http://tools.ietf.org/html/draft-ietf-tls-protocol-02#page-51

The definition of cipher suites in the design of SSL and TLS is
mostly orthogonal to the protocol version, and the change control
was over the cipher suite registry was undoubtedly transferred
to the TLS.  If cipher suites had ever been conceived to be
protocol-version-specific, they would have partitioned the
cipher suite code points.

Quite obviously, the cipher suite registry was _NOT_ partitioned
for TLSv1.0.  cipher suites were issued with no distinction whatsoever,
so they were clearly meant to apply in a protocol-version-independent
fashion, forwards and backwards.

I agree that impairing interoperability without a convince rationale
why doing otherwise would create a security problem is an extremely
poor engineering decision (commonly referred to as "bug").

Unless there is a (currently undocumented) security problem when
a client agrees to using an rfc-3268 cipher suite with protocol
version {0x03,0x00}, when that very same client would successfully
complete the handshake if the server chose a more traditional
cipher suite (like TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }),
then such a client is defective/interoperability-impaired, and
it would be much more benficial to the community to fix the
(probably trivial to fix code-wise) defect rather than
documenting how long the problem has been known and ignored,
fully aware of the usability problems it inflicts on the consumers
of the technology.

-Martin

---

From: Tim Dierks <[email-masked]>
Date: Wed, 19 Jan 2011 14:32:26 -0500

>        http://tools.ietf.org/html/draft-ietf-tls-protocol-02#page-51

"Dierks", but yes, that's no coincidence.

> fashion, forwards and backwards.

I think I'm in a position of authority to say that we didn't seriously
consider the issue and there was no intention one way or the other about
whether newly-defined ciphersuites were valid in SSLv3 or not. Overlaps
needed to be excluded to avoid negotiation issues, but other than that, the
issue wasn't considered. That's why I say that arguments about what is
"correct" or not are really moot, because there's no actual standard that
specifies one way or the other.

 - Tim

---

From: Marsh Ray <[email-masked]>
Date: Wed, 19 Jan 2011 14:23:49 -0600

On 01/19/2011 01:07 PM, Martin Rex wrote:
>
> If cipher suites had ever been conceived to be

+1

We have to keep in mind that SSLv3 is deprecated abandon-ware, but this 
premise "AES ciphers are not valid choices for SSLv3" is wrong.

If the client proposes advertises a range of protocol versions and the 
server picks a value from that range, and if the client proposes a set 
of ciphersuites and the server picks a ciphersuite from that set, then 
interoperability should ensue.

Note the similarity with the servers that fail to handshake with clients 
who propose extensions. "SSLv3 does not allow extensions" was the 
justification given that time. SSL/TLS is an extensible protocol, just 
because some options weren't defined at the time of the core protocol 
version doesn't mean they're invalid to use. The handshake negotiation 
was designed to allow this.

The problem is that the client is in some sort of "fall back to SSLv3" 
heuristic mode. The reason clients are forced to do that is the 
occasional presence of poorly interoperating servers.

The root cause is thus the poorly interoperating servers. They are the 
stratospheric chlorofluorocarbons catalyzing away the ozone. They do 
damage to the ecosystem with a large multiplier effect.

The only solution is to relentlessly pursue interoperability and be 
diligent about providing updates.

- Marsh

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 19 Jan 2011 13:59:19 -0800

On Wed, Jan 19, 2011 at 12:23 PM, Marsh Ray <[email-masked]> wrote:
> heuristic mode. The reason clients are forced to do that is the occasional
> presence of poorly interoperating servers.
>
> The root cause is thus the poorly interoperating servers.

For the SSLv3 AES cipher suite problem, it is the client (in SChannel)
that is poorly interoperating.

Another problem is how an RFC of a TLS feature references TLS.  It
usually references the latest version of TLS only.  For example, RFC
5746 (the TLS renegotiation indication extension) references the TLS
1.2 RFC (RFC 5246) only.  An implementor could be misled into thinking
the TLS feature is only applicable to that version of TLS.

Wan-Teh

---

From: Martin Rex <[email-masked]>
Date: Wed, 19 Jan 2011 23:15:50 +0100 (MET)

> the TLS feature is only applicable to that version of TLS.

While you're correct about a number of TLS-related documents,
RFC5746 is an exception to this tradition and refers to all
existing versions of TLS explicitly, and to SSLv3 on top of that.

http://tools.ietf.org/html/rfc5746

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 20 Jan 2011 01:54:11 +0100 (MET)

Martin Rex wrote:
> > usually references the latest version of TLS only.
> >                   ... An implementor could be misled into thinking
> While you're correct about a number of TLS-related documents ...

I believe that some of the TLS related RFCs use the Obsolete/Update
markers in a fashion quite different from how these markers are
meant to be used.  An a small error in that tagging, that appears
to have started with rfc-4366, has propagated to other TLS-related RFCs.
e.g.  4346, ->(4366), ->5246, ->6066

Quoting from RFC2223 "Instructions to RFC Authors"
http://tools.ietf.org/html/rfc2223#section-12

   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, the defective "obsoletes" allegations of the base TLS
protocol specs have adversely affected the third update of the
TLS extensions document (rfc-6066).  The second update transition
of the TLS extensions document 3546->4366 was correct about the
obsoletion (but is missing the update: marker)

 to implement TLSv1.0 with TLS extensions you can use RFCs 2246+4366
 to implement TLSv1.1 with TLS extensions you can use RFCs 4346+4366

however

 2246+6066 is insufficient to implement TLSv1.0 with TLS extensions and
 4346+6066 is insufficient to implement TLSv1.1 with TLS extensions

--you still need 4366 because the definition of the Extended Hello PDU
is not part 6066.  6066 is an updated version of the "leftover parts"
of 4366 that didn't make it into 5246--which bars it from obsoleting 4366.

Overview of the header markings for some TLS documents:

for the TLS Protocol documents:

  TLSv1.0   rfc-2246  - (OK)

  TLSv1.1   rfc-4346  shows (INVALID): Obsoletes: 2246
                      MISSING:         Updates: 2246

  TLSv1.1   rfc-5246  shows (INVALID): Obsoletes: 3268, 4346, 4366
                      shows (OK):      Updates: 4492
                      MISSING:         Updates: 2246, 3268, 4346, 4366

and for TLS Extensions documents:

  TLSext    rfc-3546  shows (OK):      Updates: 2246

  TLSext    rfc-4366  shows (OK):      Obsoletes: 3546
                      MISSING:         Updates: 2246, 4346

  TLSext    rfc-6066  shows (INVALID): Obsoletes: 4366
                      MISSING:         Updates: 4366, 5246

TLS v1.0, TLSv1.1 and TLSv1.2 are protocol with small and subtle
differences. But some of the information (like the Certificate handshake
message PDU used by SSLv3,TLSv1.0,TLSv1.1) is not part of the
TLS v1.2 spec (rfc-5246), so according to rfc-2223, the allegation
of rfc-5246 to obsolete the TLSv1.0 and TLSv1.1 _spec_documents_
is clearly invalid.

An example of correct obsoletion is the three (base) HTTP protocol specs:

   rfc1945   HTTP/1.0  @PROPOSED
   rfc2068   HTTP/1.1  @PROPOSED
   rfc2616   HTTP/1.1  @DRAFT    (Obsoletes: 2068)

to implement HTTP/1.0 you only need 1945, and to implement HTTP/1.1 you
only need 2616, therefore 2068 meets the rfc2223 definition of Obsolete.

Now there is an irony to this.  The incorrect markers on rfc-4346 appear
to have started the problem for the TLS-related documents.  And it is
exactly the document header of rfc-4346 with the invalid Obsolete:
marker that gets used for illustration of document header formatting
in rfc-5741:

  http://tools.ietf.org/html/rfc5741#page-4

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 20 Jan 2011 15:02:17 +0100 (MET)

Ooops.   I meant CertificateRequest not Certificate.

TLSv1.0:  http://tools.ietf.org/html/rfc2246#section-7.4.4
TLSv1.1:  http://tools.ietf.org/html/rfc4346#section-7.4.4
TLSv1.2:  http://tools.ietf.org/html/rfc5246#section-7.4.4

There is a significant PDU change from TLSv1.1 -> TLSv1.2.
(insertion of a SignatureAndHashAlgorithm list)

The change between SSLv3/TLSv1.0 and TLSv1.1 is "fairly" small
(unknown to some and many implementations have it wrong).

-Martin