RTCDtlsTransport.start() with multiple RTCDtlsFingerprint

[ibc]

start (RTCDtlsParameters remoteParameters);

dictionary RTCDtlsParameters {
             RTCDtlsRole                  role = "auto";
             sequence<RTCDtlsFingerprint> fingerprints;
};

Which is the purpose of passing multiple remote RTCDtlsFingerprint to the start() method? what should the UA do with them when it comes to verify the remote certificate? Should the UA check all the fingerprints?

[aboba]

According to JSEP Section 5.2.1, more than one fingerprint will be present when there is more than one certificate (as opposed to having multiple fingerprints for the same certificate):

o An "a=fingerprint" line for each of the endpoint's certificates,
as specified in [RFC4572], Section 5; the digest algorithm used
for the fingerprint MUST match that used in the certificate
signature.

However, in the same section it also says:

For DTLS, all m= sections MUST use the certificate for the identity
that has been specified for the PeerConnection; as a result, they
MUST all have the same [RFC4572] fingerprint value, or this value
MUST be a session-level attribute.

From this I conclude that we can have multiple fingerprints only if multiple certificates are passed in the DtlsTransport constructor.

[ibc]

I expected that the purpose multiple RTCDtlsFingerprint was letting the UA to validate a supported hash. This is, the user provides N RTCDtlsFingerprint with different hash (so different value) for the same remote certificate, and the browser can choose one of them (sha-224, sha-256, sha-384, sha-512...) to perform the validation.

From this I conclude that we can have multiple fingerprints only if multiple certificates are passed in the DtlsTransport constructor.

I don't think that a single DTLS peer can provide multiple certificates to the remote DTLS peer, so I don't understand how and why multiple certificates could be passed in the RTCDtlsTransport constructor.

[rshpount]

I think it was expected for end points to support multiple fingerprints in order to allow to match any of the several remote certificates. One use case was using different certificates when RTP and RTCP use different ports (which is no longer supported by WebRTC endpoints). In such case fingerprints for each of the certificates is provided and one of them matches on either RTP or RTCP.

[ibc]

So, to make things clear, the RTCDtlsFingerprint sequence has never been supposed to indicate different pairs of hash/value for the same fingerprint?

[ibc]

Guys, I don't understand anything. If someone wants different transports (with also different certificates) for RTP and RTCP he must:

• create a rtpIceTransport for RTP and another rtcpIceTransport for RTCP (created via rtpIceTransport.createAssociatedTransport(),
• create a rtpDtlsTransport for RTP (by passing rtpIceTransport to it) and another rtcpDtlsTransport for RTCP (by passing rtcpIceTransport to it).
• call start() on both RTCDtlsTransport by passing the remote DTLS parameters, which may be different in each case if the remote endpoint uses different certificates for RTP and RTCP.

So, all the rationale above regarding multiple fingerprints for validating different certificates makes no sense IMHO.

[rshpount]

Please keep in mind SDP interop. In case SDP is used to signal different certificates for RTP and RTCP, end point will specify fingerprints for two different certificates in the same m= line. There is no information in SDP which certificate is used for which component. Because of this, the end-point which receives such offer will not know which certificate will be used for RTP vs RTCP and will provide both fingerprints when starting rtp and rtcp transports. In any case, support for fingerprint sequence is required for SDP signaling interop, since SDP can include multiple fingerprints for the same m= line and all of them will need to be passed to RTCDtlsTransport.

Using RTCDtlsFingerprint sequence to specify different hash values for the same fingerprint is a valid scenario as well, especially when you need to interop with different end points which support different fingerprint algorithms. This is especially useful when new, more secure hash algorithm is being introduced in order to provide a clear migration strategy.

[ibc]

@rshpount 100% clear. I was not aware that there are real WebRTC 1.0 based endpoints that use different DTLS certificates when it comes to separate RTP and RTCP transports.

[ibc]

NOTE: I think the spec should detail this stuff in more detail.

[rshpount]

@ibc I am not sure if there are any end points that actually use different certificates for RTP and RTCP but I do believe current WebRTC end points support getting multiple fingerprints for the same m= line. Ability to pass the sequence of fingerprints to RTCDtlsTransport is needed to replicate the same behavior.

[ibc]

Clear. Thanks a lot.

I will send a PR with a more detailed text about this stuff, so will leave this issue open (unless the team decides that such a text is not needed).

[robin-raymond]

RTCDtlsTransport only uses a single certificate. A non-ORTC remote implementation might offer multiple certs which is why we need to allow a sequence of remote fingerprints so we can validate the remote party. But ORTC DTLS will never use more than one certificate which is why it's not a sequence in the constructor.

[aboba]

@ibc - If ORTC requires the fingerprint algorithm to correspond to the algorithm used in the certificate (as required in JSEP), then multiple fingerprints/hashes implies multiple certificates. However, currently the DtlsTransport constructor requires only a single certificate to be passed (and the cert argument is mandatory). So my conclusion is RTCDtlsTransport.getLocalParameters() will only have a single fingerprint/algorithm, although the remote peer may provide multiple fingerprints/algorithms.