[cabf_validation] [EXTERNAL]-Re: Question about MPDV and CAA

Thu Jul 6 13:32:05 UTC 2023

Hi Roman,

This proposal aims to strengthen the security of applicable domain
validation practices by making them more resistant to equally-specific
prefix attacks.

While these are network attacks, they represent opportunities for attackers
to exploit weaknesses in BR-approved domain validation methods that can
result in certificate mis-issuance. At Face-to-Face 58, we heard from a
Salesforce representative who observed real-world exploits that covered 21
hijacks over the last 16 months, with over 6 million USD in losses. 11
fraudulent certificates were used in the attacks, issued from 3 different
CA owners.

While I’m not familiar with the notary server example you shared, it is my
opinion that the presentation
<https://drive.google.com/file/d/15e4Z9InYbThwJsDuH0oS7vfXKvdSBzi9/view> (note:
this is not the recording from the F2F, but offers a similar overview of
the problem space) and corresponding research from the Princeton Team [1
<https://arxiv.org/abs/2302.08000> and 2
<https://www.usenix.org/system/files/sec21-birge-lee.pdf>] and others [3
<https://dl.acm.org/doi/10.1145/3460120.3484815> and 4
<https://dl.acm.org/doi/10.1145/3243734.3243790>] identifies an opportunity
for the Forum to help better protect site owners - and that this
opportunity is worth exploring.

Regarding your comments on S/MIME, for now, this proposal is specific to
the TLS BRs - though other Working Groups may choose to consider a similar
implementation.

I hope this helps.

- Ryan

On Mon, Jul 3, 2023 at 12:47 AM Roman Fischer via Validation <
validation at cabforum.org> wrote:

> Dear List-Members,
>
>
>
> I was unfortunately not able to participate in the last meeting as the
> Webex Link in the CA/B wiki was outdated… So please forgive if my questions
> have been discussed but haven’t made it to the minutes yet.
>
>
>
> Multi-point validation: Maybe a stupid question, but aren’t we trying to
> solve a network-layer problem on the application layer? I remember a
> project some years ago that tried to run “notary services” on servers all
> over the world with a browser plugin that would use these notary servers to
> check if server certificates were valid… essentially doing the same as this
> proposal, just from the client instead of from the CA. It never gained
> traction… maybe because such attacks really don’t happen often enough to
> justify the effort or because it’s the wrong approach to the problem… I
> don’t know.
>
>
>
> Also, to use DNS for mailbox ownership validation seems to me like an
> abuse of DNS (how would I get Gmail to include something in their DNS just
> so that I can get an S/MIME certificate on my Gmail email address?).
>
>
>
> IMHO, extending CAA to cover S/MIME certificates is however a good and
> necessary step as the owner of a domain can then decide which CA the
> email-users of that domain can use.
>
>
>
> Kind regards
> Roman
>
>
>
> *From:* Validation <validation-bounces at cabforum.org> *On Behalf Of *Martijn
> Katerbarg via Validation
> *Sent:* Mittwoch, 21. Juni 2023 22:08
> *To:* Pedro FUENTES <pfuentes at WISEKEY.COM>; CA/Browser Forum Validation
> SC List <validation at cabforum.org>; Ryan Dickson <ryandickson at google.com>
> *Subject:* Re: [cabf_validation] [EXTERNAL]-Re: Question about MPDV and
> CAA
>
>
>
> Pedro,
>
>
>
> Just adding my thoughts here. In my opinion items 1, 2 and 3 all tie
> together.
>
>
>
> Say that Company X wants their domains completely secured. They lock in on
> 1 CA, thus setting a CAA record allowing issuance only by CA A.
>
> They’ve chosen CA A, because CA A has disabled DCV through email
> validation (or, have found a way to make this MPDV compliant) and has
> implemented MPDV for both CAA record checking, as well as their DCV options.
>
> So far so good.
>
> But now, Attacker wants to try to obtain a certificate for one of Company
> X their domains. Upon investigation, they notice that Company X only allows
> issuance by CA A, and due to MPDV, they cannot use BGP hijacking as an
> attack vector.
>
> So, Attacker goes instead to CA B. CA B has implemented MPDV for several
> options, but not for email validation. Since Attacker can perform a BGP
> hijack on CA B, they’re able to reroute the email to their own servers.
> Now as Attacker has done BGP Hijacking, they’re also able to spoof the CAA
> DNS record, thus, showing CA B a valid CAA record, for CA B to issue the
> certificate.
>
> As such, while Company X has taken all precautions, a weak link in this
> chain, can circumvent the entry of the checks.
>
>
>
> (And as such, in time I expect we will see Email DCV go away, but probably
> not as the first step of enabling MPDV)
>
>
>
> Regards,
>
> Martijn
>
>
>
> *From:* Validation <validation-bounces at cabforum.org> *On Behalf Of *Pedro
> FUENTES via Validation
> *Sent:* Wednesday, 21 June 2023 19:19
> *To:* Ryan Dickson <ryandickson at google.com>
> *Cc:* CA/Browser Forum Validation SC List <validation at cabforum.org>
> *Subject:* Re: [cabf_validation] [EXTERNAL]-Re: Question about MPDV and
> CAA
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Hi Ryan,
>
> Thanks for the reply. This make things much clear to me.
>
>
>
> My interpretation of your risk scenarios are:
>
>    1. Enabling a CA that allows email validation… this implies that the
>    attacker not only hijacks the network, but also controls the validation
>    email. For me this risk effectively exists, but I’d assume low likelihood
>    (else the email validations methods should be considered insecure and
>    disallowed in the BR).
>    2. Disabling CAA checks such as account binding… considering that MPDV
>    must still be used to prove domain control, I still fail to see the risk
>    here…For example, the attacker could skip some ACME security features… but
>    I’d say that the issuance would still be prevented thanks to MPDV.
>    3. “no-issue” CAA record… again, given than MPDV must still be used, I
>    fail to see the risk.
>
>
>
> Can you please elaborate your comments con scenarios #2 and #3… How the
> issuance could succeed given the fact that MPDV must be still used for
> domain control validation?
>
>
>
> Any security countermeasure must necessarily exist to mitigate a risk
> that, not only exists, but it has a level (combination of impact and
> likelihood) that justifies its mitigation… it’s evident that the impact is
> very high (misissuance), but I’d like to fully understand the risk level.
>
>
>
> Just in case… we are fine deploying distributed CAA checks if required,
> but I’d like to fully understand the rational here… mostly because CA
> systems that are more complex and with critical components distributed in
> the cloud will also increase the attack surface and risks for the CA itself.
>
>
>
> Best,
>
> Pedro
>
>
>
>
>
> On 21 Jun 2023, at 15:18, Ryan Dickson <ryandickson at google.com> wrote:
>
>
>
> Hi Pedro,
>
> Thanks for taking the time to review the proposal - and for your question.
> Also, sorry for the delayed response - I’ve been out of the office for a
> few days.
>
>
> The researchers at Princeton initially advised us to evaluate both domain
> validation challenges and CAA records to add resilience to the issuance
> process. Specifically, the goal was to make it more difficult for an
> adversary to launch what they described as a “downgrade attack.”
>
> For example, let’s consider a domain owner who used CAA to restrict
> issuance to a set of CAs that do not support email-based domain control
> validation because they do not want to allow validation of their domain to
> occur via email. Also, suppose we aren’t checking CAA from multiple Network
> Perspectives. In this case, it’d be easier for an adversary to downgrade
> the issuance process because they would only need to launch one successful
> attack (the perspective used by the CA to establish the primary
> determination) to subvert CAA and allow a CA not included in the set of CAs
> permitted to issue a certificate to the domain to do so. In contrast, if
> CAA was checked across multiple Network Perspectives, the adversary would
> need to launch a global BGP attack to obtain a certificate for the target
> domain (harder to accomplish and not always viable by the adversary, for
> example, they might only have the means to accomplish a local or regional
> attack).
>
> We also see layers of security built on top of CAA, for example, Account
> Binding and Validation Method Binding as specified by RFC 8657. These
> extensions allow organizations to restrict issuance to specific 1) account
> IDs or 2) ACME domain validation methods. Not checking CAA records from
> multiple perspectives allows an adversary to more easily downgrade these
> additional security measures (based on the same approach described above)
> and then target the added attack surface these records were intended to
> eliminate.
>
> The “no-issue” CAA record (i.e., CAA 0 issue “;”) is another example where
> the CAA record has a significant impact on issuance behavior. If CAA is not
> being checked from multiple perspectives, this is another security control
> that can be more easily downgraded than if CAA is being checked from
> multiple perspectives.
>
> As always, other considerations and perspectives are welcome!
>
> Thanks,
> Ryan
>
>
>
>
>
> On Fri, Jun 16, 2023 at 6:43 AM Pedro FUENTES via Validation <
> validation at cabforum.org> wrote:
>
> Hello,
>
> Sorry as most likely this has been already discussed, but as I came “late
> to the party”, there are things that I surely missed.
>
>
>
> About the need to consider CAA also in the MPDV… I’m thinking about this
> and I fail to see the risk we’re managing by doing it. My rational is that
> MPDV, once verifies the domain ownership/control, would also imply that
> records in the DNS (i.e. CAA) are legit.
>
>
>
> The only situation I see where this could apply, is when someone could
> trick a CAA record during the reuse period of a previously validated
> domain, so MPDV could verify proper domain control, but the CAA check that
> must be done for each issuance is faked, but I’d say that faking the CAA
> could have as only logic purpose to enable another CA to issue the
> certificate, and that CA would also need to check the domain control using
> MPDV.
>
>
>
> When you decided to include CAA in the game… what was the logic behind?
>
>
>
> Most likely there’s a good reason that clever people has discussed
> already, so I’d appreciate if you can help me understand better.
>
>
>
> Thanks!
>
> Pedro
>
>
> * WISeKey SA*
>
>
> *Pedro Fuentes *CSO - Trust Services Manager
> Office: + 41 (0) 22 594 30 00 <+41%2022%20594%2030%2000>
> Mobile: + 41 (0) 791 274 790
>
> Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland
>
> *Stay connected with **WISeKey <http://www.wisekey.com/>*
>
> *THIS IS A TRUSTED MAIL*: This message is digitally signed with a WISeKey
> identity. If you get a mail from WISeKey please check the signature to
> avoid security risks
>
>
>
> *CONFIDENTIALITY: *This email and any files transmitted with it can be
> confidential and it’s intended solely for the use of the individual or
> entity to which they are addressed. If you are not the named addressee
> you should not disseminate, distribute or copy this e-mail. If you have
> received this email in error please notify the sender
>
>
>
> *DISCLAIMER: *WISeKey does not warrant the accuracy or completeness of
> this message and does not accept any liability for any errors or
> omissions herein as this message has been transmitted over a public
> network. Internet communications cannot be guaranteed to be secure or
> error-free as information may be intercepted, corrupted, or contain
> viruses. Attachments to this e-mail are checked for viruses; however, we do
> not accept any liability for any damage sustained by viruses and therefore
> you are kindly requested to check for viruses upon receipt.
>
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/validation
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_validation&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=DsWs3jyPLw-2N-fE3sPErWvVPxoF-LYnrcdR9WhZMYA&s=GNSe8xPelzQlUicnJyZ8iRap81lwJpyA2HYpTw9jJsI&e=>
>
>
>
>
> * WISeKey SA*
>
>
> *Pedro Fuentes *CSO - Trust Services Manager
> Office: + 41 (0) 22 594 30 00 <+41%2022%20594%2030%2000>
> Mobile: + 41 (0) 791 274 790
>
> Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland
>
> *Stay connected with **WISeKey <http://www.wisekey.com/>*
>
> *THIS IS A TRUSTED MAIL*: This message is digitally signed with a WISeKey
> identity. If you get a mail from WISeKey please check the signature to
> avoid security risks
>
>
>
> *CONFIDENTIALITY: *This email and any files transmitted with it can be
> confidential and it’s intended solely for the use of the individual or
> entity to which they are addressed. If you are not the named addressee
> you should not disseminate, distribute or copy this e-mail. If you have
> received this email in error please notify the sender
>
>
>
> *DISCLAIMER: *WISeKey does not warrant the accuracy or completeness of
> this message and does not accept any liability for any errors or
> omissions herein as this message has been transmitted over a public
> network. Internet communications cannot be guaranteed to be secure or
> error-free as information may be intercepted, corrupted, or contain
> viruses. Attachments to this e-mail are checked for viruses; however, we do
> not accept any liability for any damage sustained by viruses and therefore
> you are kindly requested to check for viruses upon receipt.
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20230706/a4e7bca7/attachment-0001.html>