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

[Christer Holmberg <[e-mail]>]

Hi,

>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 am aware of systems, especially SBCs and media gating devices, that will
not accept media until the answer has been received - PRACK or no PRACK.

Having said that, I am staying neutral in this case - I just want text
that everyone can live with, so we can get the draft done...

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

The original intention of the id was to be able to indicate whether a new
association is to be established.

Martin¹s draft, draft-thomson-mmusic-sdp-uks, extends the usage, but we
earlier agreed that we are not going to reference it from draft-dtls-sdp.

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

The text was removed based on a comment in Ben¹s AD review (14th March):

"-9.2, paragraph 5: "The SIP message containing the offer SHOULD be sent
To the offerer¹s SIP proxy over an integrity protected channel":

This seems redundant with a previous statement 2 sentences back. (Yes,
this was in the original textŠ)"


Regards,

Christer