All, In the article, I saw advice about actions that project owners can take to protect themselves, but what about things that CAs or root store programs can or should do? Ben
On Thu, Sep 29, 2022 at 12:16 AM Michel Le Bihan < michel.lebihan2...@gmail.com> wrote: > Recently there was another case of BGP hijacking where an attacker > acquired a TLS certificate: > https://www.coinbase.com/blog/celer-bridge-incident-analysis > Le mercredi 23 février 2022 à 12:53:37 UTC+1, > matt...@thisisntrocket.science a écrit : > >> On Tue, Feb 22, 2022 at 2:30 AM Matt Palmer <mpa...@hezmatt.org> wrote: >> >>> On Mon, Feb 21, 2022 at 06:03:43PM +0100, Matthias van de Meent wrote: >>> > On Mon, Feb 21, 2022 at 5:09 PM Ryan Sleevi <ry...@sleevi.com> wrote: >>> > > On Mon, Feb 21, 2022 at 8:25 AM Michel Le Bihan < >>> michel.le...@gmail.com> wrote: >>> > >> 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. >>> >>> Then don't use those certain CAs, and restrict those CAs from issuing for >>> your domain by not including them the domain's CAA records. >>> >> >> That assumes that there are CAs that implement RFC8657, and that I trust >> for my domains, and would issue certificates for my use cases. >> >> > I would like it if >>> > e.g. CAA would also allow for restricting validation methods: >>> >>> RFC8657 defines the `validationmethods` parameter to the `issue` and >>> `issuewild` CAA properties. Again, if a given CA doesn't support those >>> parameters, you can avoid the problem by not including that CA in your >>> CAA >>> records. >>> >> >> Of the roots in the Mozilla root store [0], only one CPS mentions RFC >> 8657, and that one does not give me any guarantee that it will actually >> limit issuance to only the verification methods in my CAA record: "Google >> may choose to limit issuance according to RFC 8657" (i.e. non-conformance >> to RFC 8657 does not violate their CPS). Additionally, the CPS does not >> provide validation method identifiers to be used for BR validation methods; >> so only ACME validation methods are usable (while at the same time useless >> because there is no ACME endpoint that I could use). >> >> CA/B Forum Baseline Requiremets requiring compliance to RFC 8657 would be >> a great improvement. >> >> - Matthias >> >> >> [0] >> https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport, >> searched each root for CP/CPS queried for "CAA", stopping the search when I >> find a CP/CPS for that root / CA that contains the Issuer Domain Name. >> > -- > 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/b84287a6-94bd-450e-aa6b-49c629cae2ddn%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b84287a6-94bd-450e-aa6b-49c629cae2ddn%40mozilla.org?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/CA%2B1gtabKH4xi5EXUydci0A8WJNZUawxsGWHeWAuJA2tX_uyLvA%40mail.gmail.com.
