RE: [TLS] Open issue: Record Version Numbers
<Pasi.Eronen@nokia.com> Thu, 23 November 2006 13:10 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnELy-0003s3-OC; Thu, 23 Nov 2006 08:10:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnELx-0003ry-RP for tls@ietf.org; Thu, 23 Nov 2006 08:10:57 -0500
Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnELv-00078I-Tp for tls@ietf.org; Thu, 23 Nov 2006 08:10:57 -0500
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kANDAYCc028473; Thu, 23 Nov 2006 15:10:48 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 15:10:11 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 15:10:10 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Open issue: Record Version Numbers
Date: Thu, 23 Nov 2006 15:10:08 +0200
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F240371AF66@esebe105.NOE.Nokia.com>
In-Reply-To: <op.thzgyyw5vqd7e2@killashandra-ii.oslo.opera.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Open issue: Record Version Numbers
Thread-Index: Acb4SZuSGo+szNheQnOXBYF04tkE/AWtL6Lw
From: Pasi.Eronen@nokia.com
To: yngve@opera.com
X-OriginalArrivalTime: 23 Nov 2006 13:10:10.0651 (UTC) FILETIME=[B486FAB0:01C70F00]
X-eXpurgate-Category: 1/0
X-eXpurgate-ID: 149371::061123151049-6F332BB0-5D41E7C5/0-0/0-1
X-Nokia-AV: Clean
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org
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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- RE: [TLS] Open issue: Record Version Numbers Pasi.Eronen
- [TLS] Open issue: Record Version Numbers Eric Rescorla
- Re: [TLS] Open issue: Record Version Numbers Eric Rescorla
- Re: [TLS] Open issue: Record Version Numbers Bodo Moeller
- Re: [TLS] Open issue: Record Version Numbers Martin Rex
- Re: [TLS] Open issue: Record Version Numbers Bodo Moeller
- Re: [TLS] Open issue: Record Version Numbers Martin Rex
- Re: [TLS] Open issue: Record Version Numbers Bodo Moeller
- Re: [TLS] Open issue: Record Version Numbers Martin Rex
- Re: [TLS] Open issue: Record Version Numbers Bodo Moeller
- Re: [TLS] Open issue: Record Version Numbers Martin Rex
- Re: [TLS] Open issue: Record Version Numbers Bodo Moeller
- RE: [TLS] Open issue: Record Version Numbers Pasi.Eronen
- Re: [TLS] Open issue: Record Version Numbers Bodo Moeller
- [TLS] TLS 1.1 and static DH Jan Nordqvist
- RE: [TLS] TLS 1.1 and static DH Pasi Eronen
- RE: [TLS] TLS 1.1 and static DH Peter Gutmann
- RE: [TLS] TLS 1.1 and static DH Pasi.Eronen
- Re: [TLS] TLS 1.1 and static DH Bodo Moeller
- Re: [TLS] TLS 1.1 and static DH Dr Stephen Henson
- RE: [TLS] Open issue: Record Version Numbers Pasi.Eronen
- Re: [TLS] Open issue: Record Version Numbers Bodo Moeller
- Re: [TLS] TLS 1.1 and static DH EKR
- RE: [TLS] Open issue: Record Version Numbers Peter Gutmann
- Re: [TLS] TLS 1.1 and static DH Nelson B Bolyard
- Re: [TLS] TLS 1.1 and static DH Nelson B Bolyard
- Re: [TLS] Open issue: Record Version Numbers Nelson B Bolyard
- Re: [TLS] TLS 1.1 and static DH Peter Gutmann
- Re: [TLS] Open issue: Record Version Numbers tom.petch
- RE: [TLS] TLS 1.1 and static DH Pasi.Eronen
- RE: [TLS] TLS 1.1 and static DH Rob Dugal
- Re: [TLS] TLS 1.1 and static DH Jan Nordqvist
- Re: [TLS] TLS 1.1 and static DH Jan Nordqvist
- Re: [TLS] TLS 1.1 and static DH Rob Dugal
- RE: [TLS] Open issue: Record Version Numbers Pasi.Eronen
- [TLS] Stateless TLS Session Resumption extension … Jan Nordqvist
- RE: [TLS] Stateless TLS Session Resumption extens… Joseph Salowey (jsalowey)
- RE: [TLS] Stateless TLS Session Resumption extens… Joseph Salowey (jsalowey)