Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis

Hi,

I support the approach below too.

However, I think we should have a little more text: saying that k= is included for legacy reasons, that one must not include it in SDP, and if received must accept and discard it.

…or something like that.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>> on behalf of Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>
Date: Wednesday 13 September 2017 at 01:33
To: Colin Perkins <csp@csperkins.org<mailto:csp@csperkins.org>>
Cc: "mmusic@ietf.org<mailto:mmusic@ietf.org>" <mmusic@ietf.org<mailto:mmusic@ietf.org>>, "pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>" <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>>
Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis

This seems like a fine resolution to me.

On Tue, Sep 12, 2017 at 2:32 PM, Colin Perkins <csp@csperkins.org<mailto:csp@csperkins.org>> wrote:

> On 12 Sep 2017, at 16:42, Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>> wrote:
>
> On 9/12/17 10:03 AM, Cullen Jennings wrote:
>> First, I don't feel strongly about this and glad to go with whatever Colin wants ... but what I was thinking ....
>> k= is still defined by RFC4566 and things that implement RFC4566 still use it. I don't think we have an IANA table for this but if we do, the IANA registry still lists it with the reference for it as RFC4566.
>> This bis draft becomes a new RFCAAAA and RFCAAAA does not mention k= one way or another. If something that implements RFCAAAA receives a k= line, it gets treated just like any other unknown line and is ignored.
>> There not enough advice on how to use the k= stuff to expect interoperable implementation of any type of security that the IETF would currently consider acceptable to publish as a standard. Anyone who uses k= is very unlikely to be upgrading their software to RFCAAAA. I just don't see anything good that comes of putting this in the new RFC and it just adds to the confusion of how to secure RTP.
>
> One thing: if all mention of k= is removed from the bis, then in the (far) someone who is defining a new line might choose k= for it. (Admittedly this is pretty far fetched.)
>
> I think a cleaner way to handle this would be to deprecate k= in the bis.

I’d not object if the text in 4566bis was changed to:

================
5.12.  Encryption Keys ("k=")

      k=<method>
      k=<method>:<encryption key>

  The “k=“ line is obsolete and MUST NOT be used.

5.13.  Attributes (“a=“)
…
================

…or something similar. I just don’t think we can remove it entirely.

--
Colin Perkins
https://csperkins.org/

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic