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

Phil Sorber <sorber@apache.org> Thu, 25 February 2021 06:22 UTC

Return-Path: <sorber@apache.org>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E04B3A13D6 for <cdni@ietfa.amsl.com>; Wed, 24 Feb 2021 22:22:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.897
X-Spam-Level:
X-Spam-Status: No, score=-9.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1Rpe6dQRf5m for <cdni@ietfa.amsl.com>; Wed, 24 Feb 2021 22:22:50 -0800 (PST)
Received: from mxout1-ec2-va.apache.org (mxout1-ec2-va.apache.org [3.227.148.255]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F103A13D3 for <cdni@ietf.org>; Wed, 24 Feb 2021 22:22:50 -0800 (PST)
Received: from mail.apache.org (mailroute1-lw-us.apache.org [207.244.88.153]) by mxout1-ec2-va.apache.org (ASF Mail Server at mxout1-ec2-va.apache.org) with SMTP id 7DBEB43049 for <cdni@ietf.org>; Thu, 25 Feb 2021 06:06:21 +0000 (UTC)
Received: (qmail 51569 invoked by uid 99); 25 Feb 2021 06:06:21 -0000
Received: from mailrelay1-he-de.apache.org (HELO mailrelay1-he-de.apache.org) (116.203.21.61) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Feb 2021 06:06:21 +0000
Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) by mailrelay1-he-de.apache.org (ASF Mail Server at mailrelay1-he-de.apache.org) with ESMTPSA id 3AED03E824; Thu, 25 Feb 2021 06:06:20 +0000 (UTC)
Received: by mail-oi1-f176.google.com with SMTP id d20so5027409oiw.10; Wed, 24 Feb 2021 22:06:20 -0800 (PST)
X-Gm-Message-State: AOAM5312MOXr7HxvbmLSIQCgfzv6M5fPBkVWoc4BLjNWS7fsXWbSD3+K 7TaHzLVK7T5iFgMAx9eBV02uaVafLuVdEHUeMV8=
X-Google-Smtp-Source: ABdhPJxCGdr4m0ih9S13wzVZRLyRzhNXkyiUPvGRmYf7BdmUKc81kS5a3Fn/XKGQHhkTEe2r7reSn/Vu94K08Vg+wgA=
X-Received: by 2002:a54:440c:: with SMTP id k12mr936876oiw.147.1614233179041; Wed, 24 Feb 2021 22:06:19 -0800 (PST)
MIME-Version: 1.0
References: <161413206910.24324.24815121496705778@ietfa.amsl.com>
In-Reply-To: <161413206910.24324.24815121496705778@ietfa.amsl.com>
From: Phil Sorber <sorber@apache.org>
Date: Wed, 24 Feb 2021 23:06:07 -0700
X-Gmail-Original-Message-ID: <CABF6JR1MVuYTQ68KSSX+=Z-=fYJ0dm63sfBOHF0HTEvuiO6OAw@mail.gmail.com>
Message-ID: <CABF6JR1MVuYTQ68KSSX+=Z-=fYJ0dm63sfBOHF0HTEvuiO6OAw@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-cdni-uri-signing@ietf.org, "<cdni@ietf.org>" <cdni@ietf.org>, Kevin Ma J <kevin.j.ma@ericsson.com>, cdni-chairs@ietf.org
Content-Type: multipart/alternative; boundary="00000000000038b70505bc22f33e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cdni/3H_ILY_hqBduWbvQidTSAFYKfHg>
Subject: Re: [CDNi] Roman Danyliw's Discuss on draft-ietf-cdni-uri-signing-21: (with DISCUSS and COMMENT)
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cdni/>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Feb 2021 06:22:53 -0000

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 <
noreply@ietf.org> 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.


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


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


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


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


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


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


>
> ** Nits
>

I will address all of these.


> -- 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
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni
>