Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

[Bodo Moeller <[e-mail]>]

> > - Because this draft relies on extensions, it seems not to resist
> >   active attack when clients do insecure version fallback
> >   (see for instance:
> > http://www.ietf.org/mail-archive/web/tls/current/msg09468.html)
>
> Right, but given that the problem is broken clients I'm not sure what the
> issue is.  Anything that falls back to older, less secure versions of
> protocols is going to be vulnerable to things that the newer protocols fix.
>

Consider a client and server that both support a secure protocol version,
but where the client will reconnect using an older protocol version if it
suspects that that's necessary for interoperability.  Since in this
scenario, the client won't reliably know if handshake failures indicate
interoperability problems with the actual server or with an active
attacker, having a security fix that can be applied to the older protocol
version as well has a clear benefit.

(Also, offering this Encrypt-then-MAC option rather than just switching to
AEAD ciphersuites completely could make it easier to fix older
implementations before they can migrate to newer protocol versions; but I'm
very skeptical about this rationale in the case of falling back to SSL 3.0
[and no TLS extensions] -- if an implementation really is stuck at SSL 3.0,
that looks hopeless to me.)

While removing SSL 3.0 support entirely would avoid this kind of problem,
SSL 3.0 is still sometimes required for interoperability. (Cf. the history
of RFC 6187: http://tools.ietf.org/html/rfc6176)


So maybe the right fix to this kind of problem is to adapt an idea from
draft-rescorla-tls-version-cs-00 and create a signalling ciphersuite value
that would *only* be used in SSL 3.0 connections by clients that have
downgraded, and tells the server "If you can read this, tear down the
connection because we shouldn't actually be using SSL 3.0 for this
connection"?

Bodo