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

[Roman Shpount <[e-mail]>]

On Thu, Jun 8, 2017 at 8:03 PM, Cullen Jennings <[e-mail]> wrote:

>
> > On Jun 8, 2017, at 10:49 AM, Roman Shpount <[e-mail]> wrote:
> >
> > We can expand the language regarding unverified DTLS association that
> end point SHOULD inform the end user when unverified media is played and
> SHOULD not send user generated media until stream is verified.
> >
> > I also want to add that fingerprints SHOULD be sent over integrity
> protected signaling channel. I think this should address your concern about
> the Answer identity. I think specifics of integrity protection of
> fingerprint delivery is outside of scope of this draft.
> >
> > Would this address your comments?
>
> No.
>
> You keep trying to design the overall security of every system that uses
> this draft in this draft and that won't work. You need to let the system
> that use this draft define out the security for that system works. All we
> need here is to define how to set up a DTLS session using TLS. How any
> systems decides to use identity founds in TLS is complicated and differs
> for different usages. That's the same here - how the fingerprint are bound
> to identities changes for different usages of this.  For example, the
> important part is to know who the media is coming from or going to. In some
> cases, integrity protection channels from trusted sources might provide
> that the SIP From  header and fingerprint were matched together and helped
> solve that. But in some case, for example the work on passport at IETF, it
> is not the integrity protected channel that that mattered, it was a
> signature on a the passport object that tied the fingerprint to the
> identity that is important.
>
> What would help is if the first thing is do we agree on the points I sent
> out and if not, lets figure out why, and if yes, then we can work on text.
>

You have mentioned that we removed the requirement that session description
should be sent over integrity protected channel. This requirement was
present in https://tools.ietf.org/html/rfc5763#section-5 and got removed in
this draft. I assumed you wanted to bring this back.

I understand that until answer identity and integrity is verified and until
fingerprint is matched, received media is coming from an unverified source
and ultimately not secure. Validation of session description identity and
integrity is something that is outside of scope of this document. Stating
that this document only provides a partial solution and that it SHOULD be
used with a signaling channel that provides identity and integrity
validation in order to guarantee that data delivered over  DTLS association
is secure is very much in scope. It should also be in scope to state that
media can be received before DTLS association is verified and that it is up
to the application if this media should be played and how to appropriately
inform the user.

I am trying to understand what exactly you are trying to change in my
proposal. I am trying to propose something that addresses your points but
apparently I am getting wrong. So, can you propose the text?

Regarding handling of data, we just finished datachannel related drafts.
None of them define how data sent over SCTP association is supposed to be
handled before DTLS association is verified. If this information is not
present in any of those drafts, should it simply be left undefined?

Keep in mind that people (like W3C in regard of webrtc) are asking how
unverified media and data should be handled. If anything, some guideline
should be provided in security considerations section of this draft.

Regards,
_____________
Roman Shpount