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

["Brian Weis (bew)" <[e-mail]>]

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