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

[Roman Shpount <[e-mail]>]

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?

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
> >>
> >
>
>