[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Open issue: Record Version Numbers
Pasi.Eronen@xxxxxxxxx wrote:
>
> Martin Rex wrote:
> > However, the approach of the client using {3,1} in the record
> > protocol will rightfully cause some SSLv3-only Server to abort the
> > handshake, which amounts to a real interoperability problem, so
> > clients ought to be strongly discouraged from taking that approach.
>
> On the other hand, using {3,0} in the record protocol will cause
> some TLS 1.0 servers to abort the handshake (or fail it some way).
> Yngve's draft shows such servers do exist.
There is not problem with requiring broken servers to be fixed.
There is a serious problem with requiring perfectly correct
implementations to be fixed to cater much newer broken implementations.
The availability of patches is likely better for newer implementations
(broken TLSv1) than for older implementations (correct SSLv3).
>
> I don't think arguing which of them does it "rightfully" is very
> useful (as Bodo pointed out, TLS 1.0 spec does not say that TLS
> 1.0-only servers should accept {3,0} in the record version);
On the contrary. The version on the record protocol is a PDU encoding,
and TLS was specifically designed to reuse most of SSLv3.
There is no requirement for a TLSv1 server to agree to talking
SSLv3 {3,1}, but it certainly is required to parse the SSLv3
record procotol without hitches!
>
> As basically all current TLS implementations send {3,1} in the
> record version (when configured to support both SSLv3 and TLS 1.0),
> interoperability with servers that reject this is already broken
> in real world.
Only the (TLSv1) servers that require this hack are broken, and
they're broken in a real stupid fashion. Clients that are sending
{3,1} even with SSLv3 enabled are technically not broken, but they're
not doing what is recommended. Only clients that do not offer the
user a switch to make them behave in the recommended fashion are
broken with regards to the spirit of the spec.
-Martin
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls