noise: implement an early data API

[marten-seemann]

This is recreating libp2p/go-libp2p-noise#110. There were a few merge conflicts, so I'm asking for a re-review.

[Stebalien]

Hm. Isn't our early data a bit too early here? I assume the initiator would send early data on the second message (when the connection is encrypted, and the client is authenticated) instead of the first.

Note: I can't actually use the early data until the sender has been authenticated.

I.e., I'd assume:

1. initiator -> receiver: no early data
2. receiver -> initiator: early data + auth
3. initiator -> receiver: early dataa + auth

[Stebalien]

we do now

[marten-seemann]

Hm. Isn't our early data a bit too early here? I assume the initiator would send early data on the second message (when the connection is encrypted, and the client is authenticated) instead of the first.

That wouldn't be early data, that would just be using the established Noise connection. In our case, we do want to send unencrypted, unauthenticated data. This data is, as far as I can tell, included in the handshake transcript hash, so if an attacker modifies it, the handshake will fail.

For WebTransport, we only need to send early data from the client to the server (the certificate hashes), we don't have anything to send in the opposite direction.

[Stebalien]

That wouldn't be early data, that would just be using the established Noise connection

Not quite. The initiator would still send data before the connection has been authenticated, allowing the receiver to open streams ASAP.

For WebTransport, we only need to send early data from the client to the server (the certificate hashes), we don't have anything to send in the opposite direction.

Oh! I see, I thought this was for multistream.

[BigLep]

2022-08-19 conversation: need to update the PR based off recent Noise changes. This is being driven by WebTransport initiative work.