[Ach] [cryptography] Better Crypto

[L. Aaron Kaplan]

On Jan 7, 2014, at 2:34 AM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:

> "L. Aaron Kaplan" <kaplan at cert.at> writes:
> 
>>> As a general observation, it also promotes the thinking that all we need to do
>>> is choose magic algorithm A instead of magic algorithm B and everything is
>>> fixed. 
>> 
>> No, if we created that impression then we failed.
> 
> The problem is that as you read through the text you see, again and again, a
> large amount of material telling you how to configure algorithms for OpenSSL
> (and then to a lesser extent OpenSSH and others).  It seems to be the
> overriding theme throughout the document.  A better option would be to refer
> to a single location for this (in an appendix) and then give users a choice: a
> generic safe config (disable null, export ciphers, short keys, known-weak,
> etc), a maximum-interoperability config (3DES and others), and a super-
> paranoid config (AES-GCM-256, Curve25519, etc), with warnings that that's
> going to break lots of things.
> 
I like that idea

>> That's what we state in the abstract as well as in the disclaimer.
> 
> That assumes that people will read all of that, as well as the theory chapter
> that follows.  Since the document is laid out as a cookbook, I have the
> feeling that most people who just want to get a server up and running will
> flip through until they find the bit corresponding to the software they'll be
> running and then cut&paste the config lines they find there.  Or at least
> that's been my experience in maintaining an open-source crypto library for
> nearly two decades, the documentation isn't an instruction manual in the usual
> sense but a set of code templates ready to cut&paste into a finished app.
> Look at the popularity of HOWTOs for any number of how-to-set-up-XYZ issues,
> most people just want a cookbook and won't read long, detailed discussions.  
> Or for that matter any discussion that goes beyond "do this to get it 
> running".
> 

I agree... that's how most people will read it probably. Unfortunately.

As Aaron Zauner already mentioned, we thought about this a lot and ended up with 
1. writing a "How to read this guide" section  in the beginning including a flowchart
2. moving the theory section to the end (so that people can quickly find the copy & paste section)
and 
3. always try to pull in the readers interest to follow up in the theory section.

None if this is perfect yet of course.  One of the very productive feedback results was that we should make a HTML version. 


So, Peter, how about this approach?

  1. We will have three config options: cipher String A,B,C ( generic safe config, maximum interoperability (== this also makes the mozilla people happy then) and finally a super-hardened setting (with reduced compatibility)).
Admins will get a choice and explanations on when to use which option.
  2. (time-wise) first we focus on some of the weak spots in the guide like the ssh config (client config is missing...), the theory section etc.
  3. we give people a config generator tool on the webpage which gives them snippets which they can include into their webservers, mailservers etc. The tool also shows admins (color codes?) which settings are compatible, unsafe etc.
  4. In addition to having the config generator on the web page, the config snippets are moved to the appendix (as you suggested). The theory section moves up.


Would that be more in your line of thinking? 


Anyway, we will have a authors' meeting today at  ~ 19:00 CET and can discuss this.
Anyone who wants to join via teleconference: please get in contact with me. We will arrange for remote participation.


Aaron.


> Peter.
> 

--- 
// L. Aaron Kaplan <kaplan at cert.at> - T: +43 1 5056416 78
// CERT Austria - http://www.cert.at/
// Eine Initiative der nic.at GmbH - http://www.nic.at/
// Firmenbuchnummer 172568b, LG Salzburg




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20140107/854c7ef3/attachment.sig>