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

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 May 2017 06:43:24 +0000

Hi,

The pull request based on the WGLC comments from Roman S and Martin T,
suggests text saying that if an offerer receives ClientHello it must not
send ServerHello until it has received the answer (that carries the
fingerprint associated with the DTLS association).

It has been claimed that we DO need to allow the offerer to establish the
DTLS association BEFORE it has received the answer, in order to support
certain early media use-cases. Until the offerer has received the answer,
such media would be considered un-authenticated. Others do not want to allow
it, due to security concerns.

We need to find a solution to this, so any input is welcome.

The pull request: https://github.com/cdh4u/draft-dtls-sdp/pull/31/files

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 May 2017 06:54:02 -0700

> fingerprint associated with the DTLS association).

I may have missed their comments, but I don't understand why you would make
that
rule. In neither TLS 1.2 or 1.3 are you able to evaluate the fingerprint at
this
point anyway, because you don't have the cert.

It's one thing not to determine that the handshake is complete until you
receive
the answer, but that's different from not sending the SH. That seems silly.
[0]

-Ekr

[0] I want to preemptively acknowledge that in most full-ICE cases, you
won't
be able to send the SH at this point anyway, but that's a distinct question.

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

---

From: Roman Shpount <[email-masked]>
Date: Tue, 16 May 2017 10:24:52 -0400

On Tue, May 16, 2017 at 9:54 AM, Eric Rescorla <[email-masked]> wrote:

> I may have missed their comments, but I don't understand why you would
> make that
> rule. In neither TLS 1.2 or 1.3 are you able to evaluate the fingerprint
> at this
> the answer, but that's different from not sending the SH. That seems
> silly. [0]
>
>
First of all, draft-thomson-mmusic-sdp-uks puts tls-id from the answer in
ClientHello. This tls-id can be used to identify that received ClientHello
is related to the current signaling exchange and refuse other ClientHello
messages.

Second, not sending ServerAnswer until signaling answer is received,
prevents unverified media and removes significant number of execution paths
that would need to be defined both in the dtls-id specification and then
tested during development and interop of compliant solutions. I do not want
to spend time defining this unless it is absolutely necessary.

As a small historic reference, all that previous versions of specifications
said is that ClientHello can be received by the offering party before the
answer is received. It did not specify how such ClientHello should be
processed. Webrtc group in W3C asked how unverified media should be
handled. We have determined that this should not occur with WebRTC end
points, but this does point out that handling of unverified media is indeed
undefined. I think dtls-id is the right place to specify this and the
simplest thing I can see is to prohibit it.

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 May 2017 07:48:21 -0700

> is related to the current signaling exchange and refuse other ClientHello

Not following why that is necessary at this stage. You can reject the
handshake
when it completes.

> to spend time defining this unless it is absolutely necessary.

I'm not sure what you're talking about in terms of "ServerAnswer". That's
not a TLS
concept AFAIK.

-Ekr

> As a small historic reference, all that previous versions of
> specifications said is that ClientHello can be received by the offering
> party before the answer is received. It did not specify how such
> ClientHello should be processed. Webrtc group in W3C asked how unverified
> media should be handled. We have determined that this should not occur with
> WebRTC end points, but this does point out that handling of unverified
> media is indeed undefined. I think dtls-id is the right place to specify
> this and the simplest thing I can see is to prohibit it.
>
> Regards,
> _____________
> Roman Shpount
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 May 2017 17:12:39 +0000

Hi,

…

Second, not sending ServerAnswer until signaling answer is received, prevents unverified media and removes significant number of execution paths that would need to be defined both in the dtls-id specification and then tested during development and interop of compliant solutions. I do not want to spend time defining this unless it is absolutely necessary.

I'm not sure what you're talking about in terms of "ServerAnswer". That's not a TLS concept AFAIK.

I assume he means ServerHello.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 May 2017 08:24:50 +0000

Hi,

I have updated the PR. The text now allows the offerer to establish the DTLS association before it has received the SDP answer, but that any media received before the answer shall be considered unauthenticated.

https://github.com/cdh4u/draft-dtls-sdp/pull/31

I intend to submit a new version of the draft soon, so please indicate if you don’t agree with the text – together with text that you (and hopefully others) would agree too :)

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 16 May 2017 at 20:12
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>, Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer?

Hi,

…

I'm not sure what you're talking about in terms of "ServerAnswer". That's not a TLSconcept AFAIK.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 May 2017 20:08:23 +1000

On 22 May 2017 at 18:24, Christer Holmberg
<[email-masked]> wrote:
> I have updated the PR. The text now allows the offerer to establish the DTLS
> association before it has received the SDP answer, but that any media
> received before the answer shall be considered unauthenticated.
>
> I intend to submit a new version of the draft soon, so please indicate if
> you don’t agree with the text – together with text that you (and hopefully
> others) would agree too :)

Roman is right here, this is going too far.  As ekr points out, we
over-corrected by insisting that the handshake not proceed without the
answer, but doesn't mean that we should let the handshake complete
without knowing to whom we are completing the handshake with.

There is a case for taking the data you receive and holding it until
you get an answer; it would be OK to allow that, though it would need
some careful writing.

However, I believe that the reason we've been asked to do this is in
aid of actually playing out media from a completely unauthenticated
source.  That's the point at which this goes pear-shaped.  The whole
point of this is to provide integrity, and that doesn't happen if an
attacker gets to provide the first few bits of a stream.

I realize that this makes Cullen's use case harder, but several
alternative solutions have been offered.

My preference is to forbid handshake completion until the anchors by
which the handshake is assessed (a=fingerprint, a=tls-id) are
available.

