RE: [TLS] Open issue: Record Version Numbers
<Pasi.Eronen@nokia.com> Wed, 25 October 2006 13:27 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcimf-00078j-KO; Wed, 25 Oct 2006 09:27:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcimd-00075i-N6 for tls@ietf.org; Wed, 25 Oct 2006 09:27:03 -0400
Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcimY-0005WX-Fd for tls@ietf.org; Wed, 25 Oct 2006 09:27:02 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9PDQfsb031687; Wed, 25 Oct 2006 16:26:54 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 16:26:17 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 16:26:17 +0300
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: Wed, 25 Oct 2006 16:26:15 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2403500D01@esebe105.NOE.Nokia.com>
In-Reply-To: <20061023090757.GA10448@tau.invalid>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Open issue: Record Version Numbers
Thread-Index: Acb2gs4nln5sTXRrQla1fxlOWzpZWABr5K8A
From: Pasi.Eronen@nokia.com
To: bmoeller@acm.org
X-OriginalArrivalTime: 25 Oct 2006 13:26:17.0543 (UTC) FILETIME=[26DC3D70:01C6F839]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
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
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@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)