On 4/8/16, 12:08, "DNSOP on behalf of Ray Bellis" <dnsop-boun...@ietf.org on behalf of r...@bellis.me.uk> wrote:
>That said, Cloudflare's implementation appears to assert that the >wildcard doesn't exist either - I've asked Olafur to check out the >implications of that. Not to pick, but I'm trying to remove the fact that this is tied to a specific commercial offering. Not because I want to ignore the real world but to maintain proper discipline in thinking this through. Yes, there is an implicit assumption about the wildcard. I would restate it as "the wild card doesn't apply". Or, a "*" label doesn't exist one label below the closest encloser (as defined in "The Role of Wildcards in the Domain Name System" [trying to break the habit of talking in obscure numbers]) of the QNAME. The reason I recalled the MUST NOT is that, for the sake of argument, I wrote it way back when. I hadn't had in mind the wildcard, but, Ray's right. A non-DNSSEC aware zone could be left wondering - although in fairness, before DNSSEC, harking back to "Negative Caching of DNS Queries (DNS NCACHE)" [2308], pre-DNSSEC, negative answers didn't reveal anything about wildcards. I do recall the reason why the MUST NOT clause came into being was so that I could write a signer and keep my sanity. I didn't want anyone to think that they had to generate names just because they thought the name had to say it didn't have any records. There was some other reason too, when eliminating names to sign, perhaps related to empty-non-terminals. They don't have NSEC records. Where I see a root cause for concern is that DNSSEC was designed assuming off-line signing. This means that all negative answers had to be precomputed. With that, and a fairly large range of possible QNAMES, the best approach to say "no" was to say "well, here's what I have, you can see what you want isn't there." NSEC and NSEC3 are both based on that philosophy. With on-line signing, you can craft a response to the incoming QNAME that specifically says "what you want I don't have an answer for." This situation is fighting two uphill battles. One, we are forcing the use of a over-ly constrained container (meaning NSEC designed for not having on-line keys). Two, a zone has to say "no" consistently (this gets into how a zone admin would work out having a set of servers that have on-line signing simultaneous with a set that does not have on-line signing). What if some servers say QNAME NSEC QNAME++ nsec rrsig and another set say ONAME NSEC YANAME types and *.something NSEC somethingelse.something types? I.e., the "black lies" and canonical NSEC. Or if the other uses a canonical NSEC3 response? Will this confuse any attempts to do aggressive use of NSEC? And, not to be throwing FUD but asking out of wild wondering, QNAME mininalization? At first I thought that using NSEC would solve "two" above, but I'm not sure. What I am beginning to wonder about is how we can merge on-line signing and off-line signing DNSSEC within a zone. If we can rule that we can't mix and match, that does change the assumptions regarding what it means to interoperate between server implementations that do not support on-line signing and those that do. The off-line signing assumption of DNSSEC is not because anyone wanted it that way. In the era of the 90's, systems were 0wned so easily that no one dreamed of putting keys on anything on the internet. Today I can see that there is willingness to run with on-line keys - but there are and always will be - strong reasons for some operators to keep the key away from the internet. The choice to do so may work if done zone by zone and not server set by server set.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
