Subject: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp

From: Flemming Andreasen <[email-masked]>
Date: Fri, 21 Apr 2017 09:08:00 -0400

Greetings MMUSIC

Following the recent changes in dtls-sdp, we are issuing a 1-week WGLC 
on the changes from -22 to -24, i.e.:

https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-dtls-sdp-22&url2=draft-ietf-mmusic-dtls-sdp-24

If you have any comments on the changes, please provide those by Friday, 
April 28. Comments should be sent to the document authors and the MMUSIC 
WG list.

Thanks

-- Flemming (as MMUSIC co-chair)

---

From: Roman Shpount <[email-masked]>
Date: Wed, 26 Apr 2017 13:03:52 -0400

I have several comments regarding the document:

1. I would like to add justification for tls-id to the introduction and
change:

The SDP 'tls-id' attribute can also be used for negotiating a TLS
connection, using the procedures in this document in conjunction with the
procedures in [RFC5763] and [RFC8122].  The TLS specific considerations are
described in Section 8.

to:

The SDP 'tls-id' attribute can be specified when negotiating a TLS
connection, using the procedures in this document in conjunction with the
procedures in [RFC5763] and [RFC8122].  The unique combination of SDP
'tls-id' attribute values can be used to identity the negotiate TLS
connection.  The unique value can be used, for example, within TLS protocol
extensions to differentiate between multiple TLS connections and correlate
those connections with specific offer/answer exchanges.  The TLS
specific considerations are described in Section 8.

2. In section 8 "mulitple" should be "multiple"

3. I think in section 10 RFC Updates it would look better if the title of
the section would be formatted like "10.2.1. Update to RFC 5763 Section 5:
Establishing a Secure Channel" and then "OLD TEXT:/NEW TEXT:" sections
without titles or section numbers. This way section numbers from previous
RFC will not interrupt section flow of the current document. Also, "RFC
5763 Section 5" should reference to section 5 of RFC 5763, not to the
unexciting section number in the current draft.

4. I think there is a lot of confusion on the list about handling of
ClientHello before the answer is received. Should we add the following text
to section 5.2 or 5.4:

If DTLS ClientHello message is received before the answer is received
ClientHello message MUST be cached, but not processed. When the answer is
received and if SDP 'setup' attribute in the answer is 'passive', then DTLS
handshake MUST proceed by procssing the cached DTLS ClientHello message. If
SDP 'setup' attribute in the answer is 'active', the cached DTLS
ClientHello message must be discarded and offerer MUST initiate a new DTLS
handshake by sending a DTLS ClientHello message towards the answerer.

NOTE: DTLS handshake cannot proceed before the answer is received since
before this point remote address, ICE candidates, and ICE ufrag and
password are not known and DTLS ServerHello message cannot be sent to the
answerer. Since DTLS handshake does not proceed until server answer is
received, unlike TLS, it is impossible to receive data over DTLS
association before remote fingerprints are received and verified.

Regards,

_____________
Roman Shpount

On Fri, Apr 21, 2017 at 9:08 AM, Flemming Andreasen <[email-masked]>
wrote:

> Greetings MMUSIC
>
> Following the recent changes in dtls-sdp, we are issuing a 1-week WGLC on
> the changes from -22 to -24, i.e.:
>
> April 28. Comments should be sent to the document authors and the MMUSIC WG
> list.
>
> Thanks
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Apr 2017 05:48:54 +0000

Hi,

>connection, using the procedures
>in this document in conjunction with the procedures in [RFC5763] and
>[RFC8122].  The TLS specific considerations
>are described in Section 8.
>
>to:
>
>connection, using the procedures in this
>document in conjunction with the procedures in [RFC5763] and [RFC8122].
>The unique combination of SDP 'tls-id¹
>attribute values can be used to identity the negotiate TLS connection.
>The unique value can be used, for example,
>within TLS protocol extensions to differentiate between multiple TLS
>connections and correlate those connections
>with specific offer/answer exchanges.  The TLS specific considerations
>are described in Section 8.

Ok, I can add that.

>2. In section 8 "mulitple" should be "multiple"

Will fix.

>the section would be formatted like
>"10.2.1. Update to RFC 5763 Section 5: Establishing a Secure Channel² and
>then "OLD TEXT:/NEW TEXT:" sections without
>titles or section numbers. This way section numbers from previous RFC
>will not interrupt section flow of the current
>document. Also, "RFC 5763 Section 5" should reference to section 5 of RFC
>5763, not to the unexciting section number in the current draft.

How would you fix section 10.3.1, where the old text refers to multiple
sections (4., 4.1., etc)?

>ClientHello before the answer is received. Should we
>add the following text to section 5.2 or 5.4:
>
>ClientHello message MUST be cached, but not
> processed. When the answer is received and if SDP 'setup' attribute in
>the answer is 'passive', then DTLS handshake
> MUST proceed by processing the cached DTLS ClientHello message. If SDP
>'setup' attribute in the answer is 'active¹,
> the cached DTLS ClientHello message must be discarded and offerer MUST
>initiate a new DTLS handshake by sending a
> DTLS ClientHello message towards the answerer.

Is that supported by DTLS? Shouldn¹t it be considered an error if you
receive a ClientHello that you shouldn¹t receive?

Also, has the WG community agreed on the procedure you suggest? This WGLC
is not about adding new functionality that has not been discussed.

Regards,

Christer

>before this point remote address, ICE candidates,
> and ICE ufrag and password are not known and DTLS ServerHello message
>cannot be sent to the answerer. Since DTLS handshake
> does not proceed until server answer is received, unlike TLS, it is
>impossible to receive data over DTLS association
> before remote fingerprints are received and verified.

On Fri, Apr 21, 2017 at 9:08 AM, Flemming Andreasen
<[email-masked]> wrote:

Greetings MMUSIC

https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-dtls-sdp-22&url2=draft-
ietf-mmusic-dtls-sdp-24

Thanks

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Apr 2017 16:29:09 +1000

> receive a ClientHello that you shouldn¹t receive?

DTLS can handle all sorts of abuse, but I think that Christer is right
in that we shouldn't tolerate a ClientHello if the answer contains
'passive'.

The question as to whether we should mandate this is a tougher one.
All the discussion about unauthenticated media and so forth has
convinced me that the best we get here is an optimization.  I would
prefer to keep any recommendations about how to optimize out of the
specifications.

DTLS will re-send the ClientHello.  The only risk here is that the
DTLS client will give up before the answer arrives.  Frankly, that
doesn't seem particularly likely unless the answerer has insane delays
and glacial signaling.  I really don't want to cater to this to the
extent of mandating special behaviour for handling this corner case.

I'd be OK with a suggestion.  With ICE, it can't send the ServerHello
until it has an ICE password, so the process stalls there.  An offerer
could save a ClientHello and process it when it receives the answer.
That saves some time.

If we want to acknowledge the absence of ICE as well, we could say
that it could allow the handshake to complete, but delay reporting
success until it can validate the remote certificate.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Apr 2017 10:30:09 +0000

Hi,

I am also not sure whether I would like to mandate procedures.

We COULD say that the offerer MUST NOT process the ClientHello before it
has received the answer, but I am not sure we say more than that…

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Apr 2017 20:36:41 +1000

> has received the answer, but I am not sure we say more than that…

I wouldn't do that; the real gate here is that they not call the
handshake done and proceed to exchange data.  Frankly, you could even
complete the handshake and buffer incoming data without any real
exposure.

Sending is not a good idea and playing out what you receive is equally
unwise.  Those are what you need to safeguard.  (Fluffy might
disagree; #include other threads regarding W3C liaison).

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Apr 2017 11:38:30 +0000

Hi,

>> has received the answer, but I am not sure we say more than thatŠ
>

Fair enough. So, do we want to say that the offerer may complete the
handshake, and buffer received data, before it has received the answer,
but the offerer shall not process received data, or send data, before it
has received the answer?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 27 Apr 2017 14:17:38 -0400

Hi Christer,

> sections (4., 4.1., etc)?

For the section 10.3.1 I would name it "Update to Section 4: SDP
Offerer/Answerer Procedures". I will make sure that "Section 4" points to
the RFC 7345 Section 4, not Section 4 in the current document. Within OLD
TEXT, I would not include "4. SDP Offerer/Answerer Procedures" since it is
already part of the common header and I would list sub-section heading,
such as "General" and Generating The Initial Offer" without section
numbers.  In the NEW TEXT I would put current text without "4. SDP
Offerer/Answerer Procedures".

I know this is not ideal but will remove the section number confusion. The
other options are:

a) Put prefix in front of each subsection such as "RFC 7345: 4.1. General"

b) For this particular update simply put "The content of RFC 7345 Section 4
SDP Offerer/Answerer Procedures is replaced in its entirety with the
following text:" and then put the new text without the heading.

In any case, the references from section names should be fixed to point to
original RFC, not to the current document.

> is not about adding new functionality that has not been discussed.

Let me rephrase this as a more generic question. Section 5.2 currently says:

If the offerer inserts the SDP 'setup' attribute with an 'actpass' or
'passive' attribute value, the offerer MUST be prepared to receive a DTLS
ClientHello message (if a new DTLS association is established by the
answerer) from the answerer before the offerer receives the SDP answer.

What does offerer supposed to do with the ClientHello which is received
before the answer? Does it suppose to proceed with the handshake or cache
it? Or do we prefer not to specify?

This is not a theoretical problem, since client will get DTLS ClientHello
before the answer on a large portion of the calls, since DTLS ClientHello
is sent at the same time as an answer. Answer typically needs to got to
signaling server and then back to offerer. ClientHello is sent directly
from answerer to offerer, so it has one less hop to travel. This is a race
condition and ClientHello has a shorter path to travel, especially when two
end points are located on the same local network, but the signaling server
is remote.

The problem with immediately proceeding with DTLS handshake is that in case
of full ICE or "pure" UDP, offerer does not know where to send ServerHello.
In case of full ICE, remote password is not known so consent to send cannot
be obtained. In case of of "pure" UDP, remote address is not known, since
end points do not have to use the same IP:port to send and receive data.

On the other hand, in case of ICE Lite, ICE TCP passive, and SCTP, offerer
can send ServerHello. We can either allow offerer to proceed with DTLS
Handshake in these cases or specify that CleintHello should be cached
anyway and handshake should not be initiated until the answer is received.

Finally, there is the issue on what should be done if multiple ClientHello
messages are received due to either forking (sequential or parallel) or due
to a denial of service attack (if attacker knows that ClientHello can force
end point to initiate connection which will prevent legitimate connection
from running, it can spray the server with fake ClientHello messages). If
ClientHello is cached, then in combination with SDP UKS, cached ClientHello
messages can be correlated with answer SDP and fake ClientHello messages
discarded. Caching ClientHello can also cleanly resolve on what should
happen when answer with setup:passive is received after ClientHello (which
could be due to attack or forking).

I understand this issue should have been brought up earlier, but I have not
thought about it until Bernard brought up the issue of unverified media.
Which brings the question, should this draft propose the solution for the
unverified media issue and can this solution be just caching ClientHello
until answer is received?

Regards,

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Apr 2017 19:19:59 +0000

Hi,

>For the section 10.3.1 I would name it "Update to Section 4: SDP Offerer/Answerer Procedures". I will make sure that "Section 4" points to the RFC 7345 Section 4, not >Section 4 in the current document. Within OLD TEXT, I would not include "4. SDP Offerer/Answerer Procedures" since it is already part of the common header and I would >list sub-section heading, such as "General" and Generating The Initial Offer" without section numbers.
>
>I know this is not ideal but will remove the section number confusion. The other options are:
>

I don't like that, since the NEW TEXT would be empty.

>b) For this particular update simply put "The content of RFC 7345 Section 4 SDP Offerer/Answerer Procedures is replaced in its entirety with the following text:" and then >put the new text without the heading.
>
>In the NEW TEXT I would put current text without "4. SDP Offerer/Answerer Procedures".

I'd prefer something like that: simply add text saying that sub-sections 4.1 - 4.5 are removed, without actually including the old text itself. 

-----
 
>>If the offerer inserts the SDP 'setup' attribute with an 'actpass' or 'passive' attribute value, the 
>>offerer MUST be prepared to receive a DTLS ClientHello message (if a new DTLS association is 
>>established by the answerer) from the answerer before the offerer receives the SDP answer.
>>
>>What does offerer supposed to do with the ClientHello which is received before the answer? 
>>Does it suppose to proceed with the handshake or cache it? Or do we prefer not to specify?

We can point out that it can happen, but I don't think we should specify procedures how to handle it. 

>This is not a theoretical problem, since client will get DTLS ClientHello before the answer on a large portion
>of the calls, since DTLS ClientHello is sent at the same time as an answer. Answer typically needs to got to
>signaling server and then back to offerer. ClientHello is sent directly from answerer to offerer, so it has one
>less hop to travel. This is a race condition and ClientHello has a shorter path to travel, especially when two
>end points are located on the same local network, but the signaling server is remote.
>
>The problem with immediately proceeding with DTLS handshake is that in case of full ICE or "pure" UDP, 
>offerer does not know where to send ServerHello. In case of full ICE, remote password is not known so 
>consent to send cannot be obtained. In case of of "pure" UDP, remote address is not known, since end 
>points do not have to use the same IP:port to send and receive data.
>
>On the other hand, in case of ICE Lite, ICE TCP passive, and SCTP, offerer can send ServerHello. We can
>either allow offerer to proceed with DTLS Handshake in these cases or specify that CleintHello should
>be cached anyway and handshake should not be initiated until the answer is received.

With ICE, don't you have to do at least one successful connectivity check before you can send anything?

>Finally, there is the issue on what should be done if multiple ClientHello messages are received due to either
>forking (sequential or parallel) or due to a denial of service attack (if attacker knows that ClientHello can force
>end point to initiate connection which will prevent legitimate connection from running, it can spray the server
>with fake ClientHello messages). If ClientHello is cached, then in combination with SDP UKS, cached ClientHello
>messages can be correlated with answer SDP and fake ClientHello messages discarded. Caching ClientHello can
>also cleanly resolve on what should happen when answer with setup:passive is received after ClientHello (which

I think Martin's draft could say that SDP UKS can be used to detect fake ClientHello messages.

>I understand this issue should have been brought up earlier, but I have not thought about it until Bernard
>brought up the issue of unverified media. Which brings the question, should this draft propose the solution
>for the unverified media issue and can this solution be just caching ClientHello until answer is received?

As Martin said, the ClientHello will be re-transmitted, so I don't think we should mandate caching. As I said above, we can point out that it can occur, and it will then be an implementation issue how to handle it.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 27 Apr 2017 15:52:59 -0400

On Thu, Apr 27, 2017 at 3:19 PM, Christer Holmberg <
[email-masked]> wrote:

> >b) For this particular update simply put "The content of RFC 7345 Section
> 4 SDP Offerer/Answerer Procedures is replaced in its entirety with the
> following text:" and then >put the new text without the heading.
> >
> I'd prefer something like that: simply add text saying that sub-sections
> 4.1 - 4.5 are removed, without actually including the old text itself.
>

I do prefer this option since excessive quoting of now irrelevant text
makes the document harder to read.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

> 'passive' attribute value, the
> before the answer?

The text in section 5.2 already says that client MUST be prepared to
receive DTLS ClientHello, so it is should be obvious that this can happen.
What the text does not do is say what should be done with this ClientHello.
I guess you are suggesting this can be left unspecified.

> before the answer on a large portion
> from answerer to offerer, so it has one
> >less hop to travel. This is a race condition and ClientHello has a
> shorter path to travel, especially when two

With ICE lite end point can send data as soon as it received a connectivity
check, so it is definitely possible to establish a DTLS association before
the answer to an offer from ICE lite end point is received. This is a
security and implementation issue, so it would be nice to specify what
should be done here.

> >Finally, there is the issue on what should be done if multiple
> ClientHello messages are received due to either
> >forking (sequential or parallel) or due to a denial of service attack (if
> attacker knows that ClientHello can force
> from running, it can spray the server
> >with fake ClientHello messages). If ClientHello is cached, then in
> combination with SDP UKS, cached ClientHello
> discarded. Caching ClientHello can

I agree, we can leave the multiple ClientHello handling for martin's draft.

> As Martin said, the ClientHello will be re-transmitted, so I don't think
> we should mandate caching. As I said above, we can point out that it can
> occur, and it will then be an implementation issue how to handle it.

If ClientHello is not cached, connection setup will be delayed by 5 sec
(DTLS re-transmit timer). This is quite noticeable and produces negative
client experience. So, caching or immediate handling is desired. If
ClientHello is cached, this will work with full ICE and will prevent
unverified media.

Regards,
______________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Apr 2017 10:42:09 +1000

> but the offerer shall not process received data, or send data, before it

"MAY buffer received packets" might be better.  As the later
discussion shows, processing the ClientHello risks skipping the UKS
checks, so that would be unwise.  And Roman points out assymmetric
paths (I suppose that could happen; though it seems unwise that never
stopped anyone before).

---

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Apr 2017 10:44:50 +1000

> ClientHello is cached, this will work with full ICE and will prevent

If you are retransmitting ClientHello at 5 seconds, you are going to
have a really bad time.  NSS is a tad aggressive, but our first
retransmit is at 50ms (QUIC recommends 200ms I think).  Even TCP isn't
that slow.  Packet loss happens and 5 seconds is well beyond the point
that users give up.

In general, I agree that caching is going to give better performance.
We can recommend it, but I wouldn't mandate it.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 27 Apr 2017 20:48:18 -0400

> that slow.  Packet loss happens and 5 seconds is well beyond the point

I think 5 sec is default for opensips, but I might be wrong.

> We can recommend it, but I wouldn't mandate it.

I would suggest that we say that ClientHello may be cached, but DTLS
handshake MUST NOT start until answer is received.

Regards,
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Apr 2017 10:49:28 +1000

> handshake MUST NOT start until answer is received.

SGTM.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Apr 2017 07:35:33 +0000

Pull request created:

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

Regards,

Christer