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

LGTM

On Fri, Sep 15, 2017 at 2:02 PM, Ali C. Begen <[email protected]>
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]> 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]> on behalf of Eric Rescorla <
>> [email protected]>
>> Date: Wednesday 13 September 2017 at 01:33
>> To: Colin Perkins <[email protected]>
>> Cc: "[email protected]" <[email protected]>, "[email protected]" <
>> [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]> wrote:
>>
>>>
>>> > On 12 Sep 2017, at 16:42, Paul Kyzivat <[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]
>>> 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