Hi Jacob, On Thu, Jul 20, 2017 at 11:46 AM, Jacob Hoffman-Andrews <[email protected]> wrote: > > 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!
Great! We will be happy to reach out to you in a separate thread if you are interested in reading a draft version, and providing some feedback? > > 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! Thanks for the suggestion about the IETF draft, we will look into. I do not think anyone of us has any prior IETF draft experience, so hopping onto an existing one would be the better option for us :-) >From our other response to Ilari: Our definition of stale DNS seems be slightly different or broader than yours: specifically, we also consider domains as stale for which there is only A record, and not only cases in which a single IP address out of multiple might be stale. For instance, a practice we encountered quite often is that VM instances on a cloud provider are freed and the associated IP addresses are released, but the respective DNS records are not updated for some days. In turn, someone else can claim the same IP address and then request a certificate for the domain. In practice, some hours are often sufficient to claim a released address to successfully launch the attack (which might be possible with caching depending on the used nameservers) and we have seen some cases with customer-specific sub-domains being susceptible to the attack (which might be a worthwhile phishing target). We definitely agree with you that requiring all IP addresses they found in DNS to complete HTTP/TLS challenges to combat stale DNS is not a solution, simply for performance and reliability reasons as you mentioned. > > 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. Possibly overly naive, but a solution here could be: * Adapt the HTTP challenge to HTTPS, requiring a valid certificate chain. * Upon receiving a certificate request, offer HTTPS and a second challenge that is considered more trustworthy (DNS? out-of-band?). * Default to attempting HTTPS, fail if the certificate chain is not following the stricter policy. * The remaining challenge is DNS/out-of-band. It would introduce a stricter policy, but would not require changing any language in the current draft, but only require adding two sub-sections: 1. HTTPS challenge 2. How and why to use a stricter policy Furthermore, a CA could default to HTTPS over HTTP if it has issued a certificate to the same domain in the past. Best, Kevin On Thu, Jul 20, 2017 at 11:46 AM, Jacob Hoffman-Andrews <[email protected]> wrote: > 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
