Subject: [MMUSIC] Handling of unverified data and media

From: Bernard Aboba <[email-masked]>
Date: Thu, 9 Mar 2017 12:10:00 -0800

In the W3C WEBRTC WG, an issue has been submitted relating to playout of
unverified media:
https://github.com/w3c/webrtc-pc/issues/849

It has been suggested that if the browser is configured to do so, that
playout be allowed for a limited period (e.g. 5 seconds) prior to
fingerprint verification:
https://github.com/w3c/webrtc-pc/pull/1026

Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the following
text, carried over from RFC 4572:

   Note that when the offer/answer model is being used, it is possible
   for a media connection to outrace the answer back to the offerer.
   Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
   role, it MUST (as specified in RFC 4145 [7]) begin listening for an
   incoming connection as soon as it sends its offer.  However, it MUST
   NOT assume that the data transmitted over the TLS connection is valid
   until it has received a matching fingerprint in an SDP answer.  If
   the fingerprint, once it arrives, does not match the client's
   certificate, the server endpoint MUST terminate the media connection
   with a bad_certificate error, as stated in the previous paragraph.

Given the outstanding issue relating to handling of unverified media, the
Chairs of the W3C WEBRTC WG would like to request clarification from the
IETF MMUSIC WG as to the meaning of the "MUST NOT" in the above paragraph.
In particular, what is it permitted for an implementation to do with
received data and media prior to verification? For example:

     1. May data received over the data channel be provided to the
application prior to verification?
         a. If the answer to the above is "no", may unverified received
data be delivered by the DTLS transport to SCTP, which may buffer it?
     2. May received media be played out prior to verification?

Bernard Aboba
On behalf of the W3C WEBRTC WG

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Mar 2017 10:58:00 +1100

I think that the data channel question is easy, anything other than a
"no" is not acceptable.  Data in that form enters the security
boundary for an origin and it doesn't make any sense to risk attack
there.  (It's also likely unnecessary, if a half a round trip of
signaling is slower than 5 round trips on the media path, then
something is messed up.)

I'm in two minds about the media part. For media, you could also
reasonably make the same origin-purity argument.  I'm inclined to say
that.  But we CAN isolate media from the origin (and we definitely
should if we allow this).

So, the media that arrives had to comply with your offer.  The DTLS
handshake also has to complete, which tells the receiver whether the
media needs to be confidential or not (at which point you can disable
this feature).

It's also possible that a receiver can require that an ICE
connectivity check was made (though this is inbound only, and I'm
unclear on whether having received an inbound check would normally
prevent the receiver from accepting a packet).

All told, that's a lot of information about the negotiated session for
an attacker to have.  The odds of this being an attack would *seem* to
be low.

On the other hand, we don't assume confidentiality of signaling; the
security model assumes that all this information is effectively public
and the protection we have against attack is the certificate
fingerprint.  This would remove that protection, albeit for a short
duration.

I have an extra question: does anyone plan to implement this?  It's
non-trivial.  I think that I know what I'd need to do in Firefox and
it would be quite disruptive.  Before committing to do that work
(which I will leave to others closer to this to decide), I'd probably
want more information on the actual advantage that it provides.

On 10 March 2017 at 07:10, Bernard Aboba <[email-masked]> wrote:
> Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the following text,
> carried over from RFC 4572:
>
>          a. If the answer to the above is "no", may unverified received data
> be delivered by the DTLS transport to SCTP, which may buffer it?
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 10 Mar 2017 17:47:44 -0500

My assumption always was that data is received, decoded and discarded until
fingerprint is received and verified. This way DTLS handshake completes,
key frames are decoded, but user is nor presented with any unverified media.

Regards,

_____________
Roman Shpount

On Thu, Mar 9, 2017 at 6:58 PM, Martin Thomson <[email-masked]>
wrote:

> data

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Mar 2017 16:01:10 -0800

I haven't spent too much time on it, but it seems like it ought to be safe
to hold
anything you receive prior to getting the fingerprint. It might be better,
as MT
suggests, to discard the datachannel data, but I'm not sure why it would be
necessary.

-Ekr

On Fri, Mar 10, 2017 at 2:47 PM, Roman Shpount <[email-masked]> wrote:

> My assumption always was that data is received, decoded and discarded
> until fingerprint is received and verified. This way DTLS handshake
> completes, key frames are decoded, but user is nor presented with any
> unverified media.
>
> Regards,
>
> _____________
> Roman Shpount
>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 10 Mar 2017 16:05:51 -0800

