search

libp2p / specs

Technical specifications for the libp2p networking stack
https://libp2p.io
1.58k stars 275 forks source link

webtransport: use CBOR to encode cert hashes during Noise handshake #429

Closed marten-seemann closed 2 years ago

marten-seemann commented 2 years ago

A typical protobuf sent here weighs ~75 bytes, whereas this encoding results in ~20 bytes more being sent.

Given that WebRTC (#412) will also use Noise's Early Data feature, it would be nice if the data structure sent in the early data was self-describing, to avoid confusing WebTransport's and WebRTC's early data in implementations that use a single instance of a Noise Transport (the Go implementation won't, but it's not completely crazy to imagine other implementations choosing this route). Having WebTransport use a CBOR struct with "webtransport-hashes" as a field name makes sure we don't accidentally define the same Protobuf (on the wire) and mix up things.

mxinden commented 2 years ago

I am not sure I understand the proposition. Am I paraphrasing this correctly?

Protobuf is not self-describing. This particular CBOR is self-describing. Being self-describing makes sure the message is not accidentally used for a different purpose (e.g. WebRTC instead of WebTransport).

Reponse below applies to what I understand above.

(the Go implementation won't, but it's not completely crazy to imagine other implementations choosing this route).

I don't think the Rust implementation would either.

to avoid confusing WebTransport's and WebRTC's early data in implementations that use a single instance of a Noise Transport

I would not consider this a large issue. In other words, I think we have bigger foot guns.

A typical protobuf sent here weighs ~75 bytes, whereas this encoding results in ~20 bytes more being sent.

As far as I know we don't use CBOR anywhere. I very much value the consistency, i.e. libp2p using mostly ProtoBuf.

Say we want to go the route of ensuring a message to not be mistaken as a different one, would a Protobuf Dictionary not do the job as well?

melekes commented 2 years ago

to avoid confusing WebTransport's and WebRTC's early data in implementations that use a single instance of a Noise Transport (the Go implementation won't, but it's not completely crazy to imagine other implementations choosing this route)

The problem seems a little far-fetched to me. Rust implementation also uses a separate instance of Noise. What would be the benefits of using the same instance between two transports?

marten-seemann commented 2 years ago

We now have the Noise extension registry, which is the more libp2p-idiomatic solution for this problem.