[noise] Noise Explorer

[Karthikeyan Bhargavan]

Hey Trevor,

> I think you're objecting to the terms "authentication" and
> "confidentiality" for this, because you view authentication as
> relevant to both parties ("sender authentication", "receiver
> authentication”).

Not exactly, I think “authentication” and “confidentiality” are useful classifications.
My complaint was that some “authentication” properties were misclassified and placed within the confidentiality clauses.

For example: "This message can also be replayed, since there's no ephemeral contribution from the recipient.”
This is a useful point, but replay prevention is considered an authentication property (e.g. it can be achieved with a MAC without any need for encryption.)

Similarly, there is some notion of receiver authentication implied by "However, the binding between the recipient's alleged ephemeral public key and the recipient's static public key hasn't been verified by the sender” but this is also within the confidentiality section.

Instead, I would recommend the Authentication properties in 7.4 to include something like:

0. No authentication. This payload may have been sent by any party, including an active attacker.

1. Sender authentication vulnerable to key-compromise impersonation (KCI). ... 

2. Sender authentication resistant to key-compromise impersonation (KCI). …

3. Recipient authentication. The recipient knows that the sender intended to send this message to it and not to someone else. In other words,
    the attacker cannot redirect a message sent for one recipient to another recipient.

4. Replay prevention. The recipient can detect/prevent a message from being replayed.

Best,
Karthik


> 
> If we relabelled the two properties in the Noise spec to something
> like "recipient security properties" (instead of "authentication") and
> "sender security properties" (instead of "confidentiality"), would
> that clear things up and match your categories?
> 
> Trevor