Re: [TLS] 2nd WGLC: draft-ietf-tls-downgrade-scsv

[Bodo Moeller <[e-mail]>]

Sean Turner <[e-mail]>:

This message initiates the 2nd WGLC for draft-ietf-tls-downgrade-scsv-02.
>  Please review the document and send your comments to the list by Friday,
> December 12, 2014.
>
> [...]  The scope of this WGLC is however limited to making sure that the
> text that has been added represents WG consensus.  For example, rehashing
> whether the documented solution should use an extension or cipher suite is
> not in scope of this review.
>

The relevant part from the IETF-91 minutes (
http://www.ietf.org/proceedings/91/minutes/minutes-91-tls)

        Downgrading SCSV
                Very close to finished with WG LC
                Martin Thompson: still questions of how the step-by-step is done
                        Maybe specify what version you tried and failed
                Andrei Popov: Would like this to be an extension
                Ekr (Eric Rescorla): There are only a few things, so
we can just make a few SCSV
                Martin: Already shipped, and is willing to live with
the current limitations
                Ekr: Are we going to break IE if we support this? That
would suck
                Andrei: Can live with the current draft
                Martin: Their numbers show the step-by-step is stupid
                Joe Salowey: Will be another WG LC on this
                More people mentioned other weird cases

The question of doing a step-by-step downgrade or not (as mentioned in
the above) has come up on the list too:

http://www.ietf.org/mail-archive/web/tls/current/msg14579.html
http://www.ietf.org/mail-archive/web/tls/current/msg14591.html
http://www.ietf.org/mail-archive/web/tls/current/msg14596.html

As discussed there, trying protocol version in non-consecutive order
isn't strictly disallowed by or impossible with
draft-ietf-tls-downgrade-scsv-02, although I personally do think that
it is a bad tradeoff and doing a step-by-step downgrade is not stupid
-- see also https://www.ietf.org/jabber/logs/tls/2014-11-13.html:

[19:13:16] <https://www.ietf.org/jabber/logs/tls/2014-11-13.html#19:13:16.934945>
<Bodo Moeller> MIC: If the server does not support the SCSV and you
fall back by accident (network glitch), falling back to TLS 1.1 is
better than to TLS 1.0.

As mentioned before, the point of draft-ietf-tls-downgrade-scsv-02 is
not to specify that or how clients should be doing fallbacks (ideally,
there'd never be a need to), since this involves moving targets --
broken servers --, and all fallback connection attempts will be
equally useless with servers that are current and correct.

The point of this specification is to provide a simple and
easy-to-deploy mechanism to help avoid downgrade attacks *if* clients
choose to fall back to improve interoperability with broken servers. A
detailed discussion of whether and how to fall back necessarily
depends on the deployment status of legacy servers with a specific
application protocol, and so is subject to change across space and
time, and much more complex than would be appropriate for
draft-ietf-tls-downgrade-scsv-02. The UTA WG is considering to create
a BCP document on the fallback dance; see
http://www.ietf.org/proceedings/91/minutes/minutes-91-uta for details.

Bodo