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

[Bodo Moeller <[e-mail]>]

Adam Langley <[e-mail]>:

> On Mon, Nov 25, 2013 at 7:52 PM, Andy Wilson <[e-mail]>
> wrote:
>


>  > I take it you're aware of
> > http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00
>

 Yes thanks. My one sentence design is obviously very similar. I don't
> understand some of the extra logic for the server in Bodo's draft.


I think your new proposal corresponds to my original sketch for the SCSV's
semantics ("If you can read this, tear down the connection"), before I
actually wrote that Internet-Draft.

Writing the I-D, I realized that it would be a pity if, in case a need came
up to implement similar fallback strategies when deploying future protocol
versions, you'd have to wait for *another* document to specify *another*
SCSV to be able to prevent new protocol downgrade attacks, such as from TLS
1.3 to TLS 1.2.  Ideally all servers
implementing TLS_FALLBACK_SCSV/TLS_DOWNGRADE_SCSV would be fully version
tolerant, but obviously tolerance for *future* protocol versions is not a
server feature normally exercised in practice -- so to cope with the "Universal
Rule of Users", we'll have to assume that some servers may be around that
aren't fully version tolerant, while working perfectly as far as said Users
are concerned.  Hence the server logic to compare the client's protocol
version to the server's supported protocol version: if the client is
falling back to the server's highest supported protocol, that's not a
malicious protocol downgrade.

Similarly, implemented in TLS 1.2-intolerant servers,
draft-bmoeller-tls-downgrade-scsv-00 could prevent a rollback from TLS 1.1
to TLS 1.0 without breaking interoperability with clients employing a
fallback strategy (and using the SCSV); in TLS 1.1-intolerant servers, it
could prevent a rollback from TLS 1.0 with TLS extensions to TLS 1.0
without TLS extensions without breaking interoperability.  As you've noted,
if the SCSV is used by widely deployed clients first, we won't have to
worry about interoperability with such servers (because the vendors will
notice that their servers are broken before they get deployed).

So in that case, the special logic for client_hello_extension_list can be
removed from the specification (yay!); only the version comparison needs to
remain.

Bodo



PS: Needless to say ...

1. None of the above is meant to imply that I think of TLS version fallback
as a protocol feature meant to stay.  Rollback connections *are*
an abomination -- the I-D is all about what to do *if* we find ourselves in
the sad situation of having to reconnect for interoperability.  If we
manage to get rid of the need for that, all the better.

2. None of the above is meant to imply that we shouldn't retrofit secure
ciphersuites to older protocol versions.  This, too, seems pretty much
orthogonal to what this I-D is all about.  (A TLS 1.0 client hello
proposing only secure ciphersuites wouldn't need the SCSV.)