Last Call Review of draft-ietf-cdni-footprint-capabilities-semantics-12
review-ietf-cdni-footprint-capabilities-semantics-12-secdir-lc-weis-2016-03-23-00

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