RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt

Rob Dugal <RDugal@certicom.com> Wed, 05 July 2006 16:02 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9pO-0006SZ-W4; Wed, 05 Jul 2006 12:02:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9pN-0006SU-I1 for tls@ietf.org; Wed, 05 Jul 2006 12:02:13 -0400
Received: from [66.48.18.194] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy9pM-0007Wn-Pb for tls@ietf.org; Wed, 05 Jul 2006 12:02:13 -0400
Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 6E306100233CB; Wed, 5 Jul 2006 12:02:09 -0400 (EDT)
Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22484-25; Wed, 5 Jul 2006 12:02:07 -0400 (EDT)
Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 4A01310027FF0; Wed, 5 Jul 2006 12:02:07 -0400 (EDT)
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F2402DDC56B@esebe105.NOE.Nokia.com>
To: <Pasi.Eronen@nokia.com>
Subject: RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
Message-ID: <OFDF711E5E.573D0369-ON852571A2.0057CA09-852571A2.00583B2E@certicom.com>
From: Rob Dugal <RDugal@certicom.com>
Date: Wed, 5 Jul 2006 12:01:24 -0400
X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 07/05/2006 12:01:35 PM, Serialize complete at 07/05/2006 12:01:35 PM
X-Spam-Score: 0.5 (/)
X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31
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>
Content-Type: multipart/mixed; boundary="===============1493826214=="
Errors-To: tls-bounces@lists.ietf.org

FYI - Opera 9 will sometimes send a client hello with SSLv3 as the record 
version and TLSv1 as the client version.
In my tests with SSLv3 & TLSv1 enabled it first sends a client hello with 
TLSv1as the record version and TLSv1 as the client version.
If this handshake fails it retries using SSLv3/TLS1. 

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

<Pasi.Eronen@nokia.com>; wrote on 07/05/2006 07:33:49 AM:

> Martin,
> 
> While your interpretation of the spec does make sense in general, it
> is exactly the opposite of what most implementations seem to use.
> 
> After some additional work with OpenSSL and Mozilla NSS (see my
> reply to Bodo earlier today), *all* the implementations mentioned so
> far (OpenSSL, Mozilla NSS, Microsoft IE, SunJSSE, GnuTLS, PureTLS)
> seem to send 03,01 in both fields (when V2 hellos are disabled, and
> both SSL3 and TLS1.0 are enabled), and *none* of them seems to ever
> send different values in these fields.
> 
> Since the goal of the specification is to help interoperability, the
> right clarification to this ambiguity should not be based solely on a
> "protocol lawyer reading" of the spec (and declaring most current
> implementations "broken"), but also on what existing widely used
> implementations do.
> 
> But as you and Bodo pointed out, while knowing what existing clients 
> do is useful, it's not sufficient: what existing servers do also
> matters. This requires some further investigation...
> 
> (I do agree that for servers, the best guidance seems to be that
> "when receiving ClientHello, ignore the record version (or at least
> the minor version) and try to parse it anyway").
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: ext Martin Rex [mailto:martin.rex@sap.com] 
> > Sent: 03 July, 2006 20:09
> > To: Eronen Pasi (Nokia-NRC/Helsinki)
> > Cc: martin.rex@sap.com; tls@ietf.org
> > Subject: Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
> > 
> > Pasi.Eronen@nokia.com wrote:
> > > 
> > > I agree that the spec is ambiguous in this respect, but I'm not
> > > so sure about what the correct interpretation should be. In 
> > > other words, when a TLS client supports more than one of (SSLv3,
> > > TLSv10, TLSv11), should the record layer version number contain
> > > the lowest supported protocol, or the same value as handshake
> > > layer ClientHello?
> > 
> > It SHOULD contain the lowest protocol version that the client is
> > willing to negotiate.  Anything else is going to cause
> > interoperability problems.  The most interesing question: what does
> > the installed base do today when it receives a client hello with a
> > 3.2 or even 3.3 or 3.4 version the "version" field of the SSL/TLS
> > record protocol AND in the client_version of the ClientHello
> > message.  I expect some servers to choke heavily (and rightfully).
> > 
> > The potential ambiguity is only for the casual reader, there
> > definitely never was an abiguity for the careful protocol
> > implementor.  The SSLv3 spec (which somewhat happened after the
> > fact) does not contain any ambiguity either, because it doesn't
> > define anything other than {3, 0} PDUs and version numbers.
> > 
> > The root of any ambiguity is that the spec fails to clearly seperare
> > version tags for the purpose of negotation (client_version,
> > server_version) and version tags (version) that indicates a
> > particular PDU encoding.
> > 
> > The description of the PDUs in the appendix of SSL/TLS specs contains
> > the protocol version in exactly three distinct variants:
> > 
> >     version
> >     client_version (only in ClientHello and PreMasterSecret)
> >     server_version (only in ServerHello)
> > 
> > All existing specs were NOT ambiguous in that exactly one field was
> > supposed to contain the negotiated version number.  And from the
> > description of the individual PDUs in Appendix A, it should have
> > been obvious to implementors which version field should have been
> > meant, and which one should not have been meant.
> > 
> > There are very few error-free specs, and this particular error (and
> > the correct wording) are fairly easy to figure, IMHO.
> > 
> > 
> > > 
> > > 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.
> > 
> > fine.
> > 
> > >   - When configured in "TLS10 only" mode, sends {03,01} in 
> > >     both fields
> > 
> > fine.
> > 
> > > - Mozilla Firefox 1.5
> > >   - Seems to send V2 ClientHello no matter what the settings??
> > 
> > fine.
> > 
> > > - MS Internet Explorer 6.0
> > >   - When configured in "both SSLv3 and TLSv1.0 allowed" mode,
> > >     sends V3 ClientHello with {03,01} in both fields
> > 
> > broken.
> > 
> > > - SunJSSE (JDK 1.4.2)
> > >   - When configured in "both SSLv3 and TLSv1.0 allowed" mode,
> > >     sends V3 ClientHello with {03,01} in both fields
> > 
> > broken.
> > 
> > > - GnuTLS (10.0.20)
> > >   - When configured in "both SSLv3 and TLSv1.0 allowed" mode,
> > >     sends V3 ClientHello with {03,01} in both fields
> > 
> > broken.
> > 
> > >   - When configured in "SSLv3, TLSv1.0 and TLSv1.1 allowed" mode,
> > >     sends V3 ClientHello with {03,02} in both fields
> > 
> > broken.
> > 
> > > 
> > > In other words: All these implementation seem to follow the
> > > rule that TLSPlaintext.version==ClientHello.client_version, or
> > > use V2 ClientHellos...
> > 
> > Didn't you just say that OpenSSL and Mozilla used a correct behaviour
> > on the client side?
> > 
> > The more interesting question is what SSL/TLS servers do upon receipt,
> > and in particular what they do upon receipt of a high up 
> > version number, like {03,03} or {03,04}.
> > 
> > > 
> > > Given that Yngve's interoperability draft suggests that some
> > > servers incorrectly use the record layer version number for
> > > negotiation, I think the safest clarification would be to 
> > > say that the two version numbers must be equal.
> > 
> > The clarification should say that there's an awfully large installed
> > base that is broken and that the server will likely have to entirely
> > ignore the version number in the record protocol when processing
> > a ClientHello message, and upons sending, should send the lowest
> > version number that they're willing to use.
> > This makes protocol layering not as independent as it should be.
> > 
> > 
> > -Martin
> 
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls