> On Feb 5, 2016, at 3:08 PM, John C Klensin <john-ietf@xxxxxxx> 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.