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

From: "Kent Leung (kleung)" <[email-masked]>
Date: Fri, 14 Feb 2014 01:26:58 +0000

FYI. This new version addressed some of the issues and comments raised during last IETF session. The key changes are:

- Updated the document to be in line with the new approach of mandatory packaging and encapsulated information elements.
- Only one attribute in the URI query string is used for URI Signing. The attribute name is provided by CDNI metadata or via configuration.
- Adjusted section 2 to make a clear distinction between an information element (the three categories) and the packaging attribute. 
- Fixed inconsistencies and errors in the document which addressed Kevin's comments

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 5:08 PM
To: Ray van Brandenburg; Kent Leung (kleung); Bill Downey; Bill Downey; Scott Leibrand; Scott Leibrand; Kent Leung (kleung); Francois Le Faucheur (flefauch); Ray van Brandenburg; Francois Le Faucheur (flefauch)
Subject: New Version Notification for draft-leung-cdni-uri-signing-04.txt

A new version of I-D, draft-leung-cdni-uri-signing-04.txt
has been successfully submitted by Kent Leung and posted to the IETF repository.

Name:		draft-leung-cdni-uri-signing
Revision:	04
Title:		URI Signing for CDN Interconnection (CDNI)
Document date:	2014-02-13
Group:		Individual Submission
Pages:		34
URL:            http://www.ietf.org/internet-drafts/draft-leung-cdni-uri-signing-04.txt
Status:         https://datatracker.ietf.org/doc/draft-leung-cdni-uri-signing/
Htmlized:       http://tools.ietf.org/html/draft-leung-cdni-uri-signing-04
Diff:           http://www.ietf.org/rfcdiff?url2=draft-leung-cdni-uri-signing-04

Abstract:
   This document describes how the concept of URI signing supports the
   content access control requirements of CDNI and proposes a 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 requests 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

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Fri, 14 Feb 2014 16:48:52 +0000

Hi Mark. We had a discussion about "URI Squatting" issues with this draft at the last IETF. This particular issue is covered in draft-ietf-appsawg-uri-get-off-my-lawn. There was a consensus to use CDNI Metadata Interface to define the attribute name(s) in the URI query string as the resolution. The revision to this draft addressed the point that you've raised (see 2nd bullet below). Please let me know if you have any comments or concerns. Thanks.

Kent

-----Original Message-----
From: CDNi [mailto:[email-masked]] On Behalf Of Kent Leung (kleung)
Sent: Thursday, February 13, 2014 5:27 PM
To: [email-masked]
Subject: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-04.txt

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 5:08 PM
To: Ray van Brandenburg; Kent Leung (kleung); Bill Downey; Bill Downey; Scott Leibrand; Scott Leibrand; Kent Leung (kleung); Francois Le Faucheur (flefauch); Ray van Brandenburg; Francois Le Faucheur (flefauch)
Subject: New Version Notification for draft-leung-cdni-uri-signing-04.txt

Abstract:

The IETF Secretariat

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Feb 2014 12:17:08 +1100

Hi Kent,

Thanks for the heads up.

I'm looking a the draft and the diffs quickly, so apologies if I'm misreading it.

In Sections 3 and 4, as I understand it, you're using a temporary URI with all of the various metatdata you're interested in added to it, taking a signature of it, and then adding that signature to the actual URI with the parameter that's communicated by the metadata interface, correct?

If so, the text could be a little more clear about this -- the way that it's written, it's easy to think that 'URISigningPackage' is static and unchanging. 

E.g., in section 3:

> 5.  Append the parameter name used to indicate the URI Signing	
>  	       Package Attribute.  This parameter name is communicated via the	
>  	       CDNI Metadata Interface.  Alternatively, it is set to	
>  	       'URISigningPackage' by configuration.  Append the string	
>  	       "URISigningPackage=" to the message.

This would be more clear as something like:

"""
5. Append the parameter name used to indicate the URI Signing Package Attribute, as communicated via the CDNI Metadata interface, followed by an "=". If non is communicated by the metadata interface, it defaults to "URISigningPackage".  For example, if the CDNI Metadata interface specifies "SIG", append the string "SIG=" to the message.
"""

and so forth.

More deeply, the draft assumes that URIs always have query strings encoded in the format specified by HTML <http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4.1>. While that format is extremely common, it isn't a constraint on URIs -- even HTTP URIs.

One way to avoid this would be to have the CDNI Metadata Interface convey a URI Template to specify where the signature goes:
  http://tools.ietf.org/html/rfc6570
  https://code.google.com/p/uri-templates/wiki/Implementations

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 19 Feb 2014 20:56:32 +0000

Hi Mark. See comments below.

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Sunday, February 16, 2014 5:17 PM
To: Kent Leung (kleung)
Cc: [email-masked]
Subject: Re: [CDNi] New Version Notification for draft-leung-cdni-uri-signing-04.txt

Hi Kent,

Thanks for the heads up.

KL> Right.

"""

and so forth.

KL> OK. We can add an example. For your text, ""=". If non is communicated by the metadata interface, it defaults to "URISigningPackage"", are you saying it's OK to default to an attribute name specified in the draft? If so, would this attribute name need to be IANA-based? I'd like the clarify the language.

KL> OK. We'll need to look at this when the CDNI Metadata interface section is filled in. Thanks.

Kent

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Feb 2014 14:40:39 +1100

On 20 Feb 2014, at 7:56 am, Kent Leung (kleung) <[email-masked]> wrote:

>> KL> OK. We can add an example. For your text, ""=". If non is communicated by the metadata interface, it defaults to "URISigningPackage"", are you saying it's OK to default to an attribute name specified in the draft?

Think so.

>> If so, would this attribute name need to be IANA-based? I'd like the clarify the language.

Don't think so... Happy to talk about it in London, though.

>> KL> OK. We'll need to look at this when the CDNI Metadata interface section is filled in. Thanks.

Thanks,

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Fri, 21 Feb 2014 18:21:00 +0000

<snip>
> 5. Append the parameter name used to indicate the URI Signing Package Attribute, as communicated via the CDNI Metadata interface, followed by an "=". If none(sic) is communicated by the metadata interface, it defaults to "URISigningPackage".  For example, if the CDNI Metadata interface specifies "SIG", append the string "SIG=" to the message.
> """
> 
> and so forth.
> 

