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

On 6/8/17 9:25 AM, Cullen Jennings 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.

The above discussion only pertains to DTLS used for *media*. Some 
additional consideration is needed regarding non-media usage. (Notably 
data channels.)

	Thanks,
	Paul

>> On Jun 7, 2017, at 3:52 PM, Flemming Andreasen <fandreas@cisco.com> 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 <fluffy@iii.ca> wrote:
>>>
>>>> On May 31, 2017, at 4:51 PM, Roman Shpount <roman@telurix.com> 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
>>>   
>>
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 