Skip to main content

Shepherd writeup
draft-ietf-cdni-uri-signing

Document Shepherd: Kevin J. Ma

Responsible AB: Barry Leiba

This document defines a standard for URI signing to enable interoperability
between interconnected CDNs.  We are requesting publication as "Proposed
Standard" as we feel it has been extensively reviewed and vetted by the WG. 
The draft has undergone significant rewrite multiple times as a result of the
reviews and implementations.  There are commercial implementations, as well as
interest and review by other SDOs (e.g., the Streaming Video Alliance and the
MPEG WG, see https://datatracker.ietf.org/liaison/1413/).  During the most
recent rewrite, over the course of many IETFs, the authors, interested parties,
and WG discussed all aspects of the switch to JWT.  In the more recent
revisions, non-editorial changes were primarily the result of implementation
findings.  At this point, the WG feels that the document is mature and complete.

The document originally went to WGLC in July 2016.  In an pre-sec-dir review,
Matt Miller had "reinventing the wheel" (more specifically, reinventing crypto
wheels by non-security folks) concerns (see
https://mailarchive.ietf.org/arch/msg/cdni/3xTSo1OzQyFf6ky8gj8kMxPTU1Q/).  At
that time, it was decided to rewrite the draft to rely on JWT for the security
aspects.  This greatly simplified the security aspects of the draft to
specifying just the JWT claims needed to implement the CDNI security policies.

There are known security limitations with URI signing, and they are documented
in the Introduction and Security Considerations sections.  If used responsibly
for its intended purpose, URI signing serves a specific function providing
basic access control, useful in protecting the CDN itself (though not
necessarily the content being served by the CDN).  Though these limitations are
often misunderstood by or misrepresented to content owners, URI signing is
widely used for its intended (stated) purpose by network operators.  Because of
this wide use, the WG feels that standardizing URI signing is important for
interoperability.

As Matt Miller was deeply involved in the rewrite, the WG feels that the
security aspects should be well vetted at this point.

The other major change since the original WGLC was the inclusion of Token
Renewal for HTTP Addaptive Streaming (HAS).  Originally, the WG decided to
avoid HAS in all WG documents, because we could not come to a concensus on how
to address it, and there was concern that a lot of IPR would be implicated. 
For URI signing, an IPR disclosure was made on HAS related conten (see
https://datatracker.ietf.org/ipr/2603/), and the WG decided to split out the
IPR encumbered portion at IETF-93 (see
https://tools.ietf.org/wg/cdni/minutes?item=minutes-93-cdni.html).  The IPR
disclosure was subsequently updated (see
https://datatracker.ietf.org/ipr/2806/) removing the royalties and the WG
decided to re-incorporate the IPR encumbered portion at IETF-96 (see
https://tools.ietf.org/wg/cdni/minutes?item=minutes-96-cdni.html).

Because HAS has become such a significant portion of CDN traffic, the WG felt
that HAS support was important to include and the updated IPR terms were deemed
acceptable.

The authors have confirmed that there is no other known undisclosed IPR related
to the contents of this document.

There are no downward references in the document, and I agree with the
normative vs informative reference designations.  I suppose it could be argued
that the CDNI problem statement and requirements documents are normative to URI
Signing's purpose, but they don't really affect the protocol specifics so they
are listed as informative.  Similarly, the reference to the CDNI Request
Routing interface, only used to say that there is no dependency on the CDNI
Request Routing interface also seems fine as non-normative.

This document registers a new CDNI Payload Type in our IANA registry, for the
purpose of identifying URI Signing CDNI Metadata and advertising URI Signing
CDNI Capabilities.  This is inline with the intended purpose of the registry. 
I am the creator of and one of the two expert reviewers for that registry and
approve of this registration.

This document registers a new CDNI Logging Record Type and two associated CDNI
Logging Field Names.  These registrations are inline with the intended
extensibility design of CDNI Logging.  I am  one of the two expert reviewers
for these registries and approve of this registration.

This document registers seven new claims in the JSON Web Token Claims registry.
 The authors have discussed the registrations with Brian Campbell, one of the
Expert reviewers for the JSON Web Token Claims registry, and he approved of the
registrations.

This document creates two new IANA registries: the CDNI URI Signing
Verification Code registry and the CDNI URI Signing Signed Token Transport
registry.  Both registries are defined as Specification Required.  Phil Sorber
and I volunteer to be expert reviewers for both registries.

The CDNI URI Signing Verification Code registry is for registering error codes
reported in CDNI logs.  URI Signing allows for extension claims to be defined
in the future.  The error codes correspond one-to-one with claims.  Though
future extensions would likely be defined in RFCs, and new error codes could be
defined in those RFCs, a registry seemed like a better way to prevent
overlapping or duplicate error codes.

The CDNI URI Signing Signed Token Transport registry is for registering valid
values for the CDNI Signed Token Transport claim.  There are only two values
initially defined: none and cookie.  The intent of the registry is to allow for
future extensibility.  Though cookies were the proposed implementation for HAS
support, the WG did not wanted to assume cookies would always be the best
solution.

Back