EKR said:

"I haven't spent too much time on it, but it seems like it ought to be safe
to hold
anything you receive prior to getting the fingerprint. It might be better,
as MT
suggests, to discard the datachannel data, but I'm not sure why it would be
necessary."

[BA] So you are saying that the MUST NOT allows the browser to buffer
data/media but not to pass it to the application (in the case of the data
channel) or to play it out?

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Mar 2017 16:56:38 -0800

Sorry, no, I was just talking about what might or might not be safe.... The
doc text is
a different question.

-Ekr

On Fri, Mar 10, 2017 at 4:05 PM, Bernard Aboba <[email-masked]>
wrote:

> EKR said:
>
> "I haven't spent too much time on it, but it seems like it ought to be
> safe to hold
>> I haven't spent too much time on it, but it seems like it ought to be
>> safe to hold
>> anything you receive prior to getting the fingerprint. It might be
>> better, as MT
>>> On Thu, Mar 9, 2017 at 6:58 PM, Martin Thomson <[email-masked]
>>> > wrote:
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 11 Mar 2017 14:52:18 +0000

Hi,

Is this a theoretical issue?

At least if you use ICE, you are going to receive the answer before you receive any media, as you are going to do the connectivity checks etc.

Also, in reality some implementations will not accept content before the answer arrives – no matter if DTLS is used or not – so the best thing is to, once the answer has been sent, just wait for a while before sending any content.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: 11 March 2017 02:57
To: Bernard Aboba <[email-masked]>
Cc: Flemming Andreasen <[email-masked]>; [email-masked]; mmusic WG <[email-masked]>
Subject: Re: [MMUSIC] Handling of unverified data and media

Sorry, no, I was just talking about what might or might not be safe.... The doc text is
a different question.

-Ekr

On Fri, Mar 10, 2017 at 4:05 PM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:
EKR said:

"I haven't spent too much time on it, but it seems like it ought to be safe to hold
anything you receive prior to getting the fingerprint. It might be better, as MT
suggests, to discard the datachannel data, but I'm not sure why it would be
necessary."

[BA] So you are saying that the MUST NOT allows the browser to buffer data/media but not to pass it to the application (in the case of the data channel) or to play it out?

On Fri, Mar 10, 2017 at 4:01 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
I haven't spent too much time on it, but it seems like it ought to be safe to hold
anything you receive prior to getting the fingerprint. It might be better, as MT
suggests, to discard the datachannel data, but I'm not sure why it would be
necessary.

-Ekr

On Fri, Mar 10, 2017 at 2:47 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
My assumption always was that data is received, decoded and discarded until fingerprint is received and verified. This way DTLS handshake completes, key frames are decoded, but user is nor presented with any unverified media.

Regards,

_____________
Roman Shpount

On Thu, Mar 9, 2017 at 6:58 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

On 10 March 2017 at 07:10, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 11 Mar 2017 16:12:18 +0100

2017-03-10 23:47 GMT+01:00 Roman Shpount <[email-masked]>:
> fingerprint is received and verified. This way DTLS handshake completes, key
> frames are decoded, but user is nor presented with any unverified media.

Just imagine an app (running in a computer with public IP) which sends
the SDP offer to a server, DTLS handshake is done, and the server
sends DataChannel messages to the browser *before* the browser
receives the SDP answer.

Do you mean that such a DataChannel messages should be discarded? I
consider that catastrophic as the server may not know whether the
browser has yet received the answer or not. Apps should implement some
kind of 3-way signaling handshake (send offer, receive answer, send
ACK) before the server sends any DataChannel message.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 11 Mar 2017 15:24:21 +0000

Hi,

In case of a Data Channel, you also need to establish the SCTP association before you can send any content.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
Sent: 11 March 2017 17:12
To: Roman Shpount <[email-masked]>
Cc: Flemming Andreasen <[email-masked]>; [email-masked]; mmusic WG <[email-masked]>
Subject: Re: [MMUSIC] Handling of unverified data and media

2017-03-10 23:47 GMT+01:00 Roman Shpount <[email-masked]>:
> completes, key frames are decoded, but user is nor presented with any unverified media.

Just imagine an app (running in a computer with public IP) which sends the SDP offer to a server, DTLS handshake is done, and the server sends DataChannel messages to the browser *before* the browser receives the SDP answer.

