On Mon, Feb 21, 2022 at 5:09 PM Ryan Sleevi <r...@sleevi.com> wrote: > > > On Mon, Feb 21, 2022 at 8:25 AM Michel Le Bihan < > michel.lebihan2...@gmail.com> 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? >
Account binding might not be available for certain CAs. I would like it if e.g. CAA would also allow for restricting validation methods: A well-implemented DNS verification method uses DNSSec, which protects against BGP hijacks; whereas (to the best of my knowledge) there is no way to detect BGP hijacks for HTTP- or other certificate requestor client verification (unless DANE is implemented, but this isn't widely deployed). 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. > Although difficult, locality of a resolver can be verified to some degree using a latency-based proof, using the signature of multiple timestamp signing servers Example: if 10 distinct public (but with known location) timestamp signing servers sign increasing requests within half a second, the locality of the requestor is known as being within an average 50ms ping of all of those (or more precise: N1 ms from server 1, N2 ms from server 2, etc.). A seperate set of 10 TsSigServers in a different locale can be used to bind the location of a different response, all assuming high enough signed timestamp precision). 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? > There is RPKI, which uses a certificate/PKI-based approach to the question of who is allowed to publish routes for certain prefixes. This makes certain prefixes 'bgp-hijacking-proof' for some definition of 'proof': If your ISP and all ISPs in between you and the client implement RPKI correctly, then your route to the client is guaranteed to be authorized by the owner of that prefix (excluding the possibility of key compromise). Sadly, not all infrastructure providers have implemented RPKI yet (see also: https://isbgpsafeyet.com/), but it doesn't seem impossible (or implausable) to require a CA to do validation from RPKI-protected (and filtering) endpoints. 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 " > 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/CAErg%3DHGB8c%2BJFKEmzvyGtkvHvwX4fcoe_Sq64VmmpF%2B6ODph2Q%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHGB8c%2BJFKEmzvyGtkvHvwX4fcoe_Sq64VmmpF%2B6ODph2Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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_OQsW%3DwFUo9Wx8AoZgmNRtKoZr98VuKLMkesipLxTnBYFkA%40mail.gmail.com.
