[noise] Noise Explorer

[Trevor Perrin]

On Thu, May 24, 2018 at 8:54 AM, Karthikeyan Bhargavan
<karthik.bhargavan at gmail.com> wrote:
> 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.

Sure, but they might not be the best labels for the two classification
axes in 7.4 of the Noise spec.  I'll think about whether there's a
better way to label those axes - that might reduce some confusion.


> 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.


So your 0-2 match our existing "authentication" axis.

3 would need to be split up to cover the different degrees of
authentication the sender has for the recipient's public key, yielding
a set of options that could be paired with one of 0-2.

So that might end up similar to our current 2-axis classification
scheme?  I can totally believe that the presentation here could be
improved, but I'm not yet sure I understand the alternative proposal.

Stepping back, my concern was whether there was something incorrect or
missing from the spec's description.  It sounds like there isn't, and
we're just considering how to organize the discussion.

Trevor