[CDNi] Roman Danyliw's Discuss on draft-ietf-cdni-uri-signing-21: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-cdni-uri-signing-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 1.3.  Per “Note that the signed Redirection URI MUST maintain the
same (or higher) level of security as the original Signed URI.”:

-- How is this equivalence assessed?

-- Can one create an architecture to that cascades a mix of uCDNs whose path
will mix both asymmetric and symmetric keys?  Assuming that’s possible what’s
“same or higher” here?

** Section 2.1.7.  The specified use of the jti claim in the URI signing
workflow appears to conflict with the underlying definition of this claim in
RFC7519.

(a) Section 1.3. says “… the CSP needs to allow the uCDN to redistribute shared
keys to a subset of their dCDNs.”

(b) Section 2.1.7 says “If the received signed JWT contains a Nonce claim, then
any JWT subsequently generated for CDNI redirection MUST also contain a Nonce
claim, and the Nonce value MUST be the same as in the received signed JWT.”

(c.1) Section 4.1.7 of RFC7519 says “The identifier value MUST be assigned in a
manner that ensures that there is a negligible probability that the same value
will be accidentally assigned to a different data object …

(c.2) Section 4.1.7 of RFC7519 also says “… if the application uses multiple
issuers, collisions MUST be prevented among values produced by different
issuers as well.”

The constraints in (b) suggests that the Nonce claim value needs to be the same
across every logical hop in the cascading CDN path.  My understanding of the
architecture is that some of the claims in the JWTs such as the cdniuc or
cdnistd claims might changes when there are cascading CDNs.  If they change,
this seems like that would constitute a different “data object” who have the
same unique (jti claim) identifier which would violate (c.1).  One could argue
that perhaps the CDNs are at arm-length so they aren’t really an “application
us[ing] multiple issuers”, however, the architectural construct of shared keys
suggested by (a) seems to imply otherwise which would suggest that this
violated (c.2).  If I’ve misunderstood the architecture let me know.

The notion of keeping the nonce the same seems like the right design, its just
the reuse of this particular claim seems mismatched.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Éric Vyncke DISCUSS position.

** Section 2.1.  Per “(The "optional" and "mandatory" identifiers in square
brackets refer to whether or not a given claim MUST be present in a URI Signing
JWT.)”, this guidance is clear, but I don’t see any “[mandatory]” claims.

** Section 2.3.  Is there any specific guidance on how to construct this
identity in an interoperable way for CDNI?  In OAuth, the answer was largely no.

** Section 2.1.7.  Given the CDNI use case and expected lifetime of the JWTs,
are there any recommendations on nonce size?

** Section 2.2.  Per “The header value must be transmitted …”, should this be a
normative MUST?

** Section 3.3.1.  Per the text around supporting cross-domain redirection of
signed token renewal, the guidance is that “[i]n such scenarios, Signed Token
Renewal of a signed JWT SHOULD be communicated via the query string instead …”
and not via the 'URISigningPackage' cookie as specified in Section 3.3.  Since
Section 3.2.1 noted that cdnistt MUST be included, what value should be set for
a JWT passed in the query string?

** Section 5.2.  Per “This raises a security concern for applicability of URI
Signing with symmetric keys in case of DNS-based inter-CDN request routing”,
this caution seems appropriate.  Is there is a reason that stronger normative
language such as “this architecture is NOT RECOMMENDED” is not used?  It seems
like this should also be reiterated in the security considerations sections.

** Section 7.  Per “One way to reduce exposure to this kind of attack is to not
only check for Client IP but also for other attributes, e.g., attributes that
can be found in HTTP headers”, can you say more on how this fingerprinting
should be operationalized?  Knowing the application in question, couldn’t the 
illegitimate clients also reproduce these headers?

** Nits
-- Section 2.1.3.  Typo. s/verifing/verifying/

-- Section 2.1.15.  Typo. s/definined/defined/

-- Section 3.2.1. Editorial.  The voice in this section changed to “you may …”
as a opposite to a third person used elsewhere.

-- Section 4.3.  Typo. s/has has/has/

-- Section 6.4.  Typo. s/Extention/Extension/