Subject: [MMUSIC] Mirja Kühlewind's No Objection on draft-ietf-mmusic-dtls-sdp-30: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 05 Oct 2017 05:35:04 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mmusic-dtls-sdp-30: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my discuss by simply removing section 7.1!

Old comments:

A couple mostly editorial comments:
- Probably a nit: In section 3.2 'must' is used while in section 3.3 'MUST' is
used. I would assume that both sections should probably use the same.

- in sec 5.1: "Because of
   this, if an unordered transport is used for the DTLS association, a
   new transport (3-tuple) must be allocated by at least one of the
   endpoints so that DTLS packets can be de-multiplexed."
Why is this a 3-tuple (instead of a 5-tuple)? I guess you talk about the source
address, source port, transport 3-tuple? May say this more explicitly.  Also
the word of the use transport is confusing to me here because it's used for the
transport protocol as well as for the transport 'connection' (if a
connection-oriented transport protocol is used). Maybe s/new transport/new
flow/? Moreover, there should probably be a 'MUST' here instead of 'must'!

- sec 5.2:"In addition, the offerer MUST insert in the
   offer an SDP 'tls-id' attribute with a unique attribute value."
Is that a MUST or rather a SHOULD? The rest of the text reads like this should
be a SHOULD.

- Shouldn't this document cite RFC6347 normatively, e.g. here (sec 5.3):
"... the answerer MUST initiate a DTLS handshake by sending a
   DTLS ClientHello message towards the offerer."

- I would like to see more discussion about linkability based on the
introduction of the "tls-id" in the security considerations section.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 Oct 2017 09:12:16 +0000

Hi Mirja,

I think Roman earlier did reply to some of your comments, but we forgot to
implement the ones that required text modification. Sorry for that. I will
include his replies in this reply for convenience.

Please see inline.

Yes. I will fix it.

---

>address, source port, transport 3-tuple? May say this more explicitly.

Each end point allocates a 3-tuple for connection (transport/address
/port). Connections are disambiguated using 5 tuple (transport/source
address/source port/destination address/destination port).

We can make this more explicit.

   "Because of this, if an unordered transport is used for the DTLS
    association, a new 3-tuple (transport, address and port) MUST be
allocated by at least
    one of the endpoints so that DTLS packets can be de-multiplexed.²

Šand:

   "When an offerer needs to establish a new DTLS association, and if an
    unordered transport (e.g., UDP) is used, the offerer MUST allocate a
    new 3-tupleŠ²

Šand:

   "When an answerer needs to establish a new DTLS association, if an
    unordered transport is used, and if the offerer did not allocate a
    new 3-tuple, the answerer MUST allocate a new 3-tuple for the
    answer in such a way that it can disambiguate any packets associated
    with the new DTLS association from any packets associated with any
    other DTLS association."

>Also the word of the use transport is confusing to me here because it's
>used for the

I removed ³transport², and simply say 3-tuple, with the
transport/address/port clarification on the first occurrence (see above).

---

>Is that a MUST or rather a SHOULD? The rest of the text reads like this

<Roman¹s previous reply>

Implementations compliant with this specification MUST insert tls-id in
offers and respond with answer with tls-id if tls-id was present in the
offer. This is how end points indicate that they support this
specification.

---

>   DTLS ClientHello message towards the offerer."

I will add a reference to RFC6347 to the first occurrence of 'DLTS
handshake'.

---

>introduction of the "tls-id" in the security considerations section.

This comment we actually did address (but forgot to inform you), by adding
the 
following paragraph to the Security Considerations:

   "This specification does not modify the actual TLS connection setup
    procedures.  The SDP 'tls-is' attribute as such cannot be used to
    correlate an SDP Offer/Answer exchange with a TLS connection setup.
    Thus, this draft does not introduce new security considerations
    related to correlating an SDP Offer/Answer exchange with a TLS
    connection setup.²

---

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 Oct 2017 09:54:20 +0000

Hi,

I’ve created a Pull Request for the changes based on Mirja’s comments:

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

Regards,

Christer

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 6 Oct 2017 12:27:49 +0200

Thanks! Looks good!

Mirja

> Am 06.10.2017 um 11:12 schrieb Christer Holmberg <[email-masked]>:
> 
> Hi Mirja,
>