Re: IETF mail server and SSLv3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]