Subject: Re: [CDNi] Review: draft-ietf-cdni-uri-signing-05

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 3 Nov 2015 02:06:35 +0000

A few of us met yesterday to clarify the comments on the ML. Attendees were Francois, Kevin, Ray, Leif, Phil Sorber, and me.

Here's the summary. The review comments brought up some good points.  There was general consensus to incorporate them if no objections are received from the WG.

1. The URI Signing Package attribute purpose and object properties were clarified
2. Agreed on signed redirection MUST be at least same level of security as original Signed URI
3. ET should be 64 bit integer type
4. Misc editorial changes are needed as noted in the comments
5. Improve readability for URI Signing for CDNI vs. non-CDNI
6. Support URI path selection if consensus for base method can be reached
7. Allow flexible prefix length for client IP
8. Cover DOS protection use case using URI Signing
9. Support protection for original Signed URI, which cannot be changed (attributes added/deleted/re-ordered)
10. Support protection for URI scheme portion (e.g. require https://... , such that scheme cannot be changed)
11. Improve the intent of Figure 2, possibly split into HTTP vs DNS, Public Key vs Private Key cases
12. Anonymization of client IP for privacy may be supported using similar method as CDNI Logging, to be further discussed
13. Add nonce IE to improve protection property 

We will have follow-up meeting on Wed at 3pm to discuss the following items and any other outstanding issues:

A. Scheme part of URI protection
B. Path selection base method
C. Privacy issue using same anonymization method as CDNI Logging
D. Add nonce to URI Signing

We will meet at IETF reg desk at that time. Thanks.

Kent

-----Original Message-----
From: Brandenburg, R. (Ray) van [mailto:[email-masked]] 
Sent: Saturday, October 17, 2015 2:41 AM
To: Leif Hedstrom; [email-masked]
Cc: Kent Leung (kleung)
Subject: Re: Review: draft-ietf-cdni-uri-signing-05

Hi Leif,

Many thanks for your very thorough review! 

Please find my responses inline.

Ray

On 16/10/15 04:01, "Leif Hedstrom" <[email-masked]> wrote:

>Hi all,
>
>Overall, the RFC is very well written, and covers the topic in depth. I 
>have a number of suggestions below, many of which are very nitpicky. I 
>will not be offended if they are silently ignored :).
>
>That much said, I do feel that the draft is a bit verbose in some 
>areas. I've included some of that in the nitpicks below as well. Maybe 
>this is an editorial issue though, but also see Question 2) below.
>
>Caveat 1: I'm not a crypto person, so I can't vouch for the strength of 
>the symmetric and asymmetric algorithms chosen. They seem fine to me though.
>
>Caveat 2: I have not read all the other CDNI RFCs / drafts thoroughly, 
>so I have not validated all the Interface sections in this draft for 
>correctness with those RFCs.
>
>Caveat 3: I did not thorough editorial editing / suggestions here, such 
>as grammar or spelling.
>
>And thanks for adding KID_NUM :).
>
>Cheers,
>
>-- Leif
>
>
>Questions
>---------
>
>1) On Signing Package Attributes:
>
>This is mostly an observation, but why is the "Signing Package Attribute"
>needed? What problem does that solve? It sort of hides otherwise useful 
>information when debugging, log analysis ("which KID_NUM's are being 
>used") etc. Could this step be optional, such that the URL is kept 
>intact with the ET / KID_NUM / MD query parameters if so desired?

The main reason we included the Signing Package Attribute was to reduce the chance of a namespace collision in the query string with any application- or cdn-specific parameters. Without the base64 package, an implementation would have to make sure the query string doesn't contain any other parameters with names such as ET, KID, etc. Of course the chances of collision could be reduced by lengthening the information elements (e.g. IETF-CDNI-ET instead of ET), but this would increase the length of the URL unnecessarily. 

>
>It'd also make it easier / cheaper to do some obvious and quick 
>evaluations which does not require cryptographic ("expensive") 
>operations. Such as, making sure the ET is not expired, that the 
>KID_NUM is supported, and that the request does have an MD at all. This 
>is now slightly harder, since you have to
>un-base64 the string into at least a temp buffer on the stack (but be 
>aware of stack overflows :)  before any other validations can be performed.

Good point. Would I be correct in assuming you would prefer a lengthier URL as opposed to the additional un-base64 processing step?

>
>In any implementation of this, I would definitely suggest that the "cheap"
>validations be done first (time, KID_NUM validity, CIP etc.). One use 
>case of URI signatures is (as mentioned before) to make various DDoS 
>attacks, or screen scraping, harder. As such, it needs to be "cheap" on the edge nodes.

I will check the document to see whether we can re-order some of the steps. If you have any specific proposals for this, beyond removing the base64 step, please let me know.

>
>2) On CDNI interfaces vs URI signing in general
>
>I understand that the point of this RFC is for integration with CDNI. 
>And it mentions that the specifications are usable by non-CDNI 
>implementations and services. My gut tells me that this RFC could be 
>easier to read and implement, if this was split up into two RFCs. One 
>just for the URI signing implementation, and one specifically for the CDNI integration portions.

