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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 23 Feb 2021 18:01:09 -0800

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/

---

From: Phil Sorber <[email-masked]>
Date: Wed, 24 Feb 2021 23:06:07 -0700

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

> https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/

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.

> will mix both asymmetric and symmetric keys?  Assuming that’s possible

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.

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

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.

> identity in an interoperable way for CDNI?  In OAuth, the answer was

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.

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

> ** Section 2.2.  Per “The header value must be transmitted …”, should this

Yes, I agree. I will fix this.

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

> like this should also be reiterated in the security considerations

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?

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

> ** Nits

I will address all of these.

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

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 25 Feb 2021 16:38:35 +0000

Hi Phil!

Thanks for the detailed reply.  More inline …

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

On Tue, Feb 23, 2021 at 7:01 PM Roman Danyliw via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-cdni-uri-signing-21: Discuss

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.

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.

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.

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.

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.

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.

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.

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.

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

[Roman] Thanks.

Regards,
Roman

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