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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Mon, 2014-10-20 at 14:13 +0200, Bodo Moeller wrote:
> Nikos Mavrogiannopoulos <[e-mail]>:
> 
>         Indeed, there is an arguments to keep that mechanism, as there
>         are still
>         some TLS 1.3 intolerant servers. But instead of prolonging the
>         life of
>         such an insecure mechanism wouldn't it make sense to fix those
>         broken
>         servers instead; e.g., by peer pressure by documenting the
>         implementations that are not TLS 1.3-ready in [0]?

> It certainly makes sense to fix those broken servers. I disagree with
> fixing them *instead* of deploying TLS_FALLBACK_SCSV; I think that's a
> false dichotomy. If you are willing to stop fallback retries in the
> client products that Red Hat distributes right now, great (do you?),
> but clearly not everyone is willing to take that step at this time.
> Until it has happened, clients already can benefit from
> TLS_FALLBACK_SCSV.

I disagree. It is a correct dichotomy :) If the servers are fixed, there
is no use for the fallback SCSV, as clients would not need to perform
the insecure fallback.

As of the argument that clients would be protected from the SCSV, that
only works if both the clients _and_ the servers are updated to support
the fallback SCSV. Why is that step necessary, if we can instead fix the
clients and the servers to properly negotiate TLS?

regards,
Nikos