[noise] Questions regarding the Additional Symmetric Keys extension

[Trevor Perrin]

On Wed, Jul 11, 2018 at 7:40 PM, Mathias Hall-Andersen
<mathias at hall-andersen.dk> wrote:
>
> I have an updated draft for the ASK extension:
> https://github.com/rot256/noise-extension-ask/raw/f392d5e7aa48501c4e41b58ecf58ee8a077128d6/output/ask.pdf

Thanks Mathias,

I linked it from the wiki.

I had more thoughts about this new design (using ck directly) vs the
ask_master key:

(1) I mentioned previously that the ask_master key could be kept after
the handshake without affecting forward-secrecy of transport keys.
This would allow InitASK to be called post-handshake.  With this new
design, InitASK can only be called during the handshake.  One
implication of this is that InitASK won't ever be based on the final
handshake hash, unlike with ask_master.  For things like PSK
resumption, we probably want to bind the PSK to the entire handshake.

(2) A second loss is that an ask_master key could be deleted during
the handshake immediately after InitASK, for forward secrecy.  With
this new design, you only get in-handshake forward-secrecy once ck is
replaced.

Example:  Alice sends a 0-RTT encrypted message to Bob.  With this new
design, Alice has to hold onto ck (and thus all the ASKs, effectively)
until she gets Bob's response.  With the old design, Alice could
delete the ASKs after sending the message.  This is how the encryption
keys "k" work, so that's one benefit for deriving the ask_master key
in parallel with the next ck and k.

However, for the uses we're considering for ASKs, this may not be important:

 * Most ASKs will be used post-handshake, when ck has already been deleted.

 * There was str4d's use case of deriving random padding during the
handshake, but I can't see any benefit to an attacker from
compromising the key for this.

OTOH, if you're using an ASK to encrypt something during the handshake
- for some reason - you might prefer it to be like "k", so that you
could delete it right away for forward-secrecy.

So I'm not sure the right answer here (would be good to get str4d's
opinion, not sure if he's already committed).


> Maybe we should derive the first ASK output in the HKDF call that also instantiates the chain:
> The most likely use-case for ASK is the derivation of a single key per chain,
> by generating the first output together with the chain:
>
> """
> first_output, ask_chain = HKDF(ck,  h || label, info="ask", 2)
> """
>
> We would save a HKDF call and allow highly optimized/specialized
> implementations wishing to only generate a single output per chain to instead implement the ASK extension as:
>
> """
> first_output = HKDF(ck, h || label, info="ask", 1) # no chain is used, still compatible with full ASK implementation.
> """
>
> Which is about the best you can do in terms of computational effort.
> However this might complicate implementation of the extension.

That would impose a small cost on libraries, since they'd have to
store the next ASK in the chain, instead of returning it right away.

An alternative might be renaming GetASK -> GetChainASK, and adding a
GetSingleASK function that returns a single output as HKDF(ck, h ||
label, info="ask_single", 1).

Trevor