-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
noise: implement an early data API #1645
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
- initiator -> receiver: no early data
- receiver -> initiator: early data + auth
- initiator -> receiver: early dataa + auth
err = s.handleRemoteHandshakePayload(plaintext, hs.PeerStatic()) | ||
if err != nil { | ||
// stage 0 // | ||
// We don't expect any payload on the first message. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we do now
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. |
Not quite. The initiator would still send data before the connection has been authenticated, allowing the receiver to open streams ASAP.
Oh! I see, I thought this was for multistream. |
2022-08-19 conversation: need to update the PR based off recent Noise changes. This is being driven by WebTransport initiative work. |
This is recreating libp2p/go-libp2p-noise#110. There were a few merge conflicts, so I'm asking for a re-review.