Update the remote description after SDP negotiation?

[achingbrain]

This is related to #1166

For libp2p WebRTC-Direct after the DTLS handshake has taken place and the connection becomes ready to use, we open a datachannel and use it to verify the local and remote certificate fingerprints and the peer identifier so we can assert that the remote peer is the peer we think they are.

During connection we set the remote certificate fingerprint to a dummy value and disable fingerprint validation, since we are going to do it later.

When we come to do it we need access to the fingerprint of the remote certificate.

The browser RTCPeerConnection has a .currentRemoteDescription property - this returns:

an object describing the remote end of the connection as it was most recently successfully negotiated

and includes the fingerprint of the remote connection.

The node.js polyfill returns the remoteDescription when this property is accessed, the same as .remoteDescription - this is not quite right as the .remoteDescription property should return what was passed to .setRemoteDescription - this can be different to the currently negotiated state of remote end of the connection.

The Description class parses the fingerprint out of the description passed to .setRemoteDescription, later on that fingerprint is verified or not, depending on config - would it be possible to have a copy of the local Description that gets updated with the actual fingerprint the connection uses?

If this is done along with the final ICE candidates etc it would make it possible to implement .currentRemoteDescription on the polyfill correctly and also for me to implement the final piece of the WebRTC-Direct connection listener.

I can try to implement this if it's acceptable though it's really stretching my C++!

[xicilion]

sure, this is a feature that is needed on the listening side, I tried to make some modifications but may need to change the const attribute of libdatachannel's checkFingerprint function, which feels bad.
Maybe you can have a better implementation.

[achingbrain]

may need to change the const attribute of libdatachannel's checkFingerprint function, which feels bad

I opened #1204 to implement this and edit up removing the const attribute as above. It works though I'm open to better ideas..

[xicilion]

I opened #1204 to implement this and edit up removing the const attribute as above. It works though I'm open to better ideas..

Yes, I noticed that, adding currentRemoteDescription is a great idea, I like it.

[paullouisageneau]

The browser RTCPeerConnection has a .currentRemoteDescription property - this returns:

an object describing the remote end of the connection as it was most recently successfully negotiated

and includes the fingerprint of the remote connection.

The node.js polyfill returns the remoteDescription when this property is accessed, the same as .remoteDescription - this is not quite right as the .remoteDescription property should return what was passed to .setRemoteDescription - this can be different to the currently negotiated state of remote end of the connection.

The Description class parses the fingerprint out of the description passed to .setRemoteDescription, later on that fingerprint is verified or not, depending on config - would it be possible to have a copy of the local Description that gets updated with the actual fingerprint the connection uses?

@achingbrain I think there is a misunderstanding about what RTCPeerConnection.currentRemoteDescription is. The difference only matters during renegotiation: the current description corresponds to the last successful negotiation, whereas pendingRemoteDescription is the new one being negotiated. remoteDescription is the pending description if it exists, otherwise the current one. For more details look at Pending and current descriptions.

The situation you are discussing here does not happen in the standard because a peer is supposed to reject fingerprints that don't match, but the sure thing is that set descriptions must not be updated according to what happens on the wire. In this case changing the description might even be misleading as users could consider it as the source of truth for what the expected fingerprint was.

I appreciate the effort, however currentRemoteDescription is not a proper way to report information about the current connection to the user, I think a rtc::PeerConnection::remoteFingerprints() getter would be appropriate for this use case.

[achingbrain]

I chose currentRemoteDescription precisely because it can change during the lifetime of the connection, though my opinion is not very strong.

#1206 adds the suggested rtc::PeerConnection::remoteFingerprints() method.

[paullouisageneau]

I chose currentRemoteDescription precisely because it can change during the lifetime of the connection, though my opinion is not very strong.

Sure, all descriptions can change, only they have to be changed by signaling, and currentRemoteDescription must be the same as remoteDescriptionwhen there is no pending description. It must not be changed to reflect wire status.

#1206 adds the suggested rtc::PeerConnection::remoteFingerprints() method.

Thank you for adding!