[noise] Identity hiding properties of deferred patterns

[Loup Vaillant]

Hi,

I'm reading the Noise specifications, and I'm not sure what is the 
difference between identity hiding properties (3) and (9); and more 
importantly which is better for the respondent's identity hiding. From 
the specs:

3. Not transmitted, but a passive attacker can check candidates for the
    responder's private key and determine whether the candidate is
    correct. An attacker could also replay a previously-recorded message
    to a new responder and determine whether the two responders are the
    "same" (i.e. are using the same static key pair) by whether the
    recipient accepts the message.

9. An active attacker who pretends to be the initiator and records a
    single protocol run can then check candidates for the responder's
    public key.


So with (3) we'd have the following attacks:

Attack 3.1:
   1. Steal private key.
   2. Eavesdrop a handshake.
   3. Check that the private key matches.

Attack 3.2:
   1. Eavesdrop a handshake.
   2. Replay the start of the handshake.
   3. If the recipient accepts it, it's the same as what we previously
      eavesdropped.

With (9) we'd get this instead:

Attack 9.1:
   1. Initiate a connection
   2. verify that the response matches a public key we have.

---
Am I correct so far?
---

Attack 9.1 seems to dominate attack 3.1 because it only requires the 
public key. Strictly speaking it does _not_ dominate attack 3.2, but it 
would seem to me that there's an easy way to nullify 3.2 at the 
application level: don't use the same key pair on two places. For 
instance, if you're changing the IP you're responding from, change the 
key pair as well (if you can tell people which is the new IP, you can 
also tell them which is the new key pair).

So contrary to what I initially thought a few years ago, it seems that 
overall, (9) means _worse_ identity hiding properties than (3). And this 
goes contrary to the suggestion from the specs that deferred patterns 
may provide better identity hiding: from the list provided in the specs, 
here's where deferring messages changes something:

                Initiator      Responder
     NK             -              3
     NK1            -              9

     XK             8              3
     XK1            8              9

     IK             4              3
     IK1            0              9


Responder's identity hiding systematically goes from (3) to (9), so 
deferring seems to hurt there. And in the case of IK it utterly destroys 
the initiator's.

---
Would it be fair to say that in the vast majority of use cases, the 
deferred patterns hurt identity hiding more than they help?
---

Now identity hiding is not the only reason to use deferred pattenrs. The 
specs lists 3 different reasons:

1. The initiator may not want to send any 0-RTT encrypted data.
2. In some cases identity hiding may be better.
3. Future Noise extensions might need it.

But then I would respond:

To (1): How about sending the empty payload? Is there any security
         related reason to avoid sending a 0-RTT authentication tag?
To (2): As I've said above, this looks untrue in almost all cases.
         In what realistic cases would identity hiding improve?
To (3): Noted. But right now I have DH.

---
Would it be fair to say that in the vast majority of use cases, deferred 
patterns do not meaningfully improve security?
---

Thanks,
Loup.