Re: 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]> 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