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

[Cullen Jennings <[e-mail]>]

I'd really really appreciate if you could give me a hint of it you agree with my original points I asked about or which ones you disagree with and why. The three points I am interested in 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 a high level that is reasonable advice to be in this draft, then it's easier to get to the details.  I feel like we are in some weird loop where I keep trying to explain why I don't find the text acceptable and then you propose a change which does not have much to do with what I am concerned about. I suspect you have a strong idea of what you mean by "not secure" and I have no idea what you think being "secure" is in the various contexts of WebRTC, SIP, SIP to PSTN, and other places. 



> On Jun 8, 2017, at 6:36 PM, Roman Shpount <[e-mail]> wrote:
> 
> On Thu, Jun 8, 2017 at 8:03 PM, Cullen Jennings <[e-mail]> wrote:
> 
> > 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.
> 
> You have mentioned that we removed the requirement that session description should be sent over integrity protected channel. This requirement was present in https://tools.ietf.org/html/rfc5763#section-5 and got removed in this draft. I assumed you wanted to bring this back.
> 
> I understand that until answer identity and integrity is verified and until fingerprint is matched, received media is coming from an unverified source and ultimately not secure. Validation of session description identity and integrity is something that is outside of scope of this document. Stating that this document only provides a partial solution and that it SHOULD be used with a signaling channel that provides identity and integrity validation in order to guarantee that data delivered over  DTLS association is secure is very much in scope. It should also be in scope to state that media can be received before DTLS association is verified and that it is up to the application if this media should be played and how to appropriately inform the user.
> 
> I am trying to understand what exactly you are trying to change in my proposal. I am trying to propose something that addresses your points but apparently I am getting wrong. So, can you propose the text? 
> 
> Regarding handling of data, we just finished datachannel related drafts. None of them define how data sent over SCTP association is supposed to be handled before DTLS association is verified. If this information is not present in any of those drafts, should it simply be left undefined?
> 
> Keep in mind that people (like W3C in regard of webrtc) are asking how unverified media and data should be handled. If anything, some guideline should be provided in security considerations section of this draft.
> 
> Regards,
> _____________
> Roman Shpount
>  
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic