Subject: [CDNi] URI Signing for CDNI Working Group Draft

From: Daryl Malas <[email-masked]>
Date: Thu, 6 Mar 2014 15:34:43 +0000

All,

During today’s working group meeting, we agreed the latest draft revision of this draft (http://tools.ietf.org/html/draft-leung-cdni-uri-signing-05) is substantial for us to adopt it as a working group item.  However, Francois and I did not feel comfortable conducting a “Hum,” since there were not a lot of people present who had read the draft.  This draft was proposed in response to the following charter item:

A specification for "CDNI URI Signing". This document will specify a
mechanism that allows interconnected CDNs to support access control
by signing content URIs. This may involve extensions to the CDNI
interfaces (e.g. CDNI Metadata interface, CDNI Logging interface).

In addition, the working group has the following milestone:

Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Proposed Standard

With this in mind, we are requesting people read the draft in preparation for this draft to be accepted as a working group item, which will occur on March 21st.  If anyone has any major concerns with this, please post comments and concerns to the list.

Regards,

Daryl & Francois

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 6 Mar 2014 10:46:13 -0500

Daryl,

  As one of the few non-authors in the room that had read the draft, I'll
 just throw out my hum for adoption.  The latest version is in pretty good
  shape.  Last week I sent comments to the list on the current version and
 have discussed them with the authors this week.  Assuming those comments
  get addressed I think draft-leung is a good basis for the wg draft.

--  Kevin J. Ma

From: CDNi [mailto:[email-masked]] On Behalf Of Daryl Malas
Sent: Thursday, March 06, 2014 10:35 AM
To: [email-masked]
Subject: [CDNi] URI Signing for CDNI Working Group Draft

All,

During today's working group meeting, we agreed the latest draft revision of this draft (http://tools.ietf.org/html/draft-leung-cdni-uri-signing-05) is substantial for us to adopt it as a working group item.  However, Francois and I did not feel comfortable conducting a "Hum," since there were not a lot of people present who had read the draft.  This draft was proposed in response to the following charter item:

Regards,

Daryl & Francois

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 25 Mar 2014 11:03:18 +0000

Daryl, Authors,

I gave the draft a quick read. It seems a reasonable starting point.

While I was reading the draft I noticed a couple of things in it that I think are worth raising:

1) In section 2 the draft says "Any attributes appended in such way after the URI Signature has been calculated are not validated for the purpose of content access authorization."

If additional query parameters can be appended to the URI which are not validated, could a UA obtain content that it isn't authorised to obtain by adding additional query parameters? It seems like something that could be worth discussing in the security considerations section?

2) Section 2.2 allows the KeyID to be included in the Signed URI. This also seems like it might open a security hole as a malicious UA could strip the original URISigningPackage attribute, sign the URI with a Key under its control (possibly altering other things like the actual URI or expiry time) and include the appropriate KeyID for that new Key in the new URISigningPackage.

Is there a use case for signalling the KeyID within the Signed URI itself?

3) Regarding hash functions & digital signature algorithms, the draft hints at allowing several options for each and defines a default in case a particular algorithm is not specified in the URISigningPackage.

This seems a bit overkill to me. To aid inter-operability, I think it would be better to specify a single algorithm for each unless there are use cases for requiring support for more than one algorithm in the first version defined in the draft?

Regards
Ben

On 6 Mar 2014, at 15:34, Daryl Malas wrote:

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

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 25 Mar 2014 14:00:40 +0000

> This seems a bit overkill to me. To aid inter-operability, I think it would be better to specify a single algorithm for each unless there are use cases for requiring support for more than one algor…

For interoperability, we’d want to specify one "Mandatory to Implement” algorithm for each. On top of that, if useful,  additional algorithms can be allowed without compromising interoperability.

Francois

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 25 Mar 2014 15:52:52 +0000

Francois,

> For interoperability, we’d want to specify one "Mandatory to Implement” algorithm for each. On top of that, if useful,  additional algorithms can be allowed without compromising interoperability.

Fair point. What I'm suggesting is we pick one for interoperability (mandatory to implement) and unless anyone can show a use case for having more than one at this time, we just stick with that single mandatory to implement algorithm until such time as a use case requiring a different algorithm appears.

Ben