Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-02

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Dec 2015 07:48:06 +0000

Hi,

A new version (-02) of draft-ietf-mmusic-dtls-sdp-02 has been submitted.

Note that this version now suggests updates to RFC 5763 (SRTP-DTLS) and RFC 7341 (UDPTL-DTLS), so I encourage people to take a look.

In addition, there is some new text about re-using connection-oriented (read: acknowledged packet delivery) for establishing a new DTLS association.

You can also find the document on github: https://github.com/cdh4u/draft-dtls-sdp

(NOTE: This is my personal repo, as I am not aware of any "official" MMUSIC repo)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 8 Dec 2015 15:55:02 -0500

Section 8 consists solely of section 8.1. The 8.1 is redundant.

Section 10 looks a little weird, because it has the section numbering 
for the updated documents mixed in with the section numbering of this 
document. I'm not sure of long term plans. Is this stuff to eventually 
be removed once everyone agrees on what is to be done? Or is it to 
remain? If it is going to be removed, then what you have is fine. If it 
is going to stay, then I think something needs to be done to make the 
presentation less confusing. (E.g., indent it and/or move into an appendix.)

	Thanks,
	Paul

On 12/8/15 2:48 AM, Christer Holmberg wrote:
> Note that this version now suggests updates to RFC 5763 (SRTP-DTLS) and
> RFC 7341 (UDPTL-DTLS), so I encourage people to take a look.
>
> In addition, there is some new text about re-using connection-oriented
> (read: acknowledged packet delivery) for establishing a new DTLS
> association.
>
> (NOTE: This is my personal repo, as I am not aware of any “official”
> MMUSIC repo)
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Dec 2015 21:13:28 +0000

Hi,

>Section 8 consists solely of section 8.1. The 8.1 is redundant.

Correct. There was supposed to be a chapter 8.2 too, and when it was removed I forgot to fix the rest.

>Section 10 looks a little weird, because it has the section numbering for the updated documents mixed >in with the section numbering of this document. I'm not sure of long term plans. Is this stuff to >eventually be removed once everyone agrees on what is to be done? Or is it to remain? If it is going to >be removed, then what you have is fine. If it is going to stay, then I think something needs to be done >to make the presentation less confusing. (E.g., indent it and/or move into an appendix.)

I don't think it is going to be removed. This document updates the listed RFC, and the updated text will not be anywhere else (unless someone decides to incorporate the text into a bis, which at least is not my intention).

We can look at the section numbering, and see whether it can be made more clear. Perhaps the section number of the updated sections don't need to be in the updated text, as we already say which sections are updated. 

Regards,

Christer

On 12/8/15 2:48 AM, Christer Holmberg wrote:
> Note that this version now suggests updates to RFC 5763 (SRTP-DTLS) 
> and RFC 7341 (UDPTL-DTLS), so I encourage people to take a look.
>

---

From: Bo Burman <[email-masked]>
Date: Thu, 10 Dec 2015 09:13:47 +0000

MMUSIC,

The plan in Yokohama was to start moving towards WGLC after a few updates were made.

It seems to me that this document is now fairly stable. I assume the changes mentioned below will be included in an -04 (-03 already posted).

Please read the document and comment whether or not it is ready for WGLC.

/Bo & Flemming
MMUSIC co-chairs

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: den 8 december 2015 22:13
> To: Paul Kyzivat; [email-masked]
> Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-02
> 
> Hi,
> 
> >for the updated documents mixed >in with the section numbering of this
> >document. I'm not sure of long term plans. Is this stuff to >eventually
> >remain? If it is going to >be removed, then what you have is fine. If
> >it is going to stay, then I think something needs to be done >to make
> >the presentation less confusing. (E.g., indent it and/or move into an
> >appendix.)
> 
> I don't think it is going to be removed. This document updates the listed RFC, and the updated text will not be anywhere
> else (unless someone decides to incorporate the text into a bis, which at least is not my intention).
> 
> We can look at the section numbering, and see whether it can be made more clear. Perhaps the section number of the
> updated sections don't need to be in the updated text, as we already say which sections are updated.
> 
> Regards,
> 
> Christer
> 
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 17 Dec 2015 15:00:47 +0000

I have read this draft and been following it with particular interest
regarding its impact on
https://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-12.
I believe it is ready for WGLC.

Cheers,
Charles

On 12/17/15, 8:09 AM, "Christer Holmberg" <[email-masked]>
wrote:

>From: Bo Burman 
>Sent: 10. joulukuuta 2015 11:14
>To: Christer Holmberg; Paul Kyzivat; [email-masked]
>Subject: RE: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-02
>
>MMUSIC,
>
>It seems to me that this document is now fairly stable. I assume the
>changes mentioned below will be included in an -04 (-03 already posted).
>
>> >for the updated documents mixed >in with the section numbering of
>> >this document. I'm not sure of long term plans. Is this stuff to
>> >>eventually be removed once everyone agrees on what is to be done? Or
>> >is it to remain? If it is going to >be removed, then what you have is
>> >fine. If it is going to stay, then I think something needs to be done
>> >>to make the presentation less confusing. (E.g., indent it and/or
>> >move into an
>> >appendix.)
>> 
>> I don't think it is going to be removed. This document updates the
>> listed RFC, and the updated text will not be anywhere else (unless
>>someone decides to incorporate the text into a bis, which at least is
>>not my intention).
>> 
>> We can look at the section numbering, and see whether it can be made
>> more clear. Perhaps the section number of the updated sections don't
>>need to be in the updated text, as we already say which sections are
>>updated.
>> 
>> Regards,
>> 
>> Christer
>> 
>>

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 17 Dec 2015 20:55:25 +0000

I’ve read the document and believe it is now ready for WGLC.

Gonzalo

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Dec 2015 08:59:58 +1100

The conditions for " modification requires a new DTLS association"
might need to be more clearly spelled out.  I think that this is based
on some sort of local constraint, but you should say as much.

Section 2 can be removed.

I think that the definition of fingerprint change is problematic.  I
think that you should require that a partial change to the set of
fingerprints is also accompanied by signaling rather than mandating a
new DTLS connection.  If - for example - a fingerprint that is not in
use is removed, then I think that some existing implementations will
expect to continue.

I don't like the cipher suite requirements.  They don't match those
for WebRTC for starters.  I'd prefer to see them excised.  I'd be OK
with a recommendation to prefer forward secrecy or even to require it.

I don't mind the fingerprint requirements (SHA-256 and the must match
rule).  I'm not sure how others feel about restating 5763
requirements, though I think that this is OK.

"It is considered an error case if the answer contains a
'dtls-connection' attribute with an 'existing' value, and a DTLS
association does not exist." -- What do you expect someone to do in
this case?

You missed the most important consideration: when running a second
DTLS association over the same transport, it is difficult to
distinguish between the first and second association because DTLS
packets don't identify themselves externally [4].  This point is
important enough to include in the intro in my opinion, though I would
also add a sub-section to Section 4 explaining this in more detail.

I'm not sure about 8.1.  I think that a key insight here is that the
connection-oriented transport might not be end-to-end.  That suggests
that multiple DTLS associations can be established.  Based on that,
you might suggest that connection-oriented transports are no different
to any other transport.

I found Section 10 basically impossible to parse: patches like this
are very hard to read and it's half the document!  I'd rather have a
short statement identifying the nature of the changes.  I think that
the 5245 change is incorrect though because it loses some important
details.

Nits:
In 6.3: "and determines (based on the criteria for establishing a new
DTLS association)" needs a reference.

In 6.4: "if the offerer becomes DTLS client, the offerer MUST
establish a DTLS association." Might be worth mentioning that this is
based on a=setup.

[4] Unless you are lucky enough to have different epochs, but don't do
that.  Ever.

On 8 December 2015 at 18:48, Christer Holmberg
<[email-masked]> wrote:
> Note that this version now suggests updates to RFC 5763 (SRTP-DTLS) and RFC
> 7341 (UDPTL-DTLS), so I encourage people to take a look.
>
>
>
> (NOTE: This is my personal repo, as I am not aware of any “official” MMUSIC
> repo)
>
>
>
> Regards,
>
>
>
> Christer
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Dec 2015 08:11:35 +0000

Hi Martin,

Thanks for your comments! See inline.

>might need to be more clearly spelled out.  I think that this is based on some sort of local constraint, but you should say as much.

Ok, we'll think of something.

-----------------

>Section 2 can be removed.

Unless we put some content (other than "TBD") there, it will be removed.

-----------------

> I think that the definition of fingerprint change is problematic.  I think that you should require that a partial change to the set of fingerprints is also accompanied 
> by signaling rather than mandating a new DTLS connection.  If - for example - a fingerprint that is not in use is removed, then I think that some existing implementations 
> will expect to continue.

My assumption is that all changes that mandate a new DTLS  connection are accompanied by signalling. But, I agree that it needs to be more clear.

-----------------

>I don't like the cipher suite requirements.  They don't match those for WebRTC for starters.  I'd prefer to see them excised.  I'd be OK with a recommendation to prefer forward secrecy or even to require it.
>
>I don't mind the fingerprint requirements (SHA-256 and the must match rule).  I'm not sure how others feel about restating 5763 requirements, though I think that this is OK.

The requirements are taken from RFC 7345. We were asked by the security folks to include them.

I can remove it, but there is a risk it will come up again during the IESG/security review...

-----------------

>"It is considered an error case if the answer contains a 'dtls-connection' attribute with an 'existing' value, and a DTLS association does not exist." -- What do you expect someone to do in this case?

Normally the action in cases like this is "based on local policy". I guess we can say that the offerer MUST NOT assume that a DTLS association has been created.

-----------------

>You missed the most important consideration: when running a second DTLS association over the same transport, it is difficult to distinguish between the first 
> and second association because DTLS packets don't identify themselves externally [4].  This point is important enough to include in the intro in my opinion, though 
> I would also add a sub-section to Section 4 explaining this in more detail.

We were going to add text about that, but it seems like we forgot.

-----------------

> I'm not sure about 8.1.  I think that a key insight here is that the connection-oriented transport might not be end-to-end.  That suggests that multiple DTLS associations 
> can be established.  Based on that, you might suggest that connection-oriented transports are no different to any other transport.

I'll let Roman reply to this one.

-----------------

> I found Section 10 basically impossible to parse: patches like this are very hard to read and it's half the document!  I'd rather have a short statement identifying 
> the nature of the changes.  

My suggestion is to keep the current changes, but to add some text describing the changes.

> I think that the 5245 change is incorrect though because it loses some important details.

Do you mean some other RFC? The draft does not update RFC 5245. Or, do you mean that some reference to RFC 5245 is incorrect?

-----------------

>Nits:
>In 6.3: "and determines (based on the criteria for establishing a new DTLS association)" needs a reference.

Will be fixed.

>In 6.4: "if the offerer becomes DTLS client, the offerer MUST establish a DTLS association." Might be worth mentioning that this is based on a=setup.

Will be fixed.

Thanks!

Regards,

Christer

[4] Unless you are lucky enough to have different epochs, but don't do that.  Ever.

On 8 December 2015 at 18:48, Christer Holmberg <[email-masked]> wrote:
> and RFC
> MMUSIC

---

From: Roman Shpount <[email-masked]>
Date: Fri, 18 Dec 2015 14:31:36 -0500

Hi Martin,

Thanks again for your comments!

The whole reason for section 8.1 was DTLS over SCTP (RFC 6083).

This RFC makes several unfortunate design decisions which make it
incompatible with dtls-sdp.

In particular RFC 6083 states:

