On Wed, Jan 03, 2018 at 12:48:45PM +0000, Tobias Fiebig wrote: > 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?
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 _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
