Re: [CDNi] FW: New Version Notification for draft-fieau-interfaces-https-delegation-subcerts-01.txt

Hi Christoph,

  Adding a new interface to CDNI is definitely out of scope of the current
charter, and I'm not sure that it really makes sense as part of CDNI.  It
would be a fairly basic req/resp, so from that perspective, I understand
why the proposal went with metadata as opposed to an interface.

  The FCI proposal for advertising how many certs are required is
interesting.  My one concern (other than security) would be about the
load.  How often does the required number of subcerts change, and how often
do the subcerts themselves change and need to be re-retrieved?

  I think that if an existing interface was already specified for
retrieving the subcert data, having the metadata convey just a pointer to
that interface would be much cleaner.  But, the metadata is expected to be
somewhat ephemeral, so I guess there isn't a reason the data couldn't be
represented/conveyed as metadata.  My primary concern is still the fact
that key material is being passed, and that potentially opens up a can of
worms from a security perspective.

  I think the discussion of these design choices could certainly be done as
part of a working group document.  We can try to get a secdir opinion.

  Are you leaning in a particular direction?

thanx!

--  Kevin J. Ma

On Tue, Feb 15, 2022 at 12:12 PM Christoph Neumann <
Christoph.Neumann@broadpeak.tv> wrote:

