Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 11 March 2019 14:32 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F3B131083 for <mmusic@ietfa.amsl.com>; Mon, 11 Mar 2019 07:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgwpgrYkzE9m for <mmusic@ietfa.amsl.com>; Mon, 11 Mar 2019 07:32:23 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 588FF131055 for <mmusic@ietf.org>; Mon, 11 Mar 2019 07:32:23 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x2BEWJkX001654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Mar 2019 10:32:19 -0400
To: 'Colin Perkins' <csp@csperkins.org>, Ben Campbell <ben@nostrum.com>
References: <04CAFF8C-B6ED-4B7D-9FDD-ED37DCA2848B@nostrum.com> <2f297a3c-39d4-cb99-65f4-f0bcd072306a@alum.mit.edu> <C054EF10-FE82-4E9D-9ABA-5C2E6090F0C9@csperkins.org>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: mmusic@ietf.org
Message-ID: <6f0d20c2-0397-2bbd-5671-8b7ea0d8c98d@alum.mit.edu>
Date: Mon, 11 Mar 2019 10:32:18 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <C054EF10-FE82-4E9D-9ABA-5C2E6090F0C9@csperkins.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/8pEpOTpYmpx2GnkgyQKeVrEN9hY>
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2019 14:32:25 -0000

Colin and Ben,

On 2/25/19 6:02 PM, Colin Perkins wrote:

>>> - Deleted text formerly in §4.3: The removal of the “private sessions” section in its entirety deserves some explanatory text.
>>
>> I posted a query about this. The consensus was that the removal here is right, but that more discussion is needed in the Security Considerations section. But I don't know what to write. I need some help on that.
> 
> The former §4.3 just said two things. The first was that if you want to keep the SDP session description private, then you need encryption to protect for distribution. That seems obvious, but I guess a statement to that effect could be added to the security considerations (“If it’s desired to keep a session description confidential, then confidentiality protection SHOULD be used”).

I'll put that in if desired, but it sure seems like a "duh" to me.

Ben?

> It also said that a private session description can be used to convey encryption keys. I’m not sure that’s something we want to encourage.

Since the text has been removed, it no longer "encourages" it.
I gather you mean here that not mentioning it in security considerations 
is a good thing.

> §5 has several changes to normative language. Most are okay, but I think the change from “all MUST appear in exactly the order given here” to “all must appear” weakens it too much, and I’d prefer that to remain a MUST.

The reason for changing that is because the *normative* specification of 
the ordering is from the ABNF. The text here is explanatory and 
non-normative. (Note that a couple of paragraphs prior to this is a new 
statement emphasizing that the ABNF is normative.)

>>> §7, last paragraph:
>>> What is the impact of this on RFC 4568 (security descriptions)? That RFC seems to allow the use of “k=“ lines at a MAY level. Does this draft need to update that? But more importantly, is it worth distinguishing the case of E@E protection of keying material vs the HBH protection offered by security descriptions?
>>
>> This text is unchanged since 4566.
>>
>> I need help with this from a security person.
> 
> SDP security descriptions has problems, but I’d argue that those should be addressed in an RFC updating RFC 4568, or moving it to historic, rather than in the base SDP specification. Is this not something SIPBRANDY will be producing?

Ben, does passing the buck on this work for you?

>>> §6.7.1: "(e.g., an RTP-based system in
>>> recvonly mode SHOULD still send RTCP packets”
>>> Please don’t use normative keywords in examples. Examples should never be normative.
>>
>> Done.
> 
> This is a normative requirement of RTP, however. If we want to avoid normative examples, which I’d agree makes sense, then this needs to be rewritten as just “An RTP-based system in recvonly mode SHOULD…”.

That is the way it was. The change from "SHOULD" to "should" was to make 
it non-normative.

Or were you requesting to remove "e.g."?

	Thanks,
	Paul