Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Fraser Tweedale]

On Fri, Jul 07, 2023 at 01:55:52AM +, Mike Ounsworth wrote:
> Thanks for the comments Fraser.
> 
> Guilty as charged -- we were not thinking about private enterprise
> environments when we wrote it; we were thinking about
> publicly-reachable servers on public clouds getting certs from
> public CAs. In that context, the quote from the abstract "at the
> mercy of their hosting provider as to which Certification
> Authorities (CAs) can be used" is less about the ACME server being
> reachable in a network sense, and more about public hosting
> providers -- quite reasonably -- not wanting to maintain a
> dropdown menu of every ACME server on the internet. Typically if
> you want to use a CA other than the single one that your hosting
> provider knows how to ACME to, then your only option is to
> manually upload a PEM file. Yuck. The other assumption here is
> that this draft is really for domain owners who care enough about
> where their certs come from to have a "favourite CA" because
> people who don't care will be happy to use whatever default ACME
> server.
> 
> That said, it's interesting to think about how this could apply to
> your enterprise problem of "find me /some/ ACME server that I can
> reach/use in this network zone". Assuming a private network with
> multiple DNS zones, you could configure your private DNS to slap
> on a constant CAA record across a DNS zone, and that gives you
> your "give me an ACME server, any one will do", right?
> 
> Out of curiosity, what happened to draft-tweedale-acme-discovery?
> Did it just not have enough momentum to proceed? Searching on the
> ACME list archive did not turn up very much discussion.

I presented it at IETF 109.  There was broard agreement that it was
a problem that should be solved, but no appetite for the WG to adopt
it at that time.  I'm happy with the content of the proposal and
even implemented a working POC in certbot.

For context, I work at Red Hat and helped develop the ACME server
support in Red Hat Certificate System (upstream: Dogtag Certificate
System) and Identity Management in RHEL (upstream: FreeIPA).  So I
was thinking about how to further enable customers to use cert
automation within their environments.  We haven't implemented the
proposed DNS-SD records yet, because there is no client support (due
to lack of a standard to follow - a "chicken/egg" situation).

Can CAA be used?  Yes, but the number of CAA records to manage grows
with the number of domains for which certs must be issued.  This
could be a headache for some orgs.

Per published RFCs only the "dns" identifier type could be use with
the CAA approach.  "ip" identifiers are important for many orgs,
particuarly those managing their own cloud infrastructure.  But how
to use CAA for ipAddress SAN is not defined.  (Perhaps use the
existing CAA attributes in _.in-addr.arpa and _.ip6.arpa zones).
There is a draft that defines how it would work for the "email"
identifier type[1].

[1] https://datatracker.ietf.org/doc/draft-ietf-lamps-caa-issuemail/

However, I think that the CAA approach is likely to get more
traction.  It uses DNS RR types that PKI people are already familiar
with.  It *can* be used in enterprise environments, albeit with more
administrative burden in scenarios that involve a lot of domain
names.

The gap of how CAA can be applied to ipAddress SAN names should be
dealt with in a separate document.  Such work will no doubt attract
interest from other groups (CAB Forum in particular).

The approaches are not mutually exclusive but I really can't imagine
clients would want to implement support for more than one mechanism.
Let's see where this new proposal leads!

Cheers,
Fraser

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Amir Omidi]

In this flow, the subscriber is the hosting company. This means that the
end domain would be expecting an entity (the hosting company) to agree to
the CA terms of service without ever actually reading them.

Registering an account with a CA generally requires an affirmation to
follow the terms of the agreement of the CA, and I think that could impose
a problem with this draft.

On Thu, Jul 6, 2023 at 22:29 Seo Suchan  wrote:

> a. ) CAs may want to put list of acme endpoints at well-known, for
> example one each for DV/OV/EV like sectigo did with
> https://acme.sectigo.com/v2/EV
>
> b. ) I think hosting provider wouldn't want to visit a random CA without
> human intervention, not only due to potential Malicious one but an open
> acme endpoint may not allowed to use, for example CA having
> noncommercial use only limit on that endpoint, and likely stick to CA
> they know even if it's low priority from CAA.
>
> 2023-07-06 오후 11:54에 Mike Ounsworth 이(가) 쓴 글:
> > Hi ACME!
> >
> > This is new business that we would like to add to the agenda for 117.
> >
> > Thanks,
> > ---
> > Mike Ounsworth & Paul van Brouwershaven
> >
> > -Original Message-
> > From: internet-dra...@ietf.org 
> > Sent: Thursday, July 6, 2023 9:39 AM
> > To: Mike Ounsworth ; Paul van Brouwershaven
> 
> > Subject: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
> >
> > WARNING: This email originated outside of Entrust.
> > DO NOT CLICK links or attachments unless you trust the sender and know
> the content is safe.
> >
> > __
> >
> > A new version of I-D, draft-vanbrouwershaven-acme-auto-discovery-00.txt
> > has been successfully submitted by Paul van Brouwershaven and posted to
> the IETF repository.
> >
> > Name:   draft-vanbrouwershaven-acme-auto-discovery
> > Revision:   00
> > Title:  Auto-discovery mechanism for ACME client configuration
> > Document date:  2023-07-06
> > Group:  Individual Submission
> > Pages:  16
> > URL:
> https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/
> > Html:
> https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery
> >
> >
> > Abstract:
> > A significant impediment to the widespread adoption of the Automated
> > Certificate Management Environment (ACME) [RFC8555] is that ACME
> > clients need to be pre-configured with the URL of the ACME server to
> > be used.  This often leaves domain owners at the mercy of their
> > hosting provider as to which Certification Authorities (CAs) can be
> > used.  This specification provides a mechanism to bootstrap ACME
> > client configuration from a domain's DNS CAA Resource Record
> > [RFC8659], thus giving control of which CA(s) to use back to the
> > domain owner.
> >
> > Specifically, this document specifies two new extensions to the DNS
> > CAA Resource Record: the "discovery" and "priority" parameters.
> > Additionally, it registers the URI "/.well-known/acme" at which all
> > compliant ACME servers will host their ACME directory object.  By
> > retrieving instructions for the ACME client from the authorized
> > CA(s), this mechanism allows for the domain owner to configure
> > multiple CAs in either load-balanced or fallback prioritizations
> > which improves user preferences and increases diversity in
> > certificate issuers.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
> > Any email and files/attachments transmitted with it are intended solely
> for the use of the individual or entity to whom they are addressed. If this
> message has been sent to you in error, you must not copy, distribute or
> disclose of the information it contains. Please notify Entrust immediately
> and delete the message from your system.
> > ___
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
-- 
Amir Omidi (he/them)
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Seo Suchan]

a. ) CAs may want to put list of acme endpoints at well-known, for 
example one each for DV/OV/EV like sectigo did with 
https://acme.sectigo.com/v2/EV


b. ) I think hosting provider wouldn't want to visit a random CA without 
human intervention, not only due to potential Malicious one but an open 
acme endpoint may not allowed to use, for example CA having 
noncommercial use only limit on that endpoint, and likely stick to CA 
they know even if it's low priority from CAA.


2023-07-06 오후 11:54에 Mike Ounsworth 이(가) 쓴 글:

Hi ACME!

This is new business that we would like to add to the agenda for 117.

Thanks,
---
Mike Ounsworth & Paul van Brouwershaven

-Original Message-
From: internet-dra...@ietf.org 
Sent: Thursday, July 6, 2023 9:39 AM
To: Mike Ounsworth ; Paul van Brouwershaven 

Subject: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the 
content is safe.

__

A new version of I-D, draft-vanbrouwershaven-acme-auto-discovery-00.txt
has been successfully submitted by Paul van Brouwershaven and posted to the 
IETF repository.

Name:   draft-vanbrouwershaven-acme-auto-discovery
Revision:   00
Title:  Auto-discovery mechanism for ACME client configuration
Document date:  2023-07-06
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/
Html:   
https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery


Abstract:
A significant impediment to the widespread adoption of the Automated
Certificate Management Environment (ACME) [RFC8555] is that ACME
clients need to be pre-configured with the URL of the ACME server to
be used.  This often leaves domain owners at the mercy of their
hosting provider as to which Certification Authorities (CAs) can be
used.  This specification provides a mechanism to bootstrap ACME
client configuration from a domain's DNS CAA Resource Record
[RFC8659], thus giving control of which CA(s) to use back to the
domain owner.

Specifically, this document specifies two new extensions to the DNS
CAA Resource Record: the "discovery" and "priority" parameters.
Additionally, it registers the URI "/.well-known/acme" at which all
compliant ACME servers will host their ACME directory object.  By
retrieving instructions for the ACME client from the authorized
CA(s), this mechanism allows for the domain owner to configure
multiple CAs in either load-balanced or fallback prioritizations
which improves user preferences and increases diversity in
certificate issuers.




The IETF Secretariat


Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Mike Ounsworth]

Thanks for the comments Fraser.

Guilty as charged -- we were not thinking about private enterprise environments 
when we wrote it; we were thinking about publicly-reachable servers on public 
clouds getting certs from public CAs. In that context, the quote from the 
abstract "at the mercy of their hosting provider as to which Certification 
Authorities (CAs) can be used" is less about the ACME server being reachable in 
a network sense, and more about public hosting providers -- quite reasonably -- 
not wanting to maintain a dropdown menu of every ACME server on the internet. 
Typically if you want to use a CA other than the single one that your hosting 
provider knows how to ACME to, then your only option is to manually upload a 
PEM file. Yuck. The other assumption here is that this draft is really for 
domain owners who care enough about where their certs come from to have a 
"favourite CA" because people who don't care will be happy to use whatever 
default ACME server.

That said, it's interesting to think about how this could apply to your 
enterprise problem of "find me /some/ ACME server that I can reach/use in this 
network zone". Assuming a private network with multiple DNS zones, you could 
configure your private DNS to slap on a constant CAA record across a DNS zone, 
and that gives you your "give me an ACME server, any one will do", right?

Out of curiosity, what happened to draft-tweedale-acme-discovery? Did it just 
not have enough momentum to proceed? Searching on the ACME list archive did not 
turn up very much discussion.

---
Mike Ounsworth

-Original Message-
From: Fraser Tweedale 
Sent: Thursday, July 6, 2023 7:40 PM
To: Paul van Brouwershaven 
Cc: Richard Barnes ; Mike Ounsworth ; 
acme@ietf.org
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

On Fri, Jul 07, 2023 at 10:06:15AM +1000, Fraser Tweedale wrote:
> - The main problem solved in my draft was: "in this /network
>   environment/, what ACME servers can/should I use?"  The CAA-based
>   proposal answers a different question: "for this /domain/, what
>   ACME server should I use?"  But (a) why would a domain owner need
>   to control this, and (b) it doesn't actually solve the problem
>   stated in the abstract:
>
>   > This often leaves domain owners at the mercy of their hosting
>   > provider as to which Certification Authorities (CAs) can be used.
>
>   The hosting provider can still control which ACME servers can be
>   reached, regardless of the preferences expressed via CAA records.
>

With respect to (a) - never mind.  I thought about it some more and the answer 
is obvious.  Where a CA authorization (i.e. restriction) exists in the form of 
a CAA record, it is useful to be able to direct a client to the authorized 
issuer(s) for the affected domain(s).

I see that your draft solves a real problem.  But it does not help much in 
enterprise environments, where the question is often "find me /some/ ACME 
server that I can reach/use, or which the administrators prefer".  Two 
different problems, two complementary approaches.

Thanks,
Fraser
Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Fraser Tweedale]

On Fri, Jul 07, 2023 at 10:06:15AM +1000, Fraser Tweedale wrote:
> - The main problem solved in my draft was: "in this /network
>   environment/, what ACME servers can/should I use?"  The CAA-based
>   proposal answers a different question: "for this /domain/, what
>   ACME server should I use?"  But (a) why would a domain owner need
>   to control this, and (b) it doesn't actually solve the problem
>   stated in the abstract:
> 
>   > This often leaves domain owners at the mercy of their hosting
>   > provider as to which Certification Authorities (CAs) can be used.
> 
>   The hosting provider can still control which ACME servers can be
>   reached, regardless of the preferences expressed via CAA records.
> 

With respect to (a) - never mind.  I thought about it some more and
the answer is obvious.  Where a CA authorization (i.e. restriction)
exists in the form of a CAA record, it is useful to be able to
direct a client to the authorized issuer(s) for the affected
domain(s).

I see that your draft solves a real problem.  But it does not help
much in enterprise environments, where the question is often "find
me /some/ ACME server that I can reach/use, or which the
administrators prefer".  Two different problems, two complementary
approaches.

Thanks,
Fraser

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Fraser Tweedale]

Hi all,

Paul, Mike, thank you for publishing the draft.  I am happy to see
ACME service discovery being discussed again.

For compare/contrast, I'd like to bring attention to my draft from a
couple years ago, which proposed a DNS-SD profile for ACME service
discovery, and which I presented at IETF 109:

- https://www.ietf.org/archive/id/draft-tweedale-acme-discovery-01.html
- 
https://datatracker.ietf.org/meeting/109/materials/slides-109-acme-service-discovery-00

Broadly contrasting the approaches, I note the following:

- Use of CAA means that this mechanism is only useful for
  discovering ACME servers for DNS identifiers.  There are ways you
  could work around this but they would use CAA records in improper
  ways.

- The main problem solved in my draft was: "in this /network
  environment/, what ACME servers can/should I use?"  The CAA-based
  proposal answers a different question: "for this /domain/, what
  ACME server should I use?"  But (a) why would a domain owner need
  to control this, and (b) it doesn't actually solve the problem
  stated in the abstract:

  > This often leaves domain owners at the mercy of their hosting
  > provider as to which Certification Authorities (CAs) can be used.

  The hosting provider can still control which ACME servers can be
  reached, regardless of the preferences expressed via CAA records.

Regarding registration of CAA attributes (IANA considerations): they
need to be registered in the "Certification Authority Restriction
Properties" registry:
https://www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml#caa-properties

Cheers,
Fraser


On Thu, Jul 06, 2023 at 06:33:01PM +, Paul van Brouwershaven wrote:
> Hi Richard,
> 
> Thanks for your feedback!
> So if I understand this correctly, the idea is that an ACME client that 
> intends to obtain a certificate for 
> example.com
>  will look up CAA records for 
> example.com
>  and follow the guidance there as to which CA to contact?
> Correct
> Couple of observations on a quick skim:
> 
> A brief "protocol overview" section might be helpful to capture the intended 
> happy-path flow.
> Have you looked at the diagram in chapter 5, ACME Client Behavior?
> https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-01.html#name-acme-client-behavior
> 
> Would you suggest renaming this chapter?
> If folks are annoyed about the .well-known parts (as I am, a little): Since 
> you're going to extend CAA anyway, you could just put a URL in there instead 
> of overloading the CAA domain name.  For example, instead of the `discover` 
> parameter being a boolean, you could just put the URL of the ACME server 
> directory there.  (That would introduce a risk of divergence in the 
> multiple-domain case, different ACME servers for the same CA domain, but that 
> seems like it fails safely.)
> We have indeed considered putting the ACME server directly in the CAA record, 
> as stated in paragraph 4 of chapter 4, ACME Client Configuration:
> 
> While an alternative consideration was to include the ACME server address 
> directly as an attribute parameter in the CAA record, it was determined that 
> this approach could introduce clutter and significantly increase the size of 
> the record. Additionally, a rigid binding between the CAA record and the ACME 
> server address may present challenges if the CA needs to change its server 
> address in the future.
> 
> https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-01.html#name-acme-client-configuration
> 
> In addition to the above, I would argue that the issuer domain name is much 
> easier for users to configure.
> Section 3.1.2 says "the value "1" represents the highest priority", but 
> Section 3.2 includes "the highest priority of 0".  In general, the document 
> should be clear on how the default interacts with explicit priorities.
> Aaron Gable identified the same issue and created a pull request to address 
> and clarify the priorities. I just released a 01 version with these changes.
> 
> 
> From: Richard Barnes 
> Sent: Thursday, July 6, 2023 19:29
> To: Mike Ounsworth 
> Cc: acme@ietf.org ; Paul van Brouwershaven 
> 
> Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
> 
> Hi Mike, Paul,
> 
> So if I understand this correctly, the idea is that an ACME client that 
> intends to obtain a certificate for 
> example.com
>  will look up CAA records for 
> 

Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Paul van Brouwershaven]

Hi Richard,

Thanks for your feedback!
So if I understand this correctly, the idea is that an ACME client that intends 
to obtain a certificate for 
example.com
 will look up CAA records for 
example.com
 and follow the guidance there as to which CA to contact?
Correct
Couple of observations on a quick skim:

A brief "protocol overview" section might be helpful to capture the intended 
happy-path flow.
Have you looked at the diagram in chapter 5, ACME Client Behavior?
https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-01.html#name-acme-client-behavior

Would you suggest renaming this chapter?
If folks are annoyed about the .well-known parts (as I am, a little): Since 
you're going to extend CAA anyway, you could just put a URL in there instead of 
overloading the CAA domain name.  For example, instead of the `discover` 
parameter being a boolean, you could just put the URL of the ACME server 
directory there.  (That would introduce a risk of divergence in the 
multiple-domain case, different ACME servers for the same CA domain, but that 
seems like it fails safely.)
We have indeed considered putting the ACME server directly in the CAA record, 
as stated in paragraph 4 of chapter 4, ACME Client Configuration:

While an alternative consideration was to include the ACME server address 
directly as an attribute parameter in the CAA record, it was determined that 
this approach could introduce clutter and significantly increase the size of 
the record. Additionally, a rigid binding between the CAA record and the ACME 
server address may present challenges if the CA needs to change its server 
address in the future.

https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-01.html#name-acme-client-configuration

In addition to the above, I would argue that the issuer domain name is much 
easier for users to configure.
Section 3.1.2 says "the value "1" represents the highest priority", but Section 
3.2 includes "the highest priority of 0".  In general, the document should be 
clear on how the default interacts with explicit priorities.
Aaron Gable identified the same issue and created a pull request to address and 
clarify the priorities. I just released a 01 version with these changes.


From: Richard Barnes 
Sent: Thursday, July 6, 2023 19:29
To: Mike Ounsworth 
Cc: acme@ietf.org ; Paul van Brouwershaven 

Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

Hi Mike, Paul,

So if I understand this correctly, the idea is that an ACME client that intends 
to obtain a certificate for 
example.com
 will look up CAA records for 
example.com
 and follow the guidance there as to which CA to contact?

Couple of observations on a quick skim:

A brief "protocol overview" section might be helpful to capture the intended 
happy-path flow.

If folks are annoyed about the .well-known parts (as I am, a little): Since 
you're going to extend CAA anyway, you could just put a URL in there instead of 
overloading the CAA domain name.  For example, instead of the `discover` 
parameter being a boolean, you could just put the URL of the ACME server 
directory there.  (That would introduce a risk of divergence in the 
multiple-domain case, different ACME servers for the same CA domain, but that 
seems like it fails safely.)

Section 3.1.2 says "the value "1" represents the highest priority", but Section 
3.2 includes "the highest priority of 0".  In general, the document should be 
clear on how the default interacts with explicit priorities.

Cheers,
--RLB



On Thu, Jul 6, 2023 at 10:55 AM Mike Ounsworth 
mailto:40entrust@dmarc.ietf.org>>
 wrote:
Hi ACME!

This is new business that we would like to add to the agenda for 117.

Thanks,
---
Mike Ounsworth & Paul van Brouwershaven

-Original Message-
From: internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>
Sent: Thursday, July 6, 2023 9:39 AM
To: Mike Ounsworth 
mailto:mike.ounswo...@entrust.com>>; Paul van 
Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>
Subject: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the 
content 

Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Richard Barnes]

Hi Mike, Paul,

So if I understand this correctly, the idea is that an ACME client that
intends to obtain a certificate for example.com will look up CAA records
for example.com and follow the guidance there as to which CA to contact?

Couple of observations on a quick skim:

A brief "protocol overview" section might be helpful to capture the
intended happy-path flow.

If folks are annoyed about the .well-known parts (as I am, a little): Since
you're going to extend CAA anyway, you could just put a URL in there
instead of overloading the CAA domain name.  For example, instead of the
`discover` parameter being a boolean, you could just put the URL of the
ACME server directory there.  (That would introduce a risk of divergence in
the multiple-domain case, different ACME servers for the same CA domain,
but that seems like it fails safely.)

Section 3.1.2 says "the value "1" represents the highest priority", but
Section 3.2 includes "the highest priority of 0".  In general, the document
should be clear on how the default interacts with explicit priorities.

Cheers,
--RLB



On Thu, Jul 6, 2023 at 10:55 AM Mike Ounsworth  wrote:

> Hi ACME!
>
> This is new business that we would like to add to the agenda for 117.
>
> Thanks,
> ---
> Mike Ounsworth & Paul van Brouwershaven
>
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Thursday, July 6, 2023 9:39 AM
> To: Mike Ounsworth ; Paul van Brouwershaven <
> paul.vanbrouwersha...@entrust.com>
> Subject: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
>
> __
>
> A new version of I-D, draft-vanbrouwershaven-acme-auto-discovery-00.txt
> has been successfully submitted by Paul van Brouwershaven and posted to
> the IETF repository.
>
> Name:   draft-vanbrouwershaven-acme-auto-discovery
> Revision:   00
> Title:  Auto-discovery mechanism for ACME client configuration
> Document date:  2023-07-06
> Group:  Individual Submission
> Pages:  16
> URL:
> https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/
> Html:
> https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery
>
>
> Abstract:
>A significant impediment to the widespread adoption of the Automated
>Certificate Management Environment (ACME) [RFC8555] is that ACME
>clients need to be pre-configured with the URL of the ACME server to
>be used.  This often leaves domain owners at the mercy of their
>hosting provider as to which Certification Authorities (CAs) can be
>used.  This specification provides a mechanism to bootstrap ACME
>client configuration from a domain's DNS CAA Resource Record
>[RFC8659], thus giving control of which CA(s) to use back to the
>domain owner.
>
>Specifically, this document specifies two new extensions to the DNS
>CAA Resource Record: the "discovery" and "priority" parameters.
>Additionally, it registers the URI "/.well-known/acme" at which all
>compliant ACME servers will host their ACME directory object.  By
>retrieving instructions for the ACME client from the authorized
>CA(s), this mechanism allows for the domain owner to configure
>multiple CAs in either load-balanced or fallback prioritizations
>which improves user preferences and increases diversity in
>certificate issuers.
>
>
>
>
> The IETF Secretariat
>
>
> Any email and files/attachments transmitted with it are intended solely
> for the use of the individual or entity to whom they are addressed. If this
> message has been sent to you in error, you must not copy, distribute or
> disclose of the information it contains. Please notify Entrust immediately
> and delete the message from your system.
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Mike Ounsworth]

Hi ACME!

This is new business that we would like to add to the agenda for 117.

Thanks,
---
Mike Ounsworth & Paul van Brouwershaven

-Original Message-
From: internet-dra...@ietf.org 
Sent: Thursday, July 6, 2023 9:39 AM
To: Mike Ounsworth ; Paul van Brouwershaven 

Subject: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the 
content is safe.

__

A new version of I-D, draft-vanbrouwershaven-acme-auto-discovery-00.txt
has been successfully submitted by Paul van Brouwershaven and posted to the 
IETF repository.

Name:   draft-vanbrouwershaven-acme-auto-discovery
Revision:   00
Title:  Auto-discovery mechanism for ACME client configuration
Document date:  2023-07-06
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/
Html:   
https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery


Abstract:
   A significant impediment to the widespread adoption of the Automated
   Certificate Management Environment (ACME) [RFC8555] is that ACME
   clients need to be pre-configured with the URL of the ACME server to
   be used.  This often leaves domain owners at the mercy of their
   hosting provider as to which Certification Authorities (CAs) can be
   used.  This specification provides a mechanism to bootstrap ACME
   client configuration from a domain's DNS CAA Resource Record
   [RFC8659], thus giving control of which CA(s) to use back to the
   domain owner.

   Specifically, this document specifies two new extensions to the DNS
   CAA Resource Record: the "discovery" and "priority" parameters.
   Additionally, it registers the URI "/.well-known/acme" at which all
   compliant ACME servers will host their ACME directory object.  By
   retrieving instructions for the ACME client from the authorized
   CA(s), this mechanism allows for the domain owner to configure
   multiple CAs in either load-balanced or fallback prioritizations
   which improves user preferences and increases diversity in
   certificate issuers.




The IETF Secretariat


Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Practical concerns of draft-ietf-acme-ari

[Michael Sweet]

Ilari,

> On Jul 6, 2023, at 5:35 AM, Ilari Liusvaara  wrote:
>> On Fri, Jun 23, 2023 at 1:44 PM Michael Sweet > 40msweet@dmarc.ietf.org> wrote:
>> 
>>> In a somewhat-related situation for printing, we have an event
>>> notification interface (RFC 3996) where the printer can report back a time
>>> interval (in seconds) when the client should re-contact the printer to get
>>> more events.  This is flexible enough to handle both printer/server load
>>> and to let the client now when it should anticipate more events, i.e., the
>>> printer is printing something, the event subscription is for
>>> 'job-completed', and the printer can estimate when the print job will
>>> complete - this is analogous to an ACME certificate's expiration/renewal
>>> date/time.
> 
> The problem is that the renew time can change, and always do so in
> response to unforeseen events.

Sure, which is why you don't specify a huge interval.  Think "Time-To-Live" 
(TTL) values in DNS records.

>>> Personally, the servers I maintain use Let's Encrypt and have a weekly
>>> cron job that checks whether the server's certificate needs to be renewed.
>>> If the ACME server could provide a "retry after" response then my servers
>>> (ACME clients) could do a better job of scheduling the next update and not
>>> bug the ACME server so often...
> 
> That is way too rarely for dealing with revocation. For that, you would
> need twice a day at very least.
> 
> The ACME client I wrote checks 8-9 times a day by default...



I've been managing an admittedly small number of web/mail/etc. servers over the 
last 30 or so years, with encrypted services pretty much as soon as they became 
available.  In that time I remember revoking a certificate once because I'd 
lost the private key somehow, but otherwise the certs I've used have only ever 
been renewed.

If I'm provisioning an instance of some virtual server/container/whatever with 
an X.509 certificate, I *might* want to keep track of revocations more 
frequently, but otherwise I'm managing long-lived (infrastructure) services 
that shouldn't be going through a lot of churn.  Likewise, I'm going to choose 
a trustworthy CA so that I (and the browser developers) don't need to worry 
about doing frequent revocations.

I know that many security professionals get uncomfortable when a known security 
issue is not addressed instantly, but from a scalability and supportability 
standpoint we need to acknowledge that such a standard is impossible.

For standards we might be able to poll the various CAs and come up with some 
general guidance based on the frequency of revocations vs. duration of 
certificates.  But ultimately I'd like to see the CAs provide specific guidance 
(via ARI) that can be applied against local site configuration to better manage 
the load that ACME clients and servers have to bear.

> As for load caused by that, webhooks have usability issues, but I
> suspect polling would cause high load for for huge integrators. 3
> times a day with 50k certs would be ~1.7rps just from ARI.
> 
> Hmm... How much load would ARI cause for Let's Encrypt if everyone
> used ARI? Let's do back of the envelope calculation:
> 
> - ~270M active certificates.
> - ~180M are unreplaced.
> - ~540M checks with 3 checks per day.
> - ~6250 rps.
> 
> Which should be fine even without CDN.

So, you are estimating that 1/3 of all requests will require the issuance of a 
new certificate then?

That's ~2000 certificates/sec which seems like a lot to me.  By default those 
~270M certs will expire in 3 months, so ~90M certs should be renewed/month or 
~3M certs/day or ~35 certs/sec. Some percentage of the ~270M certs will also be 
revoked for whatever reason, but I don't think it will be 2000/sec...

For reference, running OpenSSL in a loop signing cert requests as fast as 
possible yielded an average signing rate of ~60 ECDSA certs/sec or ~12 RSA 
certs/sec on my M1 Max MacBook Pro.  Obviously you can run those things in 
parallel across multiple cores/CPUs but that will only get you so far...


Michael Sweet

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Practical concerns of draft-ietf-acme-ari

[Ilari Liusvaara]

On Mon, Jul 03, 2023 at 07:32:15AM -0400, Deb Cooley wrote:
> We are happy to have more participation in the acme working group.  The
> IETF is based on development of standards by rough consensus.  If you are
> willing to roll up your sleeves and participate (by reviewing/commenting on
> the drafts, and contributing to discussion) we are happy to have you.  It
> is not called the 'acme server' working group.  The working group is only
> as sleepy as we make it.
> 
> I will say that reading pages of a single message serves only to bury the
> lead.  Crafting opinions that are clear and concise get quicker results.
> We are all busy people.

Thinking about that message, the following occured to me:

Is there need for there to be range of renwal times, as opposed to just
a single time?

The client needs to randomly pick a time anway, and do that either
deterministically, or store the time, because doing repeated random
checks is biased.

Instead, the CA could be doing the randomization, maybe even avoiding
times of predictable load spikes (top of hour, and especially all
balls).


And secondarily, there does not seem to be any guidance when it is
appropriate to use the explanation link. It is probably not a good
idea to use it for routine renews, or even maintenance avoidance (due
to amount of noise generated).


> On Fri, Jun 23, 2023 at 1:44 PM Michael Sweet  40msweet@dmarc.ietf.org> wrote:
> 
> > In a somewhat-related situation for printing, we have an event
> > notification interface (RFC 3996) where the printer can report back a time
> > interval (in seconds) when the client should re-contact the printer to get
> > more events.  This is flexible enough to handle both printer/server load
> > and to let the client now when it should anticipate more events, i.e., the
> > printer is printing something, the event subscription is for
> > 'job-completed', and the printer can estimate when the print job will
> > complete - this is analogous to an ACME certificate's expiration/renewal
> > date/time.

The problem is that the renew time can change, and always do so in
response to unforeseen events.


> > Personally, the servers I maintain use Let's Encrypt and have a weekly
> > cron job that checks whether the server's certificate needs to be renewed.
> > If the ACME server could provide a "retry after" response then my servers
> > (ACME clients) could do a better job of scheduling the next update and not
> > bug the ACME server so often...

That is way too rarely for dealing with revocation. For that, you would
need twice a day at very least.

The ACME client I wrote checks 8-9 times a day by default...


As for load caused by that, webhooks have usability issues, but I
suspect polling would cause high load for for huge integrators. 3
times a day with 50k certs would be ~1.7rps just from ARI.

Hmm... How much load would ARI cause for Let's Encrypt if everyone
used ARI? Let's do back of the envelope calculation:

- ~270M active certificates.
- ~180M are unreplaced.
- ~540M checks with 3 checks per day.
- ~6250 rps.

Which should be fine even without CDN.


I suspect that "50k integrator" with single-threaded ACME client case
would be much nastier. Replacing all the certs at 1das per cert would
would take 500ks, which is longer than the 5 day deadline for
revocation (and screwing up DV is 1 day revocation).

(And making concurrent ACME is not trivial, due to order-order and
name-name race conditions.)




-Ilari

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme