[noise] Question: Sending ee, es, se, ss more than once?

[Ximin Luo]

By "respond" I don't necessarily mean "send a reply", I mean what the local
code does in a receive handler, e.g. launch new protocol state, change
existing state, or whatever.

When running under an unreliable transport a robust receive handler should
detect duplicates anyway since that can happen on real networks. Then it
should not matter whether a sender sends it twice or not, the effect will
be the same as if they had sent it once. Of course this should happen below
the Noise cryptographic layer, my point is that preventing resends is not
important, the focus should be on what happens *on the recipient*. Or just
state "noise expects not to receive duplicate packets and assumes a lower
layer is deduplicating them".

X


On Thu, Jun 21, 2018 at 8:42 AM, Trevor Perrin <trevp at trevp.net> wrote:

> On Thu, Jun 21, 2018 at 9:36 AM, David Wong <davidwong.crypto at gmail.com>
> wrote:
> > These tokens are not triggering any exchanges (unlike `s` and `e`).
> > These are just telling you to do a Diffie-Hellman key exchange and to
> > iterate the chaining key. Having them multiple times would just run
> > the chaining key multiple times and has no real effect. I'd say common
> > sense is enough and the spec doesn't need to mention this.
>
> I agree the spec doesn't need to mention this, since repeating
> operations in a handshake pattern would be harmless and have no
> effect, and common sense would dictate not to do this.
>
> However, the spec currently disallows sending a public key (s or e)
> multiple times, "to simplify implementation and testing".  The goal
> there was preventing implementations from worrying about the special
> case of overwriting an existing public key.
>
> I think the rationale for precluding multiple operations is weaker,
> since it doesn't normally appear as a special case in code so we
> wouldn't be saving implementations any thought or effort.
>
> OTOH, if we preclude redundant transmission of values, maybe it would
> be consistent to also preclude redundant computations.  So we could
> add another validity rule for that, similar to #2.
>
> Anyways, no strong opinion, but I could see adding another validity
> rule for this, if we decide we want this.
>
> Trevor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180622/370f259a/attachment.html>