[noise] Security audit of Noise-based DNS tunnel, protocol layering

[Trevor Perrin]

Hi David,

Nice to hear about dnstt!, some thoughts:

On Sun, Apr 25, 2021 at 2:17 PM David Fifield <david at bamsoftware.com> wrote:
>
> A Noise-based DNS tunnel I wrote has recently had a security audit. You
> can see the report and a summary of changes here:
> https://www.bamsoftware.com/software/dnstt/security.html#cure53-turbotunnel-2021
> Of the 4 Noise-related issues discovered, 3 had to do with a dependency
> Noise library, which has already been updated:
> https://github.com/flynn/noise/security/advisories/GHSA-g9mp-8g3h-3c5c

Nonce overflow isn't that likely (2^64 messages!), and the
small-subgroup validation check doesn't matter for Noise, though I
suppose this is the kind of application where you might want to
specify one way or another to avoid some sort of "fingerprinting" of
implementations.

Invalid ciphertexts incrementing the nonce looks like a good catch though.


> I want to talk about this one: "UCB-02-005: Client ID security
> considerations & Noise authenticated data."
> https://www.bamsoftware.com/software/dnstt/cure53-turbotunnel-2021.pdf#page=8
[...]
> Back to UCB-02-005. Though it is outside the censorship circumvention
> threat model (in that model, encrypted DNS hides the client ID from all
> relevant adversaries) the audit rightly notes that if an attacker can
> discover or guess a user's client ID, they can send queries on behalf
> of, and receive responses intended for, that client. This because a
> client ID attached to a DNS query is a token that entitles the sender to
> interact with the data stream associated with that client ID. It's a bit
> like TCP hijacking, where an attacker can manipulate a connection if it
> knows a client's source IP address, port, and current sequence numbers.
> The attacker cannot actually *do* anything with the data it hijacks,
> because the reassembled KCP packets contain Noise messages, to which the
> attacker does not know the key; and any injected data will invariably
> fail integrity checks and at worst cause the session to terminate. But
> the fact is, certain kinds of manipulation are possible.
>
> To mitigate this risk, the audit report recommends folding the client ID
> into the associated data in the Noise AEAD construction. While a
> reasonable suggestion, I don't think it actually solves the problem in
> this case.

Using the associated-data for AEAD would be a nonstandard use of
Noise, if you want to "bind" additional data the more-supported way
would be to include it into the prologue or handshake data, so it's
used in deriving the session keys but doesn't require calculations on
every packet.

But I also agree with your last sentence, I'm not sure how that would
improve anything:  Binding the Noise messages to a clientID would
prevent reuse of the Noise messages across a *different* clientID but
that doesn't really seem like the issue they're describing?

Is there an actual issue here? Even if an attacker discovering or
guessing a client ID would be a DoS threat, how would that happen? If
a server supported a X simultaneous connections and an attacker probed
Y client IDs they might find a collision with Z probability, and you
could maybe juggle X, Y, and Z to feel a little uncomfortable with a
64-bit space, so at most you might want to consider a larger client
ID?


Trevor