Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-mmusic-msrp-usage-data-channel-22

Benjamin Kaduk <kaduk@mit.edu> Tue, 11 August 2020 00:53 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C433A0E6B; Mon, 10 Aug 2020 17:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 gvYkRNgRFhEZ; Mon, 10 Aug 2020 17:53:01 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 222183A0E6C; Mon, 10 Aug 2020 17:53:00 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07B0quax027088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Aug 2020 20:52:58 -0400
Date: Mon, 10 Aug 2020 17:52:55 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-mmusic-msrp-usage-data-channel.all@ietf.org
Message-ID: <20200811005255.GY92412@kduck.mit.edu>
References: <bc966e2a-a06b-0156-9672-961092d411dc@isode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <bc966e2a-a06b-0156-9672-961092d411dc@isode.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/PysE7q3DVtc0NzLBHYAIXZtqL7Y>
Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-mmusic-msrp-usage-data-channel-22
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2020 00:53:03 -0000

Hi Alexey,

Thanks for this review -- I agree that the RFC 5547 security considerations
are quite important, and it's good to mention the SIP considerations as
well (even if they are technically optional).

Christer, thanks for the updates -- I balloted No Objection.

-Ben

On Mon, Jul 20, 2020 at 01:46:42PM +0100, Alexey Melnikov wrote:
> Reviewer: Alexey Melnikov
> Review result: Ready with Nits
> 
> I have reviewed this document as part of the security directorate's 
> ongoing effort to review all IETF documents being processed by the IESG. 
> These comments were written primarily for the benefit of the security 
> area directors. Document editors and WG chairs should treat these 
> comments just like any other last call comments.
> 
> The subject matter is outside my area of expertise and proper 
> understanding of the document requires reading of several referenced 
> documents. But I think I got the gist of what the document is trying to do.
> 
> The Security Consideration talks about data channels providing 
> confidentiality, integrity and source authentication for MSRP traffic, 
> which is good. It also points out to discussion of MSRP message 
> attribution in RFC 4975.
> 
> However, session setup is done over SIP, which has different security 
> considerations and nothing is mentioned about that. In particular, one 
> of normatively referenced documents RFC 5547 has very good Security 
> Considerations section (section 10) that talks about possible attacks on 
> file transfer negotiation. I think this should be referenced in the 
> document.
> 
> I also feel that more can be said about possible use of MSRP for 
> transferring of malicious files/images.
> 
> In Section 6:
> 
>   o  The gateway SHALL use CEMA towards the non-data channel endpoint.
> 
> Please explain and/or add a reference for CEMA.
> 
> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call