Re: [Acme] Default to PEM with chain for certificates

[Hugo Landau]

> One of the most common ACME deployment failures observed in practice is
> for servers to be configured to serve only the end-entity certificate,
> without the intermediate certificates. This is a particularly pernicious
> problem because some browsers will still trust the resulting
> one-certificate chain, due to caching or fetching of URLs from Authority
> Information Access. But other browsers will not, resulting in a "works
> on my computer" problem.
> 
> Arguably this configuration is the result of incorrect clients, but we
> should expect that most clients will do the easiest thing. This change
> aligns the easiest thing with the most correct thing.

- What happens to Link rel=up? You've left it in.

- What about certificates signed by an intermediate with multiple
  signers, and thus multiple actual intermediate certificates for the
  same intermediate Subject/public key? I'm not sure but I think there
  was some discussion on the list about using multiple Link rel=up
  headers to express a reverse tree
  (end entity -> { intermediate-signer1 -> signer1
 | intermediate-signer2 -> signer2 }.)

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

Re: [Acme] Simplifying ToS agreement

[Hugo Landau]

> The most likely out-of-band channel is email, right? So the CA would
> send out email informing their customers that there's a new ToS, and the
> customer needs to explicitly agree to it in the next N days, or they
> will be unable to use the service.
> 
> There are a couple of options the CA could ask their customer to do for
> the next step:
> 
>  a) Click a link in the email, read the new ToS, and click "Agree" at
> the bottom.
>  b) Click a link in the email, read the new ToS, and copy and paste the
> new ToS URL into the customer's ACME client config.
> 
> I think (a) is both more user-friendly and more likely to be what a CA
> would actually implement.
I agree that (a) would make sense for many users. However, providing an
e. mail address is not mandatory, and (b) is more automatable anyway. So
I'd expect most users to use (a) and users with large deployments or no
e. mail address registered to at least be able to use (b) if they
wanted.

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

Re: [Acme] Specify account by kid (reg URL) rather than key. #193

[Martin Thomson]

I am inclined to think that this is a good change, on the basis that
it means that the server is minting the identifiers that the client
uses.  I think that Jacob is probably understating the potential for
bugs here.  And key canonicalization is a bad smell.

On 27 September 2016 at 14:51, Jacob Hoffman-Andrews  wrote:
> I understand the concern, but I think that clients already have to store
> a significant amount of state: the ACME directory URL, the private key,
> and the domain names, certificates, and private keys of existing
> certificates. I think that one more item, the account URL, is not a
> heavy burden, especially when weighed against a real flaw in the
> protocol. You could consider it akin to storing a username and password
> for a more traditional login.
>
> All that said, for clients that find it to be a big savings, there is
> always the method of finding the account URL by POSTing again to new-reg
> with the same key.
>
> On 09/24/2016 06:16 PM, Hugo Landau wrote:
>> I'm somewhat against this on the grounds that it introduces unnecessary
>> state into clients (the registration URI), increasing their complexity.
>>
>> ___
>> 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 mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Specify account by kid (reg URL) rather than key. #193

[Jacob Hoffman-Andrews]

I understand the concern, but I think that clients already have to store
a significant amount of state: the ACME directory URL, the private key,
and the domain names, certificates, and private keys of existing
certificates. I think that one more item, the account URL, is not a
heavy burden, especially when weighed against a real flaw in the
protocol. You could consider it akin to storing a username and password
for a more traditional login.

All that said, for clients that find it to be a big savings, there is
always the method of finding the account URL by POSTing again to new-reg
with the same key.

On 09/24/2016 06:16 PM, Hugo Landau wrote:
> I'm somewhat against this on the grounds that it introduces unnecessary
> state into clients (the registration URI), increasing their complexity.
>
> ___
> 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] Default to PEM with chain for certificates

[Jacob Hoffman-Andrews]

One of the most common ACME deployment failures observed in practice is
for servers to be configured to serve only the end-entity certificate,
without the intermediate certificates. This is a particularly pernicious
problem because some browsers will still trust the resulting
one-certificate chain, due to caching or fetching of URLs from Authority
Information Access. But other browsers will not, resulting in a "works
on my computer" problem.

Arguably this configuration is the result of incorrect clients, but we
should expect that most clients will do the easiest thing. This change
aligns the easiest thing with the most correct thing.

Pull request: https://github.com/ietf-wg-acme/acme/pull/194

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

Re: [Acme] Simplifying ToS agreement

[Jacob Hoffman-Andrews]

On 09/24/2016 06:03 PM, Hugo Landau wrote:
>> Very specifically, I am trying to make life easier for clients that
>> hardcode the agreement URL.
> How can hardcoding the URL ever be legitimate?

Sorry, this was one of those worst-case typos. It should have read:
"Very specifically, I am *not* trying to make life easier for clients
that hardcode the agreement URL." I agree that that's not legitimate.


> You've also mentioned that agreement URI updates can never be automated,
> so having an in-band mechanism for agreement *update* (as opposed to
> initial assent at registration time) is pointless, but this isn't true.
> If a client user is informed of a new URI before it is deployed via an
> out-of-band channel, they may be able to configure their clients ahead
> of time to recognise and assent to it whenever they do see it. This
> could be automated if a large number of client instances are used; the
> only non-automatable work is a per-URI human-triggered approval.

The most likely out-of-band channel is email, right? So the CA would
send out email informing their customers that there's a new ToS, and the
customer needs to explicitly agree to it in the next N days, or they
will be unable to use the service.

There are a couple of options the CA could ask their customer to do for
the next step:

 a) Click a link in the email, read the new ToS, and click "Agree" at
the bottom.
 b) Click a link in the email, read the new ToS, and copy and paste the
new ToS URL into the customer's ACME client config.

I think (a) is both more user-friendly and more likely to be what a CA
would actually implement.

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

Re: [Acme] Separate Certs instead of SAN to decrease DDOS risk?

[Daniel McCarney]

> By issuing a single certificate with Subject Alternate Names to cover
multiple domains, LetsEncrypt can leak the IP of an origin server that is
behind a service such as Cloudflare. This increases the risk of DDOS attack.

I echo Hugo and Rich's position that ACME is the wrong place to solve this
particular problem.

It's also worth noting that certificate attributes are just one way[0] that
your origin might be discovered by an adversary attempting to bypass your
CDN/WAF.

[0] https://cloudpiercer.org/paper/CloudPiercer.pdf

On Sat, Sep 24, 2016 at 8:51 PM, Bryan Jones  wrote:

> Summary:
>
> By issuing a single certificate with Subject Alternate Names to cover
> multiple domains, LetsEncrypt can leak the IP of an origin server that is
> behind a service such as Cloudflare. This increases the risk of DDOS attack.
>
>
> Scenario:
>
> 1. I run a VPS that, through Apache Virtual Hosts, serves content for 5
> websites. All five sites are secured with LetsEncrypt.
>
> 2. Suppose that two of those websites are protected by Cloudflare. The IP
> address of my origin server is hidden and public traffic can only resolve
> my DNS to the IP address of Cloudflare’s server for these two websites.
>
> 3. By pulling up the LetsEncrypt SSL certificate in my browser, I can see
> all five of my websites listed in the Subject Alternate Name field. An
> attacker could reasonably assume that these sites might be related (i.e.
> running on the same server). Using that information, the attacker could
> resolve the DNS for each of the five sites and note that three of them
> resolve to a non-Cloudflare IP. The attacker now has the IP address of the
> origin server that is supposed to be protected by CloudFlare.
>
>
> Suggestion:
>
> Is it possible for LetsEncrypt to (optionally?) issue one SSL certificate
> per domain instead of using SAN?
>
>
> Reasoning:
>
> It’s very common for a single server to host several different websites
> through Virtual Hosts. It would be ideal if LetsEncrypt did not “leak” the
> fact that those websites are all related.
>
>
> Alternate Ways To Mitigate:
>
> 1. Ensure that ALL websites using the same LetsEncrypt certificate are
> protected by Cloudflare and that none of them have any CNAME aliases that
> can resolve to the origin server’s IP.
>
> 2. Run a separate server for each website.
>
>
> -Bryan
>
> ___
> 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