DNSSEC root key signing ceremony postponed because they can't open a safe
theregister.co.uk
theregister.co.uk
I clicked randomly around in the linked livestream from November and came across what seems to be them having problems with Safe 2. I'm amazed this is streamed and they are actively showing the written pads towards the camera.
"Ceremony" is the right word for IANA's handling of the root zone, which is a McGuffin in the Internet security model; the DNS roots won't be what the IC targets.
You're off base.
DNSSEC is not any more nebulous than the existing structure and control mechanism with regards to domain names. It (mostly) is adding cryptographic under-pinnings to the responses. The control remains the same (registrar level).
Seems to me that exceptions and anomalies like this are the weak points of the system. If I wanted to steal these keys, I would make an effort to create anomalies like this where I might have physical opportunities to glitch the keycards and exfiltrate the data without the whole internet watching me.
The question is: Why would you want to steal these keys? What are you going to do with it?
This is all big theatre around a technology that has barely any meaning in practice. Nothing relevant would break if you publish these private keys on the Internet tomorrow.
Now, having explained that, I'm sure it's quite wrong after spending many years thinking about this (more than 10 years but probably less than 20) and I'll try to briefly explain why.
The DNS is a key source of truth, and so we need to actually secure the DNS hierarchy. Because of the belief Hanno espouses, there have been a lot of attempts to dodge this work over the years but it's the nature of the problem that dodging it can't work, it just moves the problem and then we're back again from a different angle.
DNSSEC is narrowly tailored to solve only the problem we actually had, securing the source of truth, and nothing else. It isn't a privacy technology, or an anti-censorship technology, or a delicious new flavour of ice cream, it just secures the source of truth.
The thing about security is that the Happy Path looks exactly the same whether you have security or not. You've all been here with HTTP. Remember when most sites you visited either didn't use HTTPS or only used it for a "login" step and then kicked you back to HTTP? How often did a site you visited actually have a breach because it used HTTP? Probably never. The happy path, where nobody was trying to steal your credentials or whatever was nearly always the path you were on anyway, HTTP was dangerous but you didn't really feel it. In hindsight that seems crazy but people put up with it for years.
For DNS we're still in that dark period, and unfortunately lots of people are wrongly confident that it's for the best.
I’d be happy for a proposal that aimed to improve the threat model for network connections, but DNSSEC does not do that.
Yes, as I said, you are indeed confident you're right. That won't help by the way, but I don't expect that to have any impact on you because you have confidence and facts are a poor substitute.
It does actually matter which government. My sister's web site undoubtedly could be interfered with by the government of the country she lives in as it controls the registry her domain name is in, but if they have got it in for her then she has bigger problems than a web site. On the other hand, the status quo today without DNSSEC is that another government she's barely aware exists has the resources to intercept her traffic, because there is no cryptographic obstacle to them doing so at the DNS level. Not to mention plenty of non-government entities, we're hardly talking about Apollo programme levels of resources.
Now, in truth today what you see a lot of is lower hanging fruit. Back when I worked for the last startup we spent a bunch of time looking at cases where DNS for sensitive domain mail servers gets changed and then for a few hours or days all the email to some domain is going via a different country. Sometimes the hijackers would get themselves a TLS certificate, sometimes they wouldn't bother (presumably the targets didn't do name checks or didn't make TLS mandatory). DNSSEC wouldn't help here because the bad guys literally just broke into a registrar DNS account which was poorly secured, their new answers would have been signed.
But of course even though bad guys won't pick your locks when there's a fire door left open that's not a reason to use crappier locks, it's a reason to shut the fire door. The existence of lower hanging fruit is not a defence, if anything it means you're likely to underestimate the risks you face and be unprepared.
The fail closed behaviour is desirable. Soft-fail is, to use Adam Langley's preferred metaphor, "a seat-belt that snaps when you crash". If there's a way to have a config that isn't secure but seems to work, that's exactly the config bad guys will rely on to attack you. This was an understandable mistake when Netscape made it in the 1990s, less understandable when Microsoft did it at the turn of the century, and unforgivable today.
The status quo today is that DNS interference is being mitigated by the CA system, which is no hero but does have the benefit that rogue CAs (or CAs which have been forced to behave badly by other actors) can be delisted. The push to increase TLS deployment, detect TLS cert shenanigans, and move additional technologies behind TLS (DNS-over-HTTPS, for example) all work to move the needle on the risks in the current threat model for the vast majority of internet-based workflows. These changes are what’s actually making things better for your example of your sister’s website.
Regarding fail-closed, I didn’t say that security controls should fail open. I said that unlike other security controls, DNSSEC fails by dropping the site off the internet. As an end user, you don’t even know it’s a DNSSEC problem, you just know the site has disappeared.
Such mitigations (e.g. 0x20 or multi-perspective) are not enough to outrun the metaphorical bear. So they only work until you are slowest again. Putting such mitigations in place for those who can't or more often won't deploy DNSSEC makes sense, but somebody will get eaten by the bear this way.
> unlike other security controls, DNSSEC fails by dropping the site off the internet
You could do some small UX work here to have an explicit error like the ones for TLS version interference, but it's of dubious value. Also you're probably thinking this is valuable feedback to site owners but unfortunately it'll be choked with noise. TLS version interference, for example, mostly means your crappy anti-virus or other middlebox garbage is causing problems. But it might be an attack, or a dodgy cable... who knows. As with certificate expiry the right thing for a site owner to do is have their own alerting in place.
Turns out DNSSEC supports the modern algorithms you could want, including ECDSA P-256 and P-384. Most validating resolvers support ED25519 as well. Using P-256 creates smaller signatures and enables DNSSEC lookups to fit within the original DNS packet size of 512 bytes.
It also turns out that Cloudflare's Universal DNSSEC has supported ECDSA P-256 since 2015; as a percentage of implementation, more DNSSEC users are using fast, modern crypto than not.
And it turns out that the old, crappy algorithms are being deprecated and the DNSSEC eco-system is being updated to not sign zones using them or validate them: https://www.isc.org/docs/matthijs-mekking-oarc30-unsupported...
I'm sure there are TLDs and ccTLDs using older algorithms, but as a zone operator, you can use the latest, greatest crypto.
And because operational guidelines suggest rolling Zone Signing Keys (and Key Signing Keys) regularly, everyone will be on the latest crypto soon.
I just signed a zone I operate using ECDSAP256SHA256 even though the parent zone is using RSASHA1.
So DNSSEC's crypto is good and getting better all the time.
The author of this post is simply wrong; what's more, he was wrong five years ago, and the situation has not improved.
Anyway, Hanno writes mostly in German and for German language publications but https://www.feistyduck.com/bulletproof-tls-newsletter/ is in English and is worth a read. Perhaps the most important thing about Hanno in this context is his independence, he's not making a buck from any of the players as far as I know. I just happen to think he (and lots of other important Internet security professionals) is wrong about DNSSEC.
Some people, somewhere are relying on public keys or fingerprints published in DNS. Presumably, more will do so in the future.
I think this is begging GP's question. Is there really any such person?
https://mail.sys4.de/pipermail/dane-users/2020-February/0005...
BTW: the US is #2 in the world in terms of DANE-enabled email hosts.
Not true.
I would say secure email is something important and that relies on DANE, which requires DNSSEC. Good video on this: https://youtu.be/BhvU19RJrPY
DANE’s TLSA records is the only method available to ensure that email is always encrypted between hosts.
Otherwise it’s too easy for someone to MITM a connection and downgrade the connection.
And actual data on DNSSEC and DANE usage shows DANE usage is way up: https://stats.dnssec-tools.org/
Since DANE gives you more than just email, it has the advantage right now.
I did post data showing that nearly 2 million email servers are using DANE and that number continues to increase.
Never use Exim, by the way.
Your opinion about the usefulness of DNSSEC is well-documented. That's not the topic of this specific thread: here we are discussing the theoretical case where the DNSSEC KSKs were copied to an unauthorized party, and what damage they may be able to wreak.
As I mentioned, they could use it to forge DNSSEC responses to validating resolvers, now and in the future. It is a fact that some small number of people rely on DNSSEC responses today, so that would be the attack surface.
If DNSSEC usage declines, as it seems you wish it does, then the consequence of such a leak of key material would also decline with that. If it increases, then the consequence of such a leak would also increase, as more people in that hypothetical future would be theoretically vulnerable to forged responses.
If you're a group that steals high value keys for a living, it would be nice to steal the DNSSEC long-term keys when DNSSEC is small and unimportant, because it might be a lot more difficult later if DNSSEC becomes widely adopted to protect critical infrastructure.
Already at least a few dozen people think that these keys are sufficiently important to spend thousands of dollars and dozens of valuable witness-hours traveling to these key ceremonies and storing these safes and whatnot. Perhaps they are entirely misguided and should abandon the entire endeavor.
I don't think the "DNS TLDs are simply a proxy for governments" is enough of a disqualifying argument when several governments or even large corporations have implicitly trusted CAs in widespread use.
I think it's useful to have another choice of validated data to cross-check with. Perhaps you are worried that it would de facto replace the existing corporate-managed PKI with a government-managed one entirely?
I also think that what another commenter mentioned, that you have a choice in governments (and could theoretically publish your signed certificate data in multiple zones, controlled by multiple different governments) is an extremely beneficial set of possibilities. Multiple-TLD-publishing is certainly a better system than the attempts at public-key pinning and observatories/transparency we've seen as attempts to solve the "anyone can issue for any domain" problem as it stands.
...unless, of course, the root zone KSKs get stolen. Then all the TLD zones are unsafe. :)
However, MTA-STS has its own issues: [1]
* Still can and should prefer DANE outbound
* Authenticates domain control via CA leap of faith
* Vulnerable to MiTM at cert bootstrap
* Vulnerable to weakest root CA, and unauthorized certs
* Open to downgrade on first (or irregular) contact
* Complex mix of HTTPS, unsigned DNS and SMTP
All standards are about tradeoffs; even though MTA-STS isn’t as good or as battle-tested as DANE’s TLSA, it’s something they can implement fairly quickly versus what it would take to rearchitect so they could do DNSSEC/DANE properly. I suspect if they were able to start over, they’d do something differently, but it is what it is.
We shouldn’t be too surprised; DNSSEC implements a distributed chain of trust and that doesn’t work with the increasingly centralized systems the largest email providers run.
It has nothing to do with a lack of confidence in DNSSEC and DANE since we already know about the nearly 2 million domains with signed MX and DANE records and the over 5000 domains hosting DANE mail servers: [2]
I don't know what this "centralization" argument is. One of the biggest centralizers on the Internet, Cloud Flare, is the only proponent of DNSSEC among the tech companies (DNSSEC is a tool for centralization; it's difficult and expensive to manage, so people will pay to have Cloud Flare do it for them, and Cloud Flare knows that).
1. Funny, my version of the spec says something different:
The primary motivation of MTA-STS is to provide a mechanism
for domains to ensure transport security even when
deploying DNSSEC is undesirable or impractical. However,
MTA-STS is designed not to interfere with DANE deployments
when the two overlap; in particular, senders who implement
MTA-STS validation MUST NOT allow MTA-STS Policy validation
to override a failing DANE validation.
The point you conveniently missed is that MTA-STS was developed to address a problem that only large, centralized email providers have. They would use DNSSEC/DANE if they could, but they can't, so they created something else that's not as good.
You also didn't address the security problems MTA-STS has, but I guess I’m not surprised.
Cloudflare and Google Cloud [1] offer DNSSEC as yet another feature for their hosting services--that's no different than any of the other technologies and services they offer. I’m sure they see providing DNSSEC as a convenience and a competitive advantage.
Saying DNSSEC is a tool for centralization because of Cloudflare is like saying email is a tool for centralization because of Gmail.
Lots of organizations that deal with domain registration, running TLD servers and other parts of the internet infrastructure are publically advocating for DNSSEC but that's mostly behind the scenes stuff: ISC, ICANN, Verisign, NANOG, etc.
As the tools mature, deploying DNSSEC-signed zones gets easier. Automatic zone signing and key rollover are built into DNS software like BIND, PowerDNS and Knot DNS [2] these days, so it doesn't have to be that big of a deal for most organizations.
It literally takes 10 minutes to enable Unbound’s (which many Linux and BSD distros ship as their default DNS resolver) DNSSEC validation feature.
You can put Unbound on a Raspberry Pi and have it be the DNSSEC validating resolver for your home network. [3]
[1]: https://cloud.google.com/dns/docs/dnssec
[3]: https://weberblog.net/dnssec-validation-with-unbound-on-a-ra...
The "security problems" you raised with MTA-STS all boil down to "doesn't use DNSSEC, like I want it to" (in fact, that's literally the first security problem you raised, though all the "relies on the WebPKI" points say the same thing as well).
It is not surprising or interesting to me that DNS operators are excited about DNSSEC. But, obviously, the fact that no tech company other than Cloud Flare has adopted it refutes the argument that network and security engineers are accepting it. The opposite thing is true: the protocol has been categorically rejected, and is moribund.
I'll keep going with this thread if you want, but you should be aware that we are the only two people reading it.
DoH or DoT is nice, at least you can pick your poison, if you will, by picking your resolver, but they are still just feeding you whatever they got from auth resolvers around the world via whatever packets they happen to have received.
Sure, then use TLS as the next step. And that might work if browsers and the CA/B gets serious, but who knows, there are still nation state CAs everywhere by default.
Wouldn't it be easier to set up DNSSEC and a lot of Cert Transp style notaries that can catch Uncle Sam and the 4 other eyes in the act?
You can't use DNSSEC to "catch Uncle Sam in the act", because "Uncle Sam" has de jure control over the domain names you care about. What's worse, Certificate Transparency actually has caught misissuing CAs, and the consequences for those CAs has been lethal: Chrome and Mozilla put the largest commercial CA on the Internet out of business over misissuance. When CA's misbehave, we can revoke them. We can't do that with DNSSEC: when .COM misbehaves --- and it will, we know, because it already has --- we remain stuck with it. The DNS is absolutely not trustworthy enough to store keys.
I know, and that's okay, if we knew what are those actual actions, and were there a log of those people could decide what to do.
To me this sounds like an opportunity to decentralize DNSSEC, skip ICANN, let TLDs pick "trust root providers", make it tamper evident, and the resolvers will maintain the trusted set of roots.
Or not, and just don't put keys into DNS and learn to live with the additional network round-trips required for the workarounds. :( (Like MTA-STS, which, on the other hand, is great. Relatively easy to deploy, opt-in, has a time-lock like HSTS, so sort of resilient. But still a workaround.)
But if you accept that it's possible to gain some information, and to basically slowly build up a model of the real, so you can start trusting sources of information, eventually you can build a ceremony model and there are designated witnesses, and designated key-holders. And in theory press should regularly interview them to make sure they are trustful, mentally okay, they are not blackmailed, or otherwise tampered with, and what they say about the process, safe, stream, etc.
So in the end it's all about your priors. If you have an almost unmovable belief about we're all just being lied to, then you might never (as in not in <100 years) update to the alternative belief.
Getting all of those people, chosen for trustworthiness and various distribution of national origin, to cooperate with such a fraud conspiracy as you describe is deemed to be sufficiently difficult as to be beyond the means of the organization.
How do they ever expect a low-rent affair like this to work?
More like you reach CloudFlare's CDN
Since no browser today can do that, DNSSEC is a dead technology.
You’re thinking about DANE’s TLSA records, which supports trusting certificates not signed by the CAs browsers already trust. DANE does require DNSSEC to work but that’s not what the article is about.
DNSSEC doesn't matter; the parent commenter is right.
Some stats from this April 2019 presentation [1]:
* 91% of TLDs (.com, .org, .edu, etc.) are signed, including root, which was signed in 2010.
* about 20% of internet users are using validating resolvers, mostly thanks to Google and Cloudflare. I'd add Comcast too.
* Over 50% of the zones in .nl, .se and .no are DNSSEC-signed
What's actually damning is that DNS customers, including the ones with the savviest security teams, aren't opting in, and haven't for many, many years. They all have a choice whether to sign or not, and they choose not to. Unlike TLD signatures, that actually is a strong signal.
Signatures of European zones aren't interesting because they're done automatically by registrars. That's theater, not security.
It's not hard to check this for yourself. Just start with a list of the top domains on the Internet; I used the Moz Top 500, but Alexa will do fine. Create a flat text file with one domain per line, then do:
for N in `cat file` do; host -t ds $N; done
First, dozens of .GOV sites have DNSSEC delegations because, until a couple years ago, DNSSEC was mandatory in the USG; that mandate has since been rescinded.
Second, excluding those .GOV sites, the entire list of signed domains in the Moz Top 500 is as follows:
000webhost.com
addtoany.com
berkeley.edu
bund.de
cloudflare.com
cmu.edu
europa.eu
example.com
foxnews.com
icann.org
ietf.org
mediafire.com
mozilla.org
one.com
paypal.com
pixabay.com
stanford.edu
themeforest.net
time.com
welt.de
xfinity.com
For everybody without a signed zone, it would be trivial for a resourceful adversary to pass the challenge by simply interposing to give a bogus answer to the query. Only people with DNSSEC actually get cryptographic security here.
Whether it's surprising that most people (where "most people" includes big banks for example) are comfortable with basically just relying on the honour system as good enough is I suppose a judgement about how smart you think people are or how much they actually care about security.
Up until now, you only had to intercept one path:
> On Wednesday February 19th, 2020 we’ll turn on stricter validation requirements 30 in production. We’ll make multiple validation requests from different network perspectives.
Key personnel from ISRG (the charity which builds Let's Encrypt) have HN accounts, but mostly steer clear of contradicting HN Fan Favourite Thomas Ptacek because it's not worth it even when he says things which are directly contradicted by the facts.
However I am a sucker and will respond to point out, once again, that in fact Let's Encrypt obeys the ACME RFC in this respect (as well it might given that two of the RFC's editors are key personnel for Let's Encrypt and both ACME and Let's Encrypt are bound together from the outset) and so yes of course it does DNSSEC validation.
The anti-DANE lobby from browsers (which caused a pretty nasty scene for the TLS WG) doesn't change the facts which made DNSSEC necessary and that's why the solution for problems keeps being DNSSEC no matter how much you say it mustn't or shouldn't. The same browsers are currently working on ESNI which, punts the authenticity problem back to DNSSEC because that's the only way it gets done. And they're working on DNS records to drive HTTP/3 without Alt-Svc (and throw in ESNI at the same time) and those punt authenticity to DNSSEC as well, for the same reason.
No matter how hard you shove your fingers into your ears, the authenticity problem has to be solved in DNS and that's what DNSSEC does.
https://news.ycombinator.com/newsguidelines.html
It's a pity you posted that way, because users flagged it, which eventually removed it from view. That makes sense, because protecting the container here (the commons—not any one user) is more important. But it's a pity because it takes your argument out of the mix. Even if users hadn't flagged it, crossing into snark/flamewar/personal attack discredits your points anyway, so please don't do that.
I know nothing about the issue here, but it seems to me that if your post had begun at "Let's Encrypt obeys the ACME RFC" and ended at "for the same reason", it would have been fine for HN.
(If you care, you'd be welcome to email hn@ycombinator.com and we could let you edit the post.)
I'm sorry that you aren't the only person in the world that knows people involved with CA operations, but, like you, I've been working in this field for "more than 10 years".
If you read my short comment more carefully, you'll see that I didn't say that LetsEncrypt doesn't do DNSSEC. It does, unlike other CAs that claimed to do DNSSEC and then stopped. My point, of course, is that it doesn't matter, because nobody signs their zones.
Since browsers are the only important customer of DANE, it's funny to see them referred to as "the anti-DANE lobby". Is it a "lobby" when it's the entire population? Were the Romans the "anti-Visigoth lobby"?
Your premise that browsers using DNS means browsers will have to use DNSSEC is obviously flawed; browsers rely on DNS today, and not a single one of them does DNSSEC. The ones that tried, stopped.
Make more persuasive arguments. It's not my fault, or the result of a message board popularity contest, that anyone can simply look at a list of the most popular and important sites on the Internet and see that virtually none of them are DNSSEC-signed, or observe that it's been 25 years of standardization effort with DNSSEC to no avail, or to poke around in their browser, the most important piece of Internet software they run, and see that it has no support for DNSSEC, or find articles from the TLS architects of browsers explaining why they can't get DANE to work. Those are just facts. They're not personal attacks on you.
ps
Here's a link from another person who doesn't want to wade into the orange site to make a point, about LetsEncrypt doing multi-perspective lookups, which protect DV challenges from spoofing and, of course, do not rely on DNSSEC, which nobody uses:
https://community.letsencrypt.org/t/acme-v1-v2-validating-ch...
pps
If ISRG is so bought into DNSSEC, why isn't LetsEncrypt.org signed?
In the context that's exactly what they are? DANE proponents securing server-to-server email wanted to have an HSTS-style flag for TLS so they could use it for "OK this server says it always does DANE, if I try to connect in future and can't get DANE that's an attack, I'll just spool the mail". They wrote a simple draft which was then proposed for adoption by the working group. The honest thing for the anti-DANE lobby to do was reject adoption. The draft could proceed as an independent submission and live or die on its own. But instead tactically browser vendor participants supported adoption, and then stalled the process asking for endless tweaks and extra stuff even though they had no intention to deploy it. Basically they ensured it wouldn't get finished and adopted in a timely fashion. AIUI Kathleen chewed people out for abuse of process, everybody was very contrite but the harm can't be undone.
Can you address anything I actually said?
That all the browser developers as a bloc will pressure standards groups not to make more DNSSEC happen is not something I'm interested in litigating. Since they're the model consumers of DANE, it's weird to refer to them as a lobby; it's like talking about "the user lobby". It's a semantic point and not an important one, so I'm fine to stipulate that "almost everyone who will ever have to deal with DANE" constitutes "the anti-DANE lobby".
Here? Or in the Twitter thread where for some reason rather than quote what I wrote you decided to make stuff up about me claiming Let's Encrypt loves DNSSEC ?
Let's try this:
> it doesn't matter, because nobody signs their zones.
Last century when I spent a lot of my spare time working on a vanity site with friends that site didn't have HTTPS. These days the same site (now mostly historical) does have HTTPS.
Did HTTPS not matter last century? Did it start mattering? When and how did that happen?
No, HTTPS mattered all along but ordinary people don't really prioritise security. It's a long way behind like dental hygiene and remembering grandma's birthday, and like those it'll only get done if it's made as convenient as possible.
So that's what we have to do. Well, that's what we should be doing. Instead you're arguing for the status quo for the past half a decade or so.
> That all the browser developers as a bloc will pressure standards groups not to make more DNSSEC happen is not something I'm interested in litigating
DANE was undeployable. But what they learned with TLS 1.3 was that if something is undeployable (originally TLS 1.3 was undeployable) you can fix that through a mixture of encrypting more things and lying to middleboxes. So that's what you should be expecting.
The future isn't a closed web where everything is just Facebook posts but to a middlebox it may look that way because it turns out that middleboxes allow Facebook posts unmolested (People who sign off on buying a middlebox don't know what TCP/IP is but they use Facebook and they'll be angry if it stops working) and so it's easier to just disguise say a DNS request as a Facebook post and then unwrap and decrypt it at the destination. Only half joking.
But as you well know, virtually none of the DV challenges done by Lets Encrypt use DNSSEC in any way. Lets Encrypt is not operationally dependent on DNSSEC. If the root DNSSEC keys landed on Pastebin tomorrow, literally nothing would change at Lets Encrypt. That's not hyperbole; if it's inaccurate in any way, it'll be in some nitpicky way that will probably just prove my point.
We apparently both have, in some sense, sources from ISRG. They're apparently saying conflicting things, because the ISRG people you've heard from would speak up for DNSSEC if it weren't for their fear of me arguing with them. I have less faith in my ability to shout down Lets Encrypt staff than you do, and also people telling me the exact opposite of what you are about their take on DNSSEC; what I hear is "they feel they have to support it, and as long as they have to support it they're going to do it right, unlike other CAs".
But rather than accepting these weird secondhand arguments, we can just look at the actual behavior of Lets Encrypt:
* LetsEncrypt.org isn't DNSSEC-signed.
* The ISRG's own site isn't DNSSEC-signed.
* LetsEncrypt is investing in non-DNSSEC DNS security tools.
* LetsEncrypt doesn't even suggest that users enable DNSSEC.
Make a more persuasive argument.
Meanwhile: TLS has always mattered, because TLS actually does something meaningful to protect traffic. DNSSEC does not. That is the reason we had a push to "encrypt the web" that involved getting everyone onto TLS, and no corresponding effort to do the same with the DNS. Another thing you're well aware of was that one of the key design goals for SSL/TLS was not to depend on the DNS for security.
I'm still not clear on whether you're talking about chain-extensions or something else. Chain-extensions is pretty funny. I'm happy to drill into it if you want.
Later
I guess we don't have to take secondhand arguments for this anymore after all:
Did you hear that from @cpu too? Is it an actual quote, or is this you paraphrasing again and it might be completely wrong?
Regardless this did prompt me to go back and look at what became https://github.com/letsencrypt/boulder/pull/3726 and confirm that yeah, they still don't get it. Must try harder.
I thought I did a pretty good job of spelling out what needs to happen to have confidence here, using an example from EMV of what not to do - but it didn't have the desired effect and this is still the same "parse first, regret later" approach that is ultimately why that PR even exists in the first place (Let's Encrypt were mis-parsing CAA records and discovered in post mortem their records weren't good enough to actually figure out the impact from the incident).
> Another thing you're well aware of was that one of the key design goals for SSL/TLS was not to depend on the DNS for security.
I can't figure out any way to squint at this which makes it both true and non-trivial.
In practice what Netscape did was punt to the existing Certificate Authorities and carefully avoid asking awkward questions about how they did it. This achieves a goal "not to depend on the DNS" only in the same sense that that chap the other day was able "not to depend on a mobile phone" by just getting a friend to receive all their calls for them and pass on messages...
For many years what the Certificate Authorities actually did was not officially documented anywhere. But we do have some amazing patents they filed to protect their "innovative" solutions. They're uh... they're very bad. Go read some, you can laugh now because none of this is permitted any more. What we know of the unpatented stuff they did was mostly worse. Would you be surprised that OCRing the images from anti-spammer WHOIS websites was an actual thing that an actual trusted Certificate Authority was doing to figure out the contact email address for a domain? Guess how reliable that was...
I'm not sure how your argument hasn't been comprehensively refuted at this point.
I would love to take a merry walk with you through the tls-wg mailing list posts about dnssec-chain-extension, which I feel fairly confident I can show you've mischaracterized. The whole thing is really funny.
I don't think this has been an especially productive exchange on HN itself, but since we both appear on opposite sides of the DNSSEC issue every time it comes up here, and your arguments tend to involve subtleties of what Lets Encrypt does or doesn't do, I appreciate the opportunity and motivation to read up on specifics, so that I can more quickly shut down this bad argument when it's brought up again. Thank you!
Anyway I wasn't talking about Melinda, who as a co-author would be in your terminology one of the proponents that you think she's directing that message at, I was talking about Kathleen Moriarty at IETF 103.
The chair's choice of phrasing "This was not our finest hour" undersells it somewhat.
Links to your messages are welcome.
DNSSEC also enables them to verify whether empty CAA records are intentional or the result of something malicious.
From https://tools.ietf.org/html/rfc6844#section-4.1
Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not required. An issuer MUST NOT issue certificates if doing so would conflict with the relevant CAA Resource Record set, irrespective of whether the corresponding DNS records are signed.
DNSSEC provides a proof of non-existence for both DNS domains and RR set within domains. DNSSEC verification thus enables an issuer to determine if the answer to a CAA record query is empty because the RR set is empty or if it is non-empty but the response has been suppressed.
Use of DNSSEC allows an issuer to acquire and archive a proof that they were authorized to issue certificates for the domain.
Verification of such archives MAY be an audit requirement to verify CAA record processing compliance. Publication of such archives MAY be a transparency requirement to verify CAA record processing compliance.
Once again, it is my claim that Lets Encrypt does not operationally rely on DNSSEC. Nick Lamb disagreed, and suggested that ISRG staff would stick up for DNSSEC but for my presence on the thread. I reply with a quote from a Lets Encrypt developer: "I think DNSSEC is rubbish and so does the whole Boulder development team".
I think you should take this up with them.
That’s not the point, although I doubt most people on this thread knew that the use of DNSSEC is strongly recommended for issuers of certificates.
I’m pretty sure Lets Encrypt doesn’t operationally depend on DNSSEC, but if they’re issuing certificates to a zone with DNSSEC-signed CAA resource records, that’s irrefutable proof of the intent of the zone operator, something that Lets Encrypt and other issuers of certificates should probably pay attention to, regardless of the personal feelings of their engineers about any particular standard.
Without DNSSEC, there’s no way to know if the CAA records have been tampered with when using something like ACME.
That doesn’t sound dead to me.
It was never supposed to encrypt lookup; that was mostly a disingenuous strawman argument from the usual suspects.
It does provide a chain of trust. By using the public key published in your zone, a validating resolver checks the digital signatures from the root to your zone.
It’s no different than when a browser checks the digital signatures on a certificate that’s signed by an intermediate certificate that was signed by a root certificate.
For authentication and trust purposes, every resource record in a DNSSEC-signed zone is cryptographically signed and validating resolvers--Unbound, Knot Resolver, BIND--confirm them.