Hi Peter,
Peter Gutmann wrote:
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.
We try to offer two OpenSSL cipher-strings currently: A and B with A
being the tinfoil-hat version. Now we need input from people like you,
people that run large-traffic sites, develop SSL libraries, Client and
Server software and so forth to find a good common ground. We have
recently got a lot of useful feedback from e.g. the Firefox crypto team
and I'm sure we'll incorporate that into our paper. We're still in a
DRAFT stage and intent to update the paper even after our first release
regularly since the world of SSL/TLS changes a lot these days.
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 cutpaste 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 cutpaste 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
Yup. But that's a issue we won't be able to solve. If serious system
engineers can't find the time to read through a paper and it's reasoning
but instead look up ubuntuforums than they probably should not be
employed to do security critical decisions. We all know that problem
very well - some people just wont RTFM - this is also why the paper is
pretty terse and has put the configurations in front of the theory part
(used to be the other way around).
I still have the feeling that such a project is important since you
cannot find anything similar on the web that is useful for operations
people. Most people end up reusing configuration settings that someone
proposed somewhere on github or in an online forum, often without any
prior research.
Thanks for your input,
Aaron
signature.asc
Description: OpenPGP digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
