Subject: [Acme] Fwd: New Version Notification for draft-ietf-acme-star-delegation-01.txt

From: Yaron Sheffer <[email-masked]>
Date: Mon, 26 Aug 2019 23:28:29 -0700

The new version contains some significant changes:

- Addition of the STIR use case.
- Refinement of the CDNI use case.
- Addition of the CSR template (partial, more work required).
- Further security considerations (work in progress).

Thanks,
	Yaron

-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-acme-star-delegation-01.txt
Date: Mon, 26 Aug 2019 23:17:15 -0700
From: [email-masked]
To: Yaron Sheffer <[email-masked]>, Thomas Fossati 
<[email-masked]>, Antonio Agustin Pastor Perales 
<[email-masked]>, Antonio Pastor 
<[email-masked]>, Diego Lopez 
<[email-masked]>

A new version of I-D, draft-ietf-acme-star-delegation-01.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:		draft-ietf-acme-star-delegation
Revision:	01
Title:		An ACME Profile for Generating Delegated STAR Certificates
Document date:	2019-08-26
Group:		acme
Pages:		17
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-acme-star-delegation-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/
Htmlized: 
https://tools.ietf.org/html/draft-ietf-acme-star-delegation-01
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-delegation
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-delegation-01

Abstract:
    This memo proposes a profile of the ACME protocol that allows the
    owner of an identifier (e.g., a domain name) to delegate to a third
    party access to a certificate associated with said identifier.  A
    primary use case is that of a CDN (the third party) terminating TLS
    sessions on behalf of a content provider (the owner of a domain
    name).  The presented mechanism allows the owner of the identifier to
    retain control over the delegation and revoke it at any time by
    cancelling the associated STAR certificate renewal with the ACME CA.
    Another key property of this mechanism is it does not require any
    modification to the deployed TLS ecosystem.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 27 Aug 2019 15:11:09 +0000

Colleagues,

I encourage you to read this draft and post comments, if any, to the list.

A structure for delegation opens up ACME to a large number of use cases.

On 8/27/19, 2:28 AM, "Yaron Sheffer" <[email-masked]> wrote:

    
    Thanks,
    	Yaron
    
    -------- Forwarded Message --------
    Subject: New Version Notification for draft-ietf-acme-star-delegation-01.txt
    Date: Mon, 26 Aug 2019 23:17:15 -0700
    From: [email-masked]
    To: Yaron Sheffer <[email-masked]>, Thomas Fossati 
    <[email-masked]>, Antonio Agustin Pastor Perales 
    <[email-masked]>, Antonio Pastor 
    <[email-masked]>, Diego Lopez 
    <[email-masked]>

    
    Abstract:

    
    
    The IETF Secretariat
    
    _______________________________________________
    Acme mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/acme

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 27 Aug 2019 12:31:12 -0400

> - Further security considerations (work in progress).

I was a bit surprised to not see any references to the Delegated
Credentials for TLS ( https://tools.ietf.org/html/draft-ietf-tls-subcerts )
specification. Is my understanding correct that these are functionally
addressing the same problem?

Introduction:
The introduction introduces the concept of NDC, but then transitions to use
the acronym CDN. Perhaps it would be useful to explicitly specify if you
meant a Content Delivery Network (CDN) to be a Name Delegation Consumer
(NDC), or if perhaps that was just a typo.

Also in the introduction, it states "Understandably, most IdOs balk at
sharing their long-term private keys", but this is difficult to quantify.
It would imply that most sites do not use CDNs, when I suspect the reality
is actually inverted - more sites use CDNs or hosting provider than those
that don't. Perhaps this should be updated to say "some IdOs", or perhaps
quantify as "IdOs may balk", both of which indicate possibilities without
indicating magnitude.

4.1.2 Chained Delegation
The use of the terms uCDN and dCDN are... a bit surprising. Could you
indicate a bit what those letters are meant to specify? My worry is that
the u will be seen as similar to the Greek letter mu - aka the prefix
typically used to indicate micro.

That said, I admit, I'm a bit confused about the protocol design attempting
to accommodate this. The motivation appears to be because "IdO may not even
know about dCDN", but then immediately following, it notes that such
proxying as proposed by the protocol is "governed by policy and contracts
between the parties". It seems that if the intent is to leave it to policy,
such accommodation may not be necessary. Alternative, if the intent is to
explicitly support this, it may be desirable to allow the IdO to express
its policy to the uCDN as to expectations related to the dCDN, rather than
relying upon an out-of-band mechanism.

6.1 Restricting CDNs to the Delegation Mechanism
There are RFC 2119 MUSTs attached here, when it seems these functionally
should be SHOULDs. That is, I think it's fair to highlight the
consideration of concerns between the IdO and the CDN, but I don't think
it's reasonable to normatively specify the policy consideration mechanism.
For example, as specified, those requirements would not be sufficient to
guarantee that a conforming CA uses this mechanism, as a number of CAs
"comply with ACME" (second bullet), but also offer additional validation
methods/issuance flows which also use the "dns-01" method.

As CAA is intentionally flexible to allow for CA-specific policy
identifiers to be expressed between the IdO and the CA, I think it's best
to change these to SHOULD, and to recognize that CAs may devise other means
of technically expressing this conformance, and that's between the IdO and
the CA. CAA provides the necessary component (to allow them to restrict to
CAs that respect CAA, to allow CA-specific policy), but I think that's the
extent to which policy-specific requirements can be made.

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 29 Aug 2019 09:38:42 +0000

Hi Ryan,

Thanks very much for the comments.  I'm going to address some of your
points and let Yaron comment on the rest.

On Tue, Aug 27, 2019 at 2:28 AM Yaron Sheffer <[email-masked]> wrote:
> Credentials for TLS (
> https://tools.ietf.org/html/draft-ietf-tls-subcerts ) specification.
> Is my understanding correct that these are functionally addressing the
> same problem?

Yes, it is.

> Introduction: The introduction introduces the concept of NDC, but then
> transitions to use the acronym CDN. Perhaps it would be useful to
> explicitly specify if you meant a Content Delivery Network (CDN) to be
> a Name Delegation Consumer (NDC), or if perhaps that was just a typo.

There is no typo.  A CDN is just one type of NDC.  We'll make sure
there's no ambiguity here.

> sharing their long-term private keys", but this is difficult to
> quantify. It would imply that most sites do not use CDNs, when I
> suspect the reality is actually inverted - more sites use CDNs or
> hosting provider than those that don't. Perhaps this should be updated
> to say "some IdOs", or perhaps quantify as "IdOs may balk", both of
> which indicate possibilities without indicating magnitude.

Makes sense, we'll fix.

> 4.1.2 Chained Delegation The use of the terms uCDN and dCDN are... a
> bit surprising. Could you indicate a bit what those letters are meant
> to specify? My worry is that the u will be seen as similar to the
> Greek letter mu - aka the prefix typically used to indicate micro

This is the CDNI use case, so we reuse CDNI terminology: 'u' is for
"upstream", 'd' is "downstream".  In the CDNI model the upstream CDN is
a "normal" CDN that maybe lacks the geographical footprint to
efficiently cover a portion of its end-users population and makes
agreements (transparently to the content provider) with a "downstream"
(regional, network operator run) CDN to extend its delivery footprint.

> That said, I admit, I'm a bit confused about the protocol design
> attempting to accommodate this. The motivation appears to be because
> "IdO may not even know about dCDN", but then immediately following, it
> notes that such proxying as proposed by the protocol is "governed by
> policy and contracts between the parties". It seems that if the intent
> is to leave it to policy, such accommodation may not be necessary.
> Alternative, if the intent is to explicitly support this, it may be
> desirable to allow the IdO to express its policy to the uCDN as to
> expectations related to the dCDN, rather than relying upon an
> out-of-band mechanism.

I think the policy that we can express is solely between adjacent
parties (this is the CDNI interface model).

> 6.1 Restricting CDNs to the Delegation Mechanism There are RFC 2119
> MUSTs attached here, when it seems these functionally should be
> SHOULDs. That is, I think it's fair to highlight the consideration of
> concerns between the IdO and the CDN, but I don't think it's
> reasonable to normatively specify the policy consideration mechanism.
> For example, as specified, those requirements would not be sufficient
> to guarantee that a conforming CA uses this mechanism, as a number of
> CAs "comply with ACME" (second bullet), but also offer additional
> validation methods/issuance flows which also use the "dns-01" method.
>
> identifiers to be expressed between the IdO and the CA, I think it's
> best to change these to SHOULD, and to recognize that CAs may devise
> other means of technically expressing this conformance, and that's
> between the IdO and the CA. CAA provides the necessary component (to
> allow them to restrict to CAs that respect CAA, to allow CA-specific
> policy), but I think that's the extent to which policy-specific
> requirements can be made.

I think Yaron is better placed than me to comment on these two.

Cheers!

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.