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

From: Phil Sorber <[email-masked]>
Date: Mon, 7 Mar 2022 16:37:42 -0700

Ben,

Due to time constraints I just posted a new version without requesting your
review on the PR. I believe I addressed your DISCUSS comments as well as
several more of your COMMENTs.

I am going to also reply to your other email about a few of the COMMENTS I
did not address.

Thanks.

On Thu, Jan 6, 2022 at 3:20 PM Benjamin Kaduk <[email-masked]> wrote:

> Hi Phil,
>
> On Tue, Jan 04, 2022 at 05:38:39PM -0700, Phil Sorber wrote:
> > Thank you for your very thorough review. I apologize for not responding
> to
> > your email directly last time and only making updates. I admit I was a
> bit
> > overwhelmed with the volume of your comments and struggled to get a full
> > response out. This time I am going to start off by addressing your
> discuss
> > points only and addressing your comments later.
>
> I confess that sometimes I am overwhelmed when the reply comes back to me,
> and end up taking a week or two to be able to process it.
> Starting off with just the discuss points is a great plan. (inline)
>
> > On Tue, Jan 4, 2022 at 9:22 AM Benjamin Kaduk via Datatracker <
> > [email-masked]> wrote:
> >
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-cdni-uri-signing-24: 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/blog/handling-iesg-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:
> > > ----------------------------------------------------------------------
> > >
> > > Thanks for the updates in the -22 through -24.  I think a couple of my
> > > discuss points remain at the discuss level, which I'll expound on a bit
> > > more
> > > below.
> > >
> > > I am happy to see the pervasive disclaimers that use of a symmetric
> shared
> > > key is supported but NOT RECOMMENDED, and the note that redistribution
> of
> > > the symmetric shared key to dCDNs (including cascaded CDNs) is
> included for
> > > legacy feature parity and highly discouraged in new implementations.
> > > However, I think this does not fully address my original discuss
> point.  As
> > > I said then, [[I see a minimal acknowledgment that there is potential
> cause
> > > concern in the penultimate paragraph of the security considerations
> that
> > > "it
> > > is important to know the implications of a compromised shared key",
> but in
> > > my mind the text there does not really call out the severity of those
> > > implications.  I would have expected something like "redistributing the
> > > shared key in this manner allows the dCDNs to impersonate the CSP to
> the
> > > uCDN and produce arbitrary signed URLs that are accepted by the uCDN as
> > > authentic".]]  In particular, I think it is important to emphasize in
> some
> > > manner that the cryptographc properties of the symmetric shared key are
> > > fully symmetric across all participants, even though the
> administrative and
> > > organizational structure here is hierarchical with explicitly more- and
> > > less-trusted entities, making the symmetric cryptographic mechanism a
> > > mismatch for the desired trust boundaries and inviting abuse.  Only
> > > contractual controls prevent misuse in this scenario, whereas we have
> > > well-understood technologies that allow technical measures to prevent
> > > misuse
> > > that are preferred.
> > >
> >
> > Thank you. I was trying to come up with some clear wording based on your
> > original comment, but could not. I do however like the extra text you
> have
> > added and will incorporate some form of that:
> > "the cryptographic properties of the symmetric shared key are
> > fully symmetric across all participants, even though the administrative
> and
> > organizational structure here is hierarchical with explicitly more- and
> > less-trusted entities, making the symmetric cryptographic mechanism a
> > mismatch for the desired trust boundaries and inviting abuse.  Only
> > contractual controls prevent misuse in this scenario, whereas we have
> > well-understood technologies that allow technical measures to prevent
> misuse
> > that are preferred."
>
> Feel free to chop up, rearrange, rewrite, or do what you want with that
> text, if it helps.
>
> >
> > >
> > > It's also still unclear to me that there's sufficient need to document
> the
> > > symmetric key *redistribution* case in this document at all, if the
> only
> > > use
> > > case is for "legacy feature parity".  Given that it's a fairly simple
> idea,
> > > what is to stop us from leaving it undocumented in this Proposed
> Standard
> > > and letting any implementors that need it do so on their own, or with a
> > > separate Informational document mentioning its existence?  I am not
> aware
> > > of
> > > any preexisting IETF work that we need to retain compatibility with,
> and
> > > the
> > > data presented so far does not make a compelling (to me) case that we
> must
> > > include this functionality in order for the IETF offering to be
> > > competitive.
> > > (To be clear, I do not object to describing the use of symmetric keys
> for a
> > > single-hop scenario, as the risks there are much smaller.)
> > >
> >
> > We discussed this at our last meeting and then on the mailing list
> > afterward.
> >
> > https://mailarchive.ietf.org/arch/msg/cdni/sDsFQnZqT0r7SOYTKu21CgPOwA8/
> >
> > There was slightly more discussion in the meeting versus the mailing list
> > on this point. In fact, in the meeting it seemed we had agreed to remove
> > it, but then on the mailing list the feedback was marginally to keep it.
> >
> > https://www.youtube.com/watch?v=0kwerjqOZ6I&t=2059s
> >
> > I think the problem is just the realities of who is going to implement
> > this. I don't think someone wants to deduce how to get a feature they
> deem
> > necessary into their implementation, especially when someone else is
> > already providing them one that has it, albeit not standards compliant.
> So
> > the hope here is that we lower the bar to adoption and hope that as
> > interoperation grows people implement the asymmetric key model. Maybe
> that
> > is a naive approach. I definitely think it was not a cut and dry
> conclusion
> > to come to.
> >
> > However, you do propose a scenario which I do not think we considered,
> > which is to keep shared key for the "single-hop" case, but remove the
> idea
> > of shared key distribution. I do not think that even current proprietary
> > implementations support the distribution aspect of it either. Let me
> > confirm this and if the WG is amenable to it, I will make that change.
>
> Oh!  I am sorry to have not been more clear previously -- my strenuous
> objection is solely to the aspect where the same key is shared by CSP,
> uCDN, and dCDN (or analogous uCDN/middle-CDN/dCDN cases).  In that scenario
> the uCDN is at risk of having a compromised or malicious dCDN pretend to be
> the CSP, and the relationship between uCDN and CSP is vastly different than
> its relationship with dCDN, so the potential "privilege escalation" for the
> dCDN is huge.
>
> Using a symmetric key just between CSP and uCDN, or uCDN and dCDN, is still
> not the best choice, but (as you note) it's widely deployed and the risks
> are much more manageable.  In particular, with only the "two-party" case,
> the harm from compromise of one party is mostly limited to affecting that
> same party, as opposed to the situation I mentioned earlier where dCDN
> compromise causes harm to the CSP (in that the uCDN thinks something came
> from the CSP but actually it did not).
>
> If we can get WG agreement to just remove the shared-key redistribution
> aspect, that seems like a very workable resolution.
>
> >
> > >
> > > I'd also like to have some additional discussion on this point from my
> > > previous Discuss position, reproduced with typo fixed:
> > > ===
> > > The combined defaults for the CDNI Metadata Interface for URI Signing
> seem
> > > to be an unsafe combination.  Specifically, the default behavior for
> the
> > > "issuers" property is to allow any Issuer, and the default for the
> > > "jwt-header" property is to take the header from the JWT in band.  As
> far
> > > as
> > > I can tell, this means that the dCDN will just blindly accept anything
> that
> > > is formatted as a JWT and signed by any key known to the dCDN.  The
> > > authentication and authorization properties of such behavior are so
> poor so
> > > as to effectively be useless, absent some level of care surrounding key
> > > management to isolate keys to given URIs.  In fact, the lack of
> substantive
> > > discussion of key management and requirements thereof seems
> Discuss-worthy
> > > in its own right.  We need to say something about obtaining a key along
> > > with
> > > a trust path to what it's authorized to be used for, even if the
> specific
> > > protocol mechanism for doing so is left out of scope.
> > > ===
> > > I do see that §1.3 gained a mention of "obtain the key in a manner that
> > > allows trust to be placed in the assertions made using that key",
> > > apparently
> > > per my suggestion in my original COMMENT section.  However, I don't
> think
> > > this is sufficient.  I strongly encourage a dedicated section on the
> > > requirements for key management and how updates (both additions and
> > > removals) of the list of trusted Issuer/key pairs are managed.  Failing
> > > that, at a minimum the default for the "issuers" property in the CDNI
> > > Metadata Interface needs to be changed to say that an empty list means
> that
> > > any Issuer in the dCDN's trusted key store of issuers is acceptable for
> > > signing JWTs for URI signing.  This is to be contrasted with "any
> Issuer at
> > > all", which does not impose an obligation on the dCDN to maintain a
> list of
> > > Issuer/key pairs trusted for signing JWTs used in signed URIs.
> > >
> >
> > I will create a github PR with some proposed changes for this and get
> your
> > feedback on it. I feel like I understand and agree with your statement,
> but
> > I am failing to change the text to the level you feel it needs to be at.
>
> Okay, that sounds good.  Feel free to tag me in (@kaduk), though I get a
> lot of github notifications, so I might not see it right away.
>
> Thanks,
>
> Ben
>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 20 Mar 2022 13:27:50 -0700

Hi Phil,

On Mon, Mar 07, 2022 at 04:52:03PM -0700, Phil Sorber wrote:
> Adding a few responses below. Anything I haven't addressed or commented on
> doesn't mean I intentionally ignored, merely insufficient mental bandwidth
> on my part. If you think some important things are still missing, please
> let's revisit.

Thanks for the additional replies with history/context.
On a quick look, I don't see anything remaining that's sufficiently
important to reopen (I am also a bit pressed for time as I try to finish up
as much as possible before my term as AD ends on Wednesday).

I do still have some questions about the (discuss point) symmetric key
redistribution topic, but for discoverability I'll do that as an updated
ballot position.  I will be brief, this time :)

-Ben