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

Mon Jun 26 16:10:40 UTC 2023

Let's Encrypt performs multi-perspective CAA checking during initial
validation, when we are also performing multi-perspective domain control
validation. We do not see any particular increase in failure rates due to
CAA checking specifically. It is worth noting that Let's Encrypt does not
do any Authorization Domain coalescing: if a certificate request contains
50 domains all under the same base domain, we will still conduct validation
for all 50 domains individually. So multi-perspective CAA is not causing us
to perform 51 queries instead of 1, it's causing us to perform 100 queries
instead of 50 (from each perspective).

However, if certificate issuance is occurring more than 8 hours after
initial validation, and CAA needs to be re-checked, we then do that
re-checking only from our primary vantage point. This is because many ACME
clients do not support asynchronous finalization, so the CAA recheck has to
happen while the client is maintaining an open connection during its
Finalize call.

Aaron

On Mon, Jun 26, 2023 at 2:30 AM Dimitris Zacharopoulos (HARICA) via
Validation <validation at cabforum.org> wrote:

>
> After revisiting this issue, I somewhat agree with Pedro's assessment that
> for the "Agreed-upon change to website" and "DNS" methods, checking CAA DNS
> records from multiple vantage points is redundant and will only create
> additional cost and delays without any significant security improvements.
>
> To give an example, assume a CA receives a request to include 50 Domain
> Names and the Applicant chooses to use the "DNS Change" Domain Validation
> method. Some of those Domain Names may contain the same Base Domain Name.
> In that case, it is likely that the CA will only need to validate the Base
> Domain Names, but the CAA query must take place for all Domain Names
> requested.
>
> The DNS checks for the Random Value or Request Token would be optimized
> and would result to the least amount of traffic and delay. MPDV would
> protect against BGP hijacking so the Domain Validation is covered, even if
> the CAA records are assumed to be "hijacked".
>
> If the CA is using 3 locations for MPDV (in addition to the main audited
> location), the CAA checks will result in 4 times more traffic (200 queries
> instead of 50), just for the CAA. And that's just for 1 certificate.
>
> Therefore, I would recommend removing the mandatory requirement to check
> CAA records via multiple vantage points in the first implementation of the
> MPDV concept, in order to first evaluate the effectiveness and possible
> issues that will come up. If the group determines that MPDV works as
> designed/expected and that the additional traffic caused is not an issue,
> we could explore adding multiple vantage point checks for CAA records as
> well, but focusing more on the non-DNS/agreed-upon change to website
> methods.
>
> It would also be helpful to hear from CAs that already implement MPDV
> (Let's Encrypt ?) if they also query CAA records from multiple vantage
> points for each issuance and how this has affected their traffic volume and
> resources.
>
>
> Best regards,
> Dimitris.
>
> On 21/6/2023 11:38 μ.μ., Pedro FUENTES via Validation wrote:
>
> Thanks, Martin, for the additional insights.
>
> Yes, tricking CAA to use mail validation is the risk I can see, as other
> methods would rely on MPDV and issuance seems to be prevented as far I can
> see. I was trying to figure out the other situations identified below.
>
> Now about “Since Attacker can perform a BGP hijack on CA B, they’re able
> to reroute the email to their own servers”… I think this is not so
> straightforward as it sounds, because nowadays is more and more rare that
> companies run their own mail servers, but there’s a trend to use cloud
> services for email… so the BGP hijack would need to attack the service
> provider (Amazon, Microsoft and the like), and that’s not so easy as just
> rerouting IP traffic in the CA endpoint.
>
> Anyway, if the conclusion here is that the reason to apply MPDV to CAA is
> that we thunk that e-mail based DCV is unsafe, then I guess we’re opening
> up a Pandora Box… :)
>
> Cheers,
> Pedro
>
> On 21 Jun 2023, at 22:08, Martijn Katerbarg
> <martijn.katerbarg at sectigo.com> <martijn.katerbarg at sectigo.com> wrote:
>
> 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
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wisekey.com%2F&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C453206dbe65948fc195908db727b9eea%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638229647491007545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RCkHjL9dW1XoPxlnQis2WJJq6Lo%2BOnG%2FU4BGa7yTwTE%3D&reserved=0>
> *
>
> *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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__lists.cabforum.org_mailman_listinfo_validation%26d%3DDwMFaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3DAFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc%26m%3DDsWs3jyPLw-2N-fE3sPErWvVPxoF-LYnrcdR9WhZMYA%26s%3DGNSe8xPelzQlUicnJyZ8iRap81lwJpyA2HYpTw9jJsI%26e%3D&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C453206dbe65948fc195908db727b9eea%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638229647491007545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KdHwP%2F6wqizcIHozfWKf022XyDxDxTYfjYhPTLDdXtg%3D&reserved=0>
>
>
>
> * WISeKey SA*
>
> *Pedro Fuentes *CSO - Trust Services Manager
> Office: + 41 (0) 22 594 30 00
> Mobile: + 41 (0) 791 274 790
> Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland
>
> *Stay connected with WISeKey
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wisekey.com%2F&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C453206dbe65948fc195908db727b9eea%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638229647491007545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RCkHjL9dW1XoPxlnQis2WJJq6Lo%2BOnG%2FU4BGa7yTwTE%3D&reserved=0>
> *
>
> *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.
>
>
>
>
> * WISeKey SA *
>
> *Pedro Fuentes *CSO - Trust Services Manager
> Office: + 41 (0) 22 594 30 00
> 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 listValidation at cabforum.orghttps://lists.cabforum.org/mailman/listinfo/validation
>
>
> _______________________________________________
> 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/20230626/996cd42a/attachment-0001.html>