1. DTLS procedures for retransmissions MUST NOT be used (
https://tools.ietf.org/html/rfc6083#section-3.5)

2. Each DTLS connection MUST be established and terminated within the same
SCTP association (https://tools.ietf.org/html/rfc6083#section-4.2)

3. RFC 6083 describes setting up and shutting down multiple DTLS
associations (which it insists on calling connections) over the same SCTP
association.

I am not sure what was the use case for RFC 6083 and if it is being used
anywhere, so I am not sure if we can update it.

Due to RFC 6083 we had to do the following provisions:

1. Since retransmissions is disabled at DTLS level and since all DTLS
associations must be established over the same SCTP association, we cannot
seamlessly switch the protocol under DTLS from SCTP to UDP. This conflicts
with our usage of dtls-connection=existing attribute. Also, if anybody ever
defines SCTP ICE candidate type, this will make it impossible to switch
between the candidates of different types. For now, we decided to prohibit
switching from reliable (SCTP) to unreliable (UDP or UDP over TCP  in RFC
4571 framing). UDP over TCP in RFC 4571 framing is considered unreliable
since such connections are often not end-to-end, and most importantly, DTLS
retransmissions is not disabled, so switching between UDP and UDP over TCP
with RFC4571 framing is allowed.

2. Since RFC 6083 specifies how multiple DTLS association can share the
same SCTP based transport, we need to make a special allowance which
defines when two DTLS associations can run over the same transport. This is
the reason for section 8.1

Another option would be to specify that RFC 6083 are not compatible with
dtls-sdp and get rid of the complications caused by this transport.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Dec 2015 17:24:19 -0500

> The whole reason for section 8.1 was DTLS over SCTP (RFC 6083).

Is there any reason for DTLS over SCTP? Is there any case where it is 
preferable to SCTP over DTLS?

	Thanks,
	Paul

> 1. DTLS procedures for retransmissions MUST NOT be used
> (https://tools.ietf.org/html/rfc6083#section-3.5)
>
> 2. Each DTLS connection MUST be established and terminated within
> the same SCTP association (https://tools.ietf.org/html/rfc6083#section-4.2)
>
> associations (which it insists on calling connections) over the same
> SCTP association.
>
> associations must be established over the same SCTP association, we
> cannot seamlessly switch the protocol under DTLS from SCTP to UDP. This
> conflicts with our usage of dtls-connection=existing attribute. Also, if
> anybody ever defines SCTP ICE candidate type, this will make it
> impossible to switch between the candidates of different types. For now,
> we decided to prohibit switching from reliable (SCTP) to unreliable (UDP
> or UDP over TCP  in RFC 4571 framing). UDP over TCP in RFC 4571 framing
> is considered unreliable since such connections are often not
> end-to-end, and most importantly, DTLS retransmissions is not disabled,
> so switching between UDP and UDP over TCP with RFC4571 framing is allowed.
>
> defines when two DTLS associations can run over the same transport. This
> is the reason for section 8.1
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 18 Dec 2015 17:28:31 -0500

> preferable to SCTP over DTLS?

As I have mentioned earlier, I am not sure what was the intended use case
for DTLS over SCTP and if it was ever implemented, but I can see how this
can be useful to provide security for multi-homed SCTP connection. I do not
think DTLS over SCTP would be ever used in combination with SDP.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Dec 2015 23:14:46 +0000

Hi,

draft-ietf-mmusic-sctp-sdp currently covers DTLS-over-SCTP, which means we have to define the associated SDP O/A procedures.

Now, if we think that nobody is going to use DTLS-over-SCTP, we can of course remove it, but that's a decision the community would have to make.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Roman Shpount<mailto:[email-masked]>
Sent: ‎19/‎12/‎2015 00:28
To: Paul Kyzivat<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-02

On Fri, Dec 18, 2015 at 5:24 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
On 12/18/15 2:31 PM, Roman Shpount wrote:
Hi Martin,

Is there any reason for DTLS over SCTP? Is there any case where it is preferable to SCTP over DTLS?

As I have mentioned earlier, I am not sure what was the intended use case for DTLS over SCTP and if it was ever implemented, but I can see how this can be useful to provide security for multi-homed SCTP connection. I do not think DTLS over SCTP would be ever used in combination with SDP.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 19 Dec 2015 16:40:17 -0500

Hi Christer,

I do have a few things that should be addressed before or as part of WGLC:

* Section 5.2 ABNF:

I would like to see this formatted following the template from 
rfc4566bis. That seems to call for jiggering the section structuring. E.g.:

    5.  SDP dtls-connection Attribute

    The SDP 'connection' attribute [RFC4145] was originally defined for
    connection-oriented protocols, e.g.  TCP and TLS.  This section
    defines a similar attribute, 'dtls-connection', to be used with DTLS.

       Name: dtls-connection

       Value: conn-value

       Usage Level: media

       Charset Dependent: no

       Syntax:

           conn-value = "new" / "existing"

       Example:

           a=dtls-connection:existing

    A 'dtls-connection' attribute value of 'new' indicates that a new
    DTLS association MUST be established.  A 'dtls-connection' attribute
    value of 'existing' indicates that a new DTLS association MUST NOT be
    established.

    Unlike the SDP 'connection' attribute for TLS, there is no default
    value defined for the 'dtls-connection' attribute.  Implementations
    that wish to use the attribute MUST explicitly include it in SDP
    offers and answers.  If an offer or answer does not contain an
    attribute, other means needs to be used in order for endpoints to
    determine whether an offer or answer is associated with an event that
    requires the DTLS association to be re-established.

    The SDP Offer/Answer [RFC3264] procedures associated with the
    attribute are defined in Section 6

* Section 6.1 (General O/A procedures)

The 1st note (paragraph 2) seems intended as something temporary. Did 
you intend it to remain? If so, instead of saying "based on" it would be 
better to say "compatible with". Since this draft revises 5763,

    NOTE: The procedures in this section are generalizations of
    procedures first specified in SRTP-DTLS [RFC5763], with the addition
    of usage of the SDP 'dtls-connection' attribute. That document is
    herein revised to make use of these new procedures.

ISTM that the 2nd note:

    NOTE: The SDP 'connection' attribute may be used if the usage is
    associated with another protocol layer, e.g.  SCTP or TCP, used
    together with DTLS.

should not be a note. And the "may" should be changed to MAY, making 
this a normative statement - an exception to the MUST NOT in the prior 
paragraph.

* Section 12 (IANA Considerations)

Since there is only one IANA action, section 12.1 can be collapsed into 
section 12.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 20 Dec 2015 09:35:46 +0000

Hi Paul,

Thanks for your comments! I agree with what you say, and we'll modify the text accordingly in the next version.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 19 December 2015 23:40
To: [email-masked]
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-03

Hi Christer,

* Section 5.2 ABNF:

I would like to see this formatted following the template from rfc4566bis. That seems to call for jiggering the section structuring. E.g.:

       Name: dtls-connection

       Value: conn-value

       Usage Level: media

       Charset Dependent: no

       Syntax:

       Example:

The 1st note (paragraph 2) seems intended as something temporary. Did you intend it to remain? If so, instead of saying "based on" it would be better to say "compatible with". Since this draft revises 5763,

ISTM that the 2nd note:

should not be a note. And the "may" should be changed to MAY, making this a normative statement - an exception to the MUST NOT in the prior paragraph.

Since there is only one IANA action, section 12.1 can be collapsed into section 12.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Dec 2015 12:04:34 +1100

> My assumption is that all changes that mandate a new DTLS  connection are accompanied by signalling. But, I agree that it needs to be more clear.

This seems pretty important, yes.  I'd recommend making it the first
statement in the description of the new attribute.

> The requirements are taken from RFC 7345. We were asked by the security folks to include them.

Include by reference then.  Restating them just gives you another shot
at making a mistake.

> Do you mean some other RFC? The draft does not update RFC 5245. Or, do you mean that some reference to RFC 5245 is incorrect?

Sorry, it was the last 7345 change that I was talking about.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Dec 2015 11:40:36 +0000

Hi,

...

> Sorry, it was the last 7345 change that I was talking about.

Everything that is removed from 7345 is supposed to be covered in dtls-sdp.

Or, is there some specific stuff that you think is completely lost?

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Dec 2015 10:23:37 +1100

> Or, is there some specific stuff that you think is completely lost?

Yeah, I think that you got it right (or I forgot what was missing).