Subject: Re: [Acme] Stale DNS and high-risk issuance

From: Tobias Fiebig <[email-masked]>
Date: Wed, 3 Jan 2018 12:48:45 +0000

Hello Ilari,
> [1] Just as example, the following kinds of stuff are (legimately) seen fairly
> often or more:
> 
> 
> - Rolling over the account key for each renewal (this is usually caused
>   by containers forgetting things).
> - Rolling over the TLS key for each renewal (some actually recommend
>   this, I do not). Sometimes with very frequent renewals.
> - Getting multiple certificates with different keys for multiple
>   servers with the same name.
> - Handling validation on separate system and pushing the certificates
>   (and likely the TLS keys too, probably not in safe manner!) to server
>   systems. These systems might utilize HTTP redirects (which HTTP-01
>   does follow) or DNS CNAMEs (which DNS-01 does follow).
> - Users wiping out the TLS keys and account keys (without backup!) to
>   "reset" something (admin mistake).
> - Transferring site between servers and losing the keys (account and
>   TLS) in the process.
> - Users using all sorts of whacky ACME clients that just do not
>   implement anything more than bare minimum for the common case.
> - Users using HTTPS on servers they don't have proper control of
>   DNS for (can't edit records, or can only use very few record
>   types, at worst only A/AAAA, or worse yet, A only).
> 
> Thinking about recovery is rather important. One of the major reasons HPKP
> is so hated is lack of pretty much any kind of recovery.
I am seriously interested in surveying this kind of behavior, not only to quantify it, but also to understand MOs during systems' operation. While some of these cases seem relatively easy to measure (yet sometimes not to distinguish, i.e., cases 1 and 2), others seem to be harder harder to measure, e.g., the 4th case. The main problem here is that this would certainly require cooperation from LE. What are your thoughts on this?

> [2] This was actually one of the major reasons why the PoP challenge was
> removed.
Well, technically it should be sufficient to do the channel over HTTPs to reach the same result in comparison to actually signing the challenge.

Met vriendelijke groet,
 
Tobias Fiebig,
Department Engineering Systems and Services

Informatie- en Communicatie Technologie (ICT)
 
TU Delft / Dept. ESS
Faculty of Technology, Policy and Management (TBM)
Building 31
Jaffalaan 5 - room B3.170
2628 BX  Delft
P.O.Box 5015
2600 GA Delft, The Netherlands
T +31 (0)15 27 85700
E  [email-masked]

Present: Monday t/m Friday

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 3 Jan 2018 19:08:22 +0200

On Wed, Jan 03, 2018 at 12:48:45PM +0000, Tobias Fiebig wrote:
> I am seriously interested in surveying this kind of behavior, not only
> to quantify it, but also to understand MOs during systems' operation.
> While some of these cases seem relatively easy to measure (yet sometimes
> not to distinguish, i.e., cases 1 and 2), others seem to be harder
> harder to measure, e.g., the 4th case. The main problem here is that
> this would certainly require cooperation from LE. What are your thoughts
> on this?

I am not sure one could get much useful information about frequency
of many of these even with full validation and issuance logs from CA
(which one probably can not get).

Well, the point was: Keys get rotated or lost. One needs recovery
method. In worst case, DNS can not be used or recovery needs to be
automatic. Also, nasty hacks like how TLS-SNI is done with most
webservers are really to be avoided.

One obvious way that would not need to deal with recovery would be
validating all global IPs seen, or random subset if there are too
many. However, even this might not be problem free (because IPv6).

> > [2] This was actually one of the major reasons why the PoP challenge
> > was removed.
> Well, technically it should be sufficient to do the channel over HTTPs
> to reach the same result in comparison to actually signing the challenge.

Intestingly, the test certificate method in BRs requires keys to
match. The random number in certificate method was split from that,
and it does not have key-matching requirement.

(ACME as protocol was not designed to be able to really deal with key-
matching requirements).

-Ilari