[CDNi] Secdir early review of draft-ietf-cdni-https-delegation-subcerts-04

[Mike Ounsworth via Datatracker <[e-mail]>]

Reviewer: Mike Ounsworth
Review result: Not Ready

Hi CNDI chairs and authors.

I am performing a SecDir early review as requested by the CDNI chairs.
I will focus this review on the question you asked about transporting private
keys as-per Section 4. I'm happy to stay on as SecDir reviewer for this draft
and give it a more thorough security review when you are ready (TLS
certificates are kinda my thing).

I applaud you for submitting this for early security review. I agree with your
feeling that that this feels dangerous; you're setting up a way to
bulk-transfer TLS certificate private keys (specifically RFC 9345
delegated_credentials) between CDN providers over a weakly-protected channel.
If this goes wrong, it's gonna go catastrophically wrong. Like, all it would
take is for these CDNI Metadata objects to be logged in transit, an
unscrupulous person to have access to those logs, and now they have TLS certs
and private keys for potentially thousands of domains. I think this needs more
thought.

I would suggest to explore the following two solution spaces:

1)
Section 4 mentions: "If not specified, it is assumed that the dCDN generated
the public-private key pair for the delegated credential itself and provided
the public key information with an out-of-band mechanism to the uCDN." It would
be worth exploring this deeper and actually specifying how this should work.
Effectively that would mean that the uCDN acts as a Certification Authority for
the dCDN. The IETF has many certificate enrollment protocols to choose from.
This would be the strongest option since the dCDN could generate the private
keys in their key management solution and the private keys never need to
traverse any software layers at all.

2)
Leave the private key transport as it is, but encrypt it using a base64
envelope format such as PKCS8/PEM or JOSE/JWE. This would require the uCDN and
dCDN to have pre-established encryption keys as part of establishing their
relationship -- likely the dCDN generates an asymmetric key pair and shares the
public key to the uCDN. This at least obscures the private keys from passive
attacks such as traffic logging, but it still requires the private keys to
exist decrypted in software memory at some stage, so is not as strong as option
1.

I'm happy to work with you off-list.