Question and or idea about libp2p certificate

Help
1

Currently the public key is part of the “libp2p” certificate.

I am wondering whether it is possible to add also the
Services (protocols of identify) the Peer has to offer.
Of course those protocols should be encoded somehow, to reduce the amount of data)

Idea behind that is to accepting/rejecting peers as soon as possible. Would be for both peers the fastest way and efficient way to handle useful and non useful connections.

(For experts) Where in the certificate would be the best place to add such information (maybe also signing with the private key, might be useful)?

Any thoughts on this idea?

2

Maybe ?

I doubt it would be interesting in practice. I don’t think you could take actions uppon receiving the connection and certificate offer since it could open you to replay attacks (I could replace the protocols identification with an older protocols the node used some time ago and have you reject based on that old info).
So what you could instead is wait for the connection to be established to be sure the cert received was current, however then you can also use TLS1.3 pipelining to send this info in the same roundtrip you validate the connection.

The QUIC transport is able to get a usable connection within 1 RTT (0 with preshared keys). So when you pipeline something like identify you need 1RTT total to know when to reject the connection based on the info you need.

Doing anything in the cert is dodgy and we try to avoid doing it because it does not have the same security safeties as sending data in an established TLS channel.

3

Thank you for giving me a such a detailed answer.

So when I understand it correctly, a replay attack is a known issue for certificates when sending and receiving.
(Is it also the reason why it is so dodgy?)
Is there not a cure against such attack?

But just in case I would like to implement it by myself,
(For my servers and client’s) what would be the right place in the certificate. Or simply just enhance the crypto.proto (where the PublicKey is defined) with an optional entry for the protocols. But it should not harm the interoperability with ipfs nodes of course.
Thank in advance for any reply.

4

you can wait for the handshake to be completed.

It’s one of them, generally TLS secures the connection once it is established, before that you need to be very careful.

5

Ok after reading several articles about an
“Replay” attack. I simply think you are wrong about such an attack on the certificate at least for TLS 1.3. (there are counter measurements taken place to make sure that the certificate is not tempered, Details can be googled or just read the TLS spec)
But of course I can be wrong, in the end I am not an expert.

Also argument would be, that nobody would use a certificate when it is potentially be tempered.

I still hope that somebody has an answer where in the certificate would be the place to put such information about the provided services (protocols). Maybe there is a place for such information somewhere.

6

I am relatively sure they only work when the connection is established.
Like A send cert to B, E modify the cert sent to B, B generate response to A and at this point there is nothing E can do to fool A, A will always realise the cert has been tempered with.

Which is good, but that means B can’t take action on the certificate content until A has validated the handshake.
And if we need to wait for handshake completion anyway then we can send data in the secured channel (like we already do) pipelined with the handshake validation.

7

I think you could try doing what you want with Early data tls package - crypto/tls - Go Packages