Subject: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)

From: Adam Roach <[email-masked]>
Date: Wed, 16 Aug 2017 16:06:31 -0700

Adam Roach has entered the following ballot position for
draft-ietf-mmusic-dtls-sdp-28: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 5.4 says:

   NOTE: A new DTLS association can be established based on changes in
   either an SDP offer or answer.  When communicating with legacy
   endpoints, an offerer can receive an answer that includes the same
   fingerprint set and setup role.  A new DTLS association MUST still be
   established if such an answer was received as a response to an offer
   which requested the establishment of a new DTLS association.

Unless I've misunderstood something important, this isn't going to work with
legacy implementations, unless you also specify that an "offer which requested
the establishment of a new DTLS association" must also change something else
that the legacy answerer will recognize as requiring a new DTLS association.
For example, if I send a re-offer with a changed tls-id but the same
fingerprint, setup, and transport, the far end will have no reason to think it
needs to establish a new DTLS association. So I'll sit there waiting for a new
association to be established, and the remote side will never send one.

This doesn't seem backwards-compatible. At the very least, more text needs to
be added explaining how this is intended to work.

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

I agree with the core assertion of EKR's DISCUSS: this document needs to be
aligned with JSEP. I think we're going to need a little additional work
figuring out which document needs to change where they disagree. In addition to
those areas he highlights in his DISCUSS, the following text is also in
conflict:

DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' attribute
values, and the combination of both values identify the DTLS association."

JSEP: "If this is an answer, the tls-id value, if present, MUST be the same as
in the offer."

I would think the long-form title of this document should include "TLS," to
reflect that it also contains TLS-related procedures.

Section 1: "...but currently there is no way..." will not age well once this is
an RFC. Suggest "...previously, there was no way..." or somesuch.

Section 2 uses RFC 2119 boilerplate, and then the very next sentence uses a
non-normative "must." I would strongly recommend moving to RFC 8174 boilerplate.

The conventional name for DTLS-SRTP is "DTLS-SRTP" -- please change replace
"SRTP-DTLS" with "DTLS-SRTP" everywhere it appears.

The last paragraph in section 5.4 starts with "NOTE" (which implementors
frequently read as non-normative) and then contains a normative statement.
Suggest removing "NOTE:"

Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

 - SDP - Session Description Protocol
 - DTLS - Datagram Transport Layer Security
 - TLS - Transport Layer Security
 - ICE - Interactive Connectivity Establishment
 - SCTP - Stream Control Transmission Protocol
 - SRTP - Secure Realtime Transport Protocol
 - UDPTL - UDP Transport Layer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 17 Aug 2017 16:54:58 -0400

> be added explaining how this is intended to work.

The intention was to specify that an offering party sends an offer with new
value of tls-id, it can get back an answer without tls-id, unchanged remote
fingerprint values and setup role . In this case new DTLS association MUST
be established.

As you have correctly mentioned, tls-id can be changed with no changes in
fingerprints, but current specification requires changing the transport
parameters whenever tls-id is changed. The transport parameter change
should cause new DTLS association to be established, even if remote is a
legacy end point. In this case, even if remote legacy end point responds
with existing fingerprints, transport parameters and setup role, it is
safer to assume that new DTLS association should be established.

> JSEP: "If this is an answer, the tls-id value, if present, MUST be the

JSEP needs to be adjusted in this case. Specification does not work if
tls-id is reflected in the answer. Different tls-id in the answer are used
to disambiguate multiple DTLS associations in case of forking.

_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Aug 2017 17:51:18 -0500

On 8/17/17 3:54 PM, Roman Shpount wrote:
> On Wed, Aug 16, 2017 at 7:06 PM, Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Section 5.4 says:
>
> The intention was to specify that an offering party sends an offer 
> with new value of tls-id, it can get back an answer without tls-id, 
> unchanged remote fingerprint values and setup role . In this case new 
> DTLS association MUST be established.
>
> As you have correctly mentioned, tls-id can be changed with no changes 
> in fingerprints, but current specification requires changing the 
> transport parameters whenever tls-id is changed. The transport 
> parameter change should cause new DTLS association to be established, 
> even if remote is a legacy end point. In this case, even if remote 
> legacy end point responds with existing fingerprints, transport 
> parameters and setup role, it is safer to assume that new DTLS 
> association should be established.

Ah, okay. This makes sense. Perhaps add a bit of text to that effect 
(e.g., "A new DTLS will still be established if such an answer was 
received as a response to an offer which requested the establishment of 
a new DTLS association, as the transport parameters will have been 
changed in the offer.")

Clearing my DISCUSS.

> tls-id is reflected in the answer. Different tls-id in the answer are 
> used to disambiguate multiple DTLS associations in case of forking.

That was my assumption too.

/a