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

[Aaron Zauner]

Hi Rich, Ian,

[exluded IETF SAAG from my reply, feel free to forward if useful]

* ianG <iang at iang.org> [141104 18:12]:
> > 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:

Our recommendation evolved over a lot of discussion on this very
mailing list along with testing, feedback from different users and
researchers. Let me sum up why we've come up with a cipherstring
that confusing:

  .) When we started out in fall of 2013 there was a lot of uncertainty
     about ECC. As such we chose to prefer DHE (with obvious
     performance impacts).

  .) GCM should be prefered where possible. Are we missing something?

  .) The cipherstring needs to work with the 0.9.8 as well as 1.0.1
     trees of OpenSSL. Both parse Cipherstrings very differently,
     getting a result that will work on both took me a whole weekend
     - and, agreed, it looks terrible. But it works.

     Here's the output of a tooling script I wrote to compare
     cipherstrings among OpenSSL versions;
     - Your recommendation:
       http://nopaste.narf.at/show/43MulC42qUJGhJBMfX6Y/
     - Our current recommendation:
       http://nopaste.narf.at/show/Ej2KQkadbVledtu6LEij/

     ..which actually seems to work fine across all OpenSSL
     versions, but misses CAMELLIA completely.

     https://github.com/azet/openssl-compare

We're working on a 'version 1.0' of the paper, I'll see that we
incorporate your feedback into it; thus try to make the cipherstring
a bit more readable.

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

Thanks, barely got time to follow all the IETF lists, so I might
probably have missed that.

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

I'd also be for exluding CAMELLIA, as I've noted on the ML before,
but it's a democratic decision after all ;)

Thanks for the input,
Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20141104/8142377c/attachment.sig>