Predictable QNAME

[ShivanKaul]

No description provided.

[ShivanKaul]

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]

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

[enygren]

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]

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]

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]

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

[moonshiner]

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 "<PROVIDER_RELEVANT_NAME>-host-challenge.example.com" , a service provider could use ".<PROVIDER_RELEVANT_NAME>-host-challenge.example.com"

[paulwouters]

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]

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]

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

[enygren]

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.)