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

From: Dan Harkins <[email-masked]>
Date: Fri, 6 Jan 2017 13:51:33 -0800

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.

---

From: Roni Even <[email-masked]>
Date: Wed, 11 Jan 2017 07:30:46 +0000

Hi Dan,
Thanks for the review
See inline
Roni

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

  Greetings,

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.

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

  regards,

  Dan.

---

From: Dan Harkins <[email-masked]>
Date: Wed, 11 Jan 2017 09:50:17 -0800

Hi Roni,

On 1/10/17 11:30 PM, Roni Even wrote:
>
> Hi Dan,
>
> Thanks for the review
>
> See inline
>
> Roni
>
> *From:*Dan Harkins [mailto:[email-masked]]
> *Sent:* יום ו 06 ינואר 2017 23:52
> *To:* [email-masked]; [email-masked]; 
> [email-masked]
> *Subject:* secdir review of draft-ietf-clue-rtp-mapping
>
>
>   Greetings,
>
> */[Roni Even] I assume you are referring to the normative references in 
> general since there all references in the Security section are 
> informational. /*
   I'm referring to the 3 Internet-Drafts referenced in the
section called "Normative References", section 10.1. An I-D
is, as noted, a "work in progress". So you're making a normative
reference to a document in a state of flux. That sounds a bit
alarming to me. What if, as they progress, the things you are
normatively depending on change in a way that make this
dependency not work anymore?

   I'm just saying someone (not me) has to make sure that that
does not happen. The alternative is to wait for them to be
published and then refer to them as RFCs.
> */[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. /*
   RFC 7022 does not place a requirement on CLUE endpoints. Its
seems this I-D is placing a requirement on CLUE endpoints, namely
that they MUST generate RTCP CNAMES per RFC 7022. Now maybe I'm
misreading this and there is actually some other RFC that places
this requirement on CLUE endpoints. In which case you should refer
to that document for the requirement. But if it is this document
placing a behavioral requirement on CLUE endpoints, then it is my
personal opinion that such a requirement is not appropriate for
the Security Considerations.

   regards,

   Dan.

---

From: Roni Even <[email-masked]>
Date: Thu, 12 Jan 2017 05:56:20 +0000

HI Dan,

1.       The first two documents are in the RFC editor queue and the third one is well advanced and is an important document for a lot of work in the ART area and is in its final stages. The RFC editor waits for RFCs for normative references before publishing the document.

2.       RFC7022 is relevant for all RTP payloads, it updates RFC3550 which is the RTP specification and provide guidelines for choosing RTCP CNAMEs. The CNAME is the identification of the RTP endpoint. The CLUE RTP usage document outlines how to use RTP in CLUE and in the security section we ouline how to address security concerns for RTP by using a specific RTP profile and choosing specific ways to create the relevant parameters.
Roni

From: Dan Harkins [mailto:[email-masked]]
Sent: יום ד 11 ינואר 2017 19:50
To: Roni Even; [email-masked]; [email-masked]; [email-masked]
Subject: Re: secdir review of draft-ietf-clue-rtp-mapping

  Hi Roni,

From: Dan Harkins [mailto:[email-masked]]
Sent: יום ו 06 ינואר 2017 23:52
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: secdir review of draft-ietf-clue-rtp-mapping

  Greetings,

draft advances.

  regards,

  Dan.