4 ms·

Thanks for taking a look. I think you might have missed an important part of this (perhaps I overlooked to explain this part more thoroughly) – the "verifiable

Thanks for taking a look. I think you might have missed an important part of this (perhaps I overlooked to explain this part more thoroughly) – the "verifiable identifier" (e.g. telephone number or email address) still needs to be verified by the service provider using usual onboarding methods. An attacker can't just guess the email or telephone to be able to claim the domain on the service.

plagiarist 3y ago
Will an attacker be able to use rainbow tables to uncover emails or phone numbers from the publicly-available TXT record?
- elliottinvent 3y ago
  Great question, thanks. If the Verifiable Identifier is not salted first, and the attacker is determined to match a particular domain to a hash in a rainbow table of hundreds of millions of email addresses / phone numbers, then the answer is yes. So worst case scenario, this could be a way for a bad actor (e.g. a state) to track down the journalist that runs a blog that's critical of a regime. However, people like that would not opt-in to a Domain Verification record in the same way that they don't opt in to having their details published to the website / WHOIS. So I don't think this is a real risk. The bigger rainbow table risk is mitigated by the hash being used in the DNS label. As an example, if the hashed verifiable identifier was simply stored in TXT at: _dv.example.com Then it would be trivial to harvest e.g. 100m Domain Verification records and then match those hashes against a rainbow table (e.g. 500m hashed emails). However, since the hash is used in the label so you would need to run 500m DNS queries per domain (one for each rainbow table hash).
linuxdude314 3y ago
Don’t you see then this accomplishes nothing for the implementer and instead makes them do more work in addition to still requiring the user to add a DNS record? Why would I want to have to validate someone’s phone or email address (not free), when I could use a standard way simply instructing my user to add a particular TXT record. This reeks of NIH.
- elliottinvent 3y ago
  The implementer being e.g. Facebook? If I understand your argument correctly, you are saying: "I'm Facebook, why would I go to the trouble of asking my users to create a Domain Verification record and verifying their email? Especially when this record would then benefit my competitors like Google and Microsoft!?" I think there are a few angles to consider here: 1. There's no additional cost to verification for most service providers, since verification of email and phone is part of the onboarding process. 2. Licensing – if there are lots of domains with Domain Verification records, then there are benefits to Facebook in being able to automatically verify domains (if the DV record has already been setup by another service provider). By licensing the verification technology they could be required to instruct users to create these records. 3. The implementer may actually be a domain registrar like GoDaddy because it will improve the experience for their domain registrants and reduce support overhead for people trying to verify domains with service providers.

plagiarist 3y ago

Will an attacker be able to use rainbow tables to uncover emails or phone numbers from the publicly-available TXT record?

elliottinvent 3y ago
Great question, thanks. If the Verifiable Identifier is not salted first, and the attacker is determined to match a particular domain to a hash in a rainbow table of hundreds of millions of email addresses / phone numbers, then the answer is yes. So worst case scenario, this could be a way for a bad actor (e.g. a state) to track down the journalist that runs a blog that's critical of a regime. However, people like that would not opt-in to a Domain Verification record in the same way that they don't opt in to having their details published to the website / WHOIS. So I don't think this is a real risk. The bigger rainbow table risk is mitigated by the hash being used in the DNS label. As an example, if the hashed verifiable identifier was simply stored in TXT at: _dv.example.com Then it would be trivial to harvest e.g. 100m Domain Verification records and then match those hashes against a rainbow table (e.g. 500m hashed emails). However, since the hash is used in the label so you would need to run 500m DNS queries per domain (one for each rainbow table hash).

linuxdude314 3y ago

Don’t you see then this accomplishes nothing for the implementer and instead makes them do more work in addition to still requiring the user to add a DNS record? Why would I want to have to validate someone’s phone or email address (not free), when I could use a standard way simply instructing my user to add a particular TXT record. This reeks of NIH.

elliottinvent 3y ago
The implementer being e.g. Facebook? If I understand your argument correctly, you are saying: "I'm Facebook, why would I go to the trouble of asking my users to create a Domain Verification record and verifying their email? Especially when this record would then benefit my competitors like Google and Microsoft!?" I think there are a few angles to consider here: 1. There's no additional cost to verification for most service providers, since verification of email and phone is part of the onboarding process. 2. Licensing – if there are lots of domains with Domain Verification records, then there are benefits to Facebook in being able to automatically verify domains (if the DV record has already been setup by another service provider). By licensing the verification technology they could be required to instruct users to create these records. 3. The implementer may actually be a domain registrar like GoDaddy because it will improve the experience for their domain registrants and reduce support overhead for people trying to verify domains with service providers.