[noise] Explicit nonces (for lossy transports)

[D. J. Bernstein]

There's a long history of turning HTTP-over-TCP and XYZZY-over-TCP into
HTTP-over-crypto-over-TCP (HTTPS) and XYZZY-over-crypto-over-TCP and so
on. From a software-engineering perspective, what has made this not too
painful to implement is that crypto-over-TCP fits into essentially the
same interfaces as TCP:

   * Crypto-over-TCP provides a reliable bidirectional stream interface
     for use by HTTP, XYZZY, etc., similar to TCP's stream interface.

   * Crypto-over-TCP uses the Internet's unreliable packet interface.

I think it's a silly historical accident that all of this was done as
crypto-over-TCP instead of TCP-over-crypto---crypto on the bottom and
TCP-style retransmissions on top. The external interfaces are the same:

   * TCP-over-crypto provides a reliable bidirectional stream interface
     for use by HTTP, XYZZY, etc., similar to TCP's stream interface.

   * TCP-over-crypto uses the Internet's unreliable packet interface.

Connections over VPNs are typically TCP-over-crypto and illustrate that
TCP-over-crypto is preferable to crypto-over-TCP:

   * Crypto-over-TCP allows man-on-the-side denial-of-service attacks
     that have vastly lower cost than a network flood. For example, the
     attacker simply forges a TCP RST packet, tearing down the TCP
     connection. It's not hard to design TCP-over-crypto to make denial
     of service much more expensive.

   * Crypto-over-TCP creates larger confidentiality-auditing problems,
     i.e., less knowledge of what the confidentiality problems are.
     Both crypto-over-TCP and TCP-over-crypto require the auditor to
     look for metadata leaks at every layer and content leaks from the
     crypto, but crypto-over-TCP also has to look for content leaks from
     the TCP layer. I've never seen anyone systematically analyze this.

   * Experience indicates that the crypto layer in TCP-over-crypto,
     encrypting and authenticating packets, is simpler and smaller than
     a comparable crypto layer in crypto-over-TCP.

Fans of crypto-over-TCP might respond that the VPN example isn't
convincing---VPNs rely on the simplifying assumption that parties know
each other in advance. But how is this key-retrieval issue tied to the
engineering and security properties of the TCP-vs.-crypto layering?

The typical Internet situation---as opposed to the VPN situation---is
that the client looks up the public address of a publicly known server
and then makes a connection to the server. It's not hard to tweak the
lookup process to also provide the server's public key. Then Noise_XK
provides a session key for authentication and encryption with fast key
erasure, including encrypted client authentication. (CurveCP has a layer
that's identical at this level of detail, but I think Noise_XK is an
improvement over this CurveCP layer in various smaller details.)

Conceptually, each of these stages is a perfect match for packet-based
protocols, and running TCP _over_ this crypto layer is better than the
other way around. But---except in VPNs---people seem terrified to stray
from the model of crypto-over-TCP. The IETF, which has been failing for
decades to add any meaningful security to DNS, is now attempting to run
DNS over TLS over TCP---which might manage to encrypt but is far more
complicated and fragile than it needs to be. Noise expects to be running
over TCP or some equivalent stream protocol; formally, it isn't even
defined for packets.

I don't see denial-of-service attacks etc. as the most urgent problems
in crypto, and I have sympathy for people who want to defer solutions
until later (even when the solutions aren't difficult). But I don't
agree with the notion that these problems are an inevitable consequence
of _desirable_ layering.

---Dan