[noise] Document structure (was: Mechanical definition of "fallback" modifier)

[Jake McGinty]

A specification structure proposal I’ve had floating around in my head for a bit:

1) Core

Definitions of the handshake and transport state machines (sections 1-8 in the current rev32 spec).

2) Appendices

Overview of security properties of the various handshake options (sections 7.4 and 7.5), as they’re convenient information but not a necessary part of a specification since it can be generated from the core spec.

3) Extensions

Currently this would be one document for each of {pskN, fallback, HFS, NewHope}, and perhaps we could have a standardized set of sections for extension papers so the documents don’t look totally different from each other.

-----

To address Alex’s concern (which I share) about well-defined compliance, Noise implementations should consider the core spec to be the minimum requirement, and would simply include a list of which extensions are also supported.


~jake


> On Jun 11, 2017, at 10:02 PM, Alex <alex at centromere.net> wrote:
> 
> On Sun, 11 Jun 2017 07:08:19 +0000
> Trevor Perrin <trevp at trevp.net> wrote:
> 
>> On Sun, Jun 11, 2017 at 1:56 AM, Rhys Weatherley
>> <rhys.weatherley at gmail.com> wrote:
>>> 
>>> Should the definition of the "fallback" modifier go into rev33 or
>>> into an extension document?  Perhaps Noise Pipes can be spun off
>>> completely into an extension now?  An important extension to be
>>> sure, but maybe no longer necessary in the core.  
>> 
>> 
>> Not sure.  I talked about that with Jason before revision 32 and he
>> convinced me this is complicated and needs more discussion:
>> 
>> * If we're going to divide things into separate documents (or
>> "chapters", or "layers"), what is the division based on?  Old vs new?
>> More-important vs less-important?  Modifiers vs non-modifiers?
>> 
> 
> What is the very least a library author should have to do to consider
> their implementation compliant? If an author decides not to implement
> PSKs, are they violating the standard? If not, maybe section 9 should
> be in a separate document.
> 
> Similarly it seems that fallback patterns (section 10) are completely
> optional *and* the spec only makes a recommendation for how to
> implement it. Additionally, the type fields in fallback patterns are
> explicitly designated as application responsibilities in section 13.
> This seems like a good candidate for something that can be moved in to
> another document.
> 
>> * Are these decisions we're able to make now?
>> 
> 
> I think so.
> 
>> It would be great to hear thoughts about how these decisions would
>> affect people, e.g. would having separate documents make things easier
>> for library developers to focus on features they care about, or create
>> confusion and fragmentation?
>> 
> 
> My biggest concern is that compliance is well defined. I want it to be
> completely unambiguous as to whether you are in or out of compliance.
> I suspect that a minimalist core spec with supporting documents for
> non-normative recommendations would make this challenge more tractable.
> 
> -- 
> Alex
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise