Re: [CDNi] I-D Action: draft-ietf-cdni-interfaces-https-delegation-13.txt

"Kevin J. Ma" <kevin.j.ma.ietf@gmail.com> Tue, 20 December 2022 13:04 UTC

Return-Path: <kevin.j.ma.ietf@gmail.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8F8C14CE40 for <cdni@ietfa.amsl.com>; Tue, 20 Dec 2022 05:04:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.103
X-Spam-Level:
X-Spam-Status: No, score=-1.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_Frjh1ZbLNx for <cdni@ietfa.amsl.com>; Tue, 20 Dec 2022 05:04:49 -0800 (PST)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62810C14CE34 for <cdni@ietf.org>; Tue, 20 Dec 2022 05:04:49 -0800 (PST)
Received: by mail-qt1-x82d.google.com with SMTP id c11so2961612qtn.11 for <cdni@ietf.org>; Tue, 20 Dec 2022 05:04:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=tbrESbL9njStYUTi+pr6HAPcgO1MK+7GR/CWclRHc2s=; b=YH6N8o6cZZRFZrsa9Yo+OZH6wUB4HF2KssfJFKKYxUU3Xa9z9qERxMAkJeNNmjP3t9 EnjaNKnGiojqz7MbeloJHMQxVEoCNfmbf8fy5CYnicoRQsgqeULVuc5CI6bdh5E8jbMH GkIoSUVBwpy6C3gb/A29MU2oyAn/q78Df6wR3VVacMQVDretJj3eaPHnopnFL9VTOLGC hi0EaTA10HiVomD5e4s+ISN8olg3C/u1KAjpZGkxwEjEfNTcmoOCZRAkFeMIiaPdnA5T 3rPMI5jLfr0tk2/mxvzTo0uNxCymHi14mAS0LdGGDX2ZKwKu6AuCTukdbYVFnPWKpwS1 jaXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tbrESbL9njStYUTi+pr6HAPcgO1MK+7GR/CWclRHc2s=; b=PKphwUArheyfImTUnQ3zDtx/YTunEXJWozYCu18xK2f2SidGyrB5HaMB3CtxBEaR4U Rk+j5W9mrDl3Q45o1TVKIwXg+qAj47vT9BzWJKdS5V2w8kjVadcw434rCW2q7J1W7QgO c/mm+psqU8IFT3lmI1BYH406UYmQCmyhxfY9hGGHDjtRHG3rg4dByMpuuKM2B8igwFM9 4fL1BLYvaZ2NYmJ4dC+L19KvqXKi7OmpcPpowLCGK8OYbxLC0WRPUGpU9S+FZfDEqG/K S8T6POByEPlQXc9om/SDSLAtC+dZ49z5hIwgWB3BUh6i1wlVsq4XvesFtho/Dn5DkjPy WiCQ==
X-Gm-Message-State: ANoB5pnw6pJvmEEFHIBQYnJGVTluO0Q9rbJKpORL1aOb8PKy24cYvzxZ JyyfyeaxQCrqMUVetlxCNxJb/9l0+/g=
X-Google-Smtp-Source: AA0mqf4o5TCVhV3pHllEg7gRibFyCvz2ZLQ8dxO8rFJp6csnW4MaZ2tZfg7GlCLqpOc17h3rFBqoyA==
X-Received: by 2002:a05:622a:4c13:b0:3a6:348c:5159 with SMTP id ey19-20020a05622a4c1300b003a6348c5159mr60814555qtb.26.1671541487820; Tue, 20 Dec 2022 05:04:47 -0800 (PST)
Received: from smtpclient.apple ([2601:191:8400:1650:7d09:103f:e0b3:97f7]) by smtp.gmail.com with ESMTPSA id l1-20020ac81481000000b003a5c60686b0sm7530025qtj.22.2022.12.20.05.04.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Dec 2022 05:04:47 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-61CC0734-95AA-47C1-B734-38786F307C61"
Content-Transfer-Encoding: 7bit
From: "Kevin J. Ma" <kevin.j.ma.ietf@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 20 Dec 2022 08:04:36 -0500
Message-Id: <0AFA9CB7-27D5-48D5-9A3E-4AEB839D18CC@gmail.com>
References: <PR3PR10MB423909F14F96CDF7AE744E24E1EA9@PR3PR10MB4239.EURPRD10.PROD.OUTLOOK.COM>
Cc: frederic.fieau@orange.com, cdni@ietf.org
In-Reply-To: <PR3PR10MB423909F14F96CDF7AE744E24E1EA9@PR3PR10MB4239.EURPRD10.PROD.OUTLOOK.COM>
To: Guillaume Bichot <Guillaume.Bichot@broadpeak.tv>
X-Mailer: iPhone Mail (20B101)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cdni/3Xiv1qd0s8bWu2s_V3Rc0OmBk4Q>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-interfaces-https-delegation-13.txt
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cdni/>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2022 13:04:53 -0000

the last sentence sounds strange: “….The delegation object is defined as per Section 4.3 of [RFC8006].”  There is no delegation object defined in RFC8006.  I suppose that we should remove that sentence.

Agreed, I had the same comment to remove that sentence.

--  Kevin J. Ma

Sent from my iPhone

On Dec 20, 2022, at 3:18 AM, Guillaume Bichot <Guillaume.Bichot@broadpeak.tv> wrote:


Yes, Right. A simple URL would do the job and the examples become right. I would also suggest to clearly mention that: once the dCDN gets configured with that MI.ACMEDelegationMethod object, the dCDN can start the  ACME protocol [RFC8555] as indicated in [RFC 9115] through posting an order for a certificate related to the configured delegated name.

 

Another bug in the description (section 3.1.1): The second example is associated with a paragraph wherein the last sentence sounds strange: “….The delegation object is defined as per Section 4.3 of [RFC8006].”  There is no delegation object defined in RFC8006.  I suppose that we should remove that sentence.

 

Guillaume

 

From: Kevin J. Ma <kevin.j.ma.ietf@gmail.com>
Sent: Tuesday, December 20, 2022 5:30 AM
To: Guillaume Bichot <Guillaume.Bichot@broadpeak.tv>
Cc: frederic.fieau@orange.com; cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-interfaces-https-delegation-13.txt

 

Hi All,

 

  Thanks Guillaume for catching the Link issue!  The alternative is to just make the acme-delegation property a String and specify that it must be a URL that points to an ACME delegation object?  There's no real reason to reuse the RFC8006 Link object.

 

thanx.

 

--  Kevin J. Ma

Sent from my iPhone



On Dec 19, 2022, at 3:27 AM, Guillaume Bichot <Guillaume.Bichot@broadpeak.tv> wrote:



Hi all, in addition to Kevin’s comments I would add the following comment.

 

* In section 3.1, the property acme-delegation cannot be of the type Link as defined in RFC 8006 (4.3.1). This type has been defined to be used optionally instead of embedding a real object, again without any obligation. This means that the property acme-delegation must be of the type depicted in the referenced RFC 9115/section 2.3.1. By the way, for a reader that is not familiar with the latter, it is very difficult to understand how this object is structured. At least section 2.3.1.3. should be mentioned (instead of 2.3.1) and at best, the object  should be depicted/detailed in the draft.

 

So to summarized, the property acme-delegation must an object type with the set of properties corresponding to the json structure depicted in RFC 9115/2.3.1.3. I would recommend describing in the draft the property list.  As per RFC8006, as with any metadata interface object, it is always possible to use a Link object instead of an embedding an object.   

 

*In section 3.1.1, the examples are wrong. According to RFC 8006, a Link object is defined with two properties including one mandatory property: “href”. In the example, the property name “href” is missing.

In line with my comments above, I would suggest to rewrite the examples detailing the configuration acme-delegation property.

 

Guillaume Bichot

 

From: CDNi <cdni-bounces@ietf.org> On Behalf Of Kevin Ma
Sent: Sunday, December 18, 2022 7:04 AM
To: frederic.fieau@orange.com
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-interfaces-https-delegation-13.txt

 

Hi Frederic,

 

  Thanks again for the updated draft.  Please see my comments below.

 

thanx.

 

--  Kevin J. Ma

 

Abstract:
- "RFC 9115" -> "RFC9115"

section 3.1:
- "several properties" -> "the properties"
- "window \"end\" time of the window" -> "window \"end\" time"  --  There's an extraneous "of the window"
- remove "in Epoch time format"
- the "lifetime" and "lifetime-adjust" properties are not actually "Time" objects (they have no relation to the UNIX epoch), they're just "Integer"s.  we should just make them "Integer"s?

section 3.1.1:
- remove "The delegation object is defined as per Section 4.3 of [RFC8006]."  --  I'm not sure what this means.

section 5:
- title: "Security Considerations" -- with a capital 'C'
- "and security goal (Section 7.3" -> "and security goal (Section 7.2" -- Security Goals is  Section 7.2
- "protection of the user account associated with the delegation" -- Section 7.2 of RFC9115 essentially says that delegation is dangerous, because here, the dCDN is not being directly authorized by the IdO?  That is just telling the uCDN to make sure it trusts the dCDN.  What I'm more interested in, wrt this draft, is: what happens if a third party gets access to the `acme-delegation` URL?  What, if anything, can I do with 'a URL pointing at an ACME delegation object'?  It seems like something that should be protected (and hopefully is protected by the MI enforced TLS); if so, it would be nice to know that we recognize it, and that we rely on the MI TLS requirements to keep it safe, e.g., 'The ACME delegation object contains secret key material that would enable content theft.  The Metadata interface authentication and confidentiality requirements defined in Section 8.3 of RFC8006 MUST be followed to prevent unauthorized access to the ACME delegation object.'?  Or, if there is nothing that needs to be protected, a simple sentence to that effect, e.g., 'There is no sensitive data in the ACME delegation object.  The Metadata interface security requirements (see Section 8.3 of RFC8006) are sufficient to protect the integrity of the ACME delegation object."

 

 

On Wed, Dec 14, 2022 at 7:06 PM Kevin J. Ma <kevin.j.ma.ietf@gmail.com> wrote:

Hi Frederic,

 

  Thanks for the uodate!  I will give it a read.  I encourage others to do so as well.  And then we'll see if we're ready to move to WGLC.

 

thanx!

 

--  Kevin J. Ma

Sent from my iPhone




On Dec 14, 2022, at 9:27 AM, frederic.fieau@orange.com wrote:



Hi all,

 

Just submitted the last version of the ACME delegation draft. The draft seems to be in a pretty good shape now.

Waiting for some final reviews.

 

Regards,

Frederic


De : CDNi <cdni-bounces@ietf.org> de la part de internet-drafts@ietf.org <internet-drafts@ietf.org>
Envoyé : mercredi 14 décembre 2022 11:05:48
À : i-d-announce@ietf.org
Cc : cdni@ietf.org
Objet : [CDNi] I-D Action: draft-ietf-cdni-interfaces-https-delegation-13.txt

 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Content Delivery Networks Interconnection WG of the IETF.

        Title           : CDNI extensions for HTTPS delegation
        Authors         : Frédéric Fieau
                          Emile Stephan
                          Sanjay Mishra
  Filename        : draft-ietf-cdni-interfaces-https-delegation-13.txt
  Pages           : 10
  Date            : 2022-12-14

Abstract:
   This document defines metadata objects to support delegating the
   delivery of HTTPS content between two or more interconnected CDNs.
   Specifically, this document defines CDNI Metadata interface objects
   to enable delegation of X.509 certificates leveraging delegation
   schemes defined in RFC9115.  RFC 9115 allows delegating entities to
   remain in full control of the delegation and be able to revoke it any
   time and avoids the need to share private cryptographic key material
   between the involved entities.


The IETF datatracker status page for this draft is:
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-cdni-interfaces-https-delegation%2F&data=05%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cc1ba7eda42d14a35a6bb08dae242eaf0%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638071074735601848%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=nngHOEPFwXokcjSDSqKuo1IrnfnjOc%2FejHYUY1tUzAM%3D&reserved=0" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-cdni-interfaces-https-delegation/

There is also an HTML version available at:
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-cdni-interfaces-https-delegation-13.html&data=05%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cc1ba7eda42d14a35a6bb08dae242eaf0%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638071074735601848%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=W98YqlIcNkrdl%2BbaTn2ziqfo9fpXGYhzdnmn0DV5Ip8%3D&reserved=0" target="_blank" rel="nofollow">https://www.ietf.org/archive/id/draft-ietf-cdni-interfaces-https-delegation-13.html

A diff from the previous version is available at:
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-cdni-interfaces-https-delegation-13&data=05%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cc1ba7eda42d14a35a6bb08dae242eaf0%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638071074735601848%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=%2BSfNGnuTeipT3IuMachqNv%2BRH7%2FMLeBROmkCAV%2Fpg0s%3D&reserved=0" target="_blank" rel="nofollow">https://author-tools.ietf.org/iddiff?url2=draft-ietf-cdni-interfaces-https-delegation-13


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcdni&data=05%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cc1ba7eda42d14a35a6bb08dae242eaf0%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638071074735601848%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=4WNUUksWmzY%2B42tXR6E1x9XQ3PtIpDhop0Q%2B7Xs5WdM%3D&reserved=0" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/cdni

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcdni&data=05%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cc1ba7eda42d14a35a6bb08dae242eaf0%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638071074735601848%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=4WNUUksWmzY%2B42tXR6E1x9XQ3PtIpDhop0Q%2B7Xs5WdM%3D&reserved=0" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/cdni

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 privacy@broadpeak.tv.
Local authority : Commission Nationale Informatique et Libertés (CNIL): 3 Place de Fontenoy - TSA 80715 - 75334 PARIS CEDEX 07 or http://www.cnil.fr" rel="nofollow">www.cnil.fr

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 privacy@broadpeak.tv.
Local authority : Commission Nationale Informatique et Libertés (CNIL): 3 Place de Fontenoy - TSA 80715 - 75334 PARIS CEDEX 07 or www.cnil.fr