[Acme] Perspective on validation

[Phillip Hallam-Baker]

The discussion on validation on different ports suggests that we have the
wrong understanding of what validation is for.

All that is required to validate a certificate holder under the Basic
Requirements is to prove they have control over a domain. This is also the
minimum required.

The port number is irrelevant, either you have control or you don't.


This is even more important when you try to extend ACME to email. Because
then you end up with a hierarchy.

The domain name holder for example.com controls al...@example.com,
b...@example.com, etc. and so they can get a cert for any of them. But Alice
does not control example.com but she does control al...@example.com.

So the domain name holder may be able to get an intermediate CA with
constraints to issue only client certs for *@example.com using DV
validation. Alice, an account holder can only validate for al...@example.com
and can only get an EE cert.


We seem to keep re-opening discussions on this topic as new people join in.

ACME validation is also necessarily constrained to issue for public CAs.
the problem is very different if you are doing a private, internal CA. You
can get much stronger validation, much more easily because you control the
horizontal and the vertical.

ACME is developing a certificate validation and provisioning protocol for
an infrastructure that was originally designed 25 years ago. The basic
principles of the WebPKI were established and fixed in deployed code in
1995. Trying to redefine how that system works twenty years later without a
major requirement driving the change is futile.

X.509 is not tied to a particular layer in the stack. But the WebPKI is
tied to the application layer. Strictly speaking it was conceived as being
the interface between layer 7 and 8. The interface between the Internet and
the 'real' world back in the days before the Internet was the real world.
Port numbers are a transport layer concept.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Support for domains with redundant but not immediately synchronized servers

[Manger, James]

>> Ideally, it [Let's Encrypt] would use the IP of the 
>> requester (of course only after it has verified that the IP is in the
>> DNS) or allow the requester to specify a preferred IP.

This is quite a sensible feature request from Jonas. It supports multiple 
servers for a domain while encouraging keys that are tied to a single piece of 
hardware, without adding extra coordination requirements. It doesn't feel too 
onerous for CAs to implement.

> There's a fairly good solution available with the current protocol, which is 
> to serve a (long lived) redirect from /.well-known/acme-challenge/ on all of 
> the servers to a different URL that is always answered by the machine you run 
> an ACME client on.

This redirect-based workaround feels far from ideal. It assumes 1 server does 
all the ACME bits, which discourages per-hardware keys. It requires more 
coordination between servers (1 is different; others need its IP; need some 
extra mechanism to distribute key+cert once issued). Section 9.2 "Integrity of 
Authorizations" [draft-ietf-acme-acme-01] warns that an ACME CA following 
redirects can be risky as a web site might have a catch-all redirect rule. Even 
worse, the spec hints that CAs might not (or must not?) follow redirects at all 
due to the risk when it says: "suppose an ACME server follows HTTP redirects in 
Simple HTTP validation…".

App-level redirects might be necessary to cope with some load balancing 
schemes, but specifying that an ACME server must prefer the requester's IP or a 
specified IP from the A/ records DNS returns would still be useful.

--
James Manger


-Original Message-
From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Ryan Pendleton
Sent: Friday, 4 December 2015 8:53 PM

Personally, I think that's a more appropriate approach.

Even if a protocol change was made that allowed an ACME client to pin the 
challenge to a certain IP address, the requested IP may not always be returned 
by the authoritative DNS server. Any type of latency, geo or weighted routing 
algorithm could potentially get in the way.


-Original Message-
From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Peter Eckersley
Sent: Friday, 4 December 2015 7:46 PM
To: Jonas Wielicki 
Cc: acme@ietf.org
Subject: Re: [Acme] Support for domains with redundant but not immediately 
synchronized servers

There's a fairly good solution available with the current protocol, which is to 
serve a (long lived) redirect from /.well-known/acme-challenge/ on all of the 
servers to a different URL that is always answered by the machine you run an 
ACME client on.

Are there any cases where that is sufficiently unworkable to warrant a protocol 
change?


-Original Message-
From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Jacob Hoffman-Andrews
Sent: Friday, 4 December 2015 10:27 AM

I think there are a few possible approaches to domain validation for hostnames 
that resolve to multiple IP addresses:

1) It is sufficient to deploy a challenge response on any IP address.
2) The challenge response must be deployed on all IP addresses.
3) The server tries one deterministic IP address and succeeds or fails based on 
whether the challenge is deployed there.

Let's Encrypt currently does (3), but it's probably the worst of both worlds 
and we should fix it.

Arguably (2) is the most secure, since a single-machine compromise isn't 
sufficient to issue a certificate.

And (1) is the easiest and most user-friendly. I think it's also similar to 
existing practice in the wild.

Jonas, security-wise your proposal is equivalent to (1). Rather than adding a 
preferred IP address to the spec, why not specif that ACME servers SHOULD 
implement (1)? Alternately we could state in the spec that the choice of IP is 
a policy choice of the CA, and lay out the two most reasonable options (1 and 
2).

On Mon, Nov 30, 2015 at 06:17:21PM +0100, Jonas Wielicki wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi list,
> 
> I have asked this in the IRC and was pointed to this mailing list. I 
> tried to get a certificate for klausurschokola.de via Let’s Encrypt 
> during the currently running limited beta (we have the domain 
> whitelisted). The name has the following address records:
> 
> 1800  IN  A   176.9.101.187
> 1800  IN  A   217.115.12.71
> 
> (in addition, there is one  record for each of the machines 
> addressed by the A records)
> 
> As you can see, two different machines are addressed. Those are 
> physically separated machines with different main administrators.
> Both are pulling their web content from the same source, but it is not 
> supposed to be dynamic, so there is no "fast" (order of seconds) way 
> to mirror the content.
> 
> Our wish would be to be able to use different private keys and 
> certificates for both hosts, and renew these independently from the 
> other host. We thought that this would be possible using Let’s Encrypt.
> 
> The