_jomo 5 years ago

From RFC8483 [0] "Yeti DNS Testbed", which was published a few hours ago:

> Yeti DNS is an experimental, non-production root server testbed that provides an environment where technical and operational experiments can safely be performed without risk to production root server infrastructure.

In section 5 they publish experience with their IPv6-Only operation.

For example:

> There are reports of a notable packet drop rate due to the mistreatment of middleboxes on IPv6 fragments. One APNIC study reported that 37% of endpoints using IPv6-capable DNS resolvers cannot receive a fragmented IPv6 response over UDP.

Or:

> It was observed that Yeti-Root servers running Knot 2.0 would compress the zero-length label (the root domain, often represented as ".") using a pointer to an earlier example. Although legal, this encoding increases the encoded size of the root label from one octet to two; it was also found to break some client software -- in particular, the Go DNS library. Bug reports were filed against both Knot and the Go DNS library, and both were resolved in subsequent releases.

0: https://tools.ietf.org/html/rfc8483

LeonM 5 years ago

If only I could prepare the Yeti project maintainers for the giant anti-DNSSEC rant that tptacek is going to post here...

  • tptacek 5 years ago

    Why would I bother? These are the DNSSEC true believers, and in some cases the authors of the standard.

    • hazz99 5 years ago

      As a total outsider, what is wrong with DNSSEC? Security extensions seem like a good idea, to the uninitiated. Are there any relevant links I should read?

      • bluejekyll 5 years ago

        Rather than talking about what’s wrong with DNSSEC, let’s focus on what it’s intended to do for security. DNSSEC is a set of related DNS record types that allow zones to sign individual records with a key, and chain that back to parent zones.

        In practice, this looks very much like X509 certificate chains, if you’re familiar with those. The intention is to authenticate all data in the DNS graph with the root zones being signed by a root key, and then every sub-zone signing itself and all other sub-zones until you reach the leaf records signed by the current zones DNSKEY.

        Many people take issue with the fact that the root key is a single, long-lived, somewhat weak RSA key, that could be compromised. The general argument is that X509 with TLS is enough authentication of a site one is connecting to, and therefor DNSSEC being somewhat weak, is something unnecessary.

        • tptacek 5 years ago

          The bigger issue is that it adds to the ~50-odd CAs we're required to trust a collection of new CAs --- the owners of commercially relevant TLDs --- who, unlike existing CAs, we can't just kill when we detect misbehavior.

          • teddyh 5 years ago

            X.509 CA’s are problematic precisely because any one of them, no matter how sketchy, can issue certificates for any name. DNSSEC does not have that problem: TLD’s in DNSSEC are restricted to their TLD, and you can decide yourself if you trust the domains in the hypothetical “.sketchy” TLD to be properly DNSSEC signed.

            • tptacek 5 years ago

              And every one of them can be monitored and will be killed if they mis-issue. If Google can kill Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, what hope does some random small CA have? The same thing is absolutely not the case of TLD owners. There is no mechanism at all to "revoke" them. You can't "distrust" them without the entire TLD vanishing from the Internet.

              • toast0 5 years ago

                On the other hand, we implicitly trust the TLD owners to not just take over whatever domains they want. If they change the NS records, they can get a cert issued from their choice of CA, and the CA didn't misissue.

                It seems to me, that we would be in a better place with additional explicit trust on TLD providers, eventually leading towards not needing to trust external CAs.

                • tialaramex 5 years ago

                  Even better, a good CA will actually ask the TLD operator's own authoritative name servers directly for this record - so they can lie specifically to the CA and nobody else, the only record of this bogus response is held by the CA that will be accused of mis-issuance. It's like a locked room mystery.

                  Nobody has admitted to doing this at the TLD level, most of those people take their jobs too seriously to mess with some nobody, but it has been done down at eTLD+1 several times, and of course it's effective. So yes, there is every reason to expect that this could be done by a TLD registry operator.

                • tptacek 5 years ago

                  I don't even understand the premise of this argument. You're in effect saying that we should replace commercial trust roots that are accountable to browser vendors with government-run trust roots accountable to no-one. How could that be an improvement?

                  • toast0 5 years ago

                    My argument is, the TLDs already fully control the domain. Given that they fully control the domain, they can use that to request issuance of a domain controlled certificate.

                    If at the end of the day, the TLD controls everything, I'd rather not have anybody else to worry about.

                    • tptacek 5 years ago

                      That's not true. If Verisign tomorrow altered .COM to temporarily claim a Google name sufficient to acquire a DV Google.com cert, the CA that issued that certificate would be dead the next day.

                      • toast0 5 years ago

                        That's great if you're Google, but if neustar took over my .org domain, any CA would be happy to issue, and I'd be SOL. I don't see a whole lot of difference between that and if they take over my .org and that enables them to issue certs directly through DANE or whatever.

                        • tptacek 5 years ago

                          I don't know what to tell you other than that the mechanisms I'm talking about that protect companies like Google have done more to directly protect smaller companies from these same attacks than DNSSEC has in the 24(!) years(!) Internet standards people have been working on it.

        • teddyh 5 years ago

          > somewhat weak RSA key

          2048-bit RSA is “weak”? If I understand things correctly, 2048-bit keys are considered safe for more than ten years still, and the design of DNSSEC is such that the root keys can be rolled over at any time, so when the time comes, the key can simply be substitued for a stronger one.

          And the comparison with X.509 is unsuitable. The DNSSEC root key could be compromised? How about the fact that if any CA loses its key, the entire X.509 system is vulnerable until that key can be revoked by every single end user?

          • tptacek 5 years ago

            2048 bit keys? What about all the 1024 bit keys that litter the DNSSEC PKI?

            How about the fact that CA keys can be revoked? Google and Mozilla killed one of the largest CAs in the market for misissuance. How do you kill .COM? You think if Symantec had a say in the matter, they'd let Google kill their CA business? How about the fact that weeks after the KSK roll, more than half the Internet still depends on the old root key?

            • teddyh 5 years ago

              > What about all the 1024 bit keys that litter the DNSSEC PKI?

              You’re moving the goalposts. The parent comment was explicitly about the root key. Yes, there are still weak keys below the root, just as there are still weak certifikates with MD5 hashes out there, but that is neither here nor there.

              • akerl_ 5 years ago

                Just to clarify, bluejekyll referred to the root keys as a "somewhat weak RSA key", you pointed out that the root keys are 2048 bit, and tptacek responded pointing out that while the root keys are 2048 bit, the chain between them and basically any site with DNSSEC has 1024 bit keys involved.

                That's not really "moving the goalpost", so much as "a conversation involving more than 2 people".

                I pulled up the chain for cloudflare.com on the grounds that they'd care more than the average site about DNSSEC, and here was the result: http://dnsviz.net/d/cloudflare.com/dnssec/

                So that's a 2048 bit root, and then as the chain passes through .com there's a 1024 bit RSA key, and then they have ECC keys for their zone. If their TLS cert had a hop in the chain that used MD5 hashes, Chrome would be refusing to trust their site.

                • teddyh 5 years ago

                  Firstly, now that the root has a 2048 bit key, I predict that the rest of the TLDs will follow soonish. Previously, the concept was unproven, but now that it has been proven to work, I assume that keys will be rolled and progress will be made.

                  Secondly, as I understand it, a 1024-bit RSA key, while not recommended, is still vastly more secure than an MD5 hash.

                  • akerl_ 5 years ago

                    On the first point: quite a few DNSSEC records use ECC keys, and have for a while. If your hypothesis holds, why not switch the root 2048 bit RSA keys, and those TLD-level 1024 bit keys, for ECC keys?

                    On the second: MD5 is one example, but the browser blacklists SHA1 as well. It also blacklists CAs that behaved poorly in the past, and refuses to use vulnerable ciphers.

                    • teddyh 5 years ago

                      > why not switch the root 2048 bit RSA keys, and those TLD-level 1024 bit keys, for ECC keys?

                      Because this is the first time they ever switched the root key, and they want to observe the effects a bit more first? My prediction assumes that it works and sufficient time will pass. Also, ECC keys are not yet as widely supported by resolvers as RSA keys are. This, too, will require experimentations and time for conversion to be viable.

                      • tptacek 5 years ago

                        You're conceding a huge problem with DNSSEC. Yes, support for ECC isn't great. Either RIPE or APNIC was tracking it and last I saw something like 1/3 of the deployed base can't handle it, meaning effectively that everyone is stuck with the lowest common denominator of RSA and ECDSA. Meanwhile: the p-curve ECDSA that we're talking about seeing deployed is already very outmoded. And, unlike RSA PKCS1v15 signatures, where the concerns are theoretical and not practical, P-curve ECDSA is practically problematic. It could take a decade to get to the 2018 standard for curve security (presumably, a Schnorr-like construction on a curve like 25519).

                        Meanwhile: nobody relies on DNSSEC today. I'm not kidding when I say the root keys could land on Pastebin tonight and almost nobody would have to work late or even get paged.

                        Doesn't it seem just sort of plainly obvious that we should drop a flag on the broken protocol we're looking at now and re-do it properly with modern cryptography?

                        • teddyh 5 years ago

                          > Doesn't it seem just sort of plainly obvious that we should drop a flag on the broken protocol we're looking at now and re-do it properly with modern cryptography?

                          What makes you think that people will support this hypothetical new protocol faster than adding support for good crypto types in DNSSEC?

                          I mean, is that really what you are suggesting as the proper course of action? Throw away DNSSEC and have nothing replacing it until a new protocol is standardized and implemented as widely?

                          • tptacek 5 years ago

                            Because alternative approaches have been deployed far faster than DNSSEC. The obvious example to point to would be DoH.

                            Yes: we should throw away DNSSEC and have nothing replace it until something better is available. Nobody relies on DNSSEC today! I feel like that point just isn't sinking in with you. Take some time and consider its impact. 25+ years after the work started: nobody relies on DNSSEC at all. DNSSEC simply does not matter right now. That's not hyperbole; it's a statement of fact.

                  • tptacek 5 years ago

                    People have been predicting that since before Adam Langley wrote "Why Not Dane In Browsers", and making excuses about the keys that are there. Nobody denies that a 1024 bit RSA key is less bad than an MD5 certificate; it's still quite bad, and, personally, I'd argue, the worst kind of bad --- the kind of flaw that motivates large capital and operational expenditures at intelligence agencies.

                    • teddyh 5 years ago

                      Even if every key below the root were 1024 bits, why would this be an argument against the concept of DNSSEC in general? DNSSEC keys can, by design, be rolled and replaced, and people will replace them as soon as they feel it is reasonably safe to do so.

                      The perfect is the enemy of the good. What is the intended result of advocating for choosing not to adopt DNSSEC? Is this intended result actually likely, or is it more like a boycott for the principle of the thing?

                      • tptacek 5 years ago

                        I don't think I can answer this any more effectively than I did in "Against DNSSEC", linked upthread. I'll just point out that the bad is also the enemy of the good.

                        • teddyh 5 years ago

                          A “bad” which is by design fixable as time passes, is much better than a theoretical “good” which is not currently commonly supported, and isn’t looking likely to be such any time soon.

                          • tptacek 5 years ago

                            I have no idea what you're trying to say here.

                    • belorn 5 years ago

                      Are you saying that with the right amount of budget a 1024 RSA key can be broken today?

                      • tptacek 5 years ago

                        Yes, of course I am. I'd be repeating something Eran Tromer said 10 years ago.

              • tptacek 5 years ago

                No, modern browsers won't honor MD5 (or, for that matter SHA-1) certificates. But there's nothing they can do about 1024 bit RSA keys in DNSSEC. Starting to see the pattern?

          • bluejekyll 5 years ago

            Sorry, weak was perhaps the wrong term, it’s more the management that’s at issue. You can see the sibling comments that of course argue that perspective more accurately.

            • teddyh 5 years ago

              > Sorry, weak was perhaps the wrong term, it’s more the management that’s at issue.

              “weak” was about half of your original argument:

              > The general argument is that X509 with TLS is enough authentication of a site one is connecting to, and therefor DNSSEC being somewhat weak, is something unnecessary.

              If we discount “weak”, let me then reply to the remainder of it:

              Firstly, DNSSEC is not only for web traffic, DNSSEC secures DNS for everything which uses domain names to locate services, not only HTTP. This is a big deal not only for more obscure (not to mention future) protocols, but also for sending e-mail, the MX lookup phase of which is otherwise unsecured.

              Secondly, the general problem with X.509 with rogue CA’s remain, and the only counter I have seen is akin to “but we can close those barn doors really well after each individual horses escape”, and I remain unconvinced.

              Thirdly, how do you prove you own a domain enough to get a X.509 certificate? You answer DNS requests, which is spoofable unless secured by DNSSEC.

              • tptacek 5 years ago

                One of the two major remaining use cases for DNSSEC was in protecting mail infrastructure, which has a less-sophisticated PKI (for lack of a better term) than the web. But the major mail providers --- including Google, Yahoo, and Microsoft --- have given up on DNSSEC (note that none of them are DNSSEC-signed) and have together generated SMTP-STS, which does for SMTP what HSTS does for websites: after a first rendezvous connection, all subsequent connections are protected by continuity rules rather than policy.

                The SMTP-STS standard is explicit that it is motivated by the desire not to rely on DNSSEC.

                The other major use case for DNSSEC is, as you suggest, protecting DV verification. But in the long term, DNS is going to get factored out of domain verification entirely. CAs will eventually (who knows how long it will take, even though the protocols are there) just verify domains directly with registrars using something built on RDAP. In the meantime, there are countermeasures against DNS spoofing (that have the virtue of also working against BGP spoofing, which DNSSEC doesn't fix) that the CAs can (and gradually do) deploy.

                It's hard to see the justification for rolling out an expensive, inferior protocol to mitigate attacks that we're already adequately mitigating today and will in the future decisively address through other means.

                • teddyh 5 years ago

                  The major providers also “gave up” on SRV records for HTTP/2, but that does not make it a bad idea – on the contrary, SRV for HTTP would be a good idea for the rest of us. But not for Google, since not having it cements their position.

                  > But in the long term, DNS is going to get factored out of domain verification entirely. CAs will eventually (who knows how long it will take, even though the protocols are there) just verify domains directly with registrars using something built on RDAP.

                  Get back to me when that actually happens, or looks likely to ever happen. Last I heard, the proposed replacement of WHOIS with RDAP has been put on very thick ice, and it is uncertain what will actually happen.

                  > It's hard to see the justification for rolling out [DNSSEC] (…)

                  In my world, that ship has long sailed. DNSSEC is fully rolled out. I work for a domain name registrar, and more than 30% of all the domains we manage are DNSSEC signed, and we could easily sign another 30% if we wanted to.

                  DNSSEC has long been rolled out. It’s too late to argue that it shouldn’t be.

                  • tptacek 5 years ago

                    People have been claiming DNSSEC is "rolled out" for almost a decade now (amusingly, they said so before the major TLDs were even signed). You're missing the point: nobody uses it. No major tech company even signs their zone. The browsers don't do DNSSEC lookups --- Firefox and Chrome actually removed their support for it.

                    People affiliated with registrars are constantly pointing out how many zones they sign, as if that was any kind of argument at all. Look, nobody doubts that you can build a feature into your stack that automatically signs zones. 30%? Why not 100%? Who cares? That's just theater. What matters are companies actually relying on the protocol. Nobody does, today.

              • bluejekyll 5 years ago

                What comment of mine are you replying to exactly? You seem to have read an awful lot into something where I was trying to help someone understand why there is some conflict here.

                I only mentioned X509 as people are going to be more familiar with that than DNSSEC. The reason I mentioned it was to describe it as having a comparable method for validating the chain of certificates/signatures. It is very similar in that regard to X509 certificate chains.

                I’ve implemented DNSSEC in my own project, so I know the protocol, and I do agree that for MX records, as well as TXT and other record types that we need to validate that the records are authentic, in many contexts. Not just web and not just public internet, where we might want to pin custom trust anchors.

                I can see you are very concerned about this as am I, and if you want to reach out and discuss this in a different forum, I’d be happy to, as I think we have shared interests in seeing this succeed.

                • teddyh 5 years ago

                  > What comment of mine are you replying to exactly?

                  I argued against the argument which you presented in a summarized form, nothing more.

        • auslander 5 years ago

          > TLS is enough authentication of a site

          What about other records? MX, TXT, NS? How they are protected from tampering, both in transit and by rogue DNS servers?

          > weak RSA key

          Better than plaintext, harder to modify, is it not?

          • Fnoord 5 years ago

            > What about other records? MX, TXT, NS? How they are protected from tampering, both in transit

            DNSCrypt, DNS over TLS, DNS over HTTPS.

            > and by rogue DNS servers

            By querying multiple DNSCrypt servers and comparing the results.

            > Better than plaintext, is it not?

            Depends. People are going to assume "I am using DNSSEC so I cannot be vulnerable to DNS poisoning."

            • auslander 5 years ago

              > By querying ... and comparing

              Checking crypto signature is more reliable, imho

              I think best way to go is both, DNSSEC and DoT.

              > People are going to assume "I am using DNSSEC so I cannot be vulnerable to DNS poisoning."

              I'm one of those suckers :D

            • bluejekyll 5 years ago

              Everything you mention as alternatives don’t actually solve the authentication issue. They do make joining the DNS network harder.

              Those technologies authenticate the DNS servers, and encrypt the channels, but they do not authenticate the records.

              We should have techniques for both privacy, DNSCrypt/DoT/DoH, and authenticity, DNSSEC. I won’t offer an opinion on the root key management in DNS, but the underlying technologies for authenticating and signing records in DNSSEC are good.

              • pvg 5 years ago

                What does 'authenticated records' actually get you?

                • bluejekyll 5 years ago

                  That question is so broad. It entirely depends on what you want to use DNS for, and authenticated data allows it to be trusted for more use cases. Right now we have a system that from a security standpoint can’t stand on its own (given the internet community’s fight over DNSSEC), but yet is more widely deployed than pretty much any other protocol.

                  Shouldn’t we harden that, and allow it to be used independently of requiring systems to connect to some other centralized system over HTTPS?

                  • tptacek 5 years ago

                    No. What would the point be? You'd still need TLS. DNSSEC isn't even encrypted, and even if it were, it's still only addressing the name lookup. Meanwhile, TLS was designed to assume the DNS is insecure, and has worked that way for decades.

                    Try a thought experiment: imagine the root DNSSEC keys are published to Pastebin tonight. What happens? What blows up? I think, apart from DNS operators (maybe?), you'll have trouble identifying a company who would have to do anything.

      • pvg 5 years ago
        • auslander 5 years ago

          What a rubbish.

          • __Joker 5 years ago

            Noob here, when it comes to security and dnssec. Can you provide some information why the article is bad or some other source ? Nothing but for learning purpose.

            • auslander 5 years ago

              Look at headers. Highly opnionated, not a single pro statement. A good paper discusses all sides of a subject, no cherry picking. For info, wikipedia is a very good starting resource.

              • pvg 5 years ago

                A good paper discusses all sides of a subject

                Not really. There's plenty of good technical and other writing that is one-sided and opinionated, those things are orthogonal to accuracy and quality. It says 'Against DNSSEC' right on the tin.

                • auslander 5 years ago

                  > good technical and other writing that is one sided and opinionated

                  https://en.m.wikipedia.org/wiki/Scientific_method

                  • pvg 5 years ago

                    I don't see how this addresses anything I've said, sorry.

                    • auslander 5 years ago

                      A good research cannot be 'one sided and opinionated' by definition.

                      • dogecoinbase 5 years ago

                        Why have you failed to address the opposing viewpoint that it can be one-sided? Please stop injecting your personal beliefs into this discussion.

                      • pvg 5 years ago

                        What definition? The presentation of results (and opinions) can certainly be one-sided and opinionated. There are zillions of super-famous, oft-quoted, endlessly referenced papers, essays, articles, you name it that are one-sided and opinionated. That's a really silly criticism.

              • fosco 5 years ago

                You might want to review who wrote that article and its purpose.

                The title conveys what the article is about.... 'Against DNSSEC'

      • Abekkus 5 years ago

        If Thomas isn't responding I will. DNSSEC is an important idea, but not something a company's security department should be terribly worried about implementing just this minute. TLS will take care of most of what you need in that area.

        The most practical concern right now is that DNSSEC isn't even being honored by most clients, so even if you build a solution that you're comfortable with, it will be doing nothing to secure most of your customers' connections. If clients start using DNSSEC more in the future, you'll hear about it.

        • pvg 5 years ago

          A big part of his argument is that it's not, in fact, an important idea.

          • Abekkus 5 years ago

            Calling DNSSEC "worse than nothing" is the part where he overreaches, doesn't engage with valid counterarguments, and just calls his objectors Linux nerds, or true believers; yet he still gets upvoted by some quiet army.

auslander 5 years ago

Seems like all cool heads, not in 'Ban the DNSSEC' camp are flagged.