Re: [TLS] SCSVs and SSLv3 fallback

[Yoav Nir <[e-mail]>]

On Apr 24, 2013, at 4:59 AM, Martin Rex <[e-mail]> wrote:

> Yngve N. Pettersen wrote:
>> 
>> Martin Rex <[e-mail]> wrote:
>>> 
>>> For any kind of alternative TLS version negotiation, the server ought to
>>> entirely ignore the existing ClientHello.client_version, and use the
>>> new version signaling alone for determining the highest common protocol
>>> version.
>> 
>> Martin, how do you propose to get *rid* of the broken servers, if clients  
>> are not allowed to demonstrate their brokenness?
>> 
>> My point is that the old broken server will "never" go away as long as  
>> clients allow them to function, and new servers will be released in broken  
>> condition because clients are not telling them that they are broken during  
> 
> ... writes the one who has been shipping a multi-stage reconnect fallback
> for years.

What else can Opera do? Ship a browser that works on only 90% of the web? I think they're doing as much as they can to combat new kinds of brokenness. If Microsoft had had this attitude when they had a 98% of the browser market, we would be seeing a lot less brokenness today.

> The Engineering part of IETF is about creating and maintaining interop,
> the IETF is no manufacturer cartel for enforcing planned obsolescense!

The IETF is not a manufacturer's cartel. But if people want to change the way TLS clients behave (for whatever reason), this is the place to discuss it, and maybe document it.

> A non-marginal fraction of the problematic servers are not really broken,
> primarily they're old and based on an old version of the specification.

What old version of the specification had renegotiation info, but didn't have proper version negotiation?  Going strictly by the RFCs a lot more handshakes would be dropped.

> What concerns me *MUCH* more is the reconnect fallback hacks in several
> recent TLS clients (primarily Web Browsers), because that is what is
> causing most of the interop problems (=failed TLS handshakes).
> 
> That negotiating TLSv1.2 by sending ClientHello.client_version = {03,03}
> is an EXTREMELY dumb idea given the installed base should have been
> (and still is) painfully obvious for everyone who cared to check, so
> I really fail to understand why such ostrich behaviour was published
> as rfc5246 in the first place.
> 
> Actually the problem already existed in 2006, when rfc4346 was published.
> Surprise, surprise, ignoring the problem didn't make it go away.
> 
> When revising a protocol, it is a bad idea to perform it in a fashion
> that only works in a fantasy fairy-tale, but instead take into account
> what is going to be interoperable with the real world.
> 
> What is really needed, is a negotiation of TLSv1.2 protocol&features
> that does not need ClientHello.client_version = {03,03}, but instead
> can use ClientHello.client_version = {03,01}.  This would get rid
> of most of the TLS handshake failures and obviate the TLS reconnect
> fallback hacks in clients.  Now _that_ would be really an improvement!

Are you proposing a TLS 1.2 SCSV? If Mozilla hadn't made the decisions to include Camelia in the list of ciphersuites, we would probably have quite a few servers out there that didn't tolerate unknown ciphersuites. As it is, ClientHello.client_version = {03,03} works quite well for the vast, vast majority of web sites. The ostrich wins, and they lived happily ever after.

> But while doing that, we also SHOULD REALLY fix the semantics that are
> currently specified in rfc5246 for the SignatureAlgorithm TLS extension:
> strip all the crap between the contents of that extension and
> signature algorithms in the certificates.
> 
> 
> -Martin