On Mon, Feb 21, 2022 at 11:38 AM Michel Le Bihan < [email protected]> 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? That's not to say there may not be *some* value, but I'm just wondering if the nuanced return here might be more simplified via encouraging more RPKI (e.g. as https://www.manrs.org/ does) -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHEp5ks8VVfMXoH%3DVaGp_oSUpfHU6RGJ_0pJXWVHA-oRUQ%40mail.gmail.com.
