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

[Nikos Mavrogiannopoulos <[e-mail]>]

> > 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.
> True, but clearly they aren't fixed *now*, and more importantly, various
> current clients *do* still find it necessary to use fallback retries to
> work with such servers.
> I agree that TLS_FALLBACK_SCSV is hypothetically pointless :-)

No, not only pointless, it gives the broken servers an incentive to continue
being broken. With this change, clients still consider the servers that
require a downgrade dance secure. Why should that be the case? Why for example
chrome or firefox doesn't warn on these servers? They are certainly not
secure.

If the draft should mention that a compliant to SCSV interactive client MUST
warn the user in case of a fallback dance, then yes, I would agree that the
draft is a step forward. I believe the goal must be the elimination of 
non-compliant servers, not only to patch things up until the next attack.

> 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?
> Using the SCSV already helps if *some* servers have been updated to support
> it: connections to these servers, at least, will be more secure. For other
> servers, you get what you have now.

I agree on that, but the issue there is that we tolerate non-TLS compliant
servers and we consider them equally secure, even though your attack shows
that they are not.

regards,
Nikos