On Tue, Oct 14, 2014 at 08:04:01PM +0200, Aaron Zauner wrote:
> > 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 did not claim that SSLv3 is worse than cleartext. My claim is:
> it's not sufficently secure in 2014. And I still think I'm right,
> even for opportunistic use cases.
Well, you can't have it both ways. Opportunistic clients that are
will use cleartext when crypto is not available, need to settle
for whatever crypto they can get, for the alternative *is* cleartext.
I'm not saying SSL 3.0 is motherhood and apple pie, but I am saying
that if SSL 3.0 is all you can get, and refusing to negotiate it
means using cleartext instead, DO NOT refuse to use SSL 3.0.
Opportunistic clients need to be more forgiving in order to get
some security (be it in some use cases sub-optimal) rather than
none.
> > 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!
>
> Yes. But you'll agree that most traffic these days is not SMTP but
> rather HTTP traffic? Not that SMTP has no impact, it should be
> considered in this draft. The second reply I wrote contains two
> other attacks against SSLv3/TLS1.0: one generic and the other
> directly related to e-mail security (IMAP) where an attacker
> is able to sniff passwords.
Same attack. However, IMAP and submission are not opportunistic.
MTA to MTA is opportunistic, often sends in cleartext, and it is
specifically that use case for which we're discussing whether
the various MUST NOTs are applicable.
Clearly when the alternative is cleartext, and one is looking to
avoid *passive* attacks, SSL 3.0 looks just fine (all attacks are
active) and RC4 only an issue with "AUTH PLAIN" which should
only be used with mandatory TLS.
> > 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.
>
> I see that this is a real problem with MTA/MUA communication. It's
> not however with other protocols. Securiting e-mail traffic is
> really tricky and might require a seperate WG document or references to
> appropriate documents on the web.
In which case perhaps let's just admit that the BCP does not apply
to opportunistic TLS, since you and others are keen to avoid making
the appropriate concessions to make the text more broadly applicable,
for (perhaps justified) fear of diluting the message.
> Cleartext fallback must not be the case in any scenario where TLS is
> trying to be negotiated beween any communicating parties.
Sorry, with opportunistic security, as my draft carefully explains,
"cleartext" it is not "fallback", rather it is the "baseline"
security posture, and anything better is "gravy". SMTP is cleartext
by default, and typically reverts to cleartext when STARTTLS is
unavailable or the handshake fails.
> I don't see why this is even necessary? Sure implementations can opt
> to ignore RC4, but we're writing a BCP, why should we not warn users
> and implementers not to use it anyway?
Because there still exist in sufficient (be it small) numbers
systems that only work with RC4 and for opportunistic TLS, negotiating
RC4 with these is still markedly better than cleartext. There is
no downside to doing RC4 when cleartext is the alternative. Provided
of course that one does not use RC4 when stronger options are available.
Thus the idea to de-prioritize rather than ban RC4.
The Postfix default ciphersuite string (please pardon OpenSSL
syntax) is essentially:
ALL:+RC4:@STRENGTH
which means RC4 is the least preferred 128-bit ciphersuite. If
and when other implementations do likewise, RC4 disappears from
use. Once it has not been sighted in years (as is the case with
export ciphers), I'll consider disabling it.
> TLS and SSL support so many
> different parameters it's a mess to test and configure correctly. If
> we can get rid of some ciphersuites - I think we can improve
> security and make it easier for administrators to configure their
> servers correctly. It's not just about people that write crypto
> implementations, TLS stacks and server daemons.
Well "correctly" means different things in different use-cases.
For MTA to MTA opportunistic TLS disabling RC4 and SSL 3.0 is not
correct. Just this year the Postfix users list has seen reports
of SSL 3.0 only email servers at various banks a user needs to send
mail to. Should the user's auditor write security findings against
his MTA configuration for leaving SSL 3.0 enabled? Or should he
be able to use SSL 3.0 which poses no known risks for MTA to MTA
SMTP?
> I spent a weekend writing a set of shellscripts that does nothing
> other than to compile and negotiate connections between different
> OpenSSL versions just to see if there's a possible vulnerability
> when selecting a ciphersuite (as with the Mozilla Guide or
> bettercrypto.org). To my surprise a cipherstring that works
> perfectly for 1.0.1 may include anon-DH ciphers with 0.9.8 etc.
The cipherstring syntax was substantially improved in 1.0.0. I
can even claim a bit of the credit, as the code by Bodo Moeller
came out of our discussion some years back around various issues
in that space.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
