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

<Pasi.Eronen@nokia.com> Wed, 05 July 2006 11:33 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5dg-0001mK-Oo; Wed, 05 Jul 2006 07:33:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5df-0001ir-OI for tls@ietf.org; Wed, 05 Jul 2006 07:33:51 -0400
Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy5df-0003BJ-6j for tls@ietf.org; Wed, 05 Jul 2006 07:33:51 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k65BXlLf002491; Wed, 5 Jul 2006 14:33:50 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 14:33:49 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 14:33:49 +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] Re: draft-ietf-tls-rfc4346-bis-01.txt
Date: Wed, 5 Jul 2006 14:33:49 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2402DDC56B@esebe105.NOE.Nokia.com>
In-Reply-To: <200607031708.TAA13289@uw1048.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
Thread-Index: Acaew30S9Vxi8nr+RnGNXOt/Hz2GrwBYN+Jg
From: <Pasi.Eronen@nokia.com>
To: <martin.rex@sap.com>
X-OriginalArrivalTime: 05 Jul 2006 11:33:49.0502 (UTC) FILETIME=[E272E5E0:01C6A026]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7
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

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