[Ach] justifing config. settings in the paper

[Aaron Zauner]

Hi,

I have to disagree. We should not include lenghty justifications but short and definitive sentences what those settings actually mean and what they break. We use a lot of configuration options that will seem alien to normal system administrators since they never bothered to use them. We should document this properly.

(Sorry for all my typos yesterday, was on a very long flight and did barely sleep the night before)

Aaron

On 15 Nov 2013, at 10:14, ianG <iang at iang.org> wrote:

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

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