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

["Kevin J. Ma" <[e-mail]>]

Hi Mike,

  We really appreciate the early review, insightful suggestions, and offer to help!

SubCerts draft authors,

  Please consider Mike's suggestions below.  Once addressed, we should be ready to submit the draft.

thanx!

--  Kevin and Sanjay

Sent from my iPhone

> On Sep 6, 2023, at 10:51 PM, Mike Ounsworth via Datatracker <[e-mail]> wrote:
> 
> 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.
> 
>