[Servercert-wg] Transitive Trust and DCV (was Re: Ballot SC-080 V1)

[Tim Hollebeek]

Yes, if you read between the lines of my email, you’ll see that I acknowledge that the design goals have changed in the last six years … it’s why I think a reanalysis might actually be prudent. We’ve learned a lot.

 

Part of the reason the BRs are currently so domain-control centric is that many of the older “ownership” based methods have been removed. Some of them by me 😊

 

But if we want to specify new design goals instead of the old ones, I think we should do so explicitly and not implicitly, otherwise everybody will be secretly thinking slightly different things, and we’ll have endless arguments about whether methods need to be removed because they offended George’s sensibilities but not John or Paul’s, and who knows what Ringo thinks about all this silliness.

 

I think you can sort of already see that playing out in this thread.

 

-Tim

 

From: Aaron Gable <aaron at letsencrypt.org> 
Sent: Tuesday, September 24, 2024 2:57 PM
To: Ryan Dickson <ryandickson at google.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Cc: Tim Hollebeek <tim.hollebeek at digicert.com>
Subject: Re: [Servercert-wg] Transitive Trust and DCV (was Re: Ballot SC-080 V1)

 

Tim,

 

The historic thought to which you refer -- that proof of ownership is stronger than proof of control -- has been clearly shown to be incorrect. Nearly all of the proof of ownership methods require communication with a Domain Contact, and all of the methods of discovering and communicating with a Domain Contact (namely WHOIS, DNS SOA, and direct contact via unspecified means with the Domain Name Registrar) are at least as vulnerable to MITM/hijacking/takeover as any proof of control method. At best, they only show "instantaneous ownership". The Validation Summit Findings <https://docs.google.com/document/d/1aJiOzYVTpoAPVWDucnp20cTO2PR_cRsHncvkhlrcR10/edit>  from 2018 don't make an argument otherwise.

 

To the contrary, I am making the opposite claim: that these "proof of ownership" methods are currently weaker than their sibling "proof of control" methods, precisely because of how under-specified the method for finding the Domain Contact is.

 

- Using DNS SOA is largely equivalent to the similar methods which use DNS TXT or CAA records to convey a contact address, so that's good.

- Using WHOIS has just been shown to be suspect for data quality reasons, but it is also an unencrypted and unauthenticated protocol which comes with its own risks.

- Direct contact with the Registrar has the potential to be reasonably secure or wildly insecure depending on how it is implemented.

 

And of course, because all of these are just methods of looking up the Domain Contact, they are not subject to MPIC, and so are now notably more vulnerable to BGP hijacks than other DCV methods (including the DNS TXT and CAA methods that DNS SOA would otherwise be comparable to).

 

Finally, all of these methods have a second point of vulnerability that simply doesn't exist for the proof-of-control methods: the random token must be kept secret. There is no analysis where two methods that are nearly equivalent, but one requires a secret to be kept and the other doesn't, have the same security properties.

 

Now, I'm not actually advocating for all of the Domain Contact-based methods to be removed. I think that would be a somewhat extreme position, and one in which I have no personal stake as the CA that I represent doesn't use those methods. But I think we do need to carefully consider the ways in which Domain Contact information is acquired, and cease thinking of these methods as somehow stronger than their peers just because they purport to validate something more permanent than "instantaneous control".

 

Aaron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240924/099d49e3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5231 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240924/099d49e3/attachment-0001.p7s>