Agreed. However, a dedicated non-CDNI spec would be outside the scope of the charter of our WG. That said, I'm open to restructuring the current draft to make it easier to read for those who would use it outside the CNDI context. Do you have any specific areas where you think this could be better?

>
>3) URI Path selection
>
>We've discussed this in the past, and perhaps this is outside of the 
>scope of this revision, but I miss a component for URI path selection. 
>With this I mean, some way to say that only certain portions of the 
>path of a URI should be used for the signature. A couple of 
>requirements I've dealt with myself
>include:
>
>   a) Specify the number  (prefix) of path components that should be use. So,
>   e.g. "PS=3" indicating, use only the first three path components.
>
>   b) Selectors, like "PS=1,3-5,9", using path component 1, 3, 4, 5 and 9 in
>   the signature, but nothing else.
>
>I know this could get arbitrarily complex, but curious to hear if 
>anyone else has had these requirements. If so, maybe this is worth revisiting?

In draft-brandenburg-cdni-uri-signing-for-has I've included a proposal for a Path Pattern element that I believe matches with what you're looking for. Are you saying you believe this element might have a use outside the context of segmented content as well?

>
>
>Things to consider
>------------------
>
>Page 7:
>
>It says
>
>  "Note that the signed Redirection URI SHOULD maintain the same level 
> of  security as the original Signed URI."
>
>What is the reason why this is only a SHOULD? Why not MUST? Or maybe 
>even the even stronger
>
>  " ... MUST maintain the same, or higher, level of security ....".
>
>As I read the current text, it would be allowed to not even sign the 
>Redirection URI?

Valid point. I'll change this to your proposed text. 

>
>
>Page 9:
>
>It could be useful to allow expressing the client IP as a subnet, for 
>two reasons
>
>	1) Privacy
>	2) Flexibility (such as NAT or transparent proxy layers)
>
>Allowing for the signature to be verified for e.g. a /24 would 
>therefore be useful IMO.
>
>1) is sort of touched on in Section 10, but just says it should be 
>removed from logging. I don't think this is strong enough, with 
>pervasive monitoring of networks. 2) is of course obvious when a UA 
>sits behind a layer of 2 or more intermediaries or middle-boxes, such 
>that the source IP can be different for the various requests.

Agree on both points. I'll draft a solution that allows a CSP to convey either a fixed IP or a subnet. 

>
>
>Page 12-13 (Section 2.5 primarily):
>
>The text says that the UA is allowed to append additional attributes 
>after the URI signature. Section 2.5 talks a little bit about the 
>issues with this, and a RECOMMEND to ignore query strings passed after 
>the the Signing Package Attribute.
>
>This seems to weak to me, and potentially fragile. In addition, I can 
>think of many other ways where this could be abuse. For example, if a 
>CDN allows the additional query parameters, it could be very easy to 
>perform cache busting attacks. I think we should either
>
>	 1) Simply not allow this   - or -
>	 2) Have an additional URI Signature Information Element, to
>	    declare intent.
>
>With 2), the URI would specify if additional parameters are allowed 
>after the signature or not.

