[Ach] justifing config. settings in the paper

[ianG]

Hi guys,

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:
>
>> Hi,
>>
>> 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!
>      Srsly!!"
>
> 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 
summary is:

"Recommendations concerning ECC are currently too hard to make.  Watch 
this space."



iang


> a.
>
>
>
>>
>> Aaron
>> _______________________________________________
>> Ach mailing list
>> Ach at lists.cert.at
>> http://lists.cert.at/cgi-bin/mailman/listinfo/ach
>
> ---
> // 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
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach
>