RE: [TLS] Open issue: Record Version Numbers

[<Pasi.Eronen@xxxxxxxxx>]

Yngve Nysaeter Pettersen wrote:

> As I recall there is (or was) a problem with using a length of 32
> with some implementations, which is why Opera, at least is using a
> 16 byte challenge in the SSL v2 Hello (which we are no longer using
> by default).

Hmm... I did some testing, and both IE6 and Firefox 1.5 also use
16-byte challenge in SSLv2 Hello. RFC 2246/4346 are not quite clear
about this: in one part, they say the challenge in V2 hello MUST be
32, but elsewhere, they explain that how the challenge is padded with
zeroes if it's shorter than 32.

Given this, I don't think we should add a new requirement here.
Here's an updated version of the text I proposed (also taking into
account that according to the SSL2 spec, challenge shorter than 16 
or longer than 32 is not legal):

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, 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 between
       16 and 32 (inclusive).

   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
       Corresponds to ClientHello.random. If the challenge length
       is less than 32, the TLS server will pad the data with 
       leading (note: not trailing) zero bytes to make it 32 bytes 
       long.

   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