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

From: Roman Danyliw <[email-masked]>
Date: Wed, 19 Jun 2019 09:11:52 +0000

Hi!

> -----Original Message-----
> From: iesg [mailto:[email-masked]] On Behalf Of Roman Danyliw via
> Datatracker
> Sent: Wednesday, May 29, 2019 2:32 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-ietf-mmusic-
> [email-masked]; [email-masked]
> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jun 2019 10:45:34 -0400

Roman,

> 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 new section 7 uses a=crypto, which is a different mechanism from k=. 
So I don't see the conflict you are concerned with.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jun 2019 10:54:30 -0400

Roman,

[Adding more info]

> 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 new section 7 uses a=crypto [RFC4568], which is a different 
mechanism from k=. So I don't see the conflict you are concerned with.

	Thanks,
	Paul

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 19 Jun 2019 14:54:52 +0000

Hi Paul!

> From: iesg [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Wednesday, June 19, 2019 10:46 AM
> To: Roman Danyliw <[email-masked]>; [email-masked]; draft-ietf-mmusic-
> [email-masked]
> Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-mmusic-rfc4566bis-35:
> (with DISCUSS and COMMENT)
> 
> Roman,
> 
> > 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:
> > 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?
> 

You're right.  The text was clear, but I conflated the two sections in re-reading my discuss text.

Thanks for the updated text.  I've cleared the discuss.

Roman