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

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Jun 2017 07:17:54 +0000

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Jun 2017 07:16:19 +0000

Roman, are you planning to create a pull request?

Cullen, feel free to suggest text that would address your issue.

I do NOT want to end up having a microphone argument about this in Prague.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Thursday 1 June 2017 at 01:51
To: Cullen Jennings <[email-masked]<mailto:[email-masked]>>
Cc: Ben Campbell <[email-masked]<mailto:[email-masked]>>, Eric Rescorla <[email-masked]<mailto:[email-masked]>>, Martin Thomson <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: 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 <[email-masked]<mailto:[email-masked]>> wrote:

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 ?

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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>>
>> 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-masked]<mailto:[email-masked]>>, Eric Rescorla <[email-masked]<mailto:[email-masked]>>
>> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
>>
>> 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-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>>
>> 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-masked]<mailto:[email-masked]>> wrote:
>>>
>>>> On 26 May 2017 at 20:37, Eric Rescorla <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 5 Jun 2017 08:03:09 -0600

> On May 31, 2017, at 4:51 PM, Roman Shpount <[email-masked]> wrote:
> 

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.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Jun 2017 15:36:05 +0000

Hi,

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

Could you suggest text that you WOULD agree to? :)

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 5 Jun 2017 12:58:37 -0400

On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings <[email-masked]> 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
> 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

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 7 Jun 2017 17:52:30 -0400

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-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     > On May 31, 2017, at 4:51 PM, Roman Shpount <[email-masked]
>     <mailto:[email-masked]>> 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
> 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

---

From: Roman Shpount <[email-masked]>
Date: Wed, 7 Jun 2017 18:58:49 -0400

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-masked]>
wrote:

> Can we get some specific text proposals from the people that seem to care
> about what we end up with here ?
>
> Thanks
>
> 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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Jun 2017 07:15:57 +0200

i can live with that.

-Ekr

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

> 1. Remove any recommendation regarding handling DTLS association before
> the answer (leave it up to implementation)
>>> > 1. Starting DTLS handshake until the corresponded answer is received
>>> is NOT RECOMMENDED since it can result in unauthenticated media. If

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 8 Jun 2017 07:25:17 -0600

I think the key things are:

For devices that want to minimize delay in setting up media and avoid media clipping, doing the TLS handshake as soon as possible is good design but in some cases this means the system does  the handshake before the identity of the fingerprint is known. 

If this is done, there is a risk of sending or receiving media before the identity of the remote side is known and the system needs to be designed to deal with theses risks in a way that is appropriate for the system that uses this.  

Receiving media from an unknown sources typically has fairly low risk while sending human generated media, such as the input from a microphone or camera, to a unknown users has much higher privacy risks. 

If we agree on the above, I think we could get text that covers that. Note that I think the key thing one needs to wait for is not just the fingerprint in the Answer but also knowing the identity of the Answer. In many cases this is just the From in the answer as the signaling is trusted but in case where it is not, the key thing is to  know the media is going to the appropriate person and that might involve more that just having the fingerprint in the answer. 

> On Jun 7, 2017, at 3:52 PM, Flemming Andreasen <[email-masked]> wrote:
> 
> Can we get some specific text proposals from the people that seem to care about what we end up with here ? 
> 
> Thanks 
> 
>> 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
>>  
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 8 Jun 2017 12:49:40 -0400

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?

Regards,
_____________
Roman Shpount

On Thu, Jun 8, 2017 at 9:25 AM, Cullen Jennings <[email-masked]> wrote:

> For devices that want to minimize delay in setting up media and avoid
> media clipping, doing the TLS handshake as soon as possible is good design
> but in some cases this means the system does  the handshake before the
> identity of the fingerprint is known.
>
> If this is done, there is a risk of sending or receiving media before the
> identity of the remote side is known and the system needs to be designed to
> deal with theses risks in a way that is appropriate for the system that
> uses this.
>
> Receiving media from an unknown sources typically has fairly low risk
> while sending human generated media, such as the input from a microphone or
> camera, to a unknown users has much higher privacy risks.
>
> If we agree on the above, I think we could get text that covers that. Note
> that I think the key thing one needs to wait for is not just the
> fingerprint in the Answer but also knowing the identity of the Answer. In
> many cases this is just the From in the answer as the signaling is trusted
> but in case where it is not, the key thing is to  know the media is going
> to the appropriate person and that might involve more that just having the
> fingerprint in the answer.
>
>
>
> ICE. I understand there are legacy implementations which use symmetric UDP
> for media. In such cases it is allowed to complete handshake. Such
> 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
> >>
> >
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Jun 2017 18:23:19 +0000

Hi,

...

>If we agree on the above, I think we could get text that covers that.

We don't "get" text - someone has to produce it :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 8 Jun 2017 15:09:50 -0400

