Subject: [CDNi] Benjamin Kaduk's Discuss on draft-ietf-cdni-uri-signing-25: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Sun, 20 Mar 2022 13:29:03 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-cdni-uri-signing-25: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle 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:
----------------------------------------------------------------------

I see that the -25 has demoted discussion of symmetric key redistribution
from (paraphrasing) "a normal thing mentioned in passing" to a SHOULD NOT
action.  This is a step in the right direction, but I am not sure that
it's far enough.  Is there some additional background on why this
functionality (of key redistribution from uCDN to dCDN in particular, or
group sharing of a single symmetric key from CSP to both uCDN and dCDN) is
required to retain that I am failing to find?  The latest discussion I see
in the WG email archives is
https://mailarchive.ietf.org/arch/msg/cdni/iFP6w3z22yQ1s0IJisrsIJN1ikU/
which seemed to suggest that the mechanism would be removed entirely.
The security properties of this group key sharing are sufficiently poor
that (if we do need to keep it) I think there would need to be explicit
discussion in the document about what the use case is and why that use
case allows for the weakening of security properties.

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

Thank you for lowering the prominence of the cdniip claim/functionality,
it is much appreciated.

Thank you as well for updating the examples; I am too crunched for time to
attempt to revalidate them before the AD cutover, but am happy to see
that they were updated.

I also appreciate the additional text covering the JWT "iss" usage and
reinforcing that a key used to sign JWTs (regardless of whether it is
identified using "iss") must be delivered in trusted configuration (i.e.,
not in-band).  I would have preferred to see this point reiterated in the
Security Considerations, as much of the new text is in the description of
the usage of the "iss" claim (which one might expect to be irrelevant if
the claim itself is not being used), but that is no longer a Discuss-level
point based on the updates elsewhere in the document.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 22 Mar 2022 10:13:15 -0700

Hi Phil,

Recall that per RFC 2119 the semantics of a "SHOULD" (or "SHOULD NOT") is
only that "there may exist valid reasons in particular circumstances to
ignore a particular item", which is in some sense rather like a "MUST
(except when...)".  This particular scenario is one where I must insist
that we convey a clear sense of what those particular circumstances and
reasons might be, if we are to allow the item to be ignored at all.  If we
can't identify the circumstances and reasons, it really ought to just be a
"MUST NOT".  I think that the security risks are too large to leave an
open-ended opt-out available.  (In particular, that the architecture would
set things up so that the compromise of an entity the CSP does not even
know it's related to would cause the entire security properties of the
mechanism the CSP is using to fail.)  I recognize that there are no
protocol police to enforce it, but I still think that is the guidance we
should be giving.

-Ben

On Sun, Mar 20, 2022 at 03:47:44PM -0600, Phil Sorber wrote:
> So I struggled with what to do here, because I felt like ignoring the case
> was the wrong approach. If we didn't explicitly call it out, someone could
> potentially rediscover this on their own and think it's a clever method and
> want to implement it. So I felt that mentioning it as a bad option because
> it is insecure was warranted. I also heavily considered MUST NOT instead of
> SHOULD NOT. I just felt like telling implementers MUST NOT about something
> that would not make the implementation incompatible seemed too far, but
> please convince me otherwise. I am open to hearing how my logic is flawed,
> or my understanding of the MUST NOT/SHOULD NOT dichotomy is wrong. I just
> want a sound argument to make when challenged on it. I was jokingly pointed
> to RFC6919 and wished there actually was a REALLY SHOULD NOT.
> 
> On Sun, Mar 20, 2022 at 2:29 PM Benjamin Kaduk via Datatracker <
> [email-masked]> wrote:
> 
> > Please refer to
> > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> > _______________________________________________
> > CDNi mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/cdni
> >