[Ach] justifing config. settings in the paper
iang at iang.org
Fri Nov 15 10:14:28 CET 2013
the devil's advocate says:
On 15/11/13 11:57 AM, L. Aaron Kaplan wrote:
> On Nov 15, 2013, at 4:40 AM, Aaron Zauner <azet at azet.org> wrote:
>> I just sent the paper to a collegue of mine who made a good remark: Whats completely missing is a justification for the settings we dropped in the paper - i.e. i’d suggest to add a short paragraph after every verbatim config text that reads “Justification: […]” explaining why we chose those settings in addition we should add a second paragraph “Note on compability: […]” explaining for example which parts of the configuration won’t work with older versions of daemons (think apache, ssh, nginx,..) and which parts break certain clients. This is paramount since administrators will not deploy settings if they find out they do not work in practice - which would make the paper quite useless.
>> Whats your opinion?
> Absolutely correct!
> See also the TODO.txt file:
> "* document (cite) EVERYTHING! Why we chose certain values. References, references, references. Otherwise it does not count!
> That's something we need to fix before the first release.
I was about to say exactly the reverse :) the paper reads to me like a
maillist thread still trying to find its way. Instead, it needs to read
like 7.1 or section 8:
"Use this set of params. It has these consequences..."
I don't think you need to justify anything in the paper. If you include
justifications, the paper will balloon, justification will become the
source of endless discussions, and it will provide all the excuses that
people need to ignore it ...
OTOH, you might refer to a wiki page or a mailing list where the
justification is being worked on. Obviously, each section's
recommendations are dynamic ...
As an example of this, consider the discussion on ECC: it's still
formative. We have no recommendation. We don't know what they did ...
and we don't know what they didn't do.
Yet. We're finding out ... I found out the other day (See crypto
mailing list) that the Suite A classified ciphers are indeed promoting
the EC curves in exactly the same style as NIST in a big way.
This tells us that EC is good. Which then leaves the question as to
whether the chosen NIST influenced EC curves/suites are suspect, still
an open question (footnote 19). Which for example then tells us that
(eg) the work in TLS to add in DJB curves is a good thing.
But, we can't recommend anything there as yet, as DJB isn't complete and
we don't know about the other curves.
If you pinned me down, I would say: use the curves that are already in
TLS. You likely won't be worse off than not using TLS at all... And we
can upgrade later :) But that's just me. Committee-wise, I'd say the
"Recommendations concerning ECC are currently too hard to make. Watch
>> Ach mailing list
>> Ach at lists.cert.at
> // 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
> Ach mailing list
> Ach at lists.cert.at
More information about the Ach