Do you mean that such a DataChannel messages should be discarded? I consider that catastrophic as the server may not know whether the browser has yet received the answer or not. Apps should implement some kind of 3-way signaling handshake (send offer, receive answer, send
ACK) before the server sends any DataChannel message.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 11 Mar 2017 16:25:46 +0100

AFAIK you dont need a SDP aswer for that.

El 11/3/2017 16:24, "Christer Holmberg" <[email-masked]>
escribió:

> Just imagine an app (running in a computer with public IP) which sends the
> SDP offer to a server, DTLS handshake is done, and the server sends
> DataChannel messages to the browser *before* the browser receives the SDP
> answer.
>
> consider that catastrophic as the server may not know whether the browser
> has yet received the answer or not. Apps should implement some kind of
> 3-way signaling handshake (send offer, receive answer, send

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 11 Mar 2017 15:30:25 +0000

Hi,

>AFAIK you dont need a SDP aswer for that.

Perhaps not, but it will still take some time to do, so maybe the offerer will have received the answer once it’s done and it is possible to start sending any media?

Regards,

Christer

El 11/3/2017 16:24, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>> escribió:
Hi,

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Iñaki Baz Castillo
Sent: 11 March 2017 17:12
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: Flemming Andreasen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mmusic WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Handling of unverified data and media

--
Iñaki Baz Castillo
<[email-masked]<mailto:[email-masked]>>

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 11 Mar 2017 14:40:33 -0700

Seem like this question is way out of scope for MMUSIC.  This is about some policy question at the application layer. Cleary the MMUSIC specs support things that play unverified media as well as applications that would not want to play it. 

> On Mar 9, 2017, at 1:10 PM, Bernard Aboba <[email-masked]> wrote:
> 
> In the W3C WEBRTC WG, an issue has been submitted relating to playout of unverified media:
> It has been suggested that if the browser is configured to do so, that playout be allowed for a limited period (e.g. 5 seconds) prior to fingerprint verification:
> Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the following text, carried over from RFC 4572:
> 
> Given the outstanding issue relating to handling of unverified media, the Chairs of the W3C WEBRTC WG would like to request clarification from the IETF MMUSIC WG as to the meaning of the "MUST NOT" in the above paragraph. In particular, what is it permitted for an implementation to do with received data and media prior to verification? For example:
> 
>      1. May data received over the data channel be provided to the application prior to verification?
>          a. If the answer to the above is "no", may unverified received data be delivered by the DTLS transport to SCTP, which may buffer it?

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Mar 2017 11:33:29 +1100

> suggests, to discard the datachannel data, but I'm not sure why it would be

I didn't consider holding data, which should be fine.  If the
fingerprint later turns out to be bad, then it's easy to pretend you
were hit by a spate of packet loss than hold arbitrary amounts of
(potential) junk.

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 13 Mar 2017 18:37:27 +0000

On Mar 11, 2017, at 9:52 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

No, even with ICE it’s possible for media or the DTLS handshake to outrace the answer.

This is because ICE offering endpoints respond to connectivity checks before they receive an answer.  When the answerer receives this successful connectivity check response, it puts the relevant pair in the Valid list, and then (if it has the active role, as recommended) can legitimately initiate DTLS on this pair.

If two ICE endpoints have a short RTT and clear connectivity between them, but a long RTT to their signaling server, this can happen quite easily.

Fortunately, DTLS has retransmissions, so this shouldn’t cause failure, just a brief setup delay.

Regards,

Christer

To: Bernard Aboba <[email-masked]<mailto:[email-masked]>>

-Ekr

-Ekr

Regards,

_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 13 Mar 2017 14:46:55 -0400

On Mon, Mar 13, 2017 at 2:37 PM, Jonathan Lennox <[email-masked]> wrote:

>
> On Mar 11, 2017, at 9:52 AM, Christer Holmberg <
> [email-masked]> wrote:
> At least if you use ICE, you are going to receive the answer before you
> receive any media, as you are going to do the connectivity checks etc.
>
>
> This is because ICE offering endpoints respond to connectivity checks
> before they receive an answer.  When the answerer receives this successful
> connectivity check response, it puts the relevant pair in the Valid list,
> and then (if it has the active role, as recommended) can legitimately
> initiate DTLS on this pair.
>
> If two ICE endpoints have a short RTT and clear connectivity between them,
> but a long RTT to their signaling server, this can happen quite easily.
>
> Also, in reality some implementations will not accept content before the
> answer arrives – no matter if DTLS is used or not – so the best thing is
> to, once the answer has been sent, just wait for a while before sending any
> content.
>
>
I think what specification says right now is that DTLS ClientHello should
be processed before answer arrives (
https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-21#section-5.2 ). I
think this clearly means DTLS handshake should complete. What should happen
with data received after DTLS handshake before fingerprint arrives is a
different issue.

Without processing DTLS handshake before signaling answer, end point
effectively slows down the connection setup by 5 sec (DTLS re transmit
timer). In practice this is enough for substantial number of calls being
hanged up by the caller or called party saying that call ended up in dead
air.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 13 Mar 2017 21:44:55 +0000

Hi,

If the answerer is in such a “hurry” to start sending media, one would think it also makes sure the answer is sent as early as possible, so that media can flow in both directions.

My question is: is this something that’s causing problems in real deployments, and requires a change in the standard? To me it seems like something that is very unlikely to occur, or at least like something that can easily be avoided by implementation means…

Regards,

Christer

From: Jonathan Lennox [mailto:[email-masked]]
Sent: 13 March 2017 20:37
To: Christer Holmberg <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; Bernard Aboba <[email-masked]>; Flemming Andreasen <[email-masked]>; Harald Alvestrand <[email-masked]>; mmusic <[email-masked]>
Subject: Re: [MMUSIC] Handling of unverified data and media

Hi,

Regards,

Christer

-Ekr

-Ekr

Regards,

_____________
Roman Shpount

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 13 Mar 2017 22:17:14 +0000

On Mar 13, 2017, at 5:44 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

You can send the answer as early as possible, but if two endpoints on the same subnet are talking via a signaling server on the other side of the planet, there’s only so much you can do.

I’m pretty sure this is something that’s already allowed by the current standards, but this fact is substantially non-obvious. So I’m afraid that we’ll get interop failures if we don’t point it out.

Note that in most cases it can only happen if endpoints take advantage of the freedoms granted by RFC 5245bis’s “passive-aggressive” algorithm, where we clarified that an endpoint is allowed to send on any valid pair, not just the selected nominated pair.  (If you don’t send until you have a nominated pair, I believe the only way this race can occur is if an ICE-Lite endpoint calls a Full endpoint; otherwise, the offerer is the controlling endpoint.)

I’m not sure what “implementation means” you’re thinking of, though.  Avoiding sending media/DTLS until you receive an incoming connectivity check?

Regards,

Christer

From: Jonathan Lennox [mailto:[email-masked]]
Sent: 13 March 2017 20:37
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: Eric Rescorla <[email-masked]<mailto:[email-masked]>>; Bernard Aboba <[email-masked]<mailto:[email-masked]>>; Flemming Andreasen <[email-masked]<mailto:[email-masked]>>; Harald Alvestrand <[email-masked]<mailto:[email-masked]>>; mmusic <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Handling of unverified data and media

Hi,

Regards,

Christer

-Ekr

-Ekr

Regards,

_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Mar 2017 12:44:29 +0000

Hi,

…

>I’m not sure what “implementation means” you’re thinking of, though.  Avoiding sending media/DTLS until you receive an incoming connectivity check?

Something like that.

Regards,

Christer

Hi,

Regards,

Christer

-Ekr

-Ekr

Regards,

_____________
Roman Shpount

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 25 Mar 2017 14:12:09 -0600

> On Mar 13, 2017, at 3:44 PM, Christer Holmberg <[email-masked]> wrote:
> 
> My question is: is this something that’s causing problems in real deployments, and requires a change in the standard? 

1-800 go fedex. See webrtc requirements documents from many years ago.

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 30 Mar 2017 19:14:26 +0000

We have a mailing list discussion (here), a bug (
https://github.com/w3c/webrtc-pc/issues/849) and a PR (
https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215) about
this.  I've copied the following comments to the latter two, so I'm adding
them here as well.

TL;DR: I don't think unverified media is compatible with ICE+DTLS.  Here is
why (you can go see the bug, too):

   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.

Maybe I'm missing something, but I think this is impossible.

On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings <[email-masked]> wrote:

> My question is: is this something that’s causing problems in real
> deployments, and requires a change in the standard?
>
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Mar 2017 15:50:42 -0500

Tim had a comment that didn't make it due to time, but I thought that
it was worth forwarding here:

<derf> What I was getting up to say was, I think it's "acceptable" to
provide the data to the application if and only if the application has
a way to know that it's (potentially) invalid (and when it becomes
valid).
<derf> What would _not_ be acceptable would be to provide the data to
the application in a way that's indistinguishable from receving valid
data.

In terms of what policy the *browser* application takes towards this
data, it would seem unwise to pass anything concrete to the origin.
Media might be isolated, but that leads to it being essentially
equivalent to mixed content.  the W3C might be ... let me just say
reluctant ... to add new ways of adding mixed content to the web.

On 30 March 2017 at 14:14, Peter Thatcher <[email-masked]> wrote:
> We have a mailing list discussion (here), a bug
> (https://github.com/w3c/webrtc-pc/issues/849) and a PR
> (https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215) about
> 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
> You cannot send DTLS from the local side before receiving the remote
> 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
> Since you can't send DTLS, you can't complete the handshake, and thus can't
> extract the SRTP key.
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 30 Mar 2017 17:11:17 -0500

The unverified media scenarios seem to depend on ICE connectivity being bi-directionally enabled so as to permit the DTLS negotiation to proceed in advance of remote fingerprint arrival. If ICE candidates are signaled separately from the DTLS fingerprint exchange it might be feasible, such as in ORTC signaling where the ICE parameters are exchanged before the DtlsParameters.

At the last WebRTC interim a scenario involving PRANSWER and Trickle ICE was presented. In the scenario, the PRANSWER included a fingerprint, but possibly one which did not match the certificate provided in DTLS unlike the final answer. I do not see how this could work but perhaps I am missing something.

> On Mar 30, 2017, at 14:14, Peter Thatcher <[email-masked]> wrote:
> 
> We have a mailing list discussion (here), a bug (https://github.com/w3c/webrtc-pc/issues/849) and a PR (https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215) about this.  I've copied the following comments to the latter two, so I'm adding them here as well.
> 
> TL;DR: I don't think unverified media is compatible with ICE+DTLS.  Here is why (you can go see the bug, too):
> 
> 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.
> 
> 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.
> 
> Since you can't send DTLS, you can't complete the handshake, and thus can't extract the SRTP key.
> 
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Mar 2017 17:50:37 -0500

These both sound like legitimate cases where ICE can precede
signaling.  I would recommend that the W3C think carefully about
whether they might like to accept (potentially) invalid data before we
spend a whole lot more time on the issue.

On 30 March 2017 at 17:11, Bernard Aboba <[email-masked]> wrote:
> The unverified media scenarios seem to depend on ICE connectivity being
> bi-directionally enabled so as to permit the DTLS negotiation to proceed in
> advance of remote fingerprint arrival. If ICE candidates are signaled
> separately from the DTLS fingerprint exchange it might be feasible, such as
> in ORTC signaling where the ICE parameters are exchanged before the
> DtlsParameters.
>
> At the last WebRTC interim a scenario involving PRANSWER and Trickle ICE was
> presented. In the scenario, the PRANSWER included a fingerprint, but
> possibly one which did not match the certificate provided in DTLS unlike the
> final answer. I do not see how this could work but perhaps I am missing
> something.
>

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 30 Mar 2017 23:40:25 +0000

Bernard, you are right that this is possible with ORTC, even though I think
it's impossible with WebRTC.  But that's clearly out of scope for the
MMUSIC WG.  Perhaps the right forum to discuss Cullen's 1-800-fedex use
case is in the context of ORTC (or WebRTC NV).

On Thu, Mar 30, 2017 at 3:50 PM Martin Thomson <[email-masked]>
wrote:

> This

---

From: Roman Shpount <[email-masked]>
Date: Thu, 30 Mar 2017 21:11:07 -0400

Peter,

What about ICE lite? If ICE lite sends an offer to WebRTC end point, it can
get DTLS ClientHello before it got the answer response from the WebRTC end
point. Since ICE lite client does not send ICE requests before sending
data, it will respond with ServerHello and establish the connection. At
this point data can be sent to it before the answer arrives and fingerprint
can be verified.

I think the right answer to this situation is not to send ServerHello until
answer and fingerprint is received. ClientHello should be buffered and only
handled when answer is received.

Regards,

_____________
Roman Shpount

On Thu, Mar 30, 2017 at 7:40 PM, Peter Thatcher <[email-masked]>
wrote:

> Bernard, you are right that this is possible with ORTC, even though I
> think it's impossible with WebRTC.  But that's clearly out of scope for the

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 31 Mar 2017 10:52:37 -0500

Imagine a WebRTC browser called A sends an offer to a SBC called S.  S sends PR offer accepting data channel but not others. ICE comes up between A and S. A TLS channel comes up between A and S. S forwards the offer to gateway called G over SIP with no ICE. G sends a TLS connection to A that is relayed via G. So this new connection is in the same ICE context. The ICE goes between A and S. But the 2nd TLS goes between A and G but gateway by S. 

I realize a more complete description would be useful but hopefully that is enough to think about a bit. 

> On Mar 30, 2017, at 2:14 PM, Peter Thatcher <[email-masked]> wrote:
> 
> We have a mailing list discussion (here), a bug (https://github.com/w3c/webrtc-pc/issues/849 <https://github.com/w3c/webrtc-pc/issues/849>) and a PR (https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215 <https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215>) about this.  I've copied the following comments to the latter two, so I'm adding them here as well.
> 
> On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Mar 13, 2017, at 3:44 PM, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 31 Mar 2017 10:54:14 -0500

> On Mar 30, 2017, at 5:50 PM, Martin Thomson <[email-masked]> wrote:
> 
> I would recommend that the W3C think carefully about

I realize the topic of playing out the data is very complicated, but the topic I think should be though about first is buffering the video i frames so they are not lost.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Mar 2017 10:58:00 -0500

On 31 March 2017 at 10:54, Cullen Jennings <[email-masked]> wrote:
> I realize the topic of playing out the data is very complicated, but the
> topic I think should be though about first is buffering the video i frames
> so they are not lost.

That is something I am quite comfortable with.  Any data that is
received doesn't need to be discarded outright, some of it can be held
for a short time in anticipation of being able to authenticate it.
That's likely critical for early call performance.  This is especially
bad for video where a) you can't send a lot, b) you need to send a
lot, and c) everything else that follows is dependent on that early
data.

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 31 Mar 2017 17:35:58 +0000

How did ICE+TLS "come up" butween A and S without A knowing S's ICE
ufrag/pwd, and thus S's fingerprint?  I assume it does know S's fingerprint
before it can decrypt any media from/through S.

Now are you suggesting that the remote fingerprint be changed to G's
fingerprint?  In that case, a new DTLS handshake would take place, but only
after A know's G's fingerprint.

In both cases, A knows the fingerprint before being able to decrypt
incoming media.

The only way to be able to decrypt media before having the remote
fingerprint is if you can receive the ICE ufrag/pwd before the  DTLS
fingerprint.  And with WebRTC/JSEP, it's impossible to get the ICE
ufrag/pwd before the DTLS fingerprint.  Changing to a second/different
fingerprint after that doesn't change anything.

On Fri, Mar 31, 2017 at 8:52 AM Cullen Jennings <[email-masked]> wrote:

>
> Imagine a WebRTC browser called A sends an offer to a SBC called S.  S
> sends PR offer accepting data channel but not others. ICE comes up between
> A and S. A TLS channel comes up between A and S. S forwards the offer to
> gateway called G over SIP with no ICE. G sends a TLS connection to A that
> is relayed via G. So this new connection is in the same ICE context. The
> ICE goes between A and S. But the 2nd TLS goes between A and G but gateway
> by S.
>
>    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.
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 Mar 2017 13:53:48 -0400

Peter,

Any comments on the ICE Lite scenario? I did see it in the wild.

Regards,

_____________
Roman Shpount

On Thu, Mar 30, 2017 at 9:11 PM, Roman Shpount <[email-masked]> wrote:

> Peter,
>
> What about ICE lite? If ICE lite sends an offer to WebRTC end point, it
> can get DTLS ClientHello before it got the answer response from the WebRTC
> end point. Since ICE lite client does not send ICE requests before sending
> I think the right answer to this situation is not to send ServerHello
> until answer and fingerprint is received. ClientHello should be buffered
> and only handled when answer is received.
>
> Regards,
>
> _____________
> Roman Shpount
>

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 31 Mar 2017 17:59:25 +0000

If the full ice endpoint receives an offer, it has the remote DTLS
fingerprint, so no problem on that

It's true that the ice lite endpoint will be able to receive media from the
full ice endpoint before it receives the DTLS fingerprint of the full ICE
endpoint.  So you are correct that this is an issue for ice lite endpoints,
just as it is for non-ICE endpoints.