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

[Christoph Neumann <[e-mail]>]

Hi Kevin,

Thanks for your feedback.
Do you suggest that the MI object for delegated credentials should always be linked (rather than embedded), that the caching duration of the linked metadata should be set to null/none, and that the expected behavior for the dCDN is to fetch the metadata object (containing a delegated credential) on the provided link each time a new one is needed?
What about the case where the metadata is not linked but directly embedded? Do you suggest prohibiting the usage of embedded metadata for this particular type of MI Object?

I guess what you propose would work. It would however tweak a bit the original Metadata interface and requires a specific behavior for that specific type of object. If this is not an issue, we might study this proposal more closely.

Christoph

From: Kevin Ma <[e-mail]>
Sent: lundi 24 octobre 2022 02:40
To: Christoph Neumann <[e-mail]>
Cc: [e-mail]
Subject: Re: [CDNi] FW: New Version Notification for draft-fieau-interfaces-https-delegation-subcerts-01.txt

Hi Christoph,

  Sorry for the delayed response.  The Metadata interface uses standard HTTP caching mechanisms to control the dCDN's usage of the metadata.  There is nothing that prevents the uCDN from setting the cache control to a very short duration or none at all.  It's a bit of an end around on the original intent of the Metadata interface, but it would work?

thanx!

--  Kevin J. Ma

On Wed, Aug 17, 2022 at 5:22 AM Christoph Neumann <[e-mail]<mailto:[e-mail]>> wrote:
Hi Kevin, all,

The mechanism you are describing would be ideal, i.e., the dCDN simply requests metadata object whenever required and the uCDN serves the metadata accordingly.
However, I'm not quite sure how you would implement that with CDNI, i.e., which API or interface would allow the dCDN to request metadata as needed.
Do you have a specific mechanism in mind?

Christoph

From: Kevin Ma <[e-mail]<mailto:[e-mail]>>
Sent: vendredi 29 juillet 2022 16:11
To: Christoph Neumann <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [CDNi] FW: New Version Notification for draft-fieau-interfaces-https-delegation-subcerts-01.txt

Hi Christoph,

  I was wondering if we could get away with just a single metadata object?  If there is no expectation that the credentials read will persist for any length of time, could the dCDN just request the metadata object and use whatever is returned?  There is still the question of how many to include in the payload, but if we let the uCDN decide how many, the dCDN could just keep asking until it got as many credentials as it wanted (which may all be the same or could be different).  It would be implementation specific on how the uCDN responds to the metadata request, i.e., how the uCDN generates that specific piece of metadata, which is a don't care for interoperability?  Now, the uCDN wouldn't know if it was asking because it needed more creds or because it rebooted and needed to refresh its metadata, but with a short-lived cred, I'm not sure it matters?

thanx.

--  Kevin J. Ma


On Sat, Jul 9, 2022 at 11:11 AM Kevin Ma <[e-mail]<mailto:[e-mail]>> wrote:
Hi Christoph,

  Thanks for the response.  Some additional thoughts:

> The maximum expiration time of a delegated credential is 7 days. If we stay in this order of magnitude (i.e.  a credential lasts a few days), FCI could do the job
> So bottom line: FCI could work, but it we will not be very dynamic (e.g., if credentials that last a few hours).

Do we have any data on whether implementers would want really short durations?  It would be nice to be data driven here, if possible.  I can certainly see the perceived value of rotating as quickly as possible as it reduces the potential for criminal enterprise; I could also see using the cert expiration in a lazy customer managed key revocation scheme.  Are there specific use cases you have in mind?

> My proposal: Maybe we could start with the FCI based mechanism, knowing that it will have limitations in terms of dynamicity, and in the meantime work on how to specify/tackle more dynamic delegated credential fetching mechanisms

(As an individual) If we think we need higher dynamicity than FCI can provide, then I would just skip to just trying to figure that out.

(As a chair) I would be interested in hearing what others in the WG think.

thanx!

--  Kevin J. Ma


On Tue, Jul 5, 2022 at 4:42 AM Christoph Neumann <[e-mail]<mailto:[e-mail]>> wrote:
Hi Kevin,

The interface we are proposing to fetch the delegated credentials is indeed very simple. Only a req/resp on an URL.
If I understand you correctly you think this is still outside the scope of CDNI.
But I'm not quite sure where to define it elsewhere (also because the mechanism is quite simple).
I could not find any other existing standard our mechanism that would allow us to fetch the delegated credentials.


Regarding FCI:
The maximum expiration time of a delegated credential is 7 days. If we stay in this order of magnitude (i.e.  a credential lasts a few days), FCI could do the job: the dCDN monitors the number of credentials that expires in the next day, and ask for new ones by announcing this number of required delegated credentials via an FCI object (the uCDN will very probably query the FCI within the next day).
However, before the first configuration of the dCDN from the uCDN the dCDN does not really know how many servers will be used for the uCDN services and contents and consequently does not really know how many delegated credentials may be needed. I.e., the "first" FCI announcement will be something like the number of caching servers available by the dCDN (or the number of servers per footprint).

So bottom line: FCI could work, but it we will not be very dynamic (e.g., if credentials that last a few hours). If we go for FCI, the only MI object that would stay is the MI.DelegatedCredentials.
If we want a more dynamic mechanism, we need a simple req/resp interface.
My proposal: Maybe we could start with the FCI based mechanism, knowing that it will have limitations in terms of dynamicity, and in the meantime work on how to specify/tackle more dynamic delegated credential fetching mechanisms (and try to figure out where the right place is to specify these).

Christoph


From: Kevin Ma <[e-mail]<mailto:[e-mail]>>
Sent: lundi 4 juillet 2022 16:38
To: Christoph Neumann <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: vendredi 11 février 2022 07:04
To: Christoph Neumann <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: mercredi 26 janvier 2022 17:00
To: Christoph Neumann <[e-mail]<mailto:[e-mail]>>; Emile Stephan <[e-mail]<mailto:[e-mail]>>; Frederic Fieau <[e-mail]<mailto:[e-mail]>>; Guillaume Bichot <[e-mail]<mailto:[e-mail]>>; Stephan Emile <[e-mail]<mailto:[e-mail]>>
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=05%7C01%7CChristoph.Neumann%40broadpeak.tv%7Ce094374d8f924b63273f08dab5585004%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638021688162657944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=b6U4%2BHraHd4wy92sktyDwIOSknjQJx%2B2OHV5b0xYaRg%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=05%7C01%7CChristoph.Neumann%40broadpeak.tv%7Ce094374d8f924b63273f08dab5585004%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638021688162657944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vj4cVmczEI%2B%2BTTta2t7GQv54jZzB09H0A5Ou4AHVKes%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=05%7C01%7CChristoph.Neumann%40broadpeak.tv%7Ce094374d8f924b63273f08dab5585004%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638021688162657944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Wboyb1ZW%2FPmqtBEcR%2BgozcG4yf9K9lHriv1ZGJBEN38%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=05%7C01%7CChristoph.Neumann%40broadpeak.tv%7Ce094374d8f924b63273f08dab5585004%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638021688162657944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QYrmdRBzyG3JspD5Ds35c4drImGqEmLfA1VWnygH2NU%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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cdni<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcdni&data=05%7C01%7CChristoph.Neumann%40broadpeak.tv%7Ce094374d8f924b63273f08dab5585004%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638021688162657944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fa2wmIDXJIV0NzezkjRL%2BBq5YH7DEAhdCZZbKJPBS2U%3D&reserved=0>

Broadpeak, S.A. Registered offices at 15 rue Claude Chappe, Zone des Champs Blancs, 35510 Cesson-Sévigné, France | Rennes
Trade Register: 524 473 063
This e-mail and its attachments contain confidential information from Broadpeak S.A. and/or its affiliates (Broadpeak), which is intended only for the person to whom it is addressed.
If you are not the intended recipient of this email, please notify immediately the sender by phone or email and delete it. Any use of the information contained herein in any way, including, but not limited to, total or partial disclosure, reproduction, or dissemination, by persons other than the intended recipient(s) is prohibited, unless expressly authorized by Broadpeak. Broadpeak, S.A. and its affiliates respect privacy laws, and is committed to the protection of personal data. Emails and/or attachments thereof exchanged between us may include your personal data which may be processed by Broadpeak and/or its affiliates according to applicable privacy laws & regulations.
In compliance with Regulation (EU) 2016/679 (GDPR) and applicable implementation in local legislations, you can exercise at any time your rights of access, rectification or erasure of your personal data, as well as your rights to restriction, portability or object to the processing.
For such purpose, or to know more about how Broadpeak processes your personal data, you may contact Broadpeak by email [e-mail]<mailto:[e-mail]>.
Local authority : Commission Nationale Informatique et Libertés (CNIL): 3 Place de Fontenoy - TSA 80715 - 75334 PARIS CEDEX 07 or www.cnil.fr<https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cnil.fr%2F&data=05%7C01%7CChristoph.Neumann%40broadpeak.tv%7Ce094374d8f924b63273f08dab5585004%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638021688162657944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TiwAvrKgWYPxBJhcu2GZGKd8XTf%2FKcU%2BUlxqNgbuJnk%3D&reserved=0>

Broadpeak, S.A. Registered offices at 15 rue Claude Chappe, Zone des Champs Blancs, 35510 Cesson-Sévigné, France | Rennes
Trade Register: 524 473 063
This e-mail and its attachments contain confidential information from Broadpeak S.A. and/or its affiliates (Broadpeak), which is intended only for the person to whom it is addressed.
If you are not the intended recipient of this email, please notify immediately the sender by phone or email and delete it. Any use of the information contained herein in any way, including, but not limited to, total or partial disclosure, reproduction, or dissemination, by persons other than the intended recipient(s) is prohibited, unless expressly authorized by Broadpeak. Broadpeak, S.A. and its affiliates respect privacy laws, and is committed to the protection of personal data. Emails and/or attachments thereof exchanged between us may include your personal data which may be processed by Broadpeak and/or its affiliates according to applicable privacy laws & regulations.
In compliance with Regulation (EU) 2016/679 (GDPR) and applicable implementation in local legislations, you can exercise at any time your rights of access, rectification or erasure of your personal data, as well as your rights to restriction, portability or object to the processing.
For such purpose, or to know more about how Broadpeak processes your personal data, you may contact Broadpeak by email [e-mail]<mailto:[e-mail]>.
Local authority : Commission Nationale Informatique et Libertés (CNIL): 3 Place de Fontenoy - TSA 80715 - 75334 PARIS CEDEX 07 or www.cnil.fr<https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cnil.fr%2F&data=05%7C01%7CChristoph.Neumann%40broadpeak.tv%7Ce094374d8f924b63273f08dab5585004%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638021688162657944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TiwAvrKgWYPxBJhcu2GZGKd8XTf%2FKcU%2BUlxqNgbuJnk%3D&reserved=0>

Broadpeak, S.A. Registered offices at 15 rue Claude Chappe, Zone des Champs Blancs, 35510 Cesson-Sévigné, France | Rennes
Trade Register: 524 473 063
This e-mail and its attachments contain confidential information from Broadpeak S.A. and/or its affiliates (Broadpeak), which is intended only for the person to whom it is addressed.
If you are not the intended recipient of this email, please notify immediately the sender by phone or email and delete it. Any use of the information contained herein in any way, including, but not limited to, total or partial disclosure, reproduction, or dissemination, by persons other than the intended recipient(s) is prohibited, unless expressly authorized by Broadpeak. Broadpeak, S.A. and its affiliates respect privacy laws, and is committed to the protection of personal data. Emails and/or attachments thereof exchanged between us may include your personal data which may be processed by Broadpeak and/or its affiliates according to applicable privacy laws & regulations.
In compliance with Regulation (EU) 2016/679 (GDPR) and applicable implementation in local legislations, you can exercise at any time your rights of access, rectification or erasure of your personal data, as well as your rights to restriction, portability or object to the processing.
For such purpose, or to know more about how Broadpeak processes your personal data, you may contact Broadpeak by email [e-mail].
Local authority : Commission Nationale Informatique et Libertés (CNIL): 3 Place de Fontenoy - TSA 80715 - 75334 PARIS CEDEX 07 or www.cnil.fr