Re: k= and draft-ietf-mmusic-rfc4566bis

Looks good.

Regards,

Christer

From: Ali C. Begen [mailto:[email protected]]
Sent: 15 September 2017 23:02
To: Christer Holmberg <[email protected]>
Cc: Eric Rescorla <[email protected]>; Colin Perkins <[email protected]>; mmusic WG <[email protected]>; Paul Kyzivat <[email protected]>
Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis

Hi guys,

Here is the proposed text for 5.12 based on the comments so far:

5.12.  Encryption Keys ("k=")

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

The “k=“ line 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.

If we are good with this, I will revise the draft and we will go for WGLC.

Thanks.
-acbegen


On Wed, Sep 13, 2017 at 12:58 PM, Christer Holmberg <[email protected]<mailto:[email protected]>> wrote:
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 <[email protected]<mailto:[email protected]>> on behalf of Eric Rescorla <[email protected]<mailto:[email protected]>>
Date: Wednesday 13 September 2017 at 01:33
To: Colin Perkins <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
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 <[email protected]<mailto:[email protected]>> wrote:

> On 12 Sep 2017, at 16:42, Paul Kyzivat <[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic