Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer?

[Cullen Jennings <[e-mail]>]

> On Jun 8, 2017, at 10:49 AM, Roman Shpount <[e-mail]> wrote:
> 
> We can expand the language regarding unverified DTLS association that end point SHOULD inform the end user when unverified media is played and SHOULD not send user generated media until stream is verified.
> 
> I also want to add that fingerprints SHOULD be sent over integrity protected signaling channel. I think this should address your concern about the Answer identity. I think specifics of integrity protection of fingerprint delivery is outside of scope of this draft.
> 
> Would this address your comments?

No. 

You keep trying to design the overall security of every system that uses this draft in this draft and that won't work. You need to let the system that use this draft define out the security for that system works. All we need here is to define how to set up a DTLS session using TLS. How any systems decides to use identity founds in TLS is complicated and differs for different usages. That's the same here - how the fingerprint are bound to identities changes for different usages of this.  For example, the important part is to know who the media is coming from or going to. In some cases, integrity protection channels from trusted sources might provide that the SIP From  header and fingerprint were matched together and helped solve that. But in some case, for example the work on passport at IETF, it is not the integrity protected channel that that mattered, it was a signature on a the passport object that tied the fingerprint to the identity that is important.

What would help is if the first thing is do we agree on the points I sent out and if not, lets figure out why, and if yes, then we can work on text. 

I agree with Paul's comment that we need to deal with data too and my points did not. However, on data I will also argue that is not the place of this draft to define the totally security for all the systems that might use this. 



> 
> Regards,
> _____________
> Roman Shpount
> 
> On Thu, Jun 8, 2017 at 9:25 AM, Cullen Jennings <[e-mail]> wrote:
> 
> I think the key things are:
> 
> For devices that want to minimize delay in setting up media and avoid media clipping, doing the TLS handshake as soon as possible is good design but in some cases this means the system does  the handshake before the identity of the fingerprint is known.
> 
> If this is done, there is a risk of sending or receiving media before the identity of the remote side is known and the system needs to be designed to deal with theses risks in a way that is appropriate for the system that uses this.
> 
> Receiving media from an unknown sources typically has fairly low risk while sending human generated media, such as the input from a microphone or camera, to a unknown users has much higher privacy risks.
> 
> If we agree on the above, I think we could get text that covers that. Note that I think the key thing one needs to wait for is not just the fingerprint in the Answer but also knowing the identity of the Answer. In many cases this is just the From in the answer as the signaling is trusted but in case where it is not, the key thing is to  know the media is going to the appropriate person and that might involve more that just having the fingerprint in the answer.
> 
> 
> 
> > On Jun 7, 2017, at 3:52 PM, Flemming Andreasen <[e-mail]> wrote:
> >
> > Can we get some specific text proposals from the people that seem to care about what we end up with here ?
> >
> > Thanks
> >
> > -- Flemming (as MMUSIC co-chair)
> >
> >
> > On 6/5/17 12:58 PM, Roman Shpount wrote:
> >> On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings <[e-mail]> wrote:
> >>
> >> > On May 31, 2017, at 4:51 PM, Roman Shpount <[e-mail]> wrote:
> >> >
> >> > 1. Starting DTLS handshake until the corresponded answer is received is NOT RECOMMENDED since it can result in unauthenticated media. If unauthenticated media is played to the end user, in cases such as early media in SIP calls, this should be indicated to the end user.
> >>
> >> No. Doing the handshake as quickly as possible is recommend - it's what you do with the media before you know who you are talking to that is the issue you are concerned with. And knowing who you are talking often involves much more than checking the fingerprint. So I don't agree this is not recommended.
> >>
> >> There are also implementation issues with getting media and not playing it. End point will still need to either buffer or somehow process the received packets so that playback can be started when the answer is received. If handshake is delayed until answer is received, none of this is an issue, so implementation is simpler.
> >>
> >> More importantly, I do not think new systems should be built without ICE. I understand there are legacy implementations which use symmetric UDP for media. In such cases it is allowed to complete handshake. Such solutions are legacy and building new systems like this are not recommended. It is recommended that new systems should implement full ICE, consent to send, and do not complete DTLS handshake before an answer SDP is received.
> >>
> >> Regards,
> >> _____________
> >> Roman Shpount
> >>
> >
> 
>