[noise] Minor KDF concern

[Trevor Perrin]

Hi,

I'm replying to a private email of Stephen's, but we agreed to take
this back to the list so others can chime in:

On Sat, Jul 5, 2014 at 10:24 PM, Stephen Touset <stephen at squareup.com> wrote:
> I'd argue the tradeoff in simplicity is extremely minor. On the other hand,
> it's a good hedge against implementation mistakes and (past or future)
> design mistakes.

The added complexity is minor, but so is the value of the hedge.  It
would only protect one specific design mistake: reusing the KDF on the
same input secret in two different contexts while failing to
differentiate the contexts through "info", expecting the output_len
will differentiate them.

If this was a general-purpose KDF, I might see more value in being so
conservative.  But existing general-purpose KDFs *don't* hedge this,
that I'm aware (HKDF in RFC 5869, PBKDF1 and 2 in RFC 2898, or the 2
KDFs in NIST SP 800-56A).

And the Noise KDF is for a specific protocol where we of course won't
make this mistake.


> I empathize with but am wary of reasoning that involves the
> words "Currently that situation won't happen"; protocols change over time.
> Reasoning about properties in v1 doesn't necessarily hold for v2, but that
> fact is easy to overlook.

That's a good point in general, and one reason the KDF uses HMAC
despite length-extension being irrelevant in this specific case, i.e.
a simpler Hash(key || stuff) would probably suffice, but HMAC is
generally safer.

But having a simple/minimal protocol is nice too, the more features we
add the more drag there is to implementation and review, and the more
risk of weird, overlooked interactions, so there's a tension here we
just have to argue through in each case, I think.


> That said, I agree it's not much of a problem in its current state. It just
> seems relatively trivial to change at this point in the design, doesn't
> increase complexity by any meaningful amount, and is a reasonable
> future-proofing step.

To me, this is feeling more like a "Security Consideration" that we
note (in some yet-unwritten spec), but not really worth adding to the
protocol.  I added some comments to the KDF to address this and
Jonathan's point, see if you think this is adequate for now.

https://github.com/trevp/noise/wiki/Boxes

Trevor