* Viktor Dukhovni <[email protected]> [141014 18:47]: > 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 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.
> 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!
>
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.
> 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.
>
See above.
> 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.
Cleartext fallback must not be the case in any scenario where TLS is
trying to be negotiated beween any communicating parties. In my
opinion this - however - does not change the fact that strong
wording is needed to eventually deprecate insecure (or as you
pointed out in the case of SMTP not-so-secure) protocols.
> 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).
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? 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.
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.
It's simply a mess:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
More algorithmic agility does not improve security, it makes room
for even more attack vectors - some might be known, others unknown,
even more; implementations break (we've seen that over and over this
year). But I'm no cryptographer, here are slides by DJB on why
agility sucks: http://cr.yp.to/talks/2013.03.12/slides.pdf
Quote:
```
“Cryptographic algorithm agility”:
(1) the pretense that bad crypto is okay if there’s a backup plan +
(2) the pretense that there is in fact a backup plan.
SSL has a crypto switch that in theory allows switching to AES-GCM.
But most SSL software doesn’t support AES-GCM.
The software does support one non-CBC option: RC4.
Now widely recommended, used for 50% of SSL traffic
```
And an IAB draft on said issue:
https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/?include_text=1
Quote (4. Security Considerations):
```
[...]
The ability to use a algorithm of one's own choosing is
very desirable; however, this does not mean that any and
all cryptographic algorithms ought to be available in every
implementation. Mandatory-to-implement algorithms ought
to be well studied, giving rise to significant confidence.
In addition, inclusion of too many alternative may add
complexity to algorithm selection or negotiation.
[...]
Support for too many algorithms can lead to implementation
vulnerabilities. When many algorithms are supported, some
of them will be rarely used. Any code that is rarely used
can contain undetected bugs, and algorithm implementations
are no different.
```
(Yes. Google SMTP with RC4 pisses me off as well)
Aaron
signature.asc
Description: Digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
