search

w3c / webrtc-pc

WebRTC 1.0 API
https://w3c.github.io/webrtc-pc/
Other
437 stars 115 forks source link

Specify an AllowUnverifiedMedia RTCConfiguration property #849

Closed fluffy closed 7 years ago

dontcallmedom commented 8 years ago

@fluffy can you say more of why we need this property and what it would be used for?

aboba commented 7 years ago

@dontcallmedom Media can arrive on a DtlsTransport prior to verification of the remote fingerprint. So I think this is about how to handle this (such as whether to drop the media or decrypt it, or whether to allow the media to be rendered prior to validation). But we need to understand exactly what setting AllowedUnverifiedMedia would do.

alvestrand commented 7 years ago

Media can't arrive before the certificates arrive (DTLS can't be completed, so we don't get the key exchange, so we can't decrypt). Right? So it only matters if verifying the fingerprints takes longer than actually doing the key exchange; I don't quite see how that's a realistic scenario, but I may be missing what's intended.

aboba commented 7 years ago

@alvestrand Once the Offer arrives at the Answerer, the Answerer can verify the Offer's a=fingerprint line, and can start sending media. However, before the Answer arrives, the Offerer cannot verify the self-signed certificate that it received from the remote party during the DTLS handshake. So the question is what the Offerer should do about media that arrives before it receives the Answer and can verify that the certificate it received has the same fingerprint as one of the a=fingerprint lines in the Answer.

alvestrand commented 7 years ago

@aboba I see. The DTLS handshake exchanges the certificates inline, so it can complete before the answer arrives.

aboba commented 7 years ago

Due to the RFC 4572 verification requirement, we can't render media before verification of the remote fingerprint, and it seems particularly risky to allow that requirement to be loosened under programmatic control.

A more achievable goal is to remove latency from the system and try to avoid loss of initial packets (such as those in a keyframe) as much as possible. addTransceiver helps by allowing the RtpReceiver to be hooked up to a video tag, and ICE improvements such as passive-aggressive nomination can allow the DTLS handshake to start before ICE completes. It also may be feasible to buffer media received prior to verification without rendering (as ORTC allows) so that rendering can begin as soon as the remote fingerprint is verified.

steely-glint commented 7 years ago

I don't understand how ICE could complete if the Offerer doesn't yet know the Answerer's ufrag/pwd ?

alvestrand commented 7 years ago

At initial handshake, early meadia only happens from the answerer to the offerer, if the answer is delayed more than the ICE exchange and the media (which was sent from the answerer after the answer was sent).

So the signalling path has to be slower than the ICE exchange + the DTLS exchange in order for this to be a problem in WebRTC:

aboba commented 7 years ago

With passive aggressive nomination, DTLS negotiation can begin after a successful response and with DTLS 1.3 can complete quickly enough to allow portions of a keyframe to arrive prior to verification of the fingerprint. If those packets are discarded, they would need to be recovered via RTX or FEC or the keyframe will be lost.

The easiest solution is to buffer the packets prior to verification (this is what ORTC Lib does),

On Nov 9, 2016 11:29 AM, "Harald Alvestrand" notifications@github.com wrote:

At initial handshake, early meadia only happens from the answerer to the offerer, if the answer is delayed more than the ICE exchange and the media (which was sent from the answerer after the answer was sent).

So the signalling path has to be slower than the ICE exchange + the DTLS exchange in order for this to be a problem in WebRTC:

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/webrtc-pc/issues/849#issuecomment-259503305, or mute the thread https://github.com/notifications/unsubscribe-auth/AAxXa8Zi6gX9M-4V7KqnZW4CApxEyOWEks5q8h8GgaJpZM4KOs8b .

alvestrand commented 7 years ago

From the decision summary of December interim:

alvestrand commented 7 years ago

At April interim: The WG was confused about what sequence of signalling messages could lead to this state, given that we have to have at least a (PR-)answer in order to establish ICE connectivity, and this answer will already contain at least one a=fingerprint attribute, which, presumably, can't validate the data - so we have data coming in that isn't just unverified, it's failing verification.

After April interim: There seems to be language in 4572 that says that the suggested operation is not allowed (section 6.2). If this is true, we should not attempt to allow it in WebRTC.

pthatcherg commented 7 years ago

Taylor and I did some call flow analysis and came to the following conclusion: this is not possible with standard ICE and DTLS. Here's why:

  1. You can receive DTLS from the remote side before receiving the remote description (and thus fingerprint). This happens if the remote side sends an ICE connectivity check and the local side sends a response and then the remote side sends a DTLS packet.

  2. You cannot send DTLS from the local side before receiving the remote description (and thus fingerprint). This is because you can't send an ICE connectivity check until you have the remote ICE ufrag and pwd, and thus can't get an ICE connectivity check response, and thus can't send DTLS. This is because you can't send anything other than ICE until you get an ICE connectivity check response.

  3. Since you can't send DTLS, you can't complete the handshake, and thus can't extract the SRTP key.

It could work with ICE+SDES, but I don't see how it can work with ICE+DTLS. Maybe that's why 1-800-fedex was discussed as a use case for WebRTC in the early days before we chose to mandate DTLS. But now that DTLS is required, I think that this use case is impossible.

pthatcherg commented 7 years ago

To be more clear, even in Cullen's case of a middle box trying to do ICE/DTLS magic:

  1. The receiving endpoint cannot decrypt the media until is has a key.
  2. It doesn't have a key until the DTLS handshake complete.
  3. The DTLS handshake can't complete until an ICE connectivity response is received.
  4. The ICE connectivity response cannot be received until an ICE connectivity check is sent.
  5. An ICE connectivity check cannot be sent until the ICE ufrag and pwd is known.
  6. With JSEP, the ICE ufrag/pwd cannot be known until the remote DTLS fingerprint is known.

Therefore the receiving endpoint cannot decrypt the media until the remote DTLS fingerprint is known.

stefhak commented 7 years ago

There is some more discussion happening over at IETF / MMUSIC (https://www.ietf.org/mail-archive/web/mmusic/current/maillist.html). It seems that there is not yet fully clear if and when this can happen given JSEP etc. I'm adding the "Pending rtcweb action" label though it is really in the MMUSIC group in IETF the discussion is happening right now.

stefhak commented 7 years ago

Just to keep track of stuff: A liaison statement was sent to MMUSIC: https://mailarchive.ietf.org/arch/msg/mmusic/z-BjKpQpjrHq6RBKlc1gY14mpoQ

the draft answer (NOTE: not yet confirmed by the MMUSIC mail list, deadline to comment is April 28) from MMUSIC is: https://mailarchive.ietf.org/arch/msg/mmusic/TcyynbwyBsmJhE9eLac-gt33wtQ

stefhak commented 7 years ago

Closing this issue as it seems (from the discussion here, in MMUSIC and in the PR #1026 among other places) that unverified media cannot happen for a browser implementing WebRTC.