On Mon, Feb 21, 2022 at 8:25 AM Michel Le Bihan < [email protected]> wrote:
> > Hello, > > I know that this has been discussed several years ago, but I didn't see > any definitive final conclusion. In regards to the recent incident > https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600 > that involved the malicious actor reacquiring a valid TLS certificate, I > think that it might be worth to restart the discussion. > > I know that the recommended solution is RPKI, but should there be other > solutions that would mitigate this issue when RPKI is not deployed? > > Some possible solutions: > 1. Allow restricting validation methods in CAA records > 2. Require CAs to have multiple vantage points > 3. Not issue certificates shortly after suspicious BGP events > 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? 2 is, effectively, unauditable and, at best, a probabilistic defense whose quality varies based on the selection of vantage points. Any attempt to make it auditable (e.g. via documentation about where and how points are selected) functionally serves to document the means to evade. There’s nothing wrong, in theory, but it’s akin to saying “Don’t open links from QR codes”: well meaning advice that, in theory, can mitigate attacks, but in practice, serves to do very little. 3 requires defining suspicious BGP events in a way that’s automateable enough to result in programmatic decision making, with limited false positives (false negatives roughly reduce into the same problem as #2). While there’s certainly interest in post-incident investigation to declare something anomalous, hindsight is 20/20, and typically based on combining perspectives from multiple vantage points. I would be interested to know if there is something technically concrete, formalized, and readily accessible to solve #2 and #3, from the technical experts. My understanding of the state of the art is that it’s generally regarded that, between those two and RPKI (with ROV), RPKI is orders of magnitude easier and more measurable, and with less risk of inducing centralization through “blessed” transit providers/IX viewpoints. Has that state changed? I don’t think advisory recommendations for #2 and #3 do much for mitigating the problem, if only because the weakest link problem of CAs. However, I’d be curious to know if there was more concrete proposals in this area for something that can be objectively and independently quantified, whether as part of an audit or by root program review. At present, it feels a bit like a tiger-repelling rock: yes, rocks can help mitigate the risk of tigers, but when and how is very contextual. > -- 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%3DHGB8c%2BJFKEmzvyGtkvHvwX4fcoe_Sq64VmmpF%2B6ODph2Q%40mail.gmail.com.
