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

From: Leif Hedstrom <[email-masked]>
Date: Thu, 15 Oct 2015 19:01:50 -0700

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?

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.

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.

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.

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?

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?

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.

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.

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.

Page 23:

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

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"?

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? 

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" ?

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.

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 :). 

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.

Page 15:

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

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?

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).

Page 28 - 31:

It's unfortunate that the pictures in Section 6.1 and Section 6.2 wraps over
multiple pages.

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.

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Fri, 16 Oct 2015 17:41:29 +0000

Hi Leif,

Many thanks for your very thorough review! 

Please find my responses inline.

Ray

>/ 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. 

>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?

>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.

>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?

>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

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

>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. 

>With 2), the URI would specify if additional parameters are allowed after the

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? 

>first "/" in the path and forward.

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

>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.

>HMAC for the symmetric keys. Maybe it should say "HMAC" instead of "EC-DSA"?

You're right. Thanks.

>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. 

>"In addition" to "If applicable" ?

Agree on all of the above. 

>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. 

>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. 

>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.

>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. 

>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?

>elements are worthwhile to validate before doing cryptographic operations

Agreed.

>It's unfortunate that the pictures in Section 6.1 and Section 6.2 wraps over

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. 

>early on in the document as well, so I feel this section sort of murks the

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: Mon, 19 Oct 2015 22:49:06 +0000

Hi Leif. Thanks for the comprehensive review. Just adding a few more comments to Ray's.

>
>
>Page 9:
>
>It could be useful to allow expressing the client IP as a subnet, for 
>two reasons
>
>	1) Privacy
>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.

KL> I'm not sure how CSP would know the IP subnet of the clients. Typically, a client is authenticated and authorized to access the content. The URI signature is to authorize that client only. Also, I think privacy contradicts with source-based (i.e. client IP) authorization. What is the use case for a client to authenticate with CSP and authorize access from a subnet? Maybe for IPv6 (RFC 4941) case only, but not sure about IPv4. For IPv6, it does not contradict the source-based authorization since the client IP is /64.

As for NAT, this is the opposite problem when multiple clients share a common IP, which may have been authorized for access. This is covered in Sect 9. I'm not sure that have a subnet helps with NAT unless different IP addresses are used by same client when accessing CSP and then CDN. But that brings up the issue of invalid access to content.

>
>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 :).
>

KL> In Fig 2, the "Trust relationship (optional)" between CSP and dCDN depicts that case where asymmetric encryption is used.

KL> It may be for implementation convenience. Technically, the "scheme name" part of URI is not covered by the signature.

>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?

KL> For 64 bit, it wouldn't matter if signed or unsigned. Wraparound value is beyond the existence of our solar system. ;) We can choose what's easier for implementation. This may be integer.

Kent