Automated Certificate Management Environment (acme)

• IETF 117, Monday, 24 July 2023 1730-1830 PDT (0030-0130 UTC) , Room:
  Continental 8-9

• note-taker: Daniel Kahn Gillmor

Agenda

Note Well, technical difficulties and administrivia (chairs) – 5 min

Document Status (chairs) – 10 min

(see chair slides)

Deb Cooley: we'll talk to Brian Sipos to see what needs to be done to
finish ACME-DTN-Node-id

Brian Sipos: the logjam is broken a little bit. dependent documents are
being submitted for review.

Deb: we'll talk (with Roman, our AD) after this.

Work items

draft-ietf-acme-dns-account-challenge-00 (Omidi) - 10 min

Amir Omidi presents.

Brian Dickson: DNSOP has a draft under discussion about doing DNS
validation in the same way that you're discussing here. Might be good to
connect the authors of the two drafts.
(https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-02)
You might also be interested in "domainconnect", which helps service
providers set up records on behalf of registrants. Will send links.
(https://datatracker.ietf.org/doc/draft-carney-regext-domainconnect/)

Shivan Sahib: i'm a coauthor of the draft that Brian mentioned. The goal
is to generalize what acme recommends for domain validation. Why not
just add the label on the left? It would seem to make zone management
easier, zone delegation easier.

Amir: we're working around requirements imposed by the CA/Browser forum.
if you put it on the left, you're validating a different DNS tree, from
the CABForum perspective. There's a risk if you adjust the CABForum
language. For example, a service that gives you a subdomain, one of
their clients might be able to use a weaker form of challenge to take
control of the entire zone. I'll send a pointer
(https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-v2.0.0.pdf).

Tim Hollebeek: if we're talking about CABForum, I want to make sure we
do this the right way, even if that means changing the CAB Forum
baseline requirements. CABForum could change the baseline reqs in two
weeks if we have to. I'll volunteer to write the ballot to amend the BRs
if we decide that's the right thing to do.

Amir: thank you!

draft-ietf-acme-ari-01 (Frank) - 10 mi

Samantha Frank presents.

looks like good progress is made, with many implementations and
deployments.

no questions!

draft-ietf-acme-onion (Misell) - 10 min

Q Misell presents.

Tim Hollebeek: http-01 over onion is something i've never thought about
before. Does it have security properties that could be modified by a
malicious exit nodes? We should think about how these mechanisms to make
sure that it only works securely

Q: onion services never exit the Tor network, so no exit nodes are
involved. Tor should not be used for non onion services.

Daniel Kahn Gillmor: can you build tooling that exposes broken
configurations so an adopting CA could use that to verify that they're
not making obvious mistakes? (e.g. issuing when caa-critical is present)

Q: interesting. I don't know that i can cover all possible broken ways,
but we could maybe do some of them.

draft-vanbrouwershaven-acme-auto-discovery-00 (vanBrouwershaven, Ounsworth) - 10 min

Mike Ounsworth presents.

Mike asked Q how long it took to implement this in Certbot.
Q: Stated that it took about 90 minutes to implement

Rich Salz: This is useful and we should adopt it. It lessens the chance
of a single point of failure if the biggest CA melts down.

Mike: Yes, this will actually ramp up adoption of CAA -- at the moment,
it's a way to break your site, this makes it more actively attractive to
produce it.

Tim Hollebeek: We support this too.

Amir Omidi: I think the reason most providers aren't doing it is because
there aren't many other options in the ACME CA world, without getting an
account binding token beforehand. Does this get more CAs to go the
anonymous route? How are failure modes handled? If CAA says something
that isn't offering ACME, what happens?

Mike: No, this is not trying to get CAs to do more anonymous issuance.
we're offering two ways to bind to an account. For the failure modes:
you can put multiple CAs in your CAA record. The priority order lets you
indicate your preference. What if a CA operates multiple ACME servers?
Use of a SRV record might work.

Deb: How common is it for someone to use a backup ACME server if the
primary one goes down? Is that a thing?

Q: I use google trust services, with failover to Let's Encrypt

Tim: It's not necessarily the case that you can seamlessly switch over,
but major companies are fine with having failovers. There are companies
with 5 of the 7 major CAs.

Daniel Kahn Gillmor: I support adoption. step 1 on slide 42 (where the
ACME client queries their own CAA record) seems like another place where
DNS poison could be a problem. Maybe recommend that the client can
validate the issued cert before it is finally accepted (is it issued
from the expected CA for example). This is an obvious check a client
should do, but it needs to be written down.

Mike: Exactly, the obvious answer is to use DNSSec or DOH. The less
obvious answer is to look at how bad this is.

Samantha: Caddy already does prioritized, fallback to two different ACME
CAs (Let's Encrypt, falling back to Zerossl). Not too worried about the
breakage unless the CA doing the issuance is not following the rules.
Poisoning/hijacking DNS is possible but not trivial.

[Back to Mike's extra slides "issues raised on list"]

Mike: the cloud providers aren't going to be completely happy with
inheriting the terms of service from the client. How this is handled
will have to be clear that the keys/certs are 'owned' by the cloud
client.

Mike: question: If the hosting provider has a menu for uploaded
certificates, could they have a menu for acme URI's? Answer: But they
haven't.

Yoav: Call for adoption will be made on the list.

AOB - 0 min