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

[Benjamin Kaduk <[e-mail]>]

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 <
> [e-mail]> 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