[noise] Test Vector Specification

[Alex]

On Sat, 18 Nov 2017 03:58:04 +0000
Trevor Perrin <trevp at trevp.net> wrote:

> On Thu, Nov 16, 2017 at 12:52 AM, Alex <alex at centromere.net> wrote:
> > Hi all,
> >
> > I've formatted the test vector spec (originally on the wiki[0])
> > according to Trevor's spectemplate. It's currently available[1] on
> > my personal github account
> >
> > [1] https://github.com/centromere/test-vector-spec  
> 
> Thanks Alex!,
> 
> Process comments:
> 
>  - Can you check in the "output" directory and contents, that makes it
> easy to view the PDF from Github.
> 
>  - Can you change the status to "unofficial"? - I can make it
> "official" later, when we "officially" change its status.
> 
> 
> Substantive comments:
> 
>  - The "hybrid" field seems leftover from before we were expressing
> the full pattern in "protocol_name".  It seems like "hybrid" could be
> deleted entirely from this doc.
> 

Everything above has been modified.

>  - The responder fields ("resp_ephemeral", "resp_prologue", etc) are
> optional for one-way handshakes, I think?
> 

The document states:

init_* and resp_* (except the prologues)

are optional. Thus, the `resp_ephemeral` field is already optional. As
for `resp_prologue`, the current spec doesn't lead me to believe that
it's optional. For example, section 5.3 specifies that the `Initialize`
function is to unconditionally call `MixHash(prologue)`. Both parties
must call `Initialize` regardless of the pattern employed, so I conclude
that it's not optional, even for one-way handshakes.

>  - Should the prologue fields be optional in all cases (default to
> empty / zero-length)?
> 

I think there is a meaningful distinction that should be made between a
string which is zero-length and one which is not present (or null). As
a result, I believe that the prologue is 100% required in all cases and
can never be null. Having said that, I'm completely indifferent as to
whether the file format should require its presence or whether it should
give it a default value of a zero-length string.

>  - Should "fail" be attached to a specific message, rather than the
> protocol run as whole?
> 

This might be a good idea, since it allows greater specificity.

>  - We could also describe optional failure cases attached to messages,
> e.g. invalid_public_key = true, in which case the implementation is
> allowed to reject the message, or continue processing.
> 

In general, do you think it would be best to change the `fail` key from
a boolean to a string whose value indicates the type of failure
expected? In keeping with your example:

"fail": "invalid_public_key"

A null (or omitted) value would be considered non-failing.

If we choose to adopt failure cases, I think each case should be
represented in the test vector spec as a first-class citizen, including
whether or not the failure is optional/ignorable. The failure cases I
can think of are:

1. Invalid public key (ignorable)
2. Static key overwrite -- the remote party sent a static key when it
was already provided by the local party (fatal)
3. Decryption error -- a key or payload failed to decrypt (fatal)
4. Key missing -- a particular key is required by the given handshake
pattern but was not provided (fatal)

Can you think of any others?

>  - The fallback testing is specific to the XX/IK "pipes" concept, but
> as we consider other "compound" protocols this will probably become
> inadequate, and we will need something more general.  Maybe it would
> be best just to allow [init|resp]_remote_ephemeral so that fallback
> patterns could be tested directly for now, and we can think more about
> "compound" test vectors later?
> 

If `[init|resp]_remote_ephemeral` is provided, would that obviate the
need for `fallback` and `fallback_pattern`?

-- 
Alex