Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-uri-signing-12.txt

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 4 Jul 2017 11:58:56 +0100

Hi Phil & URI Signing authors,

I read the latest draft (-12) and below are some questions / thoughts, in no particular order, that occurred to me while reading the document.

* Why support both symmetric & asymmetric keys? What is the advantage to having both options versus just picking one option (probably asymmetric keys as they work for all use cases)?

* How are the keys distributed between CDNs? I don’t see a property in the UriSigning Metadata object that would include (or link to) the keys (I’m assuming you need to support distribution of at least 2 keys to support key rotation)?

* How does a uCDN know whether it is OK/safe/within policy to re-distribute symmetric keys to a dCDN?

* In the case of Signed Token chains, how does a CDN obtain the keys required to sign the new tokens in the chain as it generates them?

* Section 3.3.1 I think needs to be more explicit, I don’t know how one could communicate a token chain via the query string as specified in the document, as there is no “back channel” for the CDN to communicate the next token in the chain to the UA.

HTH
Ben

> On 25 Jun 2017, at 21:19, Phil Sorber <[email-masked]> wrote:
> 
> Really hoping to get some feedback on this at the meeting in Prague. It's got all the changes that have been discussed so I'm not aware of any more substantive changes needed. However, lots of editorial nits I suspect.
> 
> Thanks.
> 
> On Sun, Jun 25, 2017 at 2:12 PM <[email-masked] <mailto:[email-masked]>> wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Content Delivery Networks Interconnection of the IETF.
> 
>         Title           : URI Signing for CDN Interconnection (CDNI)
>         Authors         : Ray van Brandenburg
>                           Kent Leung
>                           Phil Sorber
>         Filename        : draft-ietf-cdni-uri-signing-12.txt
>         Pages           : 35
>         Date            : 2017-06-25
> 
> Abstract:
>    This document describes how the concept of URI signing supports the
>    content access control requirements of CDNI and proposes a URI
>    signing method as a JSON Web Token (JWT) [RFC7519] profile.
> 
>    The proposed URI signing method specifies the information needed to
>    be included in the URI to transmit the signed JWT as well as the
>    claims needed by the signed JWT to authorize a UA.  The mechanism
>    described can be used both in CDNI and single CDN scenarios.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/ <https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/>
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-cdni-uri-signing-12 <https://tools.ietf.org/html/draft-ietf-cdni-uri-signing-12>
> https://datatracker.ietf.org/doc/html/draft-ietf-cdni-uri-signing-12 <https://datatracker.ietf.org/doc/html/draft-ietf-cdni-uri-signing-12>
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-uri-signing-12 <https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-uri-signing-12>
> 
> 
> 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 <http://tools.ietf.org/>.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> _______________________________________________
> CDNi mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cdni <https://www.ietf.org/mailman/listinfo/cdni>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 5 Jul 2017 21:23:18 +0000

Hi Ben. Thanks for your review comments.  See my response to some of them below.

