On Tue, Feb 22, 2022 at 2:30 AM Matt Palmer <mpal...@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 <r...@sleevi.com> wrote: > > > On Mon, Feb 21, 2022 at 8:25 AM Michel Le Bihan < > michel.lebihan2...@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/CAAT_OQtMdck-43sCTvWU%3DxHvMhcgPy6kbszS_b_6_XaxJYdgQQ%40mail.gmail.com.
