On Tue, Oct 1, 2019 at 2:28 PM Warren Kumari <[email protected]> wrote:
> > The second scenario you suggest is also something covered by 8555, if > the attacker is able to fully control the network, then they can control > ACME. This is not just the case for IP validation, if an attacker is able > to hijack BGP routes then they are able to complete validation for both IP > and DNS identifiers (there is currently a handful of both academic and > industry work happening to try and mitigate these issues) and is also not > just the case for ACME, any CA that does network based control validation, > automated or not, is susceptible to these kinds of attacks. > > Yup, I've read 8555, but somehow it feels much more scary to have this > happen for IP addresses than for DNS names -- some of this might just > be me being triggered by expectations that addressed get reused (e.g > DHCP), and that e.g someone on the IETF meeting network could iterate > over all addresses, getting certificates for all of the space... > > This still *feels* dangerous to me... > What are the things you might be looking for to address the concern here? The trouble with the scenario you've described basically requires one of two things: - Attackers to be proximate on the 'local' network of the validation target (e.g. ARP poisoning) - Attackers being able to control or influence routing tables as seen by the issuing CA (e.g. BGP poisoning) As Roland mentioned, both of these scenarios are no different than dNSName-bearing certificates. dNSName suffers from issues such as DNS spoofing/fragmentation, as we've seen. However, once the DNS has been translated to an IP by the authoritative server, both scenarios you describe here - ARP spoofing and BGP poisoning - are just as viable to asserting possession of the domain name as they are the iPAddress. It seems that the concern you've expressed here is slightly different than the one you initially raised on the DISCUSS, and that's a question about certificate lifetimes, and how long the assertion between a key and a subjectAltName should be reasonably expected to be valid. The presumption here is that domain names are "long-lived" in some form (e.g. with their annual renewal), while iPAddresses are "short-lived" (e.g. due to DHCP dispatching from pools). Is that a fair expression of the unease you're expressing? In practice, I think the concern you're expressing for IP addresses is actually common for dNSNames too, as discussed on the topic of BygoneSSL ( https://insecure.design ), and that the solutions are largely not in the validation space, but in defining meaningful and sensible profiles. In this respect, an ACME method to support such iPAddress-bearing certificates helps the problem, more than it worsens the problem, by providing coherent and consistent APIs to facilitate shorter certificate lifetimes and clearer management of those certificates. Regardless of the position taken with respect to this draft document, such certificates exist today, are recognized by major Root Stores, and meaningfully help improve security of important services (such as DoH/DoT to the resolver). So, hopefully that suggests it's a net-good to standardize an approach that might be usable, in future policies, to only permit such IP-bearing certificates iff constraints are met, such as reduced lifetimes, automated issuance, etc. Does that help put you at ease, with respect to this document?
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
