Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
Bodo Moeller <bmoeller@acm.org> Wed, 05 July 2006 12:28 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy6UC-0007aw-NF; Wed, 05 Jul 2006 08:28:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy6UB-0007ar-FN for tls@ietf.org; Wed, 05 Jul 2006 08:28:07 -0400
Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy6UA-0000Tq-0A for tls@ietf.org; Wed, 05 Jul 2006 08:28:07 -0400
Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1Fy6TX1dvD-0003Nm; Wed, 05 Jul 2006 14:27:32 +0200
Received: by tau.invalid (Postfix, from userid 1000) id 6C8A919527; Wed, 5 Jul 2006 14:27:26 +0200 (CEST)
Date: Wed, 05 Jul 2006 14:27:26 +0200
From: Bodo Moeller <bmoeller@acm.org>
To: Rob Dugal <RDugal@certicom.com>
Subject: Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
Message-ID: <20060705122726.GA30023@iota.site>
References: <20060704094106.GA22002@iota.site> <OFA7588972.5C871003-ON852571A2.003DCFD0-852571A2.003F946E@certicom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <OFA7588972.5C871003-ON852571A2.003DCFD0-852571A2.003F946E@certicom.com>
User-Agent: Mutt/1.5.9i
X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
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
On Wed, Jul 05, 2006 at 07:32:09AM -0400, Rob Dugal wrote: > Bodo Moeller <bmoeller@acm.org> wrote on 07/04/2006 05:41:06 AM: >> On Mon, Jul 03, 2006 at 07:14:15PM +0300, Pasi.Eronen@nokia.com wrote: >>> A quick and totally unscientific survey of what some widely used >>> SSL/TLS implementations do: >>> >>> - OpenSSL (0.9.8) >>> - When configured in "both SSLv3 and TLSv10 allowed" mode, >>> sends V2 ClientHello. >> This is the behavior of OpenSSL versions up to 0.9.7g. Versions >> 0.9.7h and later, including 0.9.8, will actually send a TLS/SSL3 >> format Client Hello message with version number {03,01} in both >> fields. > The 0.9.8 behavior doesn't make sense to me. I think the correct behaviour > would be to encode the minimum protocol {03,00} in the record's protocol > field and the highest protocol {03,01} in the client_hello message's > protocol field. A server that understands only SSLv3 could reject a client > hello message that uses a record protocol of TLSv1. To negotiate with an > SSLv2 server the client must send an SSLv2 client hello so why would the > situation be any different for SSLv3/TLSv1? Using {03,00} for the record protocol field certainly would make the most sense, when you're trying to follow the protocol specification. However, the RFCs aren't totally clear about the situation: RFC 2246 only requests that "a TLS server which wishes to interoperate with SSL 3.0 clients should accept SSL 3.0 client hello messages", but it does not demand that TLS-1.0-*only* servers (with no intention to interoperate with SSL 3.0 clients) tolerate a {03,00} version in the record header. On the other hand, RFC 2246 only says that "TLS clients who wish to negotiate with SSL 3.0 servers should send client hello messages using the SSL 3.0 record format and client hello structure" and does not makes this a "must". The language in RFC 4346 (with another minor protocol version to take into account) does not clear this up, in fact if you try to take it literally it makes matters worse since the backwards compatibility section only mentions SSL 2.0 and SSL 3.0 client hello messages, but no TLS 1.0 client hello messages (which would make a lot of sense for the TLS1.0 + TLS1.1 case). Essentially, OpenSSL 0.9.7h is following a trend set by other client implementations. If everyone was using {03,00} version records to encapsulate TLS 1.0 Client Hellos, then OpenSSL probably would do this too. But there are plenty of broken servers out there, and the experience is that some of these will mistakenly use {03,00} as the client's maximum protocol version, even if this really is higher (and correctly sent in the actual content of the Client Hello message). This means that an obsolete protocol version will be negotiated (SSL 3.0 when both parties actually do support TLS 1.0 or later), and in the case of an RSA key exchange, it may lead to an aborted handshake (since client_version is duplicated in the encrypted premaster secret). Heuristically, sending {03,01} in the record header appears to be less problematic since typical SSL 3.0-only servers will accept this Client Hello without complaining. (Some very broken SSL 3.0 servers used to of problems even with this, but we can't accommodate everything.) I'm not saying that SSL3.0 + TLS1.0 clients *should* use {03,01} for the record protocol field, though. They are absolutely welcome to use {03,00}, and similarly, it is perfect for TLS1.0 + TLS1.1 clients to use {03,01} (TLS 1.0) rather than {03,02} (TLS 1.1), and for future TLS1.1 + TLS 1.2 clients to use {03,02} rather than {03,03}. Sending any value {03,xx} where the respective protocol version is supported by the client looks OK to me, and should be tolerated by servers, even if the server does not know about said protocol version. (If the handshake attempt fails since the server has to downgrade from a protocol {03,xx} supported by the client to {03,yy}, yy < xx, where {03,yy} is not supported by the client, then at least the client will learn about the highest version supported by the server, providing for an informative error message.) This, of course, assumes that the Client Hello format is not actually changed between minor protocol versions. If there were actual significant differences (apart from hello extensions, which rely on a forward compatilibity provision in the original SSL 3.0 and TLS 1.0 specifications), there was bound to be chaos. However, given the current state and the unclear language in RFC 2246 and RFC 4346, we can conclude that it would be utter madness to ever change the Client Hello structure in an incompatible way without changing the major protocol version: If such a change was ever considered necessary, then we'd again have a situation like the current SSL2.0 / SSL3.0+TLS1.x interoperability situation on a higher level, i.e. the Client Hello message would be sent in SSL3.0+TLS1.x format (using the current structure definition) and the Client Hello message would name some version {04,xx}, without being able to use any new features requiring the new native Client Hello format (like we currently can't use Client Hello extensions in SSL 2.0 backwards compatible mode). _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Martin Rex
- RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Pasi.Eronen
- Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Martin Rex
- Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt David Hopwood
- Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Bodo Moeller
- RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Pasi.Eronen
- Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Rob Dugal
- RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Pasi.Eronen
- Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Bodo Moeller
- RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Rob Dugal