> Hi Kevin,
>
>
>
> Thanks for your comments.
>
>
>
> MI.DelegatedCredentials may or may not be part of the Metadata Interface
> (MI) described in RFC8006 (In theory, it should not part of it, I agree
> with you here, at least as it is in the current proposal) but it should be
> somehow part of CDNi .
>
>
>
> The way to retrieve MI.DelegatedCredentials as defined in the proposal is
> a bit particular. As only the dCDN knows how many delegated credentials
> (MI.DelegatedCredentials) it needs , it must fetch/request as many
> MI.DelegatedCredentials as required. On the other side, the uCDN may decide
> to respond with different or identical MI.DelegatedCredentials payloads.  I
> also note that there is an error in the current text which can be a bit
> confusing: page 4: second paragraph, we should read:
>
>
>
> “The MI.ConfDelegatedCredentials contains a URI (credentials-location-uri)
> that allows the dCDN to download delegated credentials. The expected
> behavior of this URI is that each time that the dCDN accesses this URI a
> *MI.DelegatedCredentials* object containing a delegated credential with
> its corresponding private key is delivered.”
>
>
>
> I reckon this workflow is not typical to RFC8006 which would favor a
> separate/new interface for describing that process. This drives to the
> possibility of only adding MI.ConfDelegatedCredentials to MI (RFC8006) .
> However, if we cannot describe the protocol to fetch the
> MI.DelegatedCredentials object and its payload structure (i.e. private key
> +  DelegatedCredential as defined in [I-D.ietf-tls-subcerts]) as part of
> CDNi, the MI.ConfDelegatedCredentials becomes pointless. Ideally, we should
> generate a new CDNi interface dedicated to subcert describing the
> MI.DelegatedCredentials payload and the protocol between the uCDN and dCDN.
>
>
>
> There is however a possible complementary solution to this. The dCDN may
> advertise about supporting the subcert capability through a dedicated new
> FCI object named e.g., FCI.delegatedCredentials. The latter would indicate
> the number of required [different] delegated credential objects. The uCDN
> when configuring the dCDN would then use an MI object (we can name it
> MI.ConfDelegatedCredentials) to communicate the delegated credentials (i.e.
> private key +  DelegatedCredential) via an array of MI objects. I.e,
> MI.ConfDelegatedCredentials would be defines as:
>
> Property: array of MI.DelegatedCredentials objects.
>
>
>
> The MI.ConfDelegatedCredentials object would have to be
> updated/communicated by the uCDN each time any or all of the delegated
> credential’s validity is going to expired and/or each time a new
> FCI.delegatedCredentials object is updated/created.  With that way to do we
> stay compatible with the RFC 8006 spirit, do not need an extra CDNi
> interface and provides a complete/coherent mechanism for configuring the
> dCDN with the delegated credentials.
>
>
>
> Any thoughts on this latter proposal?
>
>
>
> Christoph
>
>
>
>
>
> *From:* Kevin Ma <kevin.j.ma.ietf@gmail.com>
> *Sent:* vendredi 11 février 2022 07:04
> *To:* Christoph Neumann <Christoph.Neumann@broadpeak.tv>
> *Cc:* cdni@ietf.org
> *Subject:* Re: [CDNi] FW: New Version Notification for
> draft-fieau-interfaces-https-delegation-subcerts-01.txt
>
>
>
> Hi Christoph,
>
>
>
>   (As Chair) I think it is fair to call for adoption of the draft, since
> it was just a split, though I think it would be good to reaffirm that the
> WG has an appetite for this work, since it has been a while since we agreed
> to adopt the original draft.  If folks could please confirm on the list
> that they believe TLS subcerts are still useful to support in CDNI, that
> would be great.
>
>
>
>   (As an Individual) The actual requirements to support TLS subcerts seem
> pretty minimal (see my comments on the draft below).  Assuming the TLS
> subcerts draft is on track to be published (I see that the AD recently
> requested a revision), I am in favor of adopting the draft.
>
>
>
> thanx!
>
>
>
> --  Kevin J. Ma
>
>
>
> comments:
>
> ---------
>
>
>
> - does "MI.DelegatedCredentials" need to be defined in this draft?  It is
> not transferred via the MI?  is "MI.ConfDelegatedCredentials" sufficient
> for CDNI's purposes?
>
> - in the call flows, it looks like only steps 3 and 4
> for "MI.ConfDelegatedCredentials" are related to CDNI?  perhaps we could
> make that even more clear, so that there aren't a lot of questions about
> the security of what's being proposed?
>
> - the draft needs security and privacy sections (the security section gets
> easier if we are clear that the draft only really defines
> the "MI.ConfDelegatedCredentials" object which is a simple link and
> subcerts does all the heavy security lifting; the privacy section gets
> easier if we remove MI.DelegatedCredentials and let the subvert draft deal
> with passing around a "private key")
>
>
>
>
>
>
>
> On Wed, Jan 26, 2022 at 11:33 AM Christoph Neumann <
> Christoph.Neumann@broadpeak.tv> wrote:
>
> Dear all,
>
> I submitted a new version of the draft on CDNI Metadata for Delegated
> Credentials (see below).
>
> As discussed and agreed in the CDNi working group, this draft resulted
> from splitting the original CDNi extensions for HTTPS delegation draft
> (draft-ietf-cdni-interfaces-https-delegation) into two:
> - one that handles STAR/ACME type delegation, which remained in
> draft-ietf-cdni-interfaces-https-delegation
> - one that handles delegated credentials, described in
> draft-fieau-interfaces-https-delegation-subcerts
>
> The delegated credentials draft is currently handled as an individual
> submission, and I would like to ask for adoption of this draft in the CDNi
> working group.
>
> Further, feel free to comment the draft on the mailing list.
>
> Best regards,
> Christoph
>
> -----Original Message-----
> From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> Sent: mercredi 26 janvier 2022 17:00
> To: Christoph Neumann <christoph.neumann@broadpeak.tv>; Emile Stephan <
> emile.stephan@orange.com>; Frederic Fieau <frederic.fieau@orange.com>;
> Guillaume Bichot <guillaume.bichot@broadpeak.tv>; Stephan Emile <
> emile.stephan@orange.com>
> Subject: New Version Notification for
> draft-fieau-interfaces-https-delegation-subcerts-01.txt
>
>
> A new version of I-D,
> draft-fieau-interfaces-https-delegation-subcerts-01.txt
> has been successfully submitted by Christoph Neumann and posted to the
> IETF repository.
>
> Name:           draft-fieau-interfaces-https-delegation-subcerts
> Revision:       01
> Title:          CDNI Metadata for Delegated Credentials
> Document date:  2022-01-26
> Group:          Individual Submission
> Pages:          9
> URL:
> https://www.ietf.org/archive/id/draft-fieau-interfaces-https-delegation-subcerts-01.txt
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-fieau-interfaces-https-delegation-subcerts-01.txt&data=04%7C01%7CChristoph.Neumann%40broadpeak.tv%7C31b30e046460458449b208d9ed24543b%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637801562557792088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=QFaHDtkpfYfrjAYDDoIXmSdxmjt04eywDjttAdk4FLo%3D&reserved=0>
> Status:
> https://datatracker.ietf.org/doc/draft-fieau-interfaces-https-delegation-subcerts/
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-fieau-interfaces-https-delegation-subcerts%2F&data=04%7C01%7CChristoph.Neumann%40broadpeak.tv%7C31b30e046460458449b208d9ed24543b%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637801562557792088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2FPtgxFHH9o8Ze%2FwpdzoY%2FMRfUKqGhnA%2FcKNEmp7a5%2F4%3D&reserved=0>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-fieau-interfaces-https-delegation-subcerts
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-fieau-interfaces-https-delegation-subcerts&data=04%7C01%7CChristoph.Neumann%40broadpeak.tv%7C31b30e046460458449b208d9ed24543b%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637801562557792088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Wn1%2B4HCdvDzpfYTK3ZEyXnS3Rwi%2BKn6hvusuA02hkqA%3D&reserved=0>
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-fieau-interfaces-https-delegation-subcerts-01
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-fieau-interfaces-https-delegation-subcerts-01&data=04%7C01%7CChristoph.Neumann%40broadpeak.tv%7C31b30e046460458449b208d9ed24543b%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637801562557792088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=cG1nvUUcogl7El1rhkA14b1Lltcca%2FpDazw8JTSj6PA%3D&reserved=0>
>
> Abstract:
>    The delivery of content over HTTPS involving multiple CDNs raises
>    credential management issues.  This document defines metadata in CDNI
>    Control and Metadata interface to setup HTTPS delegation using
>    Delegated Credentials from an Upstream CDN (uCDN) to a Downstream CDN
>    (dCDN).
>
>
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcdni&data=04%7C01%7CChristoph.Neumann%40broadpeak.tv%7C31b30e046460458449b208d9ed24543b%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637801562557792088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=b1aEa%2FVaj%2Fkyzf8zUJGCX8cUwfWKezIdQLWHA41uMlE%3D&reserved=0>
>
>