search

ietf-wg-dnsop / draft-ietf-dnsop-domain-verification-techniques

IETF draft surveying DNS domain verification techniques.
https://ietf-wg-dnsop.github.io/draft-ietf-dnsop-domain-verification-techniques/
Other
6 stars 9 forks source link

Predictable QNAME #23

Open ShivanKaul opened 2 years ago

ShivanKaul commented 2 years ago

This only really applies for CNAMEs - the label should be unique. TXT records shouldn't have to both with this. Not sure why this is a security concern?

ShivanKaul commented 1 year ago

@shuque @paulwouters any opinions? Will close this out otherwise.

enygren commented 3 months ago

I guess there is the issue that always having a fixed label like "_example_provider" can help an external adversary tell what service providers are being used. Having a less predictable QNAME label like "random_token._example_provider" make it harder to scan.

moonshiner commented 3 months ago

Erik for the second QNAME did you mean "random-token._example_provider" ? I like the idea of making it hard for bad actors scoping things out.

paulwouters commented 3 months ago

If the random token is part of the QNAME, wouldn't it always be hard to scan for? Using a prefix based on service that is known should still not really matter? Eg you can you find SADJSADJGNWRSFDSF._ietf-challange.nohats.ca. ?

moonshiner commented 3 months ago

Erik and I both failed to notice that \<token\> was swallowed by the issue

moonshiner commented 3 months ago

Using such a record format may allow attackers to determine which services the domain owner has deployed. Adding a random label to the beginning of the QNAME would make such efforts more difficult to determine. As an example, instead of using "_-host-challenge.example.com" , a service provider could use "._-host-challenge.example.com"

paulwouters commented 3 months ago

I am still unclear on the issue and proposed fix? I think what is meant is to say: Use "<random>._provider-serviceFoo-host-challenge.example.com" as QNAME if you wish to not leak publicly that someone uses your service where random is different from the actual token data ?

shuque commented 3 months ago

Me too. Is it actually something that we need to hide in the validation record? There are probably many other ways outsiders can find out what application service a domain owner is using. I'm not sure this is a problem we need to solve.

moonshiner commented 3 months ago

I marked it Future Work because I think it couild use some more thinking on this.

enygren commented 3 months ago

I mentioned the scanning aspect in #133 (which is just another use of the multi-provider case)

Another aspect that I didn't mention is that a predictable QNAME makes Kamnisky-stye attacks against the validator easier. This may be enough of a corner case that I'm not sure it's worth mentioning, but maybe it is? (It's also unclear that anything we can do defends against this, as in this attack use-case the Application Service Provider would give the attacker a challenge.)