Subject: [secdir] Secdir review of draft-ietf-cdni-footprint-capabilities-semantics-12

From: "Brian Weis (bew)" <[email-masked]>
Date: Tue, 22 Mar 2016 20:14:04 +0000

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 document describes high level semantics around the method that sites in a CDN Interconnection (CDNI) can perform a capability exchange, and defines the semantics that would be exchanged. The described semantics do not form a protocol, or even a data format, but provide an overview of considerations and guidance on the types of information that are to be exchanged.

The Security Considerations section does make requirements on protocols that would implement a capabilities exchange conforming to this document, which is that they must provide “integrity and authentication services” between the sites. It also notes that since a CDNI is setup as the result of business relationships, it’s reasonable to expect and out of band method for exchanging authentication state for a protocol. This seems right to me.

Confidentiality of protocols that implement these semantics is not considered a high priority because "It is not believed that there are any serious privacy risks in sharing footprint or capability information”. The section states an assumption that the shared information will be aggregated data and policy-related information about media, rather than personally identifying information (PII). However, since this document is not specifying any particular protocol, and thus does not strictly control the contents of the protocol, this seems like an uncertain assumption to me. It would be better to make a more positive assertion recommending confidentiality,  so that protocol implementors conforming to this document are less likely to forget to add confidentiality when they do pass PII, or when they forget to think about privacy threats to PII. If a traditional cryptographic system (such as TLS) is deployed to obtain integrity, including confidentiality protection comes for a very small (perhaps negligible) additional cost but provides substantial added privacy value, so there isn’t much technical justification to explicitly omit confidentiality.

Because of this privacy risks discussion, I consider document is "Ready with issues” (but it’s just the one issue, all else looks fine to me).

Brian

---

From: Kevin Ma J <[email-masked]>
Date: Wed, 23 Mar 2016 15:58:46 +0000

Hi Brian,

  Thank you for the review.  It is a fair comment and a good suggestion.  I agree that the follow-on protocol spec will have to do the real security evaluation, and it makes sense to not offer too many assumptions in the semantics doc.  I will update the security section in the next rev, to remove that statement and add the suggested privacy measures, in line with the other CDNI protocol drafts.

thanx!

--  Kevin J. Ma 

> -----Original Message-----
> From: Brian Weis (bew) [mailto:[email-masked]]
> Sent: Tuesday, March 22, 2016 4:14 PM
> To: The IESG; [email-masked]
> Cc: [email-masked]
> Subject: Secdir review of draft-ietf-cdni-footprint-capabilities-
> semantics-12
> 
> 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 document describes high level semantics around the method that sites
> in a CDN Interconnection (CDNI) can perform a capability exchange, and
> defines the semantics that would be exchanged. The described semantics do
> not form a protocol, or even a data format, but provide an overview of
> considerations and guidance on the types of information that are to be
> exchanged.
> 
> The Security Considerations section does make requirements on protocols
> that would implement a capabilities exchange conforming to this document,
> which is that they must provide "integrity and authentication services"
> between the sites. It also notes that since a CDNI is setup as the result
> of business relationships, it's reasonable to expect and out of band
> method for exchanging authentication state for a protocol. This seems
> right to me.
> 
> Confidentiality of protocols that implement these semantics is not
> considered a high priority because "It is not believed that there are any
> serious privacy risks in sharing footprint or capability information". The
> section states an assumption that the shared information will be
> aggregated data and policy-related information about media, rather than
> personally identifying information (PII). However, since this document is
> not specifying any particular protocol, and thus does not strictly control
> the contents of the protocol, this seems like an uncertain assumption to
> me. It would be better to make a more positive assertion recommending
> confidentiality,  so that protocol implementors conforming to this
> document are less likely to forget to add confidentiality when they do
> pass PII, or when they forget to think about privacy threats to PII. If a
> traditional cryptographic system (such as TLS) is deployed to obtain
> integrity, including confidentiality protection comes for a very small
> (perhaps negligible) additional cost but provides substantial added
> privacy value, so there isn't much technical justification to explicitly
> omit confidentiality.
> 
> Because of this privacy risks discussion, I consider document is "Ready
> with issues" (but it's just the one issue, all else looks fine to me).
> 
> Brian

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Wed, 23 Mar 2016 16:03:35 +0000

Hi Kevin,

That sounds like a great plan, thanks.

Brian

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]