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

[Bodo Moeller <[e-mail]>]

"Florian Weimer" <[e-mail]>:
> On 10/15/2014 11:22 AM, Bodo Moeller wrote:

>> Note that if your server does not support formally obsolete protocol
>> versions, TLS_FALLBACK_SCSV support is a no-op.

> No, only if you support exactly a single TLS version.  Then the presence
of TLS_FALLBACK_SCSV support in the server code is indeed unobservable.

I was teasing. So far at least, every new protocol version has formally
obsoleted the previous version, so we've only ever had a single
non-deprecated TLS version.

Real life, necessarily, is a different matter; that's the real point I
wanted to make.

>> Otherwise, you're making real-world tradeoffs, and I think
>> TLS_FALLBACK_SCSV is a reasonable one to make (with minimal server-side
>> logic to achieve the objective), not "punishment".

> It's still punishes those who are responsible netizens and can update
their servers—simply because they have to apply an update.  Their client
base doesn't even directly benefit from that, it's just to enable their
clients to preserve their own brokeness, so that they can continue to
connect to broken servers that may or may not be out there.

This is right, but I don't consider it "punishment". (And in practice,
you'll have to apply occasional  implementation bugfix updates anyway, and
the protocol change may not pose any extra effort.)

> Meanwhile, those who operate TLS-version-intolerant servers have to
do—nothing.

If you insist on "punishment", the very least happening to them is an
increased rate of incoming connections, and increased latency for their
users. There are no technical means to force them to address that if they
don't care about their users, but in that case, what could you do?

Bodo

Bodo