On 07/20/2017 12:18 AM, Kevin Borgolte wrote: > we are currently conducting a measurement study about DNS staleness > issues with a focus on IP address churning. Excellent, I look forward to reading it! > We encountered the issue that Let's Encrypt (and ACME in general) can > be (ab)used to request and receive a valid certificate for a domain, > as long as the attacker obtains access to the IP address to which the > DNS record points. This is true of HTTP and TLS based validation in general. I think the place to address these issues is not in the ACME standard, but potentially as a separate IETF draft with the goal of later adoption by the CA/Browser Forum. For instance, if HTTP and TLS validation were required to contact every IP address they found in DNS, that would mitigate the stale DNS issue you raise. On the other hand, it would hurt usability and reliability. And my intuition is that truly "high risk" domains (those with lots of users, or important data) do not tend to leave stale entries in DNS, because it would harm performance. Hopefully your study will shed light on that assumption! > We also propose, focusing on high-risk targets, a stricter issuance > policy: > > If a valid certificate (e.g., issued by the same operator or a set of > operators, checked via CT logs) exists for the requested domain, then > the current challenge should be signed by the key. If the last > certificate has expired, a grace period set by operators could apply > (e.g., 1 month or 3 months). If the expiration date has passed a long > time ago, or if no grace period is used by the operator, then a second > channel should be used to verify the request (e.g., DNS CRP). As Ilari mentioned, this was originally in the plan for ACME, but we removed it because it was not fully baked. I think it's definitely valuable to consider a successor as a separate document. Currently the idea I have running around my head is to specify an HTTPS challenge alongside the HTTP challenge, where the server expects to receive a currently valid certificate that chains either to its own roots or to some other roots it chooses to trust. This would be an optional extra level of validation that CAs could apply to domains they consider high risk. Upsides: Easy to implement for the both the CA and the Subscriber. Downsides: If all certificate keys are lost, issuance would be blocked; HTTPS validation still assumes that it's hard for third parties to upload unauthorized files to certain paths on the web server.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