From: CDNi [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Tuesday, July 4, 2017 3:59 AM
To: Phil Sorber <[email-masked]>
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-uri-signing-12.txt

KL> There are pros and cons of using either asymmetric keys vs symmetric key. Key distribution limitations and relationships between CSP and CDNs are factors. So I think supporting both allows flexibility for deployments of URI signing. Existing URI signing proprietary implementations typically support both already.

KL> Key distribution is out of scope. I noticed following text was dropped when method converted to JWT. We can put this back in CDNI Overview section, where the asymmetric and symmetric key methods are mentioned.

“Two types of keys can be used for URI Signing: asymmetric keys and
   symmetric keys.  Asymmetric keys are based on a public/private key
   pair mechanism and always contain a private key only known to the
   entity signing the URI (either CSP or uCDN) and a public key for the
   verification of the Signed URI.  With symmetric keys, the same key is
   used by both the signing entity for signing the URI as well as by the
   validating entity for validating the Signed URI.  Regardless of the
   type of keys used, the validating entity has to obtain the key
   (either the public or the symmetric key).  There are very different
   requirements for key distribution (out of scope of this document)
   with asymmetric keys and with symmetric keys.  Key distribution for
   symmetric keys requires confidentiality to prevent another party from
   getting access to the key, since it could then generate valid Signed
   URIs for unauthorized requests.  Key distribution for asymmetric keys
   does not require confidentiality since public keys can typically be
   distributed openly (because they cannot be used for URI signing) and
   private keys are kept by the URI signing function.”

KL> See above.

KL> See above.

Kent

HTH
Ben

On 25 Jun 2017, at 21:19, Phil Sorber <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Jun 25, 2017 at 2:12 PM <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-cdni-uri-signing-12
https://datatracker.ietf.org/doc/html/draft-ietf-cdni-uri-signing-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-uri-signing-12

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<http://tools.ietf.org/>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: Phil Sorber <[email-masked]>
Date: Sat, 15 Jul 2017 16:10:03 +0000

I created this PR to add that paragraph back. Can you guys comment?

https://github.com/PSUdaemon/URISigningSpec/pull/22

Thanks.

On Wed, Jul 5, 2017 at 11:24 PM Kent Leung (kleung) <[email-masked]>
wrote:

> *From:* CDNi [mailto:[email-masked]] *On Behalf Of *Ben
> Niven-Jenkins
> *Sent:* Tuesday, July 4, 2017 3:59 AM
> *To:* Phil Sorber <[email-masked]>
> *Cc:* [email-masked]
>
>
> *Subject:* Re: [CDNi] I-D Action: draft-ietf-cdni-uri-signing-12.txt
>
>
>
> I read the latest draft (-12) and below are some questions / thoughts, in
> no particular order, that occurred to me while reading the document.
>
>
>
> * Why support both symmetric & asymmetric keys? What is the advantage to
> having both options versus just picking one option (probably asymmetric
> keys as they work for all use cases)?
>
>
>
> KL> There are pros and cons of using either asymmetric keys vs symmetric
> key. Key distribution limitations and relationships between CSP and CDNs
> are factors. So I think supporting both allows flexibility for deployments
> of URI signing. Existing URI signing proprietary implementations typically
> support both already.
>
>
>
>
>
> * How are the keys distributed between CDNs? I don’t see a property in the
> UriSigning Metadata object that would include (or link to) the keys (I’m
> assuming you need to support distribution of at least 2 keys to support key
> rotation)?
>
>
>
> KL> Key distribution is out of scope. I noticed following text was dropped
> when method converted to JWT. We can put this back in CDNI Overview
> section, where the asymmetric and symmetric key methods are mentioned.
>
>
>
> * In the case of Signed Token chains, how does a CDN obtain the keys
> required to sign the new tokens in the chain as it generates them?
>
>
>
> KL> See above.
>
>
>
> Kent
>
>
>
>
>
> * Section 3.3.1 I think needs to be more explicit, I don’t know how one
> could communicate a token chain via the query string as specified in the
> document, as there is no “back channel” for the CDN to communicate the next
> token in the chain to the UA.
>
>
>
> HTH
>
> Ben
>
>
>
> Really hoping to get some feedback on this at the meeting in Prague. It's
> got all the changes that have been discussed so I'm not aware of any more
> substantive changes needed. However, lots of editorial nits I suspect.
>
> Thanks.
>
>
>
> On Sun, Jun 25, 2017 at 2:12 PM <[email-masked]> wrote:
>
>
> until the htmlized version and diff are available at tools.ietf.org.
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 18 Jul 2017 15:33:40 +0100

Hi Kent,

See inline

> On 5 Jul 2017, at 22:23, Kent Leung (kleung) <[email-masked]> wrote:
> From: CDNi [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Ben Niven-Jenkins

Apologies if I’m raking up discussions you’ve already had when writing the document. Can you expand on what factors justify having two different methods for signing URIs?

I am coming from the point of view that I can’t think of sufficient justification for having two methods. symmetric keys have the downside of requiring confidentiality. asymmetric keys do not suffer that issue. What is the downside of asymmetric keys that justifies using symmetric keys and tackling the issue of maintaining confidentiality?

In other words, why not just specify asymmetric keys and leave it at that?

I am also worried about interoperability because if you specify both symmetric & asymmetric keys I think it is far from guaranteed that all implementations will implement both variants and I’m yet to be convinced that we need to take that risk at all.

Ben

> On 25 Jun 2017, at 21:19, Phil Sorber <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 18 Jul 2017 15:34:52 +0100

Hi Phil,

I think the text is fine for the document as-is. Although see my response to Kent as I’m currently unconvinced we should try to specify both symmetric & asymmetric keys.

Regards
Ben

> On 15 Jul 2017, at 17:10, Phil Sorber <[email-masked]> wrote:
> 
> https://github.com/PSUdaemon/URISigningSpec/pull/22 <https://github.com/PSUdaemon/URISigningSpec/pull/22>
> 
> Thanks.
> 
> On Wed, Jul 5, 2017 at 11:24 PM Kent Leung (kleung) <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Ben. Thanks for your review comments.  See my response to some of them below. <>
>  
> 
>  
> 
>  
> 
> To: Phil Sorber <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
>

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 18 Jul 2017 21:37:52 +0000

Hi Ben. I’m trying to recall the rationale. I think initially, URI signing was based on the non-CDNI environment where both symmetric and asymmetric keys were supported and confidentiality was not an issue between CSP and CDN. The issue for symmetric key is encountered for key distribution between CSP/uCDN and dCDN. This concern has been documented:

  “In CDNI, there are two methods for request routing: DNS-based and
   HTTP-based.  For DNS-based request routing, the Signed URI (i.e.,
   Target CDN URI) provided by the CSP reaches the Downstream CDN
   directly.  In the case where the Downstream CDN does not have a trust
   relationship with the CSP, this means that only an asymmetric public/
   private key method can be used for computing the URI Signature
   because the CSP and Downstream CDN are not able to exchange symmetric
   shared secret keys.  Since the CSP is unlikely to have relationships
   with all the Downstream CDNs that are delegated to by the Upstream
   CDN, the CSP may choose to allow the Authoritative CDN to
   redistribute the shared key to a subset of their Downstream CDNs .”

  “Two types of keys can be used for URI Signing: asymmetric keys and
   symmetric keys.  …  With symmetric keys, the same key is
   used by both the signing entity for signing the URI as well as by the
   validating entity for validating the Signed URI.  …  Key distribution for
   symmetric keys requires confidentiality to prevent another party from
   getting access to the key, since it could then generate valid Signed
   URIs for unauthorized requests.”

  “With DNS-based request routing, URI Signing does not 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.  This raises a
   security concern for applicability of URI Signing with symmetric keys
   in case of DNS-based inter-CDN request routing.”

In light of keeping things simple and the path of least existence, I’m fine with defining only asymmetric key.

Maybe thoughts from Phil and Kevin and others?

Kent

From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Tuesday, July 18, 2017 4:34 PM
To: Kent Leung (kleung) <[email-masked]>
Cc: Phil Sorber <[email-masked]>; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-uri-signing-12.txt

Hi Kent,

See inline

On 5 Jul 2017, at 22:23, Kent Leung (kleung) <[email-masked]<mailto:[email-masked]>> wrote:
From: CDNi [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Tuesday, July 4, 2017 3:59 AM

Ben

KL> See above.

KL> See above.

Kent

HTH
Ben

Abstract:

---

From: "Kevin J. Ma" <[email-masked]>
Date: Tue, 18 Jul 2017 18:38:05 -0400

Hi Ben/Kent,

  (as an individual)  It's been my experience that symmetric keys have been more prevelant, historically; and I think we were originally trying to match existing schemes.  Since JWTs supported both symmetric and asymmetric, it was a freebie from that point of view.

  At this point, though, JWT has strayed sufficiently far from legacy implementations that I think we could probably define the scope for CDNI to be only asymmetric, if we wanted, without much resistance.

  I don't have any particular affinity for symmetric keys.  If the WG wants to drop them, it's ok with me.

thanx.

--  Kevin J. Ma

Sent from my iPhone

> On Jul 18, 2017, at 5:37 PM, Kent Leung (kleung) <[email-masked]> wrote:
>

---

From: Phil Sorber <[email-masked]>
Date: Wed, 19 Jul 2017 07:21:40 +0000

I agree with Kevin on the historic factor, and I think people are going to
want to have an option to do something that is comfortable. I also think
that we won't have to worry as much about implementations since most of the
heavy lifting will be done in a JOSE or JWT library. If you do it right,
you get both in one code path. I have a POC that I wrote to validate the
examples.

As far as having to deal with the confidentiality of secret keys, an
implementation will likely still have to deal with that if they include PII
such as client IP since that needs to be encrypted.

On Wed, Jul 19, 2017 at 12:38 AM Kevin J. Ma <[email-masked]>
wrote:

> Hi Ben/Kent,
>
>   (as an individual)  It's been my experience that symmetric keys have
> been more prevelant, historically; and I think we were originally trying to
> match existing schemes.  Since JWTs supported both symmetric and
> asymmetric, it was a freebie from that point of view.
>
>   At this point, though, JWT has strayed sufficiently far from legacy
> implementations that I think we could probably define the scope for CDNI to
> be only asymmetric, if we wanted, without much resistance.
>
> Hi Ben. I’m trying to recall the rationale. I think initially, URI signing
> was based on the non-CDNI environment where both symmetric and asymmetric
> keys were supported and confidentiality was not an issue between CSP and
> CDN. The issue for symmetric key is encountered for key distribution
> between CSP/uCDN and dCDN. This concern has been documented:
>
>
>
> *From:* Ben Niven-Jenkins [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Tuesday, July 18, 2017 4:34 PM
> *To:* Kent Leung (kleung) <[email-masked]>
> *Cc:* Phil Sorber <[email-masked]>; [email-masked]
> *From:* CDNi [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Ben Niven-Jenkins
>
> Apologies if I’m raking up discussions you’ve already had when writing the
> document. Can you expand on what factors justify having two different
> methods for signing URIs?
>
>
>
> I am coming from the point of view that I can’t think of sufficient
> justification for having two methods. symmetric keys have the downside of
> requiring confidentiality. asymmetric keys do not suffer that issue. What
> is the downside of asymmetric keys that justifies using symmetric keys and
> tackling the issue of maintaining confidentiality?
>
>
>
> I am also worried about interoperability because if you specify both
> symmetric & asymmetric keys I think it is far from guaranteed that all
> implementations will implement both variants and I’m yet to be convinced
> that we need to take that risk at all.
>
>
>
> Ben
>
>
>
>
>
>
>