[noise] non replayable XK/KK?

[Trevor Perrin]

On Mon, Jan 29, 2018 at 11:37 PM, Justin Cormack
<justin at specialbusservice.com> wrote:
> On 29 January 2018 at 16:12, Trevor Perrin <trevp at trevp.net> wrote:
>> Since the "defer" modifier really only applies to the four ?K
>> patterns, another option is to consider these as different base
>> patterns, e.g.
>>
>>   ?K = recipient key Known, and used immediately for 0-RTT encryption
>>   ?D = recipient key known, but encryption Deferred (no 0-RTT)
[...]
>
> That seems a good formulation as there really arent too many, and have a
> clear difference.

Let me summarize discussion so far, then see what implications are for
other deferred patterns.

---

Our current set of base patterns has:
 - *K patterns where the initiator has pre-knowledge of responder's
"s" and does 0-RTT encryption using "es"
 - *X patterns where the initiator doesn't have have pre-knowledge of
the responder's "s"

Justin pointed out that we're missing patterns where the initiator has
pre-knowledge of the responder's "s", BUT doesn't use it for 0-RTT
encryption.  Such patterns could be useful, in particular if:
 - the initiator doesn't want 0-RTT encryption, so there's no need to
send an authentication tag in first message
 - you don't want a replayed initial message to reveal whether the
server has the same identity (due to sending a response or not)
 - the responder wants to defer the DH calculation for
denial-of-service resistance or other performance reasons

So we could add four new *D base patterns (ND, XD, KD, ID), which can
be derived by either:
 * taking *K patterns, Deferring the "es" from the initial message to
the response, and eliminating any "ss" in initial message, or
 * taking the *X patterns and moving the responder's "s" to a pre-message

https://moderncrypto.org/mail-archive/noise/2018/001450.html


The role of modifiers vs base names
------------------------------------

We've talked about using modifiers to derive new patterns from the
existing base patterns.  So instead of naming these new patterns with
"D", we could name them with modifiers.  For example, "XD" could be
either "XK+defer", or "XX+pres".

The argument for using "*D" base names, instead of modifiers:
 - The new patterns seem useful and basic, it would be nice if they
had simple names
 - Using modifiers to move tokens around makes it hard to visualize
patterns, particularly if we start chaining such modifiers.

This last point suggests a general rule for base (2-letter) names vs
modifiers:  Modifiers like "fallback" and "psk*" work well because
they don't rearrange the tokens, they just add ("psk*"), or change the
boundary of pre-messages ("fallback").

So we could try to use 2-letter "base names" for different
arrangements of our base tokens, and only use modifiers for things
that leave this order of tokens unchanged (in other words, use
modifiers for additions or substitutions of tokens, rather than
"motion").


Signatures
-----------

As a test case, let's consider how we'd add patterns for signatures.

We can imagine a "sig" modifier which replaces "es" or "se" with a
"sig" token that indicates transmitting an encrypted signature.  This
modifier can only replace "es" or "se" when the sender's "s" (not the
recipient's) is involved (obviously, the sender can only sign with her
own key).

For example, the "sig" modifier can't be applied to NK, but can be
applied to ND and NX:

NK(rs):
  <- s
  ...
  -> e, es  # can't replace this es with signature
  <- e, ee

ND(rs):
  <- s
  ...
  -> e
  <- e, ee, es

NDsig(rs):
  <- s
  ...
  -> e
  <- e, ee, sig

NXsig(rs):
  -> e
  <- e, ee, s, sig


So far so good.  Unfortunately, none of the K* or I* patterns could
have the "sig" modifier applied, because "se" is used in the server's
response.

So to support "sig" variants here, we'd have to add another sort of
deferred patterns, focused on deferring the "se" in the server's
response to the client's next message.  This would be 8 new patterns,
so it's hard to know what to name them... maybe:
 - (IN, IK, IX, ID) -> (DN, DK, DX, DD)
 - (KN, KK, KX, ID) -> (PN, PK, PX, PD)  # "P" for pre-known static
but deferred...

Example for IN/KN:

IN(s):
  -> e, s
  <- e, ee, se

DN(s):
  -> e, s
  <- e, ee
  -> se


KN(s):
  -> s
  ...
  -> e
  <- e, ee, se

PN(s):
  -> s
  ...
  -> e
  <- e, ee
  -> se


Summary?
---------

Thinking about deferring operations, there's use cases for:
 - deferring the "es" from the initial message to subsequent message
(what we've mostly talked about)
 - deferring the "se" from the response message to subsequent message
(what this email proposes, to prepare for signatures)

For the first case, adding a set of four "*D" base patterns seems pretty clean.

For the second case, we'd have to add eight new patterns.  This isn't
quite as clean, making it less clear whether we should be handling all
this with new base patterns, or with modifiers ("deferes",
"deferse"?).  Maybe I still lean towards base patterns, but I'm not as
sure as I was earlier in the email...

Thoughts?


Trevor