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

[Kevin Ma J <[e-mail]>]

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:[e-mail]]
> Sent: Tuesday, March 22, 2016 4:14 PM
> To: The IESG; [e-mail]
> Cc: [e-mail]
> 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