On Mon, Feb 21, 2022 at 6:02 PM Ryan Sleevi <r...@sleevi.com> wrote: > > > On Mon, Feb 21, 2022 at 11:38 AM Michel Le Bihan < > michel.lebihan2...@gmail.com> wrote: > >> > I’m not sure I see how 1 addresses this risk by itself. Are you >> thinking about this in isolation, or combined with some other mitigations >> (like RPKI and DNSSEC)? And, if combining, do we really need 1 to bind the >> method, versus something like account binding? >> >> Yes, I assume that there is DNSSEC or the nameserver has RPKI, but the >> website ISP/hosting provider does not. I think that there might be many >> such cases. >> > > I would think that there wouldn't be that many, given the lower cost/risk > of RPKI+ROV vs DNSSEC. > > That said, it sounds like your threat model is assuming DNSSEC and relying > on methods (3.2.2.4.7 - DNS Change and 3.2.2.4.12 - Validating Applicant > as a Domain Contact) exclusively, right? > > That is, methods based on HTTP (3.2.2.4.6, 3.2.2.4.18, 3.2.2.4.19), TLS > (3.2.2.4.20), SMTP (3.2.2.4.2, 3.2.2.4.4, 3.2.2.4.13, 3.2.2.4.14), and/or > (potentially) SIP (3.2.2.4.2, 3.2.2.4.3, 3.2.2.4.15, 3.2.2.4.16, > 3.2.2.4.17) would all be potentially hijackable. However, isn't there also > an assumption here that the registrar and DNS servers are resistant to > hijacks. For example, wouldn't an account password reset flow - which I > think there might be many - defeat the security here? >
Yes, that would indeed defeat the security. But the point of closing down the verification methods is that it closes down potential attack vectors outside of the end users' control: I _could_ currently implement an attack flow that uses BGP hijacking of the IPs of the servers that my A-records point to to receive a certificate using the HTTP verification methods, and get signed certificates at any of the CA's indicated in my CAA records; assuming the CA does no further verification than only what is required in the baseline requirements. We can remove this attack vector completely by limiting the allowed verification methods on my domain to only DNS Change (3.2.2.4.7), but this would currently require specific support from the CA that I have defined in my CAA record (I'm not sure there are CAs that do this). Sure, this might also be implemented through CA account binding (or something similar); but that means that each CA would need to implement their own account binding system; which is not a scalable solution for users, and introduces the same issues as the DNS account reset flow, but now there's one more password that can be compromised. -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAAT_OQsn13oDFOam%3DQFSf_4NYwcR0sYAKdp5xHHefFygggek%2BQ%40mail.gmail.com.
