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

No ... the draft (with the PR) does not work. The key issue is the line 

   However, the offerer MUST NOT
   complete the DTLS handshake before it has received the SDP answer.

This breaks the usage of DTLS-SRTP with SIP and is not needed. The argument that you should not send media before you know who it is going to is not the problem. The key issue is that some times an SIP UA  needs to be able to receive media before it knows who it is from. Of course the UA should indicate in the caller ID etc that it is does not know who it is from. It might be really reasonable for the UA not to send any human generated media before it get the the dtls-id in the offer/answer, and validate any identity assertions, and validates in the certificates are not revoked, and whatever else the UA wants to to but the spec should not forbid receiving information while that is all happening. And to receive media, it needs to complete the DTLS handshake. 

Let me ask, for your average call flow that uses PRACK, do we think that call flow would work if we said there could not be any media before the Answer was received ? 


I'm sure the next issue is just my confusion but I was under the impression this would help solve the unauthenticated keying problem fro DTLS-SRTP. But the dtls-id in this draft never get tied to anything in the TLS session. Is that specified elsewhere? Do we need a ref to it ?

One other issues ... It seems that this removes from RFC5763 the line 

  The SIP message containing the offer SHOULD be sent to
   the offerer's SIP proxy over an integrity protected channel.

from RFC 5763. Any reason for that? Seems like the fingerprint should still be integrity protected. 






> On May 31, 2017, at 2:22 PM, Ben Campbell <[email protected]> wrote:
> 
> 
> Can people live with the PR as it currently stands, even if it’s not “perfect”? If not, what would it take to be able to live with it? It’s been almost 2 months since the IETF LC completed. It would be nice to progress this soon.
> 
> Thanks!
> 
> Ben.
> 
>> Begin forwarded message:
>> 
>> From: Christer Holmberg <[email protected]>
>> Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer?
>> Date: May 29, 2017 at 5:41:19 AM CDT
>> To: Martin Thomson <[email protected]>, Eric Rescorla <[email protected]>
>> Cc: "[email protected]" <[email protected]>
>> 
>> Hi,
>> 
>> I have updated the PR.
>> 
>> The text now says ³complete² instead of ³finalise². In addition, I removed
>> the text about attacks, and only kept the text saying that media received
>> before the answer must be considered unauthenticated.
>> 
>> If people are still not happy with the text, I¹d really appreciate some
>> text.
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> 
>> On 26/05/17 14:32, "mmusic on behalf of Christer Holmberg"
>> <[email protected] on behalf of [email protected]>
>> wrote:
>> 
>>> Hi,
>>> 
>>> You are the DTLS gurus - please suggest changes that makes the text
>>> correct - and still hopefully keeps Cullen happy :)
>>> 
>>> Regards,
>>> 
>>> Christer
>>> 
>>> 
>>> On 26/05/17 14:01, "Martin Thomson" <[email protected]> wrote:
>>> 
>>>> On 26 May 2017 at 20:37, Eric Rescorla <[email protected]> wrote:
>>>>> Also, you say that if you initiate the handshake before the answer
>>>>> is received you are vulnerable to attacks. What attacks are those?
>>>> 
>>>> It should be "complete" - on the assumption that a completed handshake
>>>> leads immediately to using the connection.  Really, it's using the
>>>> connection (sending or receiving data or using exporters) that puts
>>>> you at risk, but I don't think that it's worth putting that fine a
>>>> distinction on it.
>>> 
>>> _______________________________________________
>>> mmusic mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>> 
>> _______________________________________________
>> mmusic mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic