Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-03.txt

From: Kevin J Ma <[email-masked]>
Date: Sun, 3 Nov 2013 23:13:55 -0500

Hi Kent,

  The updates since Berlin look good.

> - URI Signing Token attribute renamed to URI Signing Package attribute,
> which is now mandatory

  Some parts of the draft still read as thought packaging is optional?

  Comments/questions on the latest draft below.

thanx.

--  Kevin J. Ma

comments:

- section 1.3: should "needs" be a SHOULD or a MUST?

    "Note that the signed Redirection URI
     needs to maintain the same level of security as the original Signed
     URI."

- section 2.1: do we want to reference the security considerations
               section wrt ET/CIP limitations?

- section 2.2: the default hash function SHA256 does not show up in
               the IANA considerations hash function list?

- section 2.3: should there be a registry for DS algorithms?

- section 2.4: should "should not" be "SHOULD NOT"?  do we want to add
               some text to describe how to handle it if they do?

    "The attributes that are appended to the
     Signed URI should not have the same name as this attribute to avoid
     failing URI Signing validation."

               note: my vote is for making packaging mandatory.

- section 3: do we want to note that allowing the changing of the URL
             scheme requires that the default port is used, or that
             the protocols must both run on the same non-standard port?

    "The entire URI except the "scheme name" part is protected
     by the URI signature.  This allows the URI signature to be validated
     correctly in the case when a client performs a fallback to another
     scheme (e.g.  HTTP) for a content referenced by an URI with a
     specific scheme (e.g.  RTSP)."

- section 3: in steps 9.A.h and 9.B.g, "with escape characters" was a
             little confusing for me, could just remove it?

    "           Note: Computation
                happens before URL encoding with escape characters is
                performed for reserved characters."

- section 3: in step 9.B.c, query strings are not allowed in the KID?
             presumably, to prevent confusion with it being in a query
             string, given that it is not URL encoded?  should that be
             noted?

- section 3: step 10 happens whether packaging or not?  is the first
             sentance necessary?  if so, what is the distinction?
             does it have to do with the lack of URL encoding to this
             point?  if so, should that be noted?

    "10.  When packaging the URI Signing attributes is not necessary,"

             as noted previously, my vote is for mandatory packaging.

- section 4: we may want to note that this procedure only occurs if
             URL signing is configured in the metadata, or perhaps add
             checking the metadata as a first step?

- section 4: step 1 uses the last instance of the packaging attribute.
             this allows for a simple DoS attack whereby a bogus
             packaging attribute can be appended without needing to
             know anything about the signing configuration?  note:
             this comment applies in general to steps 4 and 5 as well,
             where the time window and client IP are not associated
             with a valid signature prior to enforcement.

    "      If there are multiple
           instances of this attribute, the last one is used."

             an alternative would be to try them all?

- section 4: step 3 allows VER to be specified in a "configuration",
             however this seems to contradict section 2.2 which states
             that the version defaults to 1, unless specified in the
             metadata.  note: this comment applies in general to steps
             4.A.a, 4.A.b, and 4.B.a as well.

    "      e.g. configuration
           or CDNI metadata)."

- section 4: steps 4.A.f and 4.B.e, URL decoding should have occurred
             before any of the processes in section 4 occur?  should
             that just be noted up front?  also, similar to the
             previous comment, for clarity, could just remove "for
             reserved characters"? 

    "      Note:
           Computation happens after URL decoding of the escape
           characters is performed for reserved characters."

- section 4: the process provided assumes packaging?  if there is no
             packaging we may need to specify additional rules for
             selecting which attributes to use, if there are duplicates?

             as noted above, my preference would be to make packaging
             mandatory, to avoid these issues.

- section 5.4: this sentance was confusing to me at first.
               essentially anyone can create a public/private key pair,
               put the public in the URL and sign with the private, so
               we need to verify the public key?  so then, why allow
               the key id to be a URL at all?  just make it a key id
               (it if happends to be a URL, fine, but do not allow it
               to be interpreted as a URL), and only allow the actual
               URL to be specified in metadata?

    "the CDNI Metadata Interface MUST provide the public key for the
     content or information to authorize the received Key ID attribute.

