On Tue, Oct 1, 2019 at 5:25 PM Warren Kumari <war...@kumari.net> wrote: > > On Tue, Oct 1, 2019 at 5:09 PM Ryan Sleevi <ryan-i...@sleevi.com> wrote: > > > > > > > > On Tue, Oct 1, 2019 at 2:28 PM Warren Kumari <war...@kumari.net> 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. > > > > Yup, you are right -- it does end up being the same -- and yet, > somehow it still *feels* wrong... > > > > > 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? > > > > Yes, I *think* so, but I still have a gut "I really don't like this" > reaction -- and, annoyingly, I cannot figure out what is triggering > this... Whatever the case, I understand that this is just my personal > hangup, and "Ugh, this makes me twitch" is not actually one of the > DISCUSS criteria -- and so I will either change my position to > "Abstain" (which is non-blocking) or "No Objection".
.... and I've changed my position to NoObjection -- sorry for the drama, and thanks to all for helping me work though my IP address cert neurosis... :-) W > > > 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? > > Only kinda, but I do acknowledge that this is my issue, not that of > the document... I'll change to either Abstain ( in the "I oppose this > document but understand that others differ and am not going to stand > in the way of the others.") or "No Objection". > > W > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
