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

[David Fifield]

On Tue, May 04, 2021 at 05:34:02PM -0700, Trevor Perrin wrote:
> > 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.

I see, thanks for that information. Putting that information in the
prologue indeed seems like a better way to effect the binding. I see in
the spec where it requires zero-length associated data in transport
messages:
https://noiseprotocol.org/noise.html#processing-rules
"Transport messages are then encrypted and decrypted by calling
EncryptWithAd() and DecryptWithAd() on the relevant CipherState with
zero-length associated data."

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

I don't think there's any serious issue. An attacker can check whether a
particular client ID is currently in use, and with a sustained attack
can deny service to a known client ID, but the space is meant to be big
enough not to be easily guessable. It is true that incoming packets pass
through a lot of non-trival code (the KCP layer) before they are seen by
Noise authentication. Authenticating each packet individually would
reduce attack surface, from a code security standpoint.

Binding the Noise connection with a client ID is not needed, I think.
Replaying messages with a different client ID wouldn't do anything:
those messages would wind up in a different queue on the server. It
would be like replaying someone else's TCP connection from a different
IP address—it doesn't interact with the original connection.

I think I'll leave the dnstt layering alone, for the sake of backward
compatibility. I'm working on another kind of tunnel now, one that has
more space available per packet, and maybe I'll experiment with
per-packet authentication there. Thanks for your comments.