Bodo Moeller wrote:
> What remains is my main conclusion that the language in the
> specification in this regards is a total mess, and that we can't just
> look what we would *like* the specification to be, but mostly at what
> will work best with the implementations that are actually out there.

I agree. Here's some suggested text; let's see if we can improve on
it somehow...

In Section 6.2.1, when describing the version field, add the 
following text:

   "Note that a client that supports multiple versions of TLS may not
   know what version will be employed before it receives ServerHello.
   See Appendix E for discussion about what record layer version
   number should be employed for ClientHello."

And rewrite 

E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0

   For historical reasons and in order to avoid a profligate
   consumption of reserved port numbers, application protocols which
   are secured by various versions of TLS (1.0, 1.1, and 1.2) and SSL
   (2.0 and 3.0) all frequently share the same connection port: for
   example, the https protocol (HTTP secured by SSL or TLS) uses port
   443 regardless of which security protocol it is using. Thus, some
   mechanism must be determined to distinguish and negotiate among the
   various protocols.

   TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and
   use compatible ClientHello messages; thus, supporting all of them
   is relatively easy.

   A TLS 1.2 client who wishes to negotiate with such older servers
   will send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS
   1.2) in ClientHello.client_version. If the server does not support
   this version, it will respond with ServerHello containing an older
   version number. If the client agrees to use this version, the 
   negotiation will proceed as appropriate for the negotiated protocol.

   If the version chosen by the server is not supported by the client 
   (or not acceptable), the client MUST send a "protocol_version" alert 
   message and close the connection.

   If a TLS server receives a ClientHello containing a version number
   greater than the highest version supported by the server, it MUST
   reply according to the highest version supported by the server.

   A TLS server can also receive a ClientHello containing version
   number smaller than the highest supported version. If the server
   wishes to negotiate with old clients, it will proceed as
   appropriate for the highest version supported by the server that 
   is not greater than ClientHello.client_version. For example, if 
   the server supports TLS 1.0, 1.1, and 1.2, and client_version is
   TLS 1.0, the server will proceed with a TLS 1.0 ServerHello. If 
   server supports (or is willing to use) only versions greater 
   than client_version, it MUST send a "protocol_version" alert 
   message and close the connection.

   Whenever a client already knows the highest protocol known to a
   server (for example, when resuming a session), it SHOULD initiate
   the connection in that native protocol.

      Note: some server implementations are known to implement version
      negotiation incorrectly. For example, there are buggy TLS 1.0
      servers that simply close the connection when the client offers
      a version newer than TLS 1.0. Also, it is known that some
      servers will refuse connection if any TLS extensions are
      included in ClientHello.

      Interoperability with such buggy servers is a complex topic
      beyond the scope of this document, and may require multiple
      connection attempts by the client.

   Earlier versions of the TLS specification were not fully clear on
   what the record layer version number (TLSPlaintext.version) should
   contain when sending ClientHello (i.e., before it is known which
   version of the protocol will be employed). Thus, TLS servers
   compliant with this specification MUST accept any value {03,XX} as
   the record layer version number for ClientHello.

   TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number. Typical values
   would be {03,00}, the lowest version number supported by the
   client, and the value of ClientHello.client_version. No single
   value will guarantee interoperability with all old servers, 
   but this is a complex topic beyond the scope of this document.

(and move all discussion of SSL 2.0 discussion to separate section,
appendix E.2)

Best regards,
Pasi

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls