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

Roni Even <> Wed, 11 January 2017 07:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2AD36129A33; Tue, 10 Jan 2017 23:38:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.409
X-Spam-Status: No, score=-7.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 54JQC72b-CFb; Tue, 10 Jan 2017 23:38:35 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ADFDE129A2B; Tue, 10 Jan 2017 23:30:57 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DEF27481; Wed, 11 Jan 2017 07:30:53 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 11 Jan 2017 07:30:52 +0000
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Wed, 11 Jan 2017 15:30:47 +0800
From: Roni Even <>
To: Dan Harkins <>, "" <>, "" <>, "" <>
Thread-Topic: secdir review of draft-ietf-clue-rtp-mapping
Thread-Index: AQHSaGcWUaZbliSvJ0ie2TwNHoJBX6Ey5YmQ
Date: Wed, 11 Jan 2017 07:30:46 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD76C117DGGEMM506MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5875DF2E.0340, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 59470c6ffe19e9aeea39fc992eb2350c
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-clue-rtp-mapping
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Jan 2017 07:38:36 -0000

Hi Dan,
Thanks for the review
See inline

From: Dan Harkins []
Sent: יום ו 06 ינואר 2017 23:52
Subject: secdir review of draft-ietf-clue-rtp-mapping


  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.

[Roni Even] I assume you are referring to the normative references in general since there all references in the Security section are informational.

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.

[Roni Even] I am not sure, both cases are the same. RTP has multiple profiles and for security the secure profile MUST be supported. RTP also has CNAME and the creation of CNAME is specified in another document [RFC 7022],  for security reasons you MUST choose a specific mode to create the CNAMEs. I am not sure that having a section with all the normative language in the document make much sense since they will be out of context.