On Thu, Jul 20, 2017 at 11:20:58PM -0700, Kevin Borgolte wrote: > Hi Ilari, > > > > The methods in base spec just fundamentially rely on security of DNS. > > The only way to remove dependence on routing would be: > > > > 1) Deploy DNSSEC and > > 2) Add acme-CAA record restricting validation to DNS. > > This would indeed be an alternative solution to our proposal, as it > would similarly solve the problem of DNS-related issues. However, a > DNS-based solution would not be as practical for most ACME users (yet) > because they might not have full control over their nameservers (the > web interface of their registrar that they might have to use might not > even support CAA), or it might require manual work to renew the > certificate. Further considering regular key renewals, a DNS-based > solution appears to be less practical and could hamper adoption.
Yes, requiring this would have very large impact, so it would be nonstarter. There are substantial amount of DNS APIs that can be used to automate DNS updates for DNS validation, making DNS validation totally automatic (and most of the time DNS validation is used, it is totally automatic). The nasty part would be requiring DNSSec, which is substantially more difficult than automated record updates. > > > For example: Consider that Let's Encrypt is used by a service running > > > a.example.com, where the A record of a.example.com points to 192.0.2.1 and > > > 198.51.100.1, with the record pointing to 198.51.100.1 being a stale DNS > > > record, and 198.51.100.1 being an address for a VM instance in a cloud > > > provider's pool. If an attacker now finds a way to allocate 198.51.100.1, > > > she might also use Let's Encrypt to obtain a valid certificate. The > > > certificate request by the attacker is indistinguishable from the outside > > > and from interpreting the certificate transparency logs from what the > > > legitimate operator would do to fix the service behind 198.51.100.1, which > > > previously went stale. > > > Stale IP addresses cause problems when renewing (however, that does not > > occur that often). Also, due to recent "fixes", IPv6 stale addresses can > > be missed (there are just so many folks with busted DNS configuraiton). > > > > And I think that would also cause large amounts of problems for users > > if the stale record is IPv4 (if it is IPv6, then "happy eyeballs" hides > > the problem). > > We are not 100% sure what you mean exactly here, but for us, the > problem with stale DNS records is not with renewing itself, but with > an attacker exploiting the stale DNS information combined with the > high IP address churn (which we see particularly for cloud providers). I would think that having any stale IPv4 addresses in the RRset would cause major issues for users accessing the site. > > In the "order flow" change, did put the CSR first so one can look up > > the requested key first. However, this would cause major problems if > > trying to change keys (and many (I am not among them) believe that > > rotating private keys often is important). > > Would you mind elaborate where this would cause major problems exactly > when changing keys? The ACME server can detect if the key requested is the same as the last time. > > This would also complicate "disaster recovery" where the previous keys > > are lost (usually due to admin mistake, and backups being AWOL like > > usual). You would not believe how often that happens (and I hear just > > a small subset). > > Correct, disaster recovery would be made slightly more manual by > requiring a second channel to verify the request (e.g., setting a DNS > record in addition to HTTPS). Although this might happen quite > frequently, we strongly believe that we should opt for secure by > default, instead of allowing a practical attack because of disaster > recovery eventualities. The burden of our solution is not significant > in that case (see below) and what is to be expected for recovering > lost credentials (e.g., your email account): a second channel. "slightly"? You obviously have very different definition of "slightly" thn me. At scale like LE, this would have large impact. There would be huge amount of users locked out. They can't (mostly skill) to validate using DNS or any othe second factor. If I knew I was dealing with anything like that, I would basically take HPKP-level precauntions (which are far beyond most users). And which will lock the key in place (well, the key would be locked for me anyway) Basically, I think this would cause huge amount of problems for users without much gain, hurting HTTPS adoption greatly. -Ilari _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
