[noise] Draft extension: Authentication of handshake data between messages

[Trevor Perrin]

On Sun, Jun 3, 2018 at 11:43 PM, str4d <str4d at i2pmail.org> wrote:
>
> If implementations are happy to handle the complexity, then I don't mind
> making the 'h' token more flexible in my draft. I just wanted to make
> sure we had thought through the ramifications, particularly with input
> from people who have more experience using Noise than I :)

Hi str4d, all,

Few points on all this:

Justin points out that an "h0" modifier resulting in an "h" token at
the beginning of the pattern is very simliar to the Noise prologue.  I
think that's true but OK and maybe even useful.  For example, with NLS
we end up having multiple types of prologue data to append together,
from the different protocol layers, so having another field to stick
things in might make this easier in some cases.  I don't think we
should deprecate or re-design the prologue in favor of "h0" though,
it's too late for that.

It sounds like we're comfortable with the idea that "h" and "psk"
tokens might need to trigger callbacks to get the data, in some cases.

str4d pointed out that we could have more complicated modifiers like
"h1t2" to place the "h" token more precisely into the pattern.  We
could do something like that with "psk" too.  I'm not sure we need to
specify those more-complicated modifiers anytime soon, but doing
simpler modifiers like "h1", "h2" etc for now doesn't preclude more
complicated modifiers later, if uses are discovered for them.

One concern:  I'm not sure we understand the use-cases for this
feature yet.  In particular, I think str4d's case involves appending
variable-length padding onto a fixed-length Noise message:

"""
- Read a fixed-length encrypted Noise message from the network.
- Call ReadMessage() to get the Noise plaintext.
- Extract a length field from the Noise plaintext.
- Read that many bytes from the network.
- Call AuthenticateData() with those bytes.
"""

I don't quite understand where this is useful, does it have to do with
censorship-circumvention, and is there some trial-decryption involved
in ReadMessage()?

Also, for this use-case, you'd want the authenticated-data to come
after the payload, but for PSKs we assumsed "pskX" applied the PSK to
the end of the tokens, but it was processed before the payload.  So
far we've always considered the payload coming at the end, after all
the tokens for a message pattern have been processed.

Trevor