> If we agree on the above, I think we could get text that covers that. Note that I think the key thing one needs to wait for is not just the fingerprint in the Answer but also knowing the identity o…

The above discussion only pertains to DTLS used for *media*. Some 
additional consideration is needed regarding non-media usage. (Notably 
data channels.)

	Thanks,
	Paul

> [email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Thu, 8 Jun 2017 16:28:16 -0400

On Thu, Jun 8, 2017 at 3:09 PM, Paul Kyzivat <[email-masked]>
wrote:

> additional consideration is needed regarding non-media usage. (Notably data
> channels.)
>

Do you have any suggestions regarding the non "media" usage, i.e. data?

I think offering end point SHOULD not send any data before the answer is
received, but I am not sure if this means actual data or negotiation
messages (INIT-ACK) as well.  Putting this another way, should answering
end point proceed with SCTP handshake before the answer is received? If
INIT-ACK is not sent, SCTP setup is delayed and no data is sent. This is
similar to what I have proposed with DTLS where it did not work because of
data requirements, but I got to ask if this is acceptable for data.

Regards,
_____________
Roman Shpount

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 8 Jun 2017 18:03:26 -0600

> On Jun 8, 2017, at 10:49 AM, Roman Shpount <[email-masked]> 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.
> 

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. 

I agree with Paul's comment that we need to deal with data too and my points did not. However, on data I will also argue that is not the place of this draft to define the totally security for all the systems that might use this.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 8 Jun 2017 20:36:49 -0400

On Thu, Jun 8, 2017 at 8:03 PM, Cullen Jennings <[email-masked]> 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.
> >
> 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

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 9 Jun 2017 07:32:55 -0600

I'd really really appreciate if you could give me a hint of it you agree with my original points I asked about or which ones you disagree with and why. The three points I am interested in are:

If we agree on a high level that is reasonable advice to be in this draft, then it's easier to get to the details.  I feel like we are in some weird loop where I keep trying to explain why I don't find the text acceptable and then you propose a change which does not have much to do with what I am concerned about. I suspect you have a strong idea of what you mean by "not secure" and I have no idea what you think being "secure" is in the various contexts of WebRTC, SIP, SIP to PSTN, and other places. 

> On Jun 8, 2017, at 6:36 PM, Roman Shpount <[email-masked]> wrote:
> 
> 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
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 9 Jun 2017 10:18:49 -0400

On Fri, Jun 9, 2017 at 9:32 AM, Cullen Jennings <[email-masked]> wrote:

> I'd really really appreciate if you could give me a hint of it you agree
> with my original points I asked about or which ones you disagree with and
> why. The three points I am interested in are:
>

Doing TLS handshake as soon as possible is a good design. Doing answer
identity and integrity validation and validating certificate fingerprints
as soon as possible is a better design. I understand that doing answer and
fingerprint validation is not always possible when interfacing with legacy
SIP devices, but there is no reason to design new solutions which process
media before the answer. For instance WebRTC has no reason to support
unverified media. Because of this, I think that anything that produces
unverified media is a bad design which has no reason to exist apart for
legacy interop. Specifics on how to design session description identity and
integrity validation are clearly out of scope for this draft.

All of this being said, what I am proposing for the sake of moving this
draft forward does not contradict any of your points. Once again, what I am
proposing is:

Draft does not advise that DTLS association should be established before
the answer is received (I think this is wrong), but it also does not advise
that it should not (you think it is wrong). This way implementation decides
what's best for it.

Does it contradict anything that you want to accomplish?
If it does, what needs to be changed?

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Jun 2017 08:00:54 +0000

Hi,

I also don’t see how Roman’s suggestion would contradict what Cullen wants to contradict. Roman, please make the pull request so that we have actual text to look at.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Friday 9 June 2017 at 17:18
To: Cullen Jennings <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer?

On Fri, Jun 9, 2017 at 9:32 AM, Cullen Jennings <[email-masked]<mailto:[email-masked]>> wrote:
I'd really really appreciate if you could give me a hint of it you agree with my original points I asked about or which ones you disagree with and why. The three points I am interested in are:

Doing TLS handshake as soon as possible is a good design. Doing answer identity and integrity validation and validating certificate fingerprints as soon as possible is a better design. I understand that doing answer and fingerprint validation is not always possible when interfacing with legacy SIP devices, but there is no reason to design new solutions which process media before the answer. For instance WebRTC has no reason to support unverified media. Because of this, I think that anything that produces unverified media is a bad design which has no reason to exist apart for legacy interop. Specifics on how to design session description identity and integrity validation are clearly out of scope for this draft.

All of this being said, what I am proposing for the sake of moving this draft forward does not contradict any of your points. Once again, what I am proposing is:

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

Draft does not advise that DTLS association should be established before the answer is received (I think this is wrong), but it also does not advise that it should not (you think it is wrong). This way implementation decides what's best for it.

Regards,
_____________
Roman Shpount