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

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Sep 2017 17:26:08 -0600

Do we still need the "k=" line in SDP? Could we just remove all of section 5.12 ?

---

From: "Ali C. Begen" <[email-masked]>
Date: Fri, 8 Sep 2017 10:14:26 +0300

I have not seen it being used, but it could be just me who has not seen it.
Will be happy to remove it, if everyone agrees.

On Fri, Sep 8, 2017 at 2:26 AM, Cullen Jennings <[email-masked]> wrote:

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

---

From: Colin Perkins <[email-masked]>
Date: Fri, 8 Sep 2017 11:24:13 +0100

I don’t think we can remove it – we need to document it for legacy reasons, if nothing else – but we can certainly strengthen the warnings not to use it.

Colin

> On 8 Sep 2017, at 08:14, Ali C. Begen <[email-masked]> wrote:
> 
> I have not seen it being used, but it could be just me who has not seen it. Will be happy to remove it, if everyone agrees.
> 
> On Fri, Sep 8, 2017 at 2:26 AM, Cullen Jennings <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>
> 

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

---

From: Keith Drage <[email-masked]>
Date: Tue, 12 Sep 2017 10:19:18 +0100

Yes, we do not want people to use it. It was regarded as an 
inappropriate inadequately defined security mechanism when it existed.

But I agree with Colin in that straight removal is nor the answer. Among 
other things, we need to consider what we want to appear in the IANA 
lists in order to ensure that the name is not reused. Is that different 
from what appears now?

Keith

On 08-Sep-17 11:24 AM, Colin Perkins wrote:
> I don’t think we can remove it – we need to document it for legacy 
> reasons, if nothing else – but we can certainly strengthen the 
> warnings not to use it.
>
> Colin
>
>
>
>> On 8 Sep 2017, at 08:14, Ali C. Begen <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> I have not seen it being used, but it could be just me who has not 
>> seen it. Will be happy to remove it, if everyone agrees.
>>
>>     <https://www.ietf.org/mailman/listinfo/mmusic>
>>
>>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 12 Sep 2017 08:03:11 -0600

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. 

> On Sep 12, 2017, at 3:19 AM, Keith Drage <[email-masked]> wrote:
> 
> Yes, we do not want people to use it. It was regarded as an inappropriate inadequately defined security mechanism when it existed.
> 
> But I agree with Colin in that straight removal is nor the answer. Among other things, we need to consider what we want to appear in the IANA lists in order to ensure that the name is not reused. Is that different from what appears now?
> 
> Keith
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Sep 2017 11:42:33 -0400

> 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…

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.

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Sep 2017 22:32:56 +0100

> On 12 Sep 2017, at 16:42, Paul Kyzivat <[email-masked]> wrote:
> 
> 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’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/

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Sep 2017 15:33:24 -0700

This seems like a fine resolution to me.

On Tue, Sep 12, 2017 at 2:32 PM, Colin Perkins <[email-masked]> 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.
> >

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Sep 2017 09:58:35 +0000

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-masked]<mailto:[email-masked]>> on behalf of Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 13 September 2017 at 01:33
To: Colin Perkins <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis

On Tue, Sep 12, 2017 at 2:32 PM, Colin Perkins <[email-masked]<mailto:[email-masked]>> wrote:

> On 12 Sep 2017, at 16:42, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
>

================

      k=<method>

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

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

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

---

From: "Ali C. Begen" <[email-masked]>
Date: Sat, 16 Sep 2017 00:02:16 +0300

Hi guys,

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

      k=<method>

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-masked]> wrote:

> 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-masked]> on behalf of Eric Rescorla <
> [email-masked]>
> To: Colin Perkins <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Sep 2017 17:13:34 -0400

WFM

On 9/15/17 5:02 PM, Ali C. Begen wrote:
> On Wed, Sep 13, 2017 at 12:58 PM, Christer Holmberg 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     Hi,
> 
>     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-masked]
>     <mailto:[email-masked]>> on behalf of Eric Rescorla
>     <[email-masked] <mailto:[email-masked]>>
>     To: Colin Perkins <[email-masked] <mailto:[email-masked]>>
>     Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>         > On 12 Sep 2017, at 16:42, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
>         >
>         >> 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.
>         >

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 15 Sep 2017 14:18:23 -0700

LGTM

On Fri, Sep 15, 2017 at 2:02 PM, Ali C. Begen <[email-masked]>
wrote:

>>> >> 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.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 16 Sep 2017 08:17:25 +0000

Looks good.

Regards,

Christer

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

Hi guys,

      k=<method>

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.

Thanks.
-acbegen

On Wed, Sep 13, 2017 at 12:58 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

…or something like that.

Regards,

Christer

================

      k=<method>

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

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

---

From: "Ali C. Begen" <[email-masked]>
Date: Sat, 16 Sep 2017 14:39:46 +0300

Cool, we have a new version with the proposed text.

Chairs, I think we are ready for WGLC.

Thanks.
-acbegen

On Sat, Sep 16, 2017 at 11:17 AM, Christer Holmberg <
[email-masked]> wrote:

> Looks good.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Ali C. Begen [mailto:[email-masked]]
> *Sent:* 15 September 2017 23:02
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* Eric Rescorla <[email-masked]>; Colin Perkins <[email-masked]>;
> mmusic WG <[email-masked]>; Paul Kyzivat <[email-masked]>
>
> *Subject:* Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis
>
>
>
> Hi guys,
>
> *From: *mmusic <[email-masked]> on behalf of Eric Rescorla <
> [email-masked]>
> *Date: *Wednesday 13 September 2017 at 01:33
> *To: *Colin Perkins <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis
>
>
>