<div dir="ltr"><div><div>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.<br><br></div>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".<br><br></div>X<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 21, 2018 at 8:42 AM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Jun 21, 2018 at 9:36 AM, David Wong <<a href="mailto:davidwong.crypto@gmail.com">davidwong.crypto@gmail.com</a>> wrote:<br>
> These tokens are not triggering any exchanges (unlike `s` and `e`).<br>
> These are just telling you to do a Diffie-Hellman key exchange and to<br>
> iterate the chaining key. Having them multiple times would just run<br>
> the chaining key multiple times and has no real effect. I'd say common<br>
> sense is enough and the spec doesn't need to mention this.<br>
<br>
</span>I agree the spec doesn't need to mention this, since repeating<br>
operations in a handshake pattern would be harmless and have no<br>
effect, and common sense would dictate not to do this.<br>
<br>
However, the spec currently disallows sending a public key (s or e)<br>
multiple times, "to simplify implementation and testing".  The goal<br>
there was preventing implementations from worrying about the special<br>
case of overwriting an existing public key.<br>
<br>
I think the rationale for precluding multiple operations is weaker,<br>
since it doesn't normally appear as a special case in code so we<br>
wouldn't be saving implementations any thought or effort.<br>
<br>
OTOH, if we preclude redundant transmission of values, maybe it would<br>
be consistent to also preclude redundant computations.  So we could<br>
add another validity rule for that, similar to #2.<br>
<br>
Anyways, no strong opinion, but I could see adding another validity<br>
rule for this, if we decide we want this.<br>
<span class="HOEnZb"><font color="#888888"><br>
Trevor<br>
</font></span></blockquote></div><br></div>