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

[<[e-mail]>]

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:[e-mail]] 
> Sent: 03 July, 2006 20:09
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [e-mail]; [e-mail]
> Subject: Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
> 
> [e-mail] 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls