Deutsch | English

[Ach] [saag] POODLE in detail (was Re: NTP security, and thoughts on Hawaii)

ianG iang at iang.org
Tue Nov 4 18:12:17 CET 2014


On 4/11/2014 16:15 pm, Salz, Rich wrote:
>> I'm on a group of users called BetterCrypto.org.  Here's their current
>> recommendation:
> 
> First, I don't think you can blame the TLS WG for adding national ciphers to the protocol.


Yeah, but!  No offense, picking up the devil's advocacy, here, but:

This is exactly the sort of not-my-faultism that created the mess in the
first place.  It's always someone else's problem, someone else's fault.

It's not us, it's the OpenSSL dullards / naive browser fools / criminal
CAs / NSA devils / evil vendors / stupid effing users...


> It's a constant battle, apparently, but SEED GOST CAMELLIA, etc., aren't the TLS group's fault.

WG inherited the SSL system they got, so yes, algorithm vanity was in
there before the group existed.

But, they've shown no desire to remove this system.  Indeed, they've
shown the reverse:  we all know that complexity in general and multiple
algorithms in particular [0] are a crock, yet the WG promotes the
ability to add in more insecurity.


> Once national politics got into it, there's not much the IETF can do.


Where in the IETF charter or the WG charter does it say, "and we pander
to national politics?"

Surely, the role of the IETF security area is to deliver protocols *that
secure the users*.

Correct me if I'm wrong, but surely the role of the IETF is *NOT* to
fall to one or other of the various interest groups that might claim a
special status?

Or is it?  Correct me if I'm wrong?  Who does the IETF serve?  Why am I
here?  Why are you here?


> Second, that cipher suite is, well, gross complicated and confusing.


That is the point:  that's an expert group of users, as good as it gets.
 It's turtles down from there.


>  Also not the TLS WG fault. Blame it on poor use of OpenSSL (and where you then divide that blame isn't clear) if you must.


TLS WG can solve that with a single decision in its next release:

     there is one cipher suite, and it is numbered Number 1.

Can you really shift the blame to OpenSSL and others when the WG walks
blindfolded & backwards in security history and hands them a system that
isn't possible to secure?


> I ran the list through 'openssl ciphers.'  The ordering is strange, intermixing AES-GCM with AES and Camellia.  I'd put AES-GCM first, and then drop Camellia for simplicity. And then only list the algorithms I do want.  Avoid OpenSSL magic keywords that change meaning over time (like EXPORT or HIGH). Prefer ECDHE over DHE and perhaps allow RSA for legacy interop.  That gives the following cipher list:
>   ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256: \
>   ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256: \
>   ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA: \
>   DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256: \
>   DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256: \
>   DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA: \
>   AES256-SHA:AES128-SHA:
> Which is easy to understand and reason about.  And yes, it requires explicit reconfiguration to add new ciphers if and when desired.

I've cc'd the ach group, so they can look at your proposal.

> Given your oft-stated feelings on protocol flexibility, I am surprised you didn't strongly argue against Camellia.  Or did you just lose that fight?


:) I lost that fight, big time.  But rest assured, I won't forget ...



iang



[0] If you disagree that multiple algorithms are the worst possible
idea, then read it this way:

    "other algorithms than my favourite..."





More information about the Ach mailing list
Kontakt
Email: reports@cert.at
Tel.: +43 1 5056416 78
mehr ...
Warnungen
mehr ...
Blog
mehr ...
Jahresbericht 2017
Ein Resumee zur digitalen Sicherheitslage in Österreich

(HTML, PDF).
Letzte Änderung: 2018/5/28 - 15:00:00
Haftungsausschluss / Datenschutzerklärung