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

[Roman Shpount <[e-mail]>]

As a way forward on this issue, I am proposing the following:

1. Remove any recommendation regarding handling DTLS association before the
answer (leave it up to implementation)
2. Put a note that accepting DTLS association before the answer can result
in unverified media and if this media is played back to the end user, end
user SHOULD be notified that media is coming from an unverified source.
3. Add clarification that DTLS associations established before the answer
MUST be torn down when no more answers are expected and that fingerprints
in any of the received answers match the negotiated certificate (Right now
it is specified that DTLS association MUST be torn down if it does not
match the answer. This is wrong if forking is used and multiple answers are
received).

Does anyone opposes this?

Regards,

_____________
Roman Shpount

On Wed, Jun 7, 2017 at 5: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
>
>
>
>