RE: [TLS] Open issue: Record Version Numbers

[<Pasi.Eronen@xxxxxxxxx>]

Hi Bodo,

Thanks for your comments. I agree about the first change;
the second change I would reword slightly...

>    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.  Similarly, servers can easily handle clients
>    trying to use future versions of TLS as long as the clients still
>    support the highest protocol version available in the server.

This assumes the ClientHello format remains the same; perhaps this
is worth mentioning explicitly:

    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.  Similarly, servers can easily handle clients
    trying to use future versions of TLS as long as the ClientHello
    format remains compatible, and the client support the highest
    protocol version available in the server.

And here's the slightly cleaned text about SSL 2.0 compatibility:

E.2 Compatibility with SSL 2.0

   TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
   version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message
   MUST contain the same version number as would be used for ordinary
   ClientHello, MUST use CHALLENGE-LENGTH of 32, and MUST encode the
   supported TLS ciphersuites in the CIPHER-SPECS-DATA field as
   described below.
  
      Warning: The ability to send version 2.0 CLIENT-HELLO messages
      will be phased out with all due haste, since the newer
      ClientHello format provides better mechanisms for moving to
      newer versions and negotiating extensions.  TLS 1.2 clients
      SHOULD NOT support SSL 2.0.

   However, even TLS servers that do not support SSL 2.0 SHOULD accept
   version 2.0 CLIENT-HELLO messages. The message is presented below
   in sufficient detail for TLS server implementors; the true definition
   is still assumed to be [SSL2].

   For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
   way as a ClientHello with a "null" compression method and no
   extensions. Note that this message MUST be sent directly on the
   wire, not wrapped as a TLS record. For the purposes of calculating
   Finished and CertificateVerify, the msg_length field is not
   considered to be a part of the handshake message.

       uint8 V2CipherSpec[3];

       struct {
           uint16 msg_length;
           uint8 msg_type;
           ProtocolVersion version;
           uint16 cipher_spec_length;
           uint16 session_id_length;
           uint16 challenge_length;
           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
           opaque session_id[V2ClientHello.session_id_length];
           opaque challenge[V2ClientHello.challenge_length;
       } V2ClientHello;

   msg_length
       The highest bit MUST be 1; the remaining bits contain the 
       length of the following data in bytes. 

   msg_type
       The message type for V2ClientHello is one (1).

   version
       Equal to ClientHello.client_version.

   cipher_spec_length
       This field is the total length of the field cipher_specs. It
       cannot be zero and MUST be a multiple of the V2CipherSpec 
       length (3).

   session_id_length
       The length of the session_id field in bytes; MUST be zero
       for a client that claims to support TLS 1.2.

   challenge_length 
       The length of the challenge field in bytes; MUST be 32 for 
       a client that claims to support TLS 1.2.

   cipher_specs
       This is a list of all CipherSpecs the client is willing and
       able to use. In addition to the 2.0 cipher specs defined in
       [SSL2], this includes the TLS cipher suites normally sent in
       ClientHello.cipher_suites, each cipher suite prefixed by a zero
       byte. For example, TLS ciphersuite {0x00,0x0A} would be sent
       as {0x00,0x00,0x0A}.

   session_id
       This field MUST be empty.

   challenge
       Equal to ClientHello.random.

   Note: Requests to resume a TLS session MUST use a TLS client hello.

Best regards,
Pasi

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