On Feb 5, 2016, at 3:08 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
wrote:
This conversation seems to be about how newer methods are better
than SSLv3 and therefore we should get rid of the latter.
Well, as long as clear text fallback is available and works
efficiently (and I think Ned's suggested maximum two-minute
delay is, indeed, a maximum) I guess I don't care. But, for
those who think this is about privacy and its promotion, that
then makes the question one of whether SSLv3 is worse than plain
text, not only whether it is worse than an appropriate version
of TLS. It could be worse in either practically or symbolic
terms, but that goes back to goals and threat models.
With my RFC7435 opportunistic security hat on, quoting from that
document:
Cleartext, not comprehensive protection, is the default baseline. An
OS protocol is not falling back from comprehensive protection when
that protection is not supported by all peers; rather, OS protocols
aim to use the maximum protection that is available. (At some point
in time for a particular application or protocol all but a negligible
fraction of peers might support encryption. At that time, the
baseline security might be raised from cleartext to always require
encryption, and only authentication would have to be done
opportunistically.)
...
With unauthenticated, encrypted communication, OS protocols may
employ more liberal settings than would be best practice when
security is mandated by policy. Some legacy systems support
encryption, but implement only outdated algorithms or protocol
versions. Compatibility with these systems avoids the need to resort
to cleartext fallback.
...
The support of cleartext and the use of outdated algorithms, and
especially broken algorithms, is for backwards compatibility with
systems already deployed. Protocol designs based on Opportunistic
Security prefer to encrypt and prefer to use the best available
encryption algorithms available. OS protocols employ cleartext or
broken encryption algorithms only with peers that do not appear to be
capable of doing otherwise. The eventual desire is to transition
away from cleartext and broken algorithms, and particularly for
broken algorithms, it is highly desirable to remove such
functionality from implementations.
Bottom line, the decision to disable SSLv3 is reasonable provided
the impact of doing so, either in terms of loss of privacy or increase
in latency due to cleartext fallback, is truly negligible.
Curating the legacy broken crypto long past the time that effectively
nobody needs it is not a good idea. That legacy crypto comes with
an increased attack surface and with opportunities for downgrade attacks
against peers that are capable of stronger crypto.
So opportunistic TLS applications like RFC3207 SMTP do need to tolerate
weaker crypto while it is needed for operational reasons, but need to
move forward once that is no longer the case.
It is my judgement that we've reached the point in the adoption curve
where we can abandon SSLv2, SSLv3, EXPORT ciphers and single-DES ciphers.
We are rapidly approaching a time when RC4 can also be turned off, and
may be there already, but that is not yet quite clear.
So there are operational judgement calls to be made here, and I am
reasonably confident that disabling SSLv3 at ietf.org is a sensible
call.
--
Viktor.