On Tue, Oct 14, 2014 at 01:56:52PM +0200, Aaron Zauner wrote:
> > 3.
> > SSL Protocol version recommendations.
> >
> > Once again with unauthenticated opportunistic TLS even SSL 3.0 or
> > TLS 1.0 is (much) better than cleartext. So the MUST NOT SSL 3.0
> > and SHOULD NOT TLS 1.0 are too strong.
>
> So once again we have the whole 'opportunistic' discussion. I
> strongly disagree that both should be changed from MUST NOT to a
> SHOULD NOT or even something less.
I'm willing to accept MUST NOT for mandatory (non-opportunistic)
TLS. However, claiming that SSL 3.0 is worse than cleartext is
simply absurd. Perhaps the BCP should not apply to opportunistic
uses of TLS, and those should be written up separately. If however
the preference is to have one BCP that covers applies to both
mandatory and opportunistic TLS, then some of the recommendations
need to be made at least context sensitive, or else less strongly.
I'll take SSL 3.0 or TLS 1.0 over cleartext any day, especially
for applications where most of the HTTP attacks (BEAST, CRIME,
....) simply don't apply. MTA to MTA SMTP is cookie-less, and
injection of chosen plaintext early in the SMTP dialogue is not
feasible.
S: 220 ...
C: EHLO {fixed name}
S: 250 ...
C: AUTH PLAIN {fixed secret} # Only with submission and should/must
mandatory TLS!
S: 250 ...
C: MAIL FROM:<sender> [ESMTP options]
S: 250 ...
C: RCPT TO:<rcpt> [ESMTP options] # First possible chosen plaintext
C: ...
The only risk I'm aware of for SMTP is use of RC4 for submission
with PLAIN auth. This may eventually leak the user's login
credentials after some number of millions of email messages are
sent, which at O(100) per day is at O(10,000) days or 30 years!
So OK, don't use RC4 with mandatory TLS in submission. Otherwise,
with opportunistic TLS SMTP is IIRC insensitive to CRIME, BEAST,
LUCKY13, ... all or most of which rely on browser-specific chosen
plaintext injection.
For opportunistic TLS it makes a lot more sense to say that
implementations and configurations should only use weak algorithms
as a last resort (low in the handshake preference order) than to
say "MUST NOT", which just leads to unnecessary cleartext fallback.
Notice for example, that with SMTP export ciphers are essentially
never used, even though they are not disabled. They are simply
never negotiated. We can get to the same state with RC4, without
banning it outright. (As for Google banning SHA1, that's nice,
but they still to this day rank RC4 first in their outbound SMTP
client).
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