- section 9: should signature validation occur before HTTP processing,
             e.g., if-modified-since headers?

- section 9: there are some obvious complexities to this, and the
             issue of rejecting legitimate re-requests?  Is the intent
             to offer alternatives for better security, or just to
             document known security issues?

    "   One way to reduce exposure to replay
        attacks is to include in the URI a unique one-time access ID."

             similar comment here:

    "   One way to
        reduce exposure to this kind of attack is to not only check for
        Client IP but also for other attributes that can be found in the
        HTTP headers."

nits:

- abstract: "request" -> "requests"

- section 1.3: "CSP may choose" -> "the CSP may choose"

- section 2.4: "whom" -> "who"?

- section 2.4: "SIgning" -> "Signing"

- section 2.4: "theBase-64" -> "the Base-64"

- section 3: in step 9.B.i: "denoted" -> "delimited"?

- section 4: step 2: "metada" -> "metadata"

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Kent Leung (kleung)
> Sent: Thursday, September 12, 2013 1:24 AM
> To: [email-masked]
> Subject: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-
> signing-03.txt
> 
> Hi folks. Based on the discussions at the last IETF meeting, I’ve made the
> updates to the draft. Some of the key changes were:
> 
> - Updated URI Signing in a CDNI Environment figure
> - Specified that attributes added by UA/other  entity need to be after the
> CDNI URI Signing attribute
> - URI Signing Token attribute renamed to URI Signing Package attribute,
> which is now mandatory
> 
> Review comments are welcome. Thanks.
> 
> Kent
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 30, 2013 12:31 PM
> To: Ray van Brandenburg; Scott Leibrand; Kent Leung (kleung); Francois Le
> Faucheur (flefauch); Bill Downey
> Subject: New Version Notification for draft-leung-cdni-uri-signing-03.txt
> 
> 
> A new version of I-D, draft-leung-cdni-uri-signing-03.txt
> has been successfully submitted by Kent Leung and posted to the IETF
> repository.
> 
> Filename:	 draft-leung-cdni-uri-signing
> Revision:	 03
> Title:		 URI Signing for CDN Interconnection (CDNI)
> Creation date:	 2013-08-30
> Group:		 Individual Submission
> Number of pages: 33
> URL:             http://www.ietf.org/internet-drafts/draft-leung-cdni-uri-
> signing-03.txt
> Status:          http://datatracker.ietf.org/doc/draft-leung-cdni-uri-
> signing
> Htmlized:        http://tools.ietf.org/html/draft-leung-cdni-uri-signing-
> 03
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-leung-cdni-uri-
> signing-03
> 
> Abstract:
>    This document describes how the concept of URI signing supports the
>    content access control requirements of CDNI and proposes a candidate
>    URI signing scheme.
> 
>    The proposed URI signing method specifies the information needed to
>    be included in the URI and the algorithm used to authorize and to
>    validate access request for the content referenced by the URI.  Some
>    of the information may be accessed by the CDN via configuration or
>    CDNI metadata.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 4 Nov 2013 19:07:04 +0000

Hi Kevin. Thanks for your thorough review. Let me spend some time on your comments and respond later.

Kent

-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: Sunday, November 03, 2013 8:14 PM
To: Kent Leung (kleung); [email-masked]
Subject: RE: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-03.txt

Hi Kent,

> - URI Signing Token attribute renamed to URI Signing Package 
> attribute, which is now mandatory

thanx.

--  Kevin J. Ma

comments:

    "           Note: Computation

    "      If there are multiple

    "      e.g. configuration
           or CDNI metadata)."

    "      Note:

             similar comment here:

    "   One way to

nits:

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Kent Leung (kleung)
> Hi folks. Based on the discussions at the last IETF meeting, I’ve made 
> the updates to the draft. Some of the key changes were:
> 
> - Specified that attributes added by UA/other  entity need to be after 
> the CDNI URI Signing attribute
> - URI Signing Token attribute renamed to URI Signing Package 
> attribute, which is now mandatory
> 
> To: Ray van Brandenburg; Scott Leibrand; Kent Leung (kleung); Francois 
> Le Faucheur (flefauch); Bill Downey