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

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

Hi Kevin,

That sounds like a great plan, thanks.

Brian

On Mar 23, 2016, at 8:58 AM, Kevin Ma J <[e-mail]> wrote:

> 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

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: [phone]
Email: [e-mail]