Subject: Re: [CDNi] Review of draft-leung-cdni-uri-signing-01

From: "Kent Leung (kleung)" <[email-masked]>
Date: Sat, 23 Feb 2013 22:51:33 +0000

Hi Ray. Appreciate your thorough review and thoughtful comments. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brandenburg, R. (Ray) van
Sent: Tuesday, January 29, 2013 4:02 AM
To: [email-masked]
Subject: [CDNi] Review of draft-leung-cdni-uri-signing-01

Hi Kent, Francois, Matt,

I've reviewed draft-leung-cdni-uri-signing-01 and have a couple of comments. 

- In its current form, the draft seems to lack a section that deals with the concept of URI signing from more of a system/high-level perspective. Such a section could explain how the signed URI is being used between the CSP, uCDN and dCDN respectively. As an example: the current draft seems to imply that the same Signed URI that is created by the CSP is checked by the dCDN. An alternative would be to have each transcient CDN 're-sign' the URI, reducing the number of parties that need to have access to a CSP key (in the case of symmetric keys). I would imagine a section in the draft that explains the trade-offs between these choices and argumentation why a specific method was chosen.

KL> Agree that would be helpful to have in the draft.

- The draft would benefit from a clear division between the general concepts behind URI signing and the specific algorithm that is proposed in section 3. I would assume that since the draft introduces the ALG field, that the method described in the latter part of section 3 is just one example (although maybe a preferred/recommended one) of such an algorithm.

KL> This may be related to the earlier comment (i.e. provide general concept of URI signing). Section 3 is a specific algorithm (default) in the base URI signing solution. New algorithms can be introduced as extensions to URI signing.

- In either the terminology section or the overview, it might be useful to spend a few sentences on explaining your concept of 'key' and what it represents. From reading the document, it seems that keys are being used in two ways: 1) as a salt for cryptographic hashes such as SHA-1 or MD5, and 2) as encryption/decryption keys in case the URI signing algorithm specifies that the result of the hash should be encrypted (primarily in cases where asymmetric keys are used). The way the document is written right now, this second use of the 'key' concept is relatively 'hidden' from the casual reader. Considering the fact that you mention asymmetric keys early on, this can confuse the reader, since the combination of hashes and asymmetric keys seems odd. Maybe it would be even better to use two different terms for the two uses that 'key' seems to have. 

KL> Let me think if there's a better way to clarify, especially for asymmetric key support.

- In the same way that section 2 defines the HF field, shouldn't it also define something like an Encryption Function (EF) field, to define the specific form of encryption used in the case asymmetric keys are used? Alternatively, both the HF and EF fields could also be a function of the ALG field, reducing the number of necessary fields in the URI. 

KL> Let me consider that. I need to refresh my memory on asymmetric key support.

- It could be useful to divide the list of attributes in section 2 into a list containing attributes used for checking the validity of a given request (e.g. the ET and CIP fields) and a list containing attributes used for re-calculating the signature (e.g. the ALG, HF, KO and KN fields). 

KL> Sounds reasonable to categorize the attributes.

- What is the semantic distinction between the CIP and CID fields, apart from the fact that CIP could be considered a specific case of CID? 

KL> Yes, generally, CID is needed for validation. CIP is a specific information that is part of the IP packet. The other CID parameters are more details that helps identify the client/user/subscriber. Since the information is not part of the IP packet, it requires some other way of validating the correctness. I'm wondering if we should drop CID attribute?

Kent

Best regards,

Ray
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

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