This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Feature request: DANE (RFC-7929) search for keys #487
Comments
|
DANE lookups would require validating DNSSEC and would never work in a browser. OpenPGP.js since version 3.0.12 ships with a modern alternative to DANE key lookups - Web Key Directory. WKD is enabled by default in GnuPG (try Sample code for lookup of one of my test keys: new openpgp.WKD().lookup({
email: 'test-wkd@metacode.biz'
}).then(function(key) {
// use the key here
console.log(key);
}); |
|
It's not necessarily true that DNSSEC would never work in a browser, now that we have DNS over HTTPS as a published standard (RFC-8484). Also, once Node.js gains better support for DNSSEC, then this feature could be supported at least in that environment. WKD may be more recent, but it is still a draft, and has nasty edge cases like what happens when an active attacker drops packets to the WKD web server, preventing lookup of the key data. With RFC-7929, this key data can be returned as part of the necessary DNS lookup for the IP of the remote SMTP server. Having WKD in OpenPGP.js is great, and I appreciate that sample code, thank you. Perhaps someone will be inspired to support the DANE alternative too. |
If your threat model includes active attacker that can modify WKD web server why that attacker can't modify the DNS?
I don't think OpenPGP.js is used for DNS lookups of remote SMTP servers... PKA (a different DNS-based key lookup scheme) was mentioned on the GnuPG Mailing List as something that "will eventually be removed from gnupg". I wouldn't be surprised if that didn't also include DANE key lookups as they share many common traits.
Yes, someone could submit a PR but given low adoption and relative complexity in adding exotic DNS records coupled with the fact that queries leak the key info I wouldn't hold my breath. |
|
You're right to think in terms of threat models, but the threat model I'm suggesting is not one where the attacker can modify the WKD web server, only drop packets that match a certain IP/port filter. This class of attacker includes pretty much every ISP, for a start. (There is also the possibility of an attacker compromising one of hundreds of Certificate Authorities in order to create a fraudulent certificate for a fake WKD server, but that's a separate matter, and not necessary for the attack I was suggesting.) Yes, I know that OpenPGP.js isn't doing DNS lookups of remote SMTP servers, but it could be extended to access DNS-over-HTTPS servers, which would be harder for an attacker to block without causing a complete Denial of Service to the user they are attacking. Such an attack would "fail-safe", unlike the WKD attack. My point was that if an attacker tried to stop DNS lookups of SMTP servers, they would block all mail delivery, rather than causing clients to send less secure emails. As far as I'm aware, PKA is a GnuPG-specific technology that was never accepted by any standards body. It is right that the GnuPG team deprecate their obsolete technology, in favour of standardised alternatives, but there would be a bit of a conflict of interest if they removed support for an IETF approved specification in favour of their own (as yet unapproved, and arguably less secure) WKD technology. Hopefully as DNSSEC grows in adoption, there will also be more support for DNS over TLS, which will prevent the key info leak that you mention. |
They wouldn't know the query is WKD because they look like normal HTTPS queries, on the other hand DNS queries are plain text so it's easier to see what's going on there.
Hundreds of Certificate Authorities are required to log all of their certificates to Certificate Transparency logs so in case of an bad cert being issued the domain owner would immediately see that, not to mention that if something like that happened the CA would quickly go out of business (see: DigiNotar, WoSign and Symantec's PKI business to some degree). How is it with DNSSEC? Governments can transparently sign bad responses, send it to selected targeted recipients and no-one would know about. This is not purely hypothetical as there were some concerns about Lybia and bit.ly.
WKD is published as a draft and sooner or later will be standardized as there is a growing demand for it (see OpenPGP Mailing List). I'd also be interested in what GnuPG developers would say about the fate of DANE lookup. Maybe it's a good idea to ask on their mailing list?
Adding DNS over HTTPS or DNS over TLS to the mix isn't solving problems but creating new ones. Which provider to use? Google? Cloudflare? Or maybe make this a parameter that the lookup client should pass? Then they need to think about it (it's not solving problems but pushing them further away). (By the way I really enjoy the discussion here, I've been thinking about the lookup problem for some time ever since I found The complete guide to publishing PGP keys in DNS) |
|
I'm glad you're enjoying this discussion, as am I, and I hope we can both learn a lot by discussing this problem more. You're right of course that WKD looks like normal HTTPS queries, but an attacker can determine the IP addresses of the WKD servers (of the recipient victim's mail provider) and drop packets to them, without easily being detected. Imagine that the attacker wanted to stop the key lookup for alice@example.com sending an email to bob@example.org for example. Knowing that Alice doesn't use the example.org service, the attacker can block all HTTPS traffic from Alice's IP to the IP address of the WKD server for example.org . As for your claim about DNS queries being plain text, I will defend DNS-over-TLS near the end of this comment. Next you state that CAs are required to log all of their certificates to CT logs. My understanding is that this is not strictly true. It is true that major browsers have implemented a policy that they will not trust certificates that have not been published in such a log, but organisations may still ask CAs to issue unlogged certs, to be used internally or in applications which do not have a CT requirement. This then begs the question: Do all WKD clients check for certificate inclusion in a CT log? I don't find any reference to this in the latest WKD draft specification. In any case, I don't think it is much comfort to the victim of a MitM attack that the compromised CA later goes out of business. Perhaps you are arguing that "Because of the huge existential costs to a CA if they were found to be compromised, the CA is strongly motivated to make such a compromise impossible." Unfortunately that argument is undermined by the very examples you give, showing that such failures are indeed possible, or even likely. How is it with DNSSEC? Well, you provide three examples of compromised CAs, but no examples of governments signing fraudulent DNS entries. I would say that such an attack absolutely remains hypothetical (for now), as the "concerns" you point to were about a denial of service, and those concerns turned out to be unjustified. It's true that if your domain relies on the stability of the Libyan government, you may be more likely to face outages, but it's easier to avoid hosting your site under the .ly ccTLD than to avoid one of hundreds of CAs from issuing a fraudulent certificate for your domain. (Yes, there are steps you can take to mitigate the risk of a bad CA, but many of these implicitly rely on a secure DNS or have a TOFU security model. Regardless, they don't seem to be required by the WKD draft. Furthermore, there is draft or two out there which describe how to apply a similar Transparency process to the DNS key infrastructure). As for the "growing demand" for WKD, I'm afraid I'm not going to attempt a statistical analysis of the number of people on a mailing advocating for it. Even that data wouldn't prove that a draft would be accepted as an IETF proposed standard. I also don't think it is particularly helpful to ask the GnuPG developers on their mailing for their opinion of DANE lookups. There is, as I have stated, a huge conflict of interest when it comes to GnuPG developers supporting WKD. Have you not read the header of the WKD draft? "W. Koch // GnuPG e.V.". Of course the developers of GnuPG are going to support the draft that they created, or, conversely, the draft is of course going to be implemented by its author(s). That doesn't say anything about its merits, and much less about the merits of competing technologies. (Allow me to take this moment, though, to say that one of the things I appreciate about OpenPGP.js is that it provides some degree of friendly competition in the space of Free Software implementations of this open standard). Now, please excuse me as I misquote one of your other paragraphs: Adding HTTP over TLS to the mix isn't solving problems but creating new ones. Which CA to trust? DigiNotar? WoSign? Or maybe make this a list that the user can configure in their browser settings? Then they need to think about it (it's not solving problems but pushing them further away). Hopefully you already agree that HTTPS really is a benefit to the internet (all things considered), despite the apparent logic of that paragraph. DNS configuration does happen at a lower level of the operating system than the browser's list of accepted CAs, but I don't see any reason why users couldn't be given secure DNS requests as seamlessly as they are given secure HTTP requests. Let us not resign ourselves to an internet where people's DNS requests forever remain visible to all passive snoopers. (Thank you for patiently considering my comments, and accepting them in the well-meaning spirit that they are intended. I appreciate the link you include at the end of your comment, and it reminds me of a similar guide I found again recently). |
I think the key point here is this assumption: Knowing that Alice doesn't use the example.org, how would they know that? I don't often visit my homepage but when I do the traffic for WKD query and a browser request looks similar enough. And why filtering HTTPS traffic is an issue and not DNS queries that one can even do in a selective manner as it's clearly visible what's the request/response?
That's a good point, they don't, but do they validate DNSSEC? GnuPG doesn't. If the attacker uses a misissued cert and the user connects with a browser (because HTTPS traffic looks similar) they'd see that the site presents a bad cert, that could trigger suspicion.
Absence of evidence is not evidence of absence. Or, I could reverse the argument that the CA system works because you see violations. Other suggestions:
Key discovery (DANE, WKD) and trust model (TOFU, WoT) are orthogonal.
Certificate Transparency for Domain Name System Security Extensions expired in January 2016.
Being approved as IETF standard is one thing, being standard that is in use is another. Of course it would be good that WKD was approved (and probably it will) but for me the fact that a draft is widely implemented while IETF standard is not just shows that something is wrong with that standard, not with the draft.
I agree that there is a conflict of interests here and GnuPG may be biased but even if we take it out of equation WKD is supported in OpenKeychain, Mailpile, Mailvelope (in beta). I must admit my ignorance here but what software uses or plans to use RFC-7929? I did quick search but found only feature requests, no real usage... (Coincidentally the Mailpile developer raised privacy concerns about using DNS in key lookup).
CA trust stores are shipped with basically all OSes in use so the problem you paint doesn't exist but....
DNS-over-X centralizes queries to a single operator, that then, in turn, becomes a trusted third party. You may claim it's better than 100 CAs but this still worries me a bit... (not to mention DNS-over-X still uses CA system for TLS so you can't avoid that).
I usually try to refrain from long commenting on "political issues" like this one but the high quality of discussion, that is rare on the internet nowadays, convinced me to stay :) |
|
I appreciate your endorsement of the high quality we are maintaining in this discussion, and am grateful of the opportunity to continue it.
This doesn't seem like an unreasonable assumption. Even a passive attacker can check that Alice hasn't visited, for example, hotmail.com in the past month and that therefore any request she makes for it are likely to be WKD requests (assuming hotmail.com supported WKD). Moreover, WKD requests are much smaller than typical web requests, so just by counting the number of bytes per session, an attacker could determine (with reasonable statistical accuracy) which sites she only makes WKD requests to.
We've talked about this. :) DNS-over-TLS is a thing, and it's only going to become more popular. If an attacker wanted to drop all DNS requests that Alice made, then obviously Alice would realise she is being attacked, and in any case she wouldn't be sending any emails (either encrypted or unencrypted).
My understanding is that GnuPG uses the standard system resolver (when not in "Tor mode"), so it would get the benefit of DNSSEC for free. You're right, though, that it doesn't report to the user whether the information it received from the DNS was authenticated or not, which is a long-standing flaw in GnuPG and not impossible to solve.
Yes, if the user is careful about visiting the website of each mail provider they send an email to, then their web browser should detect if a fraudulent certificate is being used, or even if packets are being dropped to that server. I don't suppose this piece of OPSEC advice will make it into the final draft of the WKD specification though. :)
True, but evidence of presence is not evidence of absence either. I'm saying that if you present 3 examples of failures of CAs, and zero examples of failures of DNSSEC, it is not logical to conclude from those data that "DNSSEC is less secure than the CA system" [paraphrasing].
No debate about DNSSEC can avoid a statement by tptacek indefinitely. :) Fortunately you picked one of his more mild positions, and I think that tialaramex did a good job of highlighting the fact that DV certificates are only as secure as the DNS information used to prove ownership of the domain. As such, the question isn't "Does DNSSEC validate anything in the real world?" but "Do CAs validate anything in the real world?".
A very reasonable hypothesis, and I concede this point.
Yes, but it seems my parenthetical remark was too terse. The point I was making about TOFU is that there are ways of mitigating the flaws in the CA ecosystem, like HPKP and Expect-CT, but these are HTTP headers so they rely on the client's first connection to the server being secure (and, in the context of our discussion, that the WKD client support them).
Correct, but it would perhaps be premature to work on that until the "powerbind" loophole has been closed (which is what the other draft aims to do). I admit that I'm not planning on running a DNSSEC Transparency log myself, so I can't guarantee a time frame when such a service will be publicly available.
Taking GnuPG out of the equation again, the only publicly available client I know of is hash-slinger. There are also some webmail providers which support it, such as Posteo which you mention above, and mail.de for example. If you don't think that RFC-7929 has enough support from implementers, you are perhaps well placed to do something about that. :)
Right, and validating DNSSEC resolvers are shipped with some OSes (although maybe not with that feature enabled...). Unfortunately DNSSEC integration with OSes lags the support that CA trust stores have, but that technology did have a head start over DNSSEC.
In principle there's no reason you couldn't send you DNS-over-X queries to different providers, and it's got to be better than sending the requests to effectively any attacker who is listening (i.e. unencrypted queries). With DNSSEC, you guard against malicious responses, so privacy is the major concern. As for your worries about the dependency on the CA system, there are, as I understand it, solutions to that too, namely using DNSSEC to securely communicate the certificate public keys trusted by the DNS-over-TLS client. So the dependency is not from DNSSEC to CAs, but rather the other way around (at least in the case of DV certificates). :) Thank you again for a thoughtful discussion which really helps to clarify these ideas in my mind, and I hope our comments prove helpful for others too. |
Well request size will be similar as it's just a GET request. As for the response the attacker wouldn't know the response size until after the key is downloaded so that wouldn't give them any advantage.
You're not worried that Cloudflare or Google would basically be managing people's keys? Because that's basically it, the key request goes to Cloudflare/Google and they return what they think is right. That's I think a lot easier to abuse than the CA system that is, at least partially, monitored. People were really not happy when Firefox used Cloudflare in an experiment, but this is far more serious, letting them be a third-party in key distribution.
As it currently stands in GnuPG DNS key queries are easy to manipulate while WKD enjoy the default security of HTTPS, no wonder that only WKD is enabled by default. If DANE queries follow the lead of PKA to deprecation that'd be the final nail to the coffin, as, from what I can see, GnuPG is the biggest client that supports them.
No, but I wouldn't say it's unusual for people to open ProtonMail in the browser, and at the same time try to fetch keys from that host. Or you could be browsing the site to find the e-mail contact. When you then fetch the key it looks like another HTTPS query.
HPKP is being withdrawn from browsers (to be more strict only "static" pins will remain, so Gmail etc.) because it's a very sharp edge (or footgun), while Expect-CT doesn't serve any purpose (since 30th of April all certs must have CT, at least in Chrome). WKD, by the way, is similar to preloaded HSTS, as it always checks secure connection, with no possiblity of downgrade.
I'd say no-one wants to run the log themselves. Even with CT it's basically Google that pushed everyone to use it (for better or worse). I don't see the same push from any other company for DNSSEC. (As for solutions that provide logs for keys themselves - and that is far more interesting and advanced than RFC-7929 or WKD - there is CONIKS and Key Transparency)
Posteo supports everything, including WKD, mail.de, I couldn't find their public announcement but I tried
I value my time :) I've implemented WKD for OpenKeychain, OpenPGP.js and Mailpile because it was simple to just construct the URL and get the key. Getting into implementing 7929 properly is more complex... that's all!
Interesting link, I'll enable DNSSEC support in systemd and see how it goes, thanks!
To send a secure DNS-over-X query we need a cert and you're proposing getting the cert from DNS? How? Through DNS-over-X? Then it's a chicken-and-egg problem :) Now... why doesn't this work? |
I was imprecise when saying "WKD requests", I apologise. I should have said "WKD responses", but you're right that this means the attacker wouldn't be able to selectively block the packets based on the size of the GET request. My point was that the attacker could be building a profile of the requests that Alice makes, and if she only receives small amounts of traffic in response to her port 443 requests to example.org, then the attacker could well assume that she is not a user of the example.org webmail service, but is rather making WKD requests to that domain.
My understanding is that Cloudflare and Google are not able to trick you with incorrect DNS information if you use a validating DNSSEC resolver locally, so the issue here is about privacy (which CA certificate transparency doesn't really help with). You're right to mention the criticism of Firefox using Cloudflare, and that is applicable here, but the DNSSEC specs don't mandate using Cloudflare or Google. Also, in many cases, using Cloudflare can be more private and secure than the status quo, such as being in America with an American ISP that supports only unencrypted, unauthenticated DNS requests.
As it currently stands, users with secure DNS get secure key lookups by GnuPG when keys are requested from the DNS. It is a pity that GnuPG's security relies on the security of lower levels of the stack, but GnuPG would also be less secure if you ran it on a machine with a keylogger active, for example. Trying to replace core operating system functionality repeatedly in different applications just leads to layering violations, a proliferation of unnecessary standards, and an ecosystem that is ultimately less secure.
It's not unusual for ProtonMail users to open ProtonMail in their browser when writing an email to another ProtonMail user, correct. However, if we are just considering the use case of one webmail user communicating with another user of the same service, then we can ignore the idea that we are talking about email at all. Your second use case is much more compelling though, I must concede. It is by no means the norm that people find the email address of an intended correspond on a website whose domain matches the email address's WKD server's domain, but I could certainly imagine it being the case for users viewing a Contact Us page for a business, for example.
Indeed. I was not attempting to advocate either of these standards, they were just examples of mitigations of the flaws in the CA system (which HSTS and certificate transparency do still help with, in the browser context at least).
That's an interesting detail I hadn't considered, thank you. WKD clients may not downgrade to HTTP, but they may downgrade to "Don't attempt WKD" if an attacker can present a self-signed certificate, for example. Timing such an attack to avoid interfering with normal web browsing though would require some sophistication, as we've discussed.
It may be possible for a DNSSEC transparency system to be smaller and simpler than a transparency system for CAs, since you have a natural hierarchy, rather than any CA being able to issue a certificate for any site. With transparency for just the single root and the top level domains, it would be possible to defend against attacks that don't involve taking control of a registrar (and such an attacker could just as easily request a new TLS certificate for themselves with control over your domain name). In fact, there was even, for a time, a running implementation of a DNSSEC transparency service, created as a hackathon project. The social aspects of "What happens if a certificate for your domain appears in a log, and you didn't request that certificate?" are still somewhat undecided, but I think that there will likely always be a case for individual organisations making their own checks for the data they expect to be in the logs.
Depending on what we mean by "support", their OPENPGPKEY test page should be considered a reasonably public statement.
I value your time too, otherwise I wouldn't be asking for some of it. :) Would it really be that much work to construct the DNS record and get the key using something like this dns-over-https library?
That's easy: the egg came first. :) In this case, the egg is the public key to the DNS root, which is the trust anchor for the rest of the DNSSEC tree. This is equivalent to the list of trusted CAs that ship with a browser (for which there is a similar chicken-and-egg problem if you are downloading the browser over TLS) except that instead of a list of hundreds of CAs, you just have a single value to store.
Because I'm not the administrator for that domain, and even if I were, it would not support WKD. :) |
|
Hi Edwin, sorry for the big delay, I'm back! From what I can see OPENPGPKEY can achieve reasonable security guarantees only when:
I think that's asking for too many stars to align in a correct order to get it working. On the other hand WKD utilizes the most common elements of internet today - bare HTTP with TLS for which certificates are basically free and keys are just files on a webserver. It really can't get easier! Note that you can still wrap it in DNS-over-X. In WKD your DNS-over-X provider won't know you're even asking for keys, while with OPENPGKEY they'd see the query in plain text. But I think the real issue is network effects: no software uses OPENPGPKEY securely, barely any providers support it, it's on life support. While for WKD just recently ProtonMail added a way to query their users, Mailvelope 3 added support for fetching keys (check out the issue reference above, we're famous! ;) ), more and more users are aware of it and quite happy to set it up (from my point of view as a user of GPG mailing lists).
I generally don't do free, open-source stuff that I don't use myself and even though I have DNSSEC deployed on my domain my provider doesn't support OPENPGPKEY records and running bind just for that one record seems like an overkill. Not to mention dns-over-https is just one element of the puzzle right? We still need to validate the records ourselves! The In case we don't see each other soon: Merry 🎄 ! |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
In addition to (or instead of) issue #477, I suggest the feature of looking up a recipient's public key in the DNS using RFC-7929 (secured by DNSSEC). This avoids the problem of knowing which HKP server to use, and the problem of people uploading fake keys to these servers.
For reference, this is supported by GnuPG with the
--auto-key-locate daneoption.The text was updated successfully, but these errors were encountered: