[secdir] secdir review of draft-ietf-clue-rtp-mapping

Dan Harkins <dharkins@lounge.org> Fri, 06 January 2017 21:51 UTC

Return-Path: <dharkins@lounge.org>
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 D532A129458; Fri, 6 Jan 2017 13:51:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 ZNhDGMHccpZD; Fri, 6 Jan 2017 13:51:35 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 44A1412944B; Fri, 6 Jan 2017 13:51:35 -0800 (PST)
Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id A7B7DA888004; Fri, 6 Jan 2017 13:51:34 -0800 (PST)
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-clue-rtp-mapping.all@ietf.org
From: Dan Harkins <dharkins@lounge.org>
Message-ID: <80663eab-d5d4-07ae-7aa6-3924a5b7a579@lounge.org>
Date: Fri, 6 Jan 2017 13:51:33 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------02FC40002406B3F482997456"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Ym_u8vTgZxpm6QwaGXwXKBOtslg>
Subject: [secdir] secdir review of draft-ietf-clue-rtp-mapping
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 06 Jan 2017 21:51:37 -0000

   Greetings,

   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.

   This draft provides some recommendations and mappings to allow RTP
to be used in the CLUE protocol.

   I believe this draft is Ready with the following nits:

1) it makes normative reference to 3 other I-Ds. I am not familiar
with those drafts or their status or whether any of the normative
behavior this draft relies upon is contentious or not. Somebody
(not me) should make sure that all ducks are in a row before this
draft advances.

2) having RFC 2119 words in the Security Considerations seems OK
for saying things like "CLUE endpoints MUST support RTP/SAVPF and
DTLS-SRTP keying [RFC5764]" because it's just saying you need to
support something else that is providing you security. But I think
MUST language describing how the protocol needs to behave in order
to be secure itself belongs outside the Security Considerations.
I'm referring to: "Inappropriate choice of CNAME values can be a
privacy concern, since long-term persistent CNAME identifiers can be
used to track users across multiple calls.  CLUE endpoint MUST
generate short-term persistent RTCP CNAMES, as specified in RFC7022
[RFC7022], resulting in untraceable CNAME values that alleviate this
risk." I suggest placing that in a different section, possibly making
a new section that describes has all the various recommendations
being made on CLUE in one place.

   regards,

   Dan.