[noise] Ordering of Tokens Within Messages

[Dennis Jackson]

Noise Protocol Specification Rev31, Section 7.3:
> Handshake patterns must be valid in the following senses:
>    1. Parties can only perform DH between private keys and public keys
>       they possess.

My reading of this rule is that `ss, s` is forbidden as the receiver
processes ss, before it posses s. Maybe I'm missing something?

Best,
Dennis

On 15/04/2019 13:13, Nadim Kobeissi wrote:
> Hello everyone,
> 
> As the result of a discussion with Loup Vaillant, the author of Monokex, I realized that the Noise Protocol Framework specification currently does not explicitly specify, whether, for example, such a handshake pattern is valid or not:
> 
>   <- s
>   …
>   -> e, es, ss, s
>   <- e, ee, se
> 
> The above pattern is IK, but modified such that in the first message, the `s` token appears right after the `ss` token, instead of right before it.
> 
> If one were to treat the Noise Protocol Framework as a state machine that evolves by processing each token atomically as they appear, then this above ordering of the tokens could in fact make processing the above handshake pattern impossible, as the initiator would have to calculate a Diffie-Hellman operation with a static key they have not yet explicitly loaded into their session state. This would mean that the above pattern is invalid.
> 
> However, if one were to treat the Noise Protocol Framework as a state machine that evolves by processing each *message* atomically, regardless of the internal ordering of tokens within that message, then the above pattern would in fact be functionally identical to IK.
> 
> I believe that my initial hypothesis is the more likely one here. This is because there is already evidence that the Noise Protocol Framework does care about the ordering of tokens. For example, at a certain point in the specification it is written that "If multiple public keys are listed in either party's pre-message, the public keys are hashed *in the order that they are listed*.” Of course, this speaks only of pre-messages, and there is no equivalent evidence of token ordering being relevant outside of pre-messages. But it suggests it strongly.
> 
> If my above pattern is invalid (which is more likely to be the case), then perhaps the Noise specification should be updated to explicitly say so? I have already updated Noise Explorer to add a rule such that when its parser is confronted with the above pattern, it declares the following error:
> 
> "tokenOrderIncorrect: 'Public key tokens must be ordered in a message to appear before Diffie-Hellman operations that implicate them.’”
> 
> Loup Vaillant has already added a similar error condition in his Monokex project as well.
> 
> Happy to hear your thoughts.
> 
> Sincerely,
> 
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software
> 
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20190415/082bf698/attachment.sig>