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

[Roman Danyliw <[e-mail]>]

Hi!

> -----Original Message-----
> From: iesg [mailto:[e-mail]] On Behalf Of Roman Danyliw via
> Datatracker
> Sent: Wednesday, May 29, 2019 2:32 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; draft-ietf-mmusic-
> [e-mail]; [e-mail]
> Subject: Roman Danyliw's Discuss on draft-ietf-mmusic-rfc4566bis-35: (with
> DISCUSS and COMMENT)
> 
> 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?

Thanks for the revision to Section 7 to clarify the language within the section.  I still see a conflict between the guidance in Section 5.12 and 7.

Section 5.12 says:
   The "k=" line (key-field) is obsolete and MUST NOT be used.  It is
   included in this document for legacy reasons.  One MUST NOT include a
   "k=" line in an SDP, and MUST discard it if it is received in an SDP.

The new text in Section 7 says:
   SDP MUST NOT be used to convey keying material (e.g., using
   "a=crypto" [RFC4568]) unless it can be guaranteed that the channel
   over which the SDP is delivered is both private and authenticated. 

My read is that Section 5.12 says don't use k= and drop it if you see it; and Section 7 says don't use k= unless you can guarantee certain channel properties.  Consider the situation where one has the right channel properties (per Section 7), why would one use k= since Section 5.12 would dictate that this k= would get dropped?

> ----------------------------------------------------------------------
> 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/

Thanks for the new text in -36 to address this feedback.

Regards,
Roman