Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

[Bodo Moeller <[e-mail]>]

Hanno Böck <[e-mail]>:

Can you quantify that tradeoff? How many devices are there really out
> there that would break? I'd like to have this discussions with
> hard numbers.
>

Finding hard numbers is, well, hard. In general, you find out the whole
picture about what you've broken only after you've broken it.

That doesn't mean that people aren't trying to get good estimates (Ivan
Ristic has done some data collection -- I've include some of his results in
slide 2 of http://www.ietf.org/proceedings/90/slides/slides-90-tls-0.pdf).
However, this doesn't cover other use cases such as an old printer on your
LAN with an SSL 3.0 admin interface.


One solution (keeping downgrade-workarounds and add SCSV):
>
[...]

> Other solution (remove downgrade-workarounds):
>
[...]

> I think the argument is clearly in favor of the latter solution unless
> you have some very good counterarguments.
>

I don't agree with the premise of your reasoning, because these two
approaches are in fact not mutually exclusive. Yes, we should get rid of
downgrade workarounds (browser vendors have been struggling with this for
years). At the same time, the SCSV offers us a general and simple way to
avoid security vulnerabilities when we fail to achieve perfection in that
area.

Less importantly, you've also not considered the complete incentive (or
disincentive, aka "punishment") structure. Disabling the downgrade dance in
one browser could drive that browser's users to a different browser that
"just works" (because it still willingly downgrades itself), which wouldn't
help anyone. In any case, the downgrade dance always punishes broken sites
with bad latency.

Bodo