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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Thu, 2014-10-16 at 16:34 +0200, Bodo Moeller wrote:

> When writing the TLS_FALLBACK_SCSV specification, I was thus aiming to
> keep it simple enough so that implementors would be extremely unlikely
> to get it wrong (at least once there's some base deployment of clients
> and servers so that basic interoperability tests will immediately
> expose large classes of potential bugs, which should by now be the
> case). Do you seriously think that implementors might end up sending
> TLS_FALLBACK_SCVS unconditionally? If so, do you think that those
> implementors would be capable of avoiding other more subtle bugs, and
> overall to create a mostly usable and possibly even reasonably secure
> product? (I can't help thinking that if a client is *that* broken,
> we'd probably be doing its users a favor by having all handshakes
> fail.)
> More importantly, if there were no fallback retries and thus no need
> for TLS_FALLBACK_SCSV, how could that *possibly* make it *easier* to
> deploy TLS 1.3 given that buggy peers may be around?

I pretty much understand your argumentation, but I think that the
argument for the SCSV boils down on whether we want to keep the insecure
browser fallback mechanism for long. I believe that we shouldn't, and
this is the reason I don't like this draft; it gives legitimacy to an
out-of-standard insecure protocol fallback mechanism.

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]?

[0]. http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

regards,
Nikos