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

[Roman Danyliw <[e-mail]>]

Hi Phil!

Thanks for the detailed reply.  More inline …

From: Phil Sorber <[e-mail]>
Sent: Thursday, February 25, 2021 1:06 AM
To: Roman Danyliw <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; <[e-mail]> <[e-mail]>; Kevin Ma J <[e-mail]>; [e-mail]
Subject: Re: [CDNi] Roman Danyliw's Discuss on draft-ietf-cdni-uri-signing-21: (with DISCUSS and COMMENT)

Thank you for this thorough review. I have added my responses below.

On Tue, Feb 23, 2021 at 7:01 PM Roman Danyliw via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
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?

The main goal here is to not allow HTTPS to HTTP conversion. I think it was written in a generic manner to allow for the possibility of some other case in the future, but I don't see a reason why we couldn't be more explicit.


-- 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?

It wasn't meant to differentiate between the JWT signing keys. This was about the URI itself. One might argue that this could apply to the TLS cert and it's relative strength, but I don't think this document is in a place to make that distinction.

[Roman] Understood.  I didn’t realize you were distinguishing only between HTTP vs. HTTPs as the lower vs. higher security levels.  As suggested by my second sub-question, I read this text as trying to make an assessment relative to the crypto chosen.  It would be helpful if you could add a clarifying statement to the effect of your answer above.


** 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.

I think you are correct in your reading, but what I would counter with is that the intent of the jti claim is to prevent reuse. That is the same way the ID is using it. I think the scope of the use is what we disagree about. I discussed this with the designated expert who did the review for our custom claims for the registry (Brian Campbell), and he agreed that our usage was within the spirit of RFC 7519.

[Roman] Let me double check the references and I’ll get back to you.



----------------------------------------------------------------------
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.

There were once mandatory claims, but after discussion it was decided to make them all optional in the first version for brevity. I could remove these all and make one comment about it at the top of the section, but I have always felt that it seemed right to have that indicator on each item just to be extra explicit. In the future we may have a mandatory field, for example cdniv.

[Roman]  No problem to leave it in.  I wasn’t sure if I was missing later in the text.


** 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.

There is no section 2.3. If perhaps you meant 2.1.3, the idea here is that it would be negotiated outside of this path. We didn't find it important enough to include in the CDNI Metadata, but if a CSP or uCDN wanted to add this, they would have to exchange that value out of band.


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

I don't have a good answer for this. It should be large enough that collisions are minimized, yet not so large that we are needlessly adding to the size of the Signed JWT.

[Roman] It might be worth saying that the sizing is application dependent given the desired security constraints.


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

Yes, I agree. I will fix this.


** 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?

It looks like we are missing a value in section 6.5. I will update this. There is also text in section 3.3 that needs to be removed.

[Roman] Thanks for reaching out to the IANA review to address this.


** 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.

I can add that stronger normative language. We do mention some pitfalls of shared keys already in the security considerations section. Do you believe more is warranted?

[Roman] I was just thinking to repeat the “NOT RECOMMENDED” guidance in the SecCons so all of this is in one place.


** 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?

This is a great question. This text is from the original pre WG adopted version of the doc. It feels like it was meant to be filled in more later but never was. Let me see if I can come up with better text for this part.

[Roman] Much appreciated.  IMO, if you have better text on those operational practices that’s the best outcome.  If there isn’t anything that can be generically specified here, I would recommend just providing caution that this about how low of a bar this fingerprinting might be to overcome for an illegitimate client.


** Nits

I will address all of these.

[Roman] Thanks.

Regards,
Roman

-- 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/



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