Second in preference to that is to allow received data to be saved,
but not used.  In no circumstance should we allow data to be *sent*.
It's very hard to guarantee that an error that is detected on the peer
will actually result in the connection terminating in a reasonable
period of time.  The current draft is vague on this point.

p.s., Tim's comment about media vs. data needs to be addressed.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 May 2017 20:39:40 -0600

> On May 16, 2017, at 12:43 AM, Christer Holmberg <[email-masked]> wrote:
> 

I strongly disagree with adding this at this level. Consider for example an endpoint that does not do ICE. Will you also wait until the identity checks are complete to check that the fingerprint is valid and not inserted by a MITM? That might make sense for WebRTC but it is something specified at a much higher system level than here. This should just be a building block that allows systems to use dtls-sdp as they see fit instead of trying to mandate how it will be used at a higher level.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 May 2017 09:52:06 +0000

Hi Cullen,

Please note that the PR has been updated.

Regards,

Christer

On 23/05/17 05:39, "Cullen Jennings" <[email-masked]> wrote:

>I strongly disagree with adding this at this level. Consider for example
>an endpoint that does not do ICE. Will you also wait until the identity
>checks are complete to check that the fingerprint is valid and not
>inserted by a MITM? That might make sense for WebRTC but it is something
>specified at a much higher system level than here. This should just be a
>building block that allows systems to use dtls-sdp as they see fit
>instead of trying to mandate how it will be used at a higher level.
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 May 2017 09:59:12 +0000

Hi,

>> you don¹t agree with the text  together with text that you (and
>>hopefully

If I understand correctly, you seem to suggest that we allow the handshake
to ³proceed² (see 1st paragraph of your reply), but not to ³complete². If
so, which endpoint is responsible to make sure that it doesn¹t ³complete²?

>but not used.  In no circumstance should we allow data to be *sent*.

I assume that also includes e.g., SCTP messages, i.e., in case of a WebRTC
Data Channel it wouldn¹t be allowed to establish the SCTP association.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 May 2017 20:04:52 +1000

> so, which endpoint is responsible to make sure that it doesn¹t ³complete²?

Whichever endpoint is unable to acquire the information it needs in
order to determine that the handshake is good.

> Data Channel it wouldn¹t be allowed to establish the SCTP association.

Yes, if you don't know to whom you are sending things, the only safe
action is not to send.  You can carve out exceptions for things like
handshaking SCTP on the proviso that they are found to contain no
actionable content, but that's tricky.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 May 2017 10:15:18 +0000

Hi,

>order to determine that the handshake is good.

Ok, so in the use-case we’ve been discussing it would still be the offerer.

But, what about data received before the completion is received? You said
that you would be ok to allow received data to be saved, but not used.
However, I assume Cullen would not agree to that.

Also, if I understand the FEDEX use-case, not only would you have to be
able to receive media - if you are e.g., going to provide DTMFs you could
also have to SEND data? Or?

>actionable content, but that's tricky.

I agree. We should avoid specifying per-protocol exceptions, because
sooner or later it will end up in a mess.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 May 2017 20:25:57 +1000

On 23 May 2017 at 20:15, Christer Holmberg
<[email-masked]> wrote:
> But, what about data received before the completion is received?

Well, I'd prefer to drop that, because buffering is tricky, but as I
said, holding it without even decrypting it could work.

Note that many DTLS-SRTP implementations won't even allow you to call
the exporter until the handshake is complete.  In order to even get
the data to arrive you have to do some inadvisable things to the
stack, such as accepting the peer's certificate, then you have to kill
the connection when the a=fingerprint arrives and doesn't match.  It's
much easier to validate inline.

> also have to SEND data? Or?

Yeah, sending DTMF to who-knows isn't a good idea.  I'm not clear on
whether sending DTMF is part of the arrangement.  Sounds like a great
way to avoid tarriffs altogether; I'm surprised that service providers
would even allow that.

This is why I think that this "unverified media" is the wrong solution
here.  It's not impossible to have an authenticated session and
accomplish these goals.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 May 2017 07:30:15 +0000

Hi,

I have updated the PR. The text now says that the offer must not
*finalise* the DTLS handshake until it has received the answer.

The text still allows to process media that is received before the answer
is received. I know Martin doesn¹t like that, and I have no idea what the
sec people will think about it, but I am trying to find some common
ground. I want to move the draft forward.

Is this something everyone can live with?

Š

>way to avoid tarriffs altogether; I'm surprised that service providers

Actually, before you get the SDP answer you can¹t send any DTMFsŠ

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 May 2017 18:37:47 +0800

> *finalise* the DTLS handshake until it has received the answer.

What does that mean? Finalize isn't a DTLS concept.

Also, you say that if you initiate the handshake before the answer
is received you are vulnerable to attacks. What attacks are those?

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 May 2017 21:01:58 +1000

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 May 2017 11:32:16 +0000

Hi,

You are the DTLS gurus - please suggest changes that makes the text
correct - and still hopefully keeps Cullen happy :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 May 2017 10:41:19 +0000

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] on behalf of [email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 31 May 2017 15:22:52 -0500

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]>
> Date: May 29, 2017 at 5:41:19 AM CDT
> To: Martin Thomson <[email-masked]>, Eric Rescorla <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 
> Hi,
> 
> I have updated the PR.
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 31 May 2017 15:45:43 -0600

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

---

From: Roman Shpount <[email-masked]>
Date: Wed, 31 May 2017 18:51:56 -0400

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]> 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 ?
>
> > 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:
> >>
> >> Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS
> association before it has received the SDP answer?