Re: [TLS] An SCSV to stop TLS fallback.

[Bodo Moeller <[e-mail]>]

Wan-Teh Chang <[e-mail]>:


> However, I can't come up with a reason why the client's actual highest
> version is useful to a server. Although Eric Rescorla and Adam's old
> proposals ([1] and [2]) also included the client's actual highest
> version (which necessitated multiple, version-specific SCSVs), careful
> analysis of their old proposals showed that that version is only
> compared with ClientHello.client_version. The boolean result of that
> comparison is equivalent to your TLS_FALLBACK_SCSV.
>

Right. This single SCSV is the simplest tool that does the job (and because
it is simple, also easy to get right in implementations).


The work to implement TLS
> version negotiation correctly should be similar to the work to add
> support for TLS_FALLBACK_SCSV. Why don't we require that servers that
> support TLS_FALLBACK_SCSV must also do version negotiation correctly?
> RFC 5746 has such a requirement:
>

All standards-compliant TLS servers are already required to do version
negotiation correctly -- otherwise they wouldn't be standards-compliant TLS
servers :-)  The problem is, something that *appears* to be a
standards-compliant TLS server (and acts exactly like a standards-compliant
TLS server, as far as interactions with current standards-compliant TLS
clients are concerned) may not actually be standards-compliant: current
standards-compliant TLS clients won't ever indicate version TLS 1.3, so
incorrect protocol version negotiation behavior wouldn't be obvious.

Also remember that even if the actual TLS server implementation is
standards-compliant (in particular, version tolerant), a middlebox may
break that, by rejecting ClientHellos with versions that it doesn't
understand.  Such middleboxes clearly are broken, but that alone doesn't
prevent them from getting deployed.


Do you think it is reasonable for a server to reject a currently
> undefined ClientHello.client_version (such as TLS 1.3 or TLS 2.0)? Or
> do you think that if something is not tested, it is likely to be
> broken? Although I think the latter is true in general, in this
> particular case, I think the risk is low. So you are taking a very
> conservative approach.
>

I don't really think that it is *reasonable* for a server (or middlebox) to
reject that, but I wouldn't want to bet the usefulness
of draft-bmoeller-tls-downgrade-scsv-01 on servers (and middleboxes) being
that reasonable.



> 4. Why do you not use the server's support of the renegotiation_info
> extension as a signal ([3])? Is it because you want to allow servers
> to opt in to the fallback prevention mechanism?


[3]
> http://tools.ietf.org/html/draft-pettersen-tls-version-rollback-removal-02
>


I don't want to allow servers to opt in to or opt out of TLS_FALLBACK_SCSV.
 Rather, I want *all* servers to be strict about TLS_FALLBACK_SCSV -- hence
the word "MUST" in the specification of server-side behavior.  This allows
client implementations to send or not send the SCSV based on their security
needs (the draft says that clients SHOULD include
ClientHello.cipher_suites when falling back to a lower protocol version,
where the word "SHOULD" means that "there may exist valid reasons in
particular circumstances to ignore a particular item, but the full
implications must be understood and carefully weighed"; RFC 2119).

I don't think that the server's support of the renegotiation_info extension
is necessarily the right signal in practice: for example, if the server
supports it, you might still be deploying a broken version-intolerant
middlebox without anyone noticing that something's wrong.  Maybe, as
described in draft-pettersen-tls-version-rollback-removal-02, such breakage
will eventually become irrelevant in practice, and thus we'll avoid the
need for fallback connections: once we're there, TLS_FALLBACK_SCSV wouldn't
generally be seen on the wire in normal usage (servers would still watch
out for it, but if no client has a need to fall back to earlier protocol
versions, it wouldn't ever be sent).  In this case,
draft-bmoeller-tls-downgrade-scsv-01
won't be doing any harm (it merely requires a small amount of additional
server-side logic).  Well, upon starting to deploy TLS 1.3 or any other
future version, the future us might find out that there *is* then a (new)
need for fallback connections after all, to allow clients to try TLS 1.3 in
the presence of version-intolerant servers and/or middleboxes that, up to
then, didn't appear to be broken.  In that case, the TLS_FALLBACK_SCSV
mechanism will be useful again, until all the version-intolerant servers
and middleboxes have been removed.  Rinse, repeat: with each new protocol
version, TLS_FALLBACK_SCSV may become relevant again until all servers and
middleboxes intolerant to that new protocol version have been evicted from
the internet.

Generally, getting something like TLS_FALLBACK_SCSV deployed on *many*
servers (so that clients can benefit from it at least for many of their
connections) seems more easily feasible than getting rid of (nearly) *all*
broken servers and middleboxes (so that clients can live entirely without
protocol fallback strategies).  So TLS_FALLBACK_SCSV certainly can be
deployed much quicker (if you are interested in keeping some
interoperability with broken servers -- which of course is why protocol
fallbacks are an issue in the first place): To newly roll it out on a
server, you have to make sure that that server (and any middleboxes
handling the traffic to it) support or tolerate the *currently* deployed
TLS versions, which something that you'd automatically be observing in
standard interoperability testing (as long as you use a client supporting
the current TLS version, with TLS_FALLBACK_SCSV for any protocol fallbacks).

As I've said before, you can do both: deploy TLS_FALLBACK_SCSV for best
security even if protocol fallbacks are sometimes necessary; deploy
draft-pettersen-tls-version-rollback-removal-02
to get rid of the need for those fallback connections as soon as we can.
 There's no conflict between these, rather they complement each other --
draft-pettersen-tls-version-rollback-removal-02 doesn't seem right as a
security fix (because (1) you'll have to clean out broken servers and
middleboxes from the internet before you can actually deploy it, and (2)
once we've fixed the internet accordingly, a new TLS version may surface
more breakage), while draft-bmoeller-tls-downgrade-scsv-01 does nothing to
avoid those protocol "downgrades" in which you're only falling back to the
protocol that should have been negotiated anyway.

Bodo