I see your point, however I'm not sure we can do anything about it since there is little we can do to prevent clients from appending additional query parameters given that the client is outside the scope of our specification. Simply not allowing this might break a lot of current implementations, and with it reduce the chances of this URI Signing mechanism of becoming widely adopted. 

Could you elaborate a bit on how you would like 2) to work? 

>
>
>Page 15:
>
>Sometimes, it could be useful to allow a URI signature to not only skip 
>the scheme, but also the host portion. For example, people use domain 
>sharding still (at least until H2 is more used). As such, it might make 
>sense to allow the same signed URI to hit 2 or more different shards within the sharding.
>
>If we added another URI Signature Information Element to indicate this, 
>we could easily change the algorithm such that the "base" string is 
>from the first "/" in the path and forward.
>

Could we use the Path Pattern element (see 3) above) to achieve this?

>
>Page 23:
>
>Section 5.2 looks odd, I think there were some editing / copy-paste 
>issues here? Needs editing I think.

Thanks. It seems that error has been in the document for quite some time. I'll fix it in the next iteration.

>
>It also says "Advertise "MD" Information Element (i.e.  EC-DSA) to 
>indicate support for symmetric key method". I'm not sure I follow this, 
>we only use HMAC for the symmetric keys. Maybe it should say "HMAC" instead of "EC-DSA"?
>

You're right. Thanks.

>
>Page 24-25:
>
>In the documentation for the properties, there's always a section for 
>"Mandatory-to-specify". However, as far as I can tell it is always 
>"no", so why bother listing this for every property? Can't we just say 
>that properties are never mandatory, and reduce the docs to document the default for each one?

I'm afraid this has to do with the way draft-ietf-cdni-metadata specifies it's registry and the way new objects need to be defined. 

>
>
>
>Nitpicks
>--------
>
>Page 3:
>
>I think we should drop the HMAC terminology and just refer / link to 
>existing RFCs (just as you did referring to RFC 6707. Maybe a short 
>sentence for each reference?
>
>I'd just drop the first paragraph in section 1.2, it's verbose and 
>superfluous. The title is sufficient IMO, or could be improved with e.g.
>
>    Background and overview on URI Signing
>
>
>Page 5:
>
>It says
>
>  "In addition, it checks whether the IP address of the HTTP request 
> matches  that in the Signed URI and if the time window is still valid"
>
>
>However, the IP address is optional in the signature generation. Maybe 
>change "In addition" to "If applicable" ?

Agree on all of the above. 

>
>
>Page 6-7:
>
>In the overview, maybe it'd be useful to show an example signed URL, 
>with a very brief explanation of the components (as a picture). This 
>would help the in-depth explanations of all the components further down the road.
>

I think that's a good suggestion. I'll add something in the next version. 

>
>Page 7-8:
>
>Figure 2: and the text is slightly confusing to me. The text says that 
>in the case where the Downstream CDN does not have a trust relationship 
>with the CSP, it must use asymmetric encryption. This makes sense, but 
>I'm not sure I see or understand this in Picture 2? I guess I'm not 
>sure what the picture is trying to tell, since it looks the same for both HTTP and DNS :).
>

The picture uses a) and b) to denote the differences between DNS and HTTP, although the arrows themselves are the same. You're right that from looking at the picture, you can't see the difference between symmetric and asymmetric keys. 

>
>Page 10:
>
>It says
>
>  "Note: The time, including time zone, on the entities that generate and
>   validate the signed URI need to be in sync (e.g.  NTP is used)."
>
>
>Maybe it should be worded more strongly, such as MUST? And perhaps also 
>clarify what it should be in sync with? One could read this is being in 
>sync with the CSP, whereas the intent of this Note is that all servers 
>should be in sync with a universal time source, using e.g. NTP.

The reason we didn't make the use of e.g. NTP explicit is that there are many ways to synchronize time, with NTP being just one of them (albeit a very popular one). In addition, depending on the length of the ET, time synchronisation might not even be necessary.

That said, I agree the current text might be a little more verbose in what it is trying to say. I'll draft something in the next iteration.

>
>
>Page 15:
>
>Why do we retain the :// ? Is that just a convenience? Ease of implementation?
>It obviously adds no value to the signature.

To be honest, I'm not sure :)

I'll check with my co-authors to see if they had any specific reason in mind. The only thing I can think of is to make it clear that no part of the domain component was left off. 

>
>
>Page 15:
>
>It also says
>
>  "Get the current time in seconds since epoch (as an integer)."
>
>time_t can be either 32-bit or 64-bit, it might be worthwhile to say 
>that ET is a signed 64-bit integer type to cover all bases?

Good point. But why would it be signed? Wouldn’t unsigned 64-bit integer make more sense?

>
>
>Page 22 (Section 4.3)
>
>The first paragraph reads oddly. "Note the steps are to be skipped if 
>the ...". What steps? I believe it refers to the steps in Section 4.2?
>
>As discussed above in "Question" section, it might be worth pointing 
>out which elements are worthwhile to validate before doing 
>cryptographic operations (such as CIP and ET).

Agreed.

>
>
>Page 28 - 31:
>
>It's unfortunate that the pictures in Section 6.1 and Section 6.2 wraps 
>over multiple pages.

Yes, definitely. I'll check if it is an error in the XML or if the picture is simply to long to fit on one page. I believe xml2rfc automatically tries to fit pictures on one page if possible. 

>
>Page 34-35:
>
>The security considerations are valid, but the vulnerability of replay 
>attacks seems like a stretch. If the service is vulnerable to a replay 
>attack, it really should use something stronger than URI signatures. 
>This was pointed out early on in the document as well, so I feel this 
>section sort of murks the water a little.

Are you saying you would prefer we didn't note this vulnerability at all, or simply remove the mention of the possibility of using one-time ids?

Thanks again!

Ray

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 3 Nov 2015 02:13:36 +0000

Sorry about the format, here's another try.

Kent

-----Original Message-----
From: CDNi [mailto:[email-masked]] On Behalf Of Kent Leung (kleung)
Sent: Tuesday, November 03, 2015 11:07 AM
To: Brandenburg, R. (Ray) van; Leif Hedstrom; [email-masked]
Subject: Re: [CDNi] Review: draft-ietf-cdni-uri-signing-05

1. The URI Signing Package attribute purpose and object properties were clarified 2. Agreed on signed redirection MUST be at least same level of security as original Signed URI 3. ET should be 64 bit integer type 4. Misc editorial changes are needed as noted in the comments 5. Improve readability for URI Signing for CDNI vs. non-CDNI 6. Support URI path selection if consensus for base method can be reached 7. Allow flexible prefix length for client IP 8. Cover DOS protection use case using URI Signing 9. Support protection for original Signed URI, which cannot be changed (attributes added/deleted/re-ordered) 10. Support protection for URI scheme portion (e.g. require https://... , such that scheme cannot be changed) 11. Improve the intent of Figure 2, possibly split into HTTP vs DNS, Public Key vs Private Key cases 12. Anonymization of client IP for privacy may be supported using similar method as CDNI Logging, to be further discussed 13. Add nonce IE to improve protection property 

A. Scheme part of URI protection
B. Path selection base method
C. Privacy issue using same anonymization method as CDNI Logging D. Add nonce to URI Signing

Kent

-----Original Message-----
From: Brandenburg, R. (Ray) van [mailto:[email-masked]]
Sent: Saturday, October 17, 2015 2:41 AM
To: Leif Hedstrom; [email-masked]
Cc: Kent Leung (kleung)
Subject: Re: Review: draft-ietf-cdni-uri-signing-05

Hi Leif,

Ray

You're right. Thanks.

Agreed.

Thanks again!

Ray

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni