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

WFM

On 9/15/17 5:02 PM, Ali C. Begen wrote:
> 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
>         <https://www.ietf.org/mailman/listinfo/mmusic>
> 
> 
> 
>     _______________________________________________
>     mmusic mailing list
>     [email protected] <mailto:[email protected]>
>     https://www.ietf.org/mailman/listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>
> 
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic
> 

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