Subject: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-rfc4566bis-35: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 29 May 2019 11:31:51 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-mmusic-rfc4566bis-35: 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-rfc4566bis/

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

I’d like to escalate Alissa’s point about the k= language in Section 7
(Security Considerations).  It looks like the new Section 5.12 removes all of
the historical language beyond saying it MUST NOT be used.  This approach makes
sense to me.  However, the language in Section 7 could be read as conflicting
with that.  Specifically:

   Use of the "k=" line poses a significant security risk, since it
   conveys session encryption keys in the clear.  SDP MUST NOT be used
   to convey keying material, unless it can be guaranteed that the
   channel over which the SDP is delivered is both private and
   authenticated.
   ...
   The "k=" line MUST
   NOT be used, as discussed in Section 5.12.

The first sentence makes a strong statement.  The first clause of the second
sentence makes a more generic MUST NOT statement but the second clause seems to
say that is acceptable under certain circumstances.  The third sentence
reiterates that k= MUST NOT be used.  How should this be reconciled?  Is the
text suggesting that conveying keying materials outside of k= is acceptable
over the right kind of channel?

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

(1) Per the Security Considerations (Section 7) paragraph on “software parsing
the session should take a few precautions”, the discussion about software
taking action is helpful.  I’d also recommend explicitly adding caution about
acting on URIs (e.g., the security considerations of [RFC3986]) to this section.

(2) Section 6.7.  Typo. s/occurence/occurrence/