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

Hi All,

I will try to put together a new pull request that will address Cullen's
concerns.

What I want to propose is:

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.

2. If DTLS associations are established before the corresponding answers
are received, these associations MUST be torn down when no more answers are
expected and no matching fingerprints are found.

So, as a result, unauthenticated media is NOT RECOMMENDED, but still
allowed. End user SHOULD be properly warned when unauthenticated media is
played. SIP is saved.

Finally, to provide secure solution for 1-800-GOFEDEX scenario with full
ICE end points, trickle ICE should be extended to provide tls-id and
fingerprint. This way DTLS association can be established before codecs are
negotiated, which should allow full featured bridging with SIP.

Regards,

_____________
Roman Shpount

On Wed, May 31, 2017 at 5:45 PM, Cullen Jennings <fluffy@iii.ca> wrote:

>
> 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 <ben@nostrum.com> 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 <christer.holmberg@ericsson.com>
> >> 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 <martin.thomson@gmail.com>, Eric Rescorla <
> ekr@rtfm.com>
> >> Cc: "mmusic@ietf.org" <mmusic@ietf.org>
> >>
> >> 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"
> >> <mmusic-bounces@ietf.org on behalf of christer.holmberg@ericsson.com>
> >> 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" <martin.thomson@gmail.com> wrote:
> >>>
> >>>> On 26 May 2017 at 20:37, Eric Rescorla <ekr@rtfm.com> 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
> >>> mmusic@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/mmusic
> >>
> >> _______________________________________________
> >> mmusic mailing list
> >> mmusic@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mmusic
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
>
>