Subject: [CDNi] Review of the CDNI metadata draft

From: Jan Seedorf <[email-masked]>
Date: Sat, 8 Nov 2014 19:12:21 +0000

As promised, I reviewed the -08 version of the metadata draft. Here are my comments:

n  In general, the draft reads well and the concepts are well-described and clearly understandable (I briefly checked all the detailed object specifications and found no errors); the draft is in a very mature state and indeed seems ready for publication soon; also, the example in section 6 is very clear; I just have a couple of detailed comments below

n  Section 1.2: it talks about capabilities (which are later on explained in section 5) but there is no reference to the FCI documents; I think you should add some text and refs on how the metadata capabilities relate to the CDNI FCI

n  Section 5: this text needs to be revised according to the latest decision we have made regarding the definition of MI FCI objects being outside of the metadata draft; but this decision has been announced on the mailing list after the -08 version was published, so obviously it could not have been addressed

n  Section 8 - Security Considerations: this section needs to be improved in my view; it is not very clear about the difference between integrity and confidentiality (e.g. talks about using encryption to provide integrity, but usually digital signatures or HMACs are used for that); also the term "private" is used referring to dCDNs information (and not to end users), this needs to be clarified better; finally, among all the threats mentioned, several key ones are missing, such as an attacker modifying unprotected CDNI metadata in order to change restrictions etc. such that unauthorized end users may access content they are not supposed to (from the content provider perspective this seems to be an important threat regarding CDNI)

n  TLS usage: from the attacker model described in section 8, it seems clear that TLS is strongly advised and would fulfill the security requirements; yet, in section 1.2 it reads like supported CDNI MI over TLS needs further specifications, is this true?

n  I found several typos, but instead of listing them here I will pass on my printout with the marks to the authors on-site at IETF-91

-          Jan

============================================================
Dr. Jan Seedorf
Senior Researcher
NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel.     +49 (0)6221 4342-221
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked]<mailto:[email-masked]>
============================================================
NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB, Registered in England 2832014

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 17 Nov 2014 12:51:35 +0000

Hi Jan,

Thank you for your review, see inline for my responses to your individual points.

> n  Section 1.2: it talks about capabilities (which are later on explained in section 5) but there is no reference to the FCI documents; I think you should add some text and refs on how the metadata…

The intent of Section 1.2 is to outline what is possible with the metadata described in the document.

If you could propose specific text you would like to see that would be helpful, as I'm not exactly sure what extra to write given my understanding of the recent agreement in the WG to not talk about FCI specifically but to leave that to separate document(s)?

> n  Section 5: this text needs to be revised according to the latest decision we have made regarding the definition of MI FCI objects being outside of the metadata draft; but this decision has been…

Currently Section 5 mentions that a uCDN having knowledge of what optional a dCDN supports might be useful and a vague reference that the FCI may be used to advertise such knowledge.

Section 5, as written, doesn't seem to be in conflict with the recent agreement in the WG regarding FCI from what I can see, unless you are suggesting we reference a different document to the generic CDNI Framework document? 

Are there specific text changes you could propose that would address what you think is missing or needs re-writing?
 
> n  Section 8 – Security Considerations: this section needs to be improved in my view; it is not very clear about the difference between integrity and confidentiality (e.g. talks about using encryption to provide integrity, but usually digital signatures or HMACs are used for that); also the term “private” is used referring to dCDNs information (and not to end users), this needs to be clarified better; finally, among all the threats mentioned, several key ones are missing, such as an attacker modifying unprotected CDNI metadata in order to change restrictions etc. such that unauthorized end users may access content they are not supposed to (from the content provider perspective this seems to be an important threat regarding CDNI)

I'll respond to your comments above in a separate e-mail once I've had a chance to re-look at that section.

> n  TLS usage: from the attacker model described in section 8, it seems clear that TLS is strongly advised and would fulfill the security requirements; yet, in section 1.2 it reads like supported CD…

We discussed this at the microphone in Hawaii. The text in Section 1.2 is trying to outline what protocols can be supported for delivery and acquisition by a dCDN using the CDNI Metadata objects specified in the document.

It is not meant to be interpreted as a statement for whether or not to use TLS for securing the exchange of metadata objects across the CDNI Metadata interface itself.

I've tried to re-word the second half of Section 1.2 to make it clearer that it is talking about delivery & acquisition of content by the dCDN, what I have come up with is the following:

   The set of metadata specified in this document, covering the initial
   capabilities above, is only able to support CDN interconnection for
   the delivery of content by a dCDN using HTTPv1.1 and for a dCDN to be
   able to acquire content from a uCDN using either HTTPv1.1 or HTTPv1.1
   over TLS.

   Supporting CDN interconnection for the delivery of content using
   unencrypted HTTPv2.0 (as well as for a dCDN to acquire content using
   unencrypted HTTPv2.0 or HTTPv2.0 over TLS) requires the registration
   of these protocol names in the CDNI Metadata Protocol Sub-Registry.

   Supporting CDN interconnection for the delivery of content using
   HTTPv1.1 over TLS or HTTPv2.0 over TLS requires specifying additional
   metadata objects to carry the properties required to establish a TLS
   session, for example metadata to describe the certificate to use as
   part of the TLS handshake.

Does the new wording above address your comment?

Regards
Ben

> e-mail:  [email-masked]
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 17 Nov 2014 17:58:47 +0000

Jan,

> n  Section 8 – Security Considerations: this section needs to be improved in my view; it is not very clear about the difference between integrity and confidentiality (e.g. talks about using encrypt…

Taking a look at Section 8 again and also using the Security Considerations section of the Logging interface as a guide, I suggest we re-write Section 8 of the Metadata specification to be much more inline with section 7 & in particular section 7.1 of the logging interface:
http://tools.ietf.org/html/draft-ietf-cdni-logging-13#page-46

I think basing off sections 7/7.1 would give us a good general description and then we can include specific issues that may occur if for e.g. mutual authentication or message integrity are not used, if you think that is also required?

Similarly fir privacy, some of the general text in Section 7.3 of the logging draft looks a good base to reuse and then we can talk a little about the fact that metadata contains content provider policy and other configuration they may not want exposed.

If the outline above sounds like it is on the right path to addressing your comments, I'll work with my co-authors to produce some proposed text we can review with you further.

Ben