Subject: Re: [Acme] ACME draft is now in WGLC.

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 7 Mar 2017 03:15:11 +0000

On Tue, Feb 07, 2017 at 05:27:48PM +0000, Salz, Rich wrote:

> I put the time period as six weeks, which takes us to just around IETF-98...
> 
> PLEASE reply on list if you will review and/or are interested in working on interop. 

I see there's no reference to use of DNSSEC resolvers by CAs that
implement DNS challenges.  Just a suggestion to send probes from
multiple networks to avoid MiTM attacks, which seems rather weak
to me.  The MiTM might be collocated near the victim rather than
the CA.

There was some brief discussion of DNSSEC back in Oct/2015:

    https://www.ietf.org/mail-archive/web/acme/current/thrd3.html#00561

	https://www.ietf.org/mail-archive/web/acme/current/msg00561.html
	https://www.ietf.org/mail-archive/web/acme/current/msg00562.html
	https://www.ietf.org/mail-archive/web/acme/current/msg00563.html
	https://www.ietf.org/mail-archive/web/acme/current/msg00564.html
	https://www.ietf.org/mail-archive/web/acme/current/msg00565.html
	https://www.ietf.org/mail-archive/web/acme/current/msg00729.html

but no further action.  Is there a compellng reason to avoid
requiring acme CAs to spin up a validating resolver?  It does not
seem like a lot to ask.  If a domain is DNSSEC-signed then its ACME
challenge should IMHO be validated via DNSSEC.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 7 Mar 2017 03:20:23 +0000

> challenge should IMHO be validated via DNSSEC.

Specifically, it 10.3 use of DNSSEC is a RECOMMENDATION, not a
requirement:

    https://tools.ietf.org/html/draft-ietf-acme-acme-05#section-10.3

I would have expected a requirement here.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 Mar 2017 03:46:00 +0000

> I would have expected a requirement here.

The WG consensus has been for recommendation.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Mar 2017 20:14:10 +0000

> The WG consensus has been for recommendation.

I've had complete disinterest in CAA which initially was accepted
by CA/B forum as a "recommendation", which meant that the constraint
was meaningless.  Rumour has it that CAA will soon be a requirement,
so I've now published CAA records.  The CAA check is/was easy to
make and crippling it by not making it a requirement was IMNSHO a
mistake.

Similarly, using a DNSSEC-capable resolver is by no means rocket
science, much of the world is doing just that via Google's,
Verisign's, ... open resolvers.  Leaving the CAs wiggle-room to
avoid what should be standard practice by now makes no sense.

I urge the WG to reconsider.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 13 Mar 2017 20:17:05 +0000

> Rumour has it that CAA will soon be a requirement

It just passed their balloting so CA/B forum now requires it.  See the LAMPS WG thread(s) on CAA erratum 4515.

> The CAA check is/was easy to make and crippling it
> by not making it a requirement was IMNSHO a mistake.
...
> I urge the WG to reconsider.

Does anyone else agree with Viktor?  Please speak up on the list this week if so.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 13 Mar 2017 14:00:40 -0700

As Rich said, the CA/Browser Forum has indeed voted to mandate CAA. Hooray!

> make and crippling it by not making it a requirement was IMNSHO a
I think by this you mean that the CA/Browser Forum should have mandated
CAA support in its Baseline Requirements, back when it first adopted CAA
as "recommended." Is that right?

I think the analogous goal here is that you'd like the CA/Browser Forum
to mandate use of a DNSSEC-validating recursive resolver during
DNS-based validation procedures. That's great! However, I don't think
mandating use of a DNSSEC-validating resolver in the ACME spec will
achieve that goal, since the CA/Browser Forum is not planning to mandate
use of the ACME spec.

I realize that the CA/Browser Forum seems relatively opaque and hard to
participate in, but if you check their bylaws it is possible for any
member of the public (not just a CA or a Browser) to directly
participate in the mailing list by submitting a simple form. I'd
encourage you to get involved!

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Mar 2017 05:13:10 +0000

> as "recommended." Is that right?

Yes.

> DNS-based validation procedures.

No, dragging the CA/B forum into this discussion (by way of analogy)
was perhaps a mistake.  I am trying to say is that wiggle room to
not do DNSSEC ACME serves no purpose.  ACME should *require* DNSSEC
resolvers in *ACME conformant CAs.

> That's great! However, I don't think mandating use of a DNSSEC-validating
> resolver in the ACME spec will achieve that goal, since the CA/Browser
> Forum is not planning to mandate use of the ACME spec.

Convincing non-ACME CAs that issue DV certs do use DNSSEC for DNS
challenges is a separate issue (windmill for my Quixotic battles)
and is out of scope for this group.  So one thing at a time, I urge
the ACME WG to require DNSSEC for DNS challenges, so that security
of DNSSEC signed domains is not downgraded by ACME CAs negligently
running security-oblivious resolvers.

-- 
	Viktor.

---

From: Hugo Landau <[email-masked]>
Date: Tue, 14 Mar 2017 16:24:26 +0000

> Does anyone else agree with Viktor?  Please speak up on the list this week if so.

I'd agree that the CAA check should be made mandatory. At least, I can't
think of any good reason why it shouldn't be.

I'd also agree that the use of a DNSSEC-validating resolver accessed via
a trusted network (preferably localhost) should be mandatory.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 14 Mar 2017 14:24:56 -0400

> think of any good reason why it shouldn't be.

I very strongly disagree.  What checks the CA does before issuing is up to
the CA's policy.  This document provides tools for CAs to do those checks;
it does not constrain what CAs do.

> a trusted network (preferably localhost) should be mandatory.

Likewise.

--Richard

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 18 Mar 2017 13:08:21 -0400

On Tue, Mar 14, 2017 at 2:24 PM, Richard Barnes <[email-masked]> wrote:

> ​​

​If that were so, why does ACME have any support for DNS validat​ion? It is
merely CA policy after all.

The point of CAA is that it is the one mechanism that is provided to allow
domain owners to signal to third parties what parties they authorize to
issue certs.

In my view CAA should be mandatory for the reasons above.

The other reason for making CAA mandatory is that if we are going to fully
automate the issue process, we might well want to use information in the
CAA records to facilitate that. That was the reason I thought Paul
Hoffman's idea of using the DNS name rather than a policy oid or some PKIX
identifier was the right approach.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 20 Mar 2017 12:10:20 -0400

On Sat, Mar 18, 2017 at 1:08 PM, Phillip Hallam-Baker <[email-masked]
> wrote:

>> I very strongly disagree.  What checks the CA does before issuing is up
>> to the CA's policy.  This document provides tools for CAs to do those
>> checks; it does not constrain what CAs do.
>>
>>
>>
> ​If that were so, why does ACME have any support for DNS validat​ion? It
> is merely CA policy after all.
>

This specification has always been focused on providing tools for CAs,
*not* on constraining what CAs must do.  What MUSTs there are in the
specification are to make clear the mechanisms that the specifications
define, not to specify CA policy.

CAA is clearly on the other side of that line -- it's not a part of the
mechanisms we define in this specification, but a totally separate
mechanism that CAs apply to vet requests.  It's much more like high-value
name checking than DNS validation.

I would be fine adding a line to the "CA Policy Considerations" section
[1], which is where other similar things have gone.

To be clear: I think CAA checking is a good idea, and I'm delighted that
CABF recently decided to require it [2].  I just don't think it's
appropriate for ACME to require it.

--Richard

[1] https://ietf-wg-acme.github.io/acme/#rfc.section.10.5
[2] https://cabforum.org/pipermail/public/2017-March/009988.html