Think so.

KL>> OK. I see what you meant. What you said is fine so we are in agreement. :) Thanks for the clarification.

Kent

<snip>

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 25 Feb 2014 19:52:14 -0500

Hi Kent,

  Read through the updated draft; couple of comments below.

thanx.

--  Kevin J. Ma

- general: "CDNI <XXX> Interface" -> "CDNI <XXX> interface"
           Francois made this comment on the metadata draft, so I
           assume it would apply to url signing as well.

- section 2.4: "encoding sheme" -> "encoding scheme"

- section 3: "step 5a-5b" -> "step 5"
             note: step 4 just says "step 4"

             step 6(A)(c): "an URI" -> "a URI"

             steps 6(A)(e) and 6(B)(e) are not really steps?
             They're just making statements about what the messages look
             like up through steps 6(A/B)(d)?  Should they just be a
             comments?

             steps 6(A)(f) and 6(B)(g): Since the values in the "query
             string" are not actually going to go into the actual URI,
             there's no need to perform URL encoding.  We should just
             remove that text (and possibly add a note about it)?

             step 6(B)(f): Where is the message digest used?

             second step 2: I decoded the base64 encoded value and it
             does not match the value in second step 1?

             "VER=1&ET=1209422976&CIP=10.0.0.1&KID=foobar:keys:123&
              HF=SHA-1&MD=4fb1c1adf1588fbe11cc6a04c6e69f35" !=
             "VER=1&ET=1209422976&CIP=10.0.0.1&KID=example:keys:123&
              HF=SHA-256&MD=4fb1c1adf1588fbe11cc6a04c6e69f35"

             "VkVSPTEmRVQ9MTIwOTQyMjk3NiZDSVA9MTAuMC4wLjEm
              S0lEPWZvb2JhcjprZXlzOjEyMyZIRj1TSEEtMSZNRD00
              ZmIxYzFhZGYxNTg4ZmJlMTFjYzZhMDRjNmU2OWYzNQ==" ->
             "VkVSPTEmRVQ9MTIwOTQyMjk3NiZDSVA9MTAuMC4wLjEm
              S0lEPWV4YW1wbGU6a2V5czoxMjMmSEY9U0hBLTI1NiZN
              RD00ZmIxYzFhZGYxNTg4ZmJlMTFjYzZhMDRjNmU2OWYzNQ=="?

- section 4: The first paragraph discusses signing being enabled.
             Should it also mention checking the allowable set of dCDNs?

             in the first step 3, should we check that the VER is
             within the allowable VER set?  If it's not, I assume we
             would want to deny the request?  Should we state that?

             in step 8, if both MD and DS are specified, should we
             deny the request?

             in the second step 1 or 2, not only does the scheme need
             to be removed, but any query string parameters after the
             first URISigningPackage parameter also need to be
             discarded before beginning step 3?

             steps 4(A)(a) and 4(B)(a): if the KID is found but
             doesn't match the metadata config, or if a KID cannot be
             found in either the URISigningPackage or the
             metadata/config, or if the specified KID is not in the
             allowable KID set, I assume we would want to deny the
             request?  Should we state that?

             step 4(A)(b): HF has a default.  Is it expected that the
             default would be part of the config/metadata?  If the
             specified HF is not in the allowable HF set, I assume we
             would want to deny the request?  Should we state that?

             steps 4(A)(f) and 4(B)(e): Since the values were never
             actually in the actual URI, there's no need to perform
             URL decoding.  We should just remove that text (and
             possibly add a note about it)?

             step 4(B)(b): Should there be an extraction step for DSA,
             with consideration for the default value?

             step 4(B)(e): Should this be a digital signature using
             the EC DSA algorithm?

- section 5.4: "URI for a content" -> "URI for content"

- section 5.5: "allowed values are:" should be before the list of values.

- sections 6.1 and 6.2: missing periods in the steps
                        inconsistent "z" usage for authori[s|z]ation
                        (step 4 of figure 4: capitalize Authori[s|z]ation)

- section 6.2: "URI Signing does match" -> "URI Signing does not match"

    "With DNS-based request routing, URI Signing does match well the
     general chain of trust model of CDNI when used with symmetric keys
     because the symmetric key information needs to be distributed across
     multiple CDNI hops including non-adjacent hops."

- section 9: "approriate" -> "appropriate"
             "In general it" -> "In general, it"

> Sent: Thursday, February 13, 2014 8:27 PM
> To: [email-masked]
> FYI. This new version addressed some of the issues and comments raised
> during last IETF session. The key changes are:
> 
> - Updated the document to be in line with the new approach of mandatory
> packaging and encapsulated information elements.
> - Only one attribute in the URI query string is used for URI Signing. The
> attribute name is provided by CDNI metadata or via configuration.
> - Adjusted section 2 to make a clear distinction between an information
> element (the three categories) and the packaging attribute.
> To: Ray van Brandenburg; Kent Leung (kleung); Bill Downey; Bill Downey;
> Scott Leibrand; Scott Leibrand; Kent Leung (kleung); Francois Le Faucheur
> (flefauch); Ray van Brandenburg; Francois Le Faucheur (flefauch)
> 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
>