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

i can live with that.

-Ekr


On Thu, Jun 8, 2017 at 12:58 AM, Roman Shpount <[email protected]> wrote:

> 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 <[email protected]>
> 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 <[email protected]> wrote:
>>
>>>
>>> > On May 31, 2017, at 4:51 PM, Roman Shpount <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic