Subject: Re: [Acme] kinds of proof

From: Randy Bush <[email-masked]>
Date: Tue, 02 Dec 2014 09:05:24 +0900

>> And it is clear to me that they should be, if we want to see more encryption
>> of traffic. I have no problem with some CAs saying "we'll issue you a cert
>> only if you control port X", but I absolutely want that to be a policy of
>> the CA, not of the enrollment protocol.
> 
> Paul, do you have any examples of CAs that accept any port, or are
> you in part making that up?  Comodo for example, requires control
> of port 80:

or dns

randy

---

From: Peter Bowen <[email-masked]>
Date: Mon, 1 Dec 2014 17:12:34 -0800

>> you in part making that up?  Comodo for example, requires control

Yes, several CAs allow DNS based validation of control.
https://gist.github.com/pzb/3b57ddac91ccf0e4c814 lists several of the
schemes I've seen used.  There is clearly no standard or even
quasi-standard for DNS based validation.

Thanks,
Peter

---

From: Christian Huitema <[email-masked]>
Date: Tue, 2 Dec 2014 01:18:20 +0000

> https://gist.github.com/pzb/3b57ddac91ccf0e4c814 lists several of the schemes I've seen used.  There is clearly no > standard or even quasi-standard for DNS based validation.

To belabor the obvious: if someone somehow controls the DNS entry for the domain, they can put up a MITM attack and "insert" whatever content is suitable for validation.

Consider the following attack: attacker engages an automated transaction with the CA, simultaneously manages to spoof the DNS entry, gets certificate. That should definitely be part of the threat model.

-- Christian Huitema

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 Dec 2014 02:54:38 +0000

> > Yes, several CAs allow DNS based validation of control.

I thought this too obvious to mention, I was talking *additional*
verification methods other than DNS.

> To belabor the obvious: if someone somehow controls the DNS entry
> for the domain, they can put up a MITM attack and "insert" whatever
> content is suitable for validation.

That's not an attack.  If you control the DNS, you control the
domain, which is what DV is supposed to verify.

I'd like to see is that resolvers used by CAs should support DNSSEC,
and for signed domains apply the appropriate checks.  Which then
leaves room for MiTM attacks via the various DV email addresses,
and port 80 checks, which perhaps should be re-considered when the
candidate DV domain is signed.

-- 
	Viktor.

---

From: Peter Bowen <[email-masked]>
Date: Mon, 1 Dec 2014 20:47:37 -0800

> verification methods other than DNS.

Today it is not too obvious, as the requirements that CAs follow do
not explicitly allow DNS based validation of control but do explicitly
allow web page based (http) validation of control.

Obviously fetching a Web page identified by a uniform resource
identifier containing the FQDN requires a DNS lookup, but this is
never mentioned in the current requirements.

Thanks,
Peter

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Dec 2014 09:29:51 -0800

Greetings. It seems that some people want ACME to force a higher level of assurance on the protocol than those of us who are trying to get more authenticated encryption everywhere would want. Given that we still don't have a published Internet Draft (ahem), it would be good to come to agreement early on what is going to be required.

A specific use case that is important to me is someone running a web server on a commercial hoster should be able to get a TLS cert using ACME even if the hoster does not have its own ACME support. The site admin in that case should be able to run an ACME client on their laptop and be able to go through the ACME steps needed to get a cert that they can load into their web site, then tell the hoster to turn on port 443.

If the hoster supports the ACME steps itself, the web admin might not even need to do anything: the hoster can run ACME for them to get the cert. Given that hosters are always trying to cut customer service costs, ACME should allow hosters to automate the cert process to the point where no human interaction is needed after the hoster decides "this site will now use HTTPS".

Proposal:

- ACME clients and servers can be run without human interaction during the ACME exchange itself. All configuration can be done before the ACME client initiates the session, as long as the system running the ACME client has control over the service for which the certificate is being issued. A human may need to make manual changes if their system does not have an ACME setup, but the ACME protocol supports full automation as well.

- A CA must verify that the system on which the ACME client is running can control the service for which the certificate is being issued.

- The system running the ACME client does not have to have control over the DNS service that controls the domain name being used in the requested certificate; however, particular DNS control can be required by policy by an ACME server.

- The ACME protocol has to have expressive enough semantics so that an ACME server can tell an ACME client in detail what policy is causing the ACME server to reject a particular certificate request.

---

From: Peter Bowen <[email-masked]>
Date: Tue, 2 Dec 2014 09:37:18 -0800

> If the hoster supports the ACME steps itself, the web admin might not even need to do anything: the hoster can run ACME for them to get the cert. Given that hosters are always trying to cut custome…

I would also encourage that the case be supported where the "hoster"
controls the DNS but not the content on the site.   This is the
situation for most CDNs and Load Balancing services.  Technically the
CDN/LB could special case responses for a well known path, as it is
handling the HTTP connection, but it is frequently easier to validate
control via DNS.

> - A CA must verify that the system on which the ACME client is running can control the service for which the certificate is being issued.

If the ACME client can change DNS, then it clearly can effectively
control the service (FQDN) for which the certificate is being issued.

> - The system running the ACME client does not have to have control over the DNS service that controls the domain name being used in the requested certificate; however, particular DNS control can be…

I would expect an ACME server can choose to support DNS-based
verification, HTTP-based verification, TLS-based verification, or some
combination thereof.

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Dec 2014 10:01:50 -0800

> handling the HTTP connection, but it is frequently easier to validate

This seems like an important additional use case.

> control the service (FQDN) for which the certificate is being issued.

Yes. The current wording supports the new use case.
 
> verification, HTTP-based verification, TLS-based verification, or some

The current wording supports the new use case.

>> - The ACME protocol has to have expressive enough semantics so that an ACME server can tell an ACME client in detail what policy is causing the ACME server to reject a particular certificate reque…

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Dec 2014 13:27:54 -0500

> Greetings. It seems that some people want ACME to force a higher level of assurance on the protocol than those of us who are trying to get more authenticated encryption everywhere would want. Given…

Well we don't have a draft from the LetsEncrypt folk. But we have a
protocol for automated cert issue that has been in service for several
years now. It is tested and works. We also have plug ins to integrate
to all the major servers. This is a solved problem. The only new part
is making the issue a standard so that the plugin gets integrated into
the servers as native code. Which is of course key to making the
automatic part easy to use.

At the moment deployers have the following choices:

1) Install a certificate on their server following the instructions
provided (20 APP per renewal)
2) Install a plug in that automates the installation and renewal (30
APP one time effort)

If the plug in functionality is integrated to the server then the
number of APP (Administrator Pain Points) decreases significantly,
hopefully it becomes 5 APP or less.

Now I am not suggesting that we simply take the Comodo protocol as is.
It could probably use some work, people want JSON/REST type protocols
(whatever that might mean).

But we don't need to wait on some folk who have yet to set up a
service to document their proposal.

> A specific use case that is important to me is someone running a web server on a commercial hoster should be able to get a TLS cert using ACME even if the hoster does not have its own ACME support.…

That may be possible for the subset of cases where the commercial
provider provides the necessary access. I am not sure how automatic it
can be made without support from the hosting provider though.

> If the hoster supports the ACME steps itself, the web admin might not even need to do anything: the hoster can run ACME for them to get the cert. Given that hosters are always trying to cut custome…

If you want cooperation from the hosting providers then ACME has to be
capable of meeting all the use cases of the providers. Which means EV
and OV certs. It also means being capable of integrating with whatever
account management tools they provide.

> - ACME clients and servers can be run without human interaction during the ACME exchange itself. All configuration can be done before the ACME client initiates the session, as long as the system ru…

Seems reasonable.

> - A CA must verify that the system on which the ACME client is running can control the service for which the certificate is being issued.

Seems we are assuming a particular deployment model here.

> - The system running the ACME client does not have to have control over the DNS service that controls the domain name being used in the requested certificate; however, particular DNS control can be…

Again seems like this is mechanism, not requirements.

> - The ACME protocol has to have expressive enough semantics so that an ACME server can tell an ACME client in detail what policy is causing the ACME server to reject a particular certificate reques…

That seems reasonable.

Meeting that requirement could end up involving cases of the form
'Chosen CA can't issue cert because of CAA record, can't issue because
there is a minimum validation policy of EV, can't issue because of a
prior pinning requirement.'

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 02 Dec 2014 11:36:18 -0800

-----Original Message-----
From: Acme [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Tuesday, December 02, 2014 9:30 AM
To: [email-masked]
Subject: Re: [Acme] kinds of proof

Greetings. It seems that some people want ACME to force a higher level of
assurance on the protocol than those of us who are trying to get more
authenticated encryption everywhere would want. Given that we still don't
have a published Internet Draft (ahem), it would be good to come to
agreement early on what is going to be required.

A specific use case that is important to me is someone running a web server
on a commercial hoster should be able to get a TLS cert using ACME even if
the hoster does not have its own ACME support. The site admin in that case
should be able to run an ACME client on their laptop and be able to go
through the ACME steps needed to get a cert that they can load into their
web site, then tell the hoster to turn on port 443.

If the hoster supports the ACME steps itself, the web admin might not even
need to do anything: the hoster can run ACME for them to get the cert. Given
that hosters are always trying to cut customer service costs, ACME should
allow hosters to automate the cert process to the point where no human
interaction is needed after the hoster decides "this site will now use
HTTPS".

Proposal:

- ACME clients and servers can be run without human interaction during the
ACME exchange itself. All configuration can be done before the ACME client
initiates the session, as long as the system running the ACME client has
control over the service for which the certificate is being issued. A human
may need to make manual changes if their system does not have an ACME setup,
but the ACME protocol supports full automation as well.

[TF] Totally agree with the sentiment. However each ACME client will need
some minimal configuration and I stress minimal. I would submit it should be
possible to use:

1.       The URL of the ACME server

2.       An authenticator to prove this request belongs to a DV RA

That is all we need. The ACME client should be able to use this data to
learn when type of request(s) to build, what parameters to use, then summit
the request with a high confidence it will success because it used the
information from the ACME server to build the request, and install the
certified once issued. The small the bootstrap data set, the less scope for
misstates when repeating across multiple ACME clients. 

- A CA must verify that the system on which the ACME client is running can
control the service for which the certificate is being issued.

[TF] The ACME server would have previously verified the DV RA. The biding
between the RA and the individual request is a form of delegations i.e. this
request belongs to the DV RA. 

- The system running the ACME client does not have to have control over the
DNS service that controls the domain name being used in the requested
certificate; however, particular DNS control can be required by policy by an
ACME server.

[TF] This relates to the type of proof and scope the DV RA used. If the DV
RA used a DNS based POC then the CA can issue names in any subdomain i.e. if
you validated foo.com then you can issue *.foo.com. If the POC was to a
specific URL, then the ACME server can only issue to that same domain name. 

- The ACME protocol has to have expressive enough semantics so that an ACME
server can tell an ACME client in detail what policy is causing the ACME
server to reject a particular certificate request.

[TF] an ACME server can tell an ACME client in detail what is causing the
ACME server to reject a particular certificate request.  Let's not assume
the only failures are policy.

Acme mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/acme>
https://www.ietf.org/mailman/listinfo/acme

---

From: Randy Bush <[email-masked]>
Date: Wed, 03 Dec 2014 05:43:30 +0900

[ statement of obvious ]

if the goal is merely to enable OE, then self signed will do.

[ personally, i trust a self-signed cert about as much as one descending
from one of the 300+ cas who paid to be installed in the browser. ]

"oh, but we want the browser (or mail client or ...) indicator to turn
green."  well then, we need to agree on what that green indicator means
(swamp 1), and then how to 'prove' that the certificate requestor meets
those criteria (swamp 2), and how that proof continues in time.

i am not seeing simple clear guidance through either swamp.

randy

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Dec 2014 14:36:25 -0800

> i am not seeing simple clear guidance through either swamp.

I am not seeking guidance through either swamp either.