Point taken on the DoS scenarios you propose, but they're definitely less serious, as far as the user is concerned. An unavailable DNS is better than a spoofed one, imo.
We agree on that.
Afaik, there are known key distribution and rollover problems with the standard as proposed.
DNSSEC as proposed ends up with a single root trust anchor, which is the easiest possible configuration as far as key distribution is concerned. There aren't any rollover problems that I know of; what's currently missing is the capability of most registrars to authenticate and sign DS records, which affects initial establishment and rollover of key-signing keys, and a clear plan from Verisign to sign.com and.net. Several ccTLDs have things in place already, and.gov and.org are close to deployment, and ICANN plans to sign the root by the end of the year.
Also, I'm not so fond of the idea of a single entity controlling the domain name system.
The entropy of query IDs was thought to be adequate to defend against all known methods of blind collision.
There seems to have been no valid technical reason for that particular belief, no?
At the time, there was no valid technical reason against it, so adding source port randomization was speculative. You seem to be having a hard time understanding that speculative measures require luck in order to pan out. That's why they're speculative.
You could also, for example, note when a nameserver has multiple IP addresses and have it randomize source address as well,
What good would that do? How would treating a particular deployment scenario do anything for the security of all the different servers?
You sound a lot like the guy djb was responding to in the post you cited... which is my point exactly. It may not help every scenario, but it adds log2(number of addresses) bits of entropy. And some systems may not have a lot of free UDP ports, so source port randomization doesn't help in every scenario either. It's a judgment call where you draw the line on adding speculative countermeasures, and djb made a lucky call on this one, as far as we know.
the approach djb chose may in fact have created vulnerabilities in other areas.
You meant "might" instead of "may", probably.
I don't know where you are getting your statistics, but I definitely mean "may", since there always may be vulnerabilities. Depending on the deployment scenario, there certainly are. For example, running a heavily used source-port-randomizing nameserver on a system that also needs to generate lots of SSL keys may be detrimental to the quality of those keys if it starves the entropy pool. Running a heavily used source-port-randomizing nameserver on systems that also issue a lot of RPC calls may impair performance if enough queries are outstanding that file descriptors or UDP ports are unavailable for the RPC clients to use. Just a couple of examples off the top of my head. And in any particular implementation, there may be problems people haven't discovered yet. That's what got us here, after all.
It's improbable (verging on damn near impossible) that the multi-vendor patch would have gone out (after months of hand-wringing) if anyone had suspected the fix might introduce other problems.
Your statistical oracle is off here too. The multi-vendor patch was known to cause performance problems on Solaris at the time of release. Your oracle will advise you that performance is "damn near certainly" part of the gestalt measure known as "security".
The solution to DNS cache poisoning has a name: DNSSEC. Source port randomization is a band-aid on top of another band-aid. Until recently, it was a speculative band-aid on top of a necessary band-aid.
Here's a comment from 2001 clearly stating the class of attacks against which source port randomization works as a mitigating factor.
The entropy of query IDs was thought to be adequate to defend against all known methods of blind collision. Of course, adding entropy in the source port makes it harder, but that's not a reason to do so by itself. You could also, for example, note when a nameserver has multiple IP addresses and have it randomize source address as well, but djb didn't do that, nor did he demonstrate that defending against speculative blind collision methods was worth the cost in system entropy and code complexity.
If there's any disingenuity here, it's in how you keep ignoring the effect additional complexity has on analyzing the security of the implementation, and that the approach djb chose may in fact have created vulnerabilities in other areas. To pretend that luck was not a factor here is absurd—even the best poker players need a little luck.
Are you seriously suggesting that no hacker ever found out about that particular trick until Kaminsky made such a fuss about it?
It's obvious no one knew about this attack until recently. Attacks don't stay secret for 7 years. A few weeks, sure, even a month or two, perhaps.
I'm not being disingenuous at all. Needless complexity is the enemy of security, and until you describe an attack, the complexity of source port randomization is needless. What's disingenuous is to pretend that djb wasn't adding complexity speculatively. Anyone can toss additional complexity into an implementation; this is usually considered "security through obscurity". The more complex implementation is trickier to audit, and may have obscure degenerate failure modes. It doesn't become useful security until someone finds an attack it defends against, and even then it may turn out to be the wrong approach in the long run.
Your quotation attributed to djb doesn't seem to make much sense, and you don't indicate where you found it.
The latest "NSEC3" adds even more complications but does essentially nothing to repair the privacy leaks; NSEC3 might be successful at its marketing goal of stopping European privacy regulators but it will almost never be successful at the security goal of stopping attackers.
With DNSSEC3, every request and response packet has high-security encryption and authentication. Both DNSSEC2 and DNSSEC3 completely avoid the "NSEC" privacy leaks.
These statements appear mutually contradictory. Presumably the "privacy leaks" are the enumeration via NSEC of zone data, which some people think should be private (one wonders how much security they think they get out of that tactic, or why they put "private" information in a publicly accessible system). Yes, NSEC3 solves this problem. The FUD that it will "almost never be successful", like most FUD, comes without any example of a weakness in NSEC3.
* Although the DNSSEC protocol allows some conservative cryptographic options that won't be broken in the near future, what DNSSEC users are actually being told to deploy---to partially compensate for serious speed problems in DNSSEC---is something that big companies and botnet operators can _already_ break, namely 1024-bit RSA.
Really? That's news to me. You can see how plausible that claim is to Schneier here.
Certainly I wouldn't rely on 1024-bit RSA for the long haul, but of course, regular key rotation is part of the DNSSEC operational guidelines—months for zone signing keys, and 1-2 years for key signing keys. So if 1024-bit keys do become factorable, one simply switches to 2048-bit keys on the next rotation.
The "serious speed problems" claim is exactly the sort of FUD that keeps coming up. Yet no one ever cites any recent research, or quotes any actual numbers. I wonder why that is.
I generally don't trust the CA's further than I can throw them.
Yet, they are the current standard for providing end-to-end security. So how mainstream to you think your level of doubt is?
Mind you, I don't trust the CAs either, which is why I want DNSSEC, since it can provide a superior mechanism with far fewer vectors for subversion, which I can control for my own domains, and which also is not vulnerable to cache poisoning.
Who do you figure is trustworthy enough to handle it for DNS? Who could be regarded as trustworthy, no matter who in the world you ask?
I would trust ICANN for the root. Obviously, you can't please everyone in the world, nor do you have to. For the TLDs, the current gTLD registry operators also happen to be CAs, so they can subvert both DNS and SSL already. Have you ever heard of a case of a CA subverting SSL security by deliberately issuing a false cert?
Having trust anchors at all is the problem. You need to verify against several independent sources, preferably sources you have some reason to trust, to avoid single points of corruption.
Yes, those independent sources are called "trust anchors". From your somewhat vague statement I presume you mean you'd like to make your trust anchor some form of composite, perhaps a web of trust of some kind. So then it would require some form of conspiracy to subvert the trust anchor. And you think that's superior to having a single trust anchor, which would require some form of conspiracy to subvert it.
And how do you propose that Joe User assess whether the DNS answer he gets is trustworthy in such a system, let alone come up with an initial set of trust anchors for his web of trust?
Designing a system based on a single point not failing is simply bad engineering.
Again you are vague; it's unclear what single point would fail in DNSSEC. Presumably the scenario you have in mind would be the root or TLD operators' subverting DNSSEC. Do you really think that's a plausible scenario? If so, why isn't it happening already with the CAs, any one of which could accomplish the same thing. Again, some CAs are also TLD operators, and many more of them can subvert DNS. Yet we don't have any evidence that this has happened.
It's spelled _in_secure.
That's your argument? Wordplay?
Maybe the problem is in the actual idea.
Or maybe the problem is in the FUD that people keep promulgating about the idea.
It's not like it's hard to come up with a list of options to improve and design a naming system to be redundant, fault tolerant, intervention tolerant and secure, yet there's an apparent fixation of going with a system that has obvious flaws.
Really? If it's so easy, let's hear your design.
Of course, it's easy to claim that designs have obvious flaws without presenting actual examples. Would you care to describe these obvious flaws in DNSSEC? What vulnerabilities exist, what are the plausible threat models, and how do those threat models compare to those of the status quo, or the easily designed system you have in mind?
DNSSEC gets bogged down in political and paranoid issues because DNSSEC has political issues designed into its core. It caters to the paranoid by ensuring there is plenty of opportunity to make paranoids right.
If deploying SSL had required proving to all the tin-foil hats in the world that CAs wouldn't be able to subvert the security of the system (of course, they are), it never would have gotten off the ground. Would you have the designers cater to every marginal threat in order to design a system that would be unwieldy beyond measure, impossible for a regular user to understand, and which still fails to provide perfect security?
Note the weasel words here, that DJB got lucky and ended up defending against an attack he never encountered. Even while crediting him for being right, Kaminsky won't admit that Bernstein anticipated these attacks several years ago, documented them clearly, and designed djbdns [cr.yp.to] to deal with them as best the broken protocol allows.
That's because there's a significant performance hit associated with:
Creating a new UDP socket with each transaction.
Getting 16 bits of entropy for a randomized port number.
Assuring that the socket is bound to the randomized port number; this may take multiple tries since the port may already be in use.
Keeping the socket open concurrently with all your other request sockets while you wait for a response.
Closing the socket after the response is received.
Doing all this in a way that you don't run out of source ports to bind to.
Not DoS-ing other parts of the system that may require UDP ports.
Given all of that additional overhead and complexity, and not yet knowing a specific attack that this behavior will defend against, it's not a clearly superior way to behave. You're slowing the system down and chewing up entropy for no clear gain.
So, yes, djb is lucky in that someone found an attack that this behavior defended against, and no one has so far found an attack that is exacerbated by this behavior.
Bernstein said that DNSSEC offers "a surprisingly low level of security" while causing severe problems for DNS reliability and performance.
More FUD. It's hard to imagine how DNS could be less reliable than it is now, and port randomization actually decreases performance significantly without even assuring security; effective port randomization additionally starves the system for entropy making everything else the system does less secure.
DNSSEC is the only alternative currently on the table that actually addresses cache poisoning head-on. It would be nice if influential people would either state clearly what the vulnerabilities are so they can be addressed properly, or just keep their opinions to themselves. Even better would be for them to, say, implement DNSSEC in their widely used resolving code, where applicable.
1. Everyone is connected by a gigabit cable to a common nameserver, and the admin of the nameserver is too stupid to realize that their dns being saturated with bogus packets at gigE speeds for 10 hours is not normal.
2. Both ISPs and routers for some reason decide stop filtering source addresses so that such an attack is possible without being directly connected.
3. Attackers find a way to remotely deploy and control malware on hundreds of thousands of computers in some sort of "malnet" or "botweb" or something.
Sign your zones, and if your registrar won't accept keys from you, send them to a DLV registry while you wait for that.
People who are interested in signing their zones may want to read up on how things work at www.dnssec.net and take a look at the Sparta tools. It's really not difficult, and there is a lot of information out there.
The third party hierarchical trust you disdain is one of the primary benefits of DNSSEC, because DNSSEC can eventually replace certificates for distribution of public keys. Currently, the only PKI we have is from a third-party non-hierarchical trust—the CAs—who are really not that trustworthy. DNS, however, is already hierarchical, and it makes a lot more sense to use a hierarchical system of trust—the same system in fact—to validate it. Do you really think having hundreds of trust anchors makes more sense than having a single trust chain?
What hampers DNSSEC, more than anything, is all the FUD about it. It's really not difficult to implement, and there are tools for nameserver operators to use. If people would start actually practicing signing domains, even without the trust chain, a lot of their fears would be allayed. What is technically standing in the way is the failure to plan for it on the part of the major registrars, who need to provide a mechanism for signing the DS records. Of course, a lot of those those registrars also happen to make a lot of money on the side as CAs, and one of them in particular also operates the.com and.net TLDs. You do the math—who benefits the most both from FUD about DNSSEC and from the insecurity of traditional DNS?
People need to set aside their paranoia about DNSSEC and understand that the worst case, most fantastical, trust violation scenarios for DNSSEC are still better than the status quo. And the best case is that everyone ends up with ubiqitous PKI with no per-unit cost. You could securely publish all your public keys, ssh host keys, personal public keys, etc. for the simple cost of getting a domain. If people can start seeing the possibilities for a single distributed, redundant, hierarchical, secure network database, there will be more community pressure on the registrars to get with the program. ICANN already plans to have a signed root by the end of the year and there are several ccTLDs that are already signing their zones. What excuse do we have for not even having a plan for.com? It's infuriating that we are facing the current situation, after all these years, and people are still questioning whether DNSSEC is a good idea.
I appreciate the response. I think I'll still connect to my self-cert IMAP mail server via SSL rather than plain text.
But presumably you've already added that certificate to your local store so it's trusted. And if you're providing that service for a number of users, why don't you buy a $15 cert from a cheap CA?
Clearly we have different ideas as to what is easy and what is difficult in pulling off an attack, and what is and isn't worth bothering to protect yourself against. A passive listener (Eve) seems to be much more common and very easy to protect against than an actual attacker (Mallory).
Again, Eve has to be on the network path, which few attackers are. Mallory can be anywhere if he can poison your DNS. Getting the DSniff stuff working is not difficult at all, and you don't even need that—a couple of stunnels connected by a logging script is sufficient. It's 20 minutes' work to set up. You don't even need to log both directions; client-to-server is where the credentials and credit card numbers are.
Understanding the threat requires considering more than the superficial difference in difficulty level between plain sniffing and setting up a man-in-the-middle attack. The potential reward to the attacker and the amount of effort required are important factors. With sniffing, the reward is small because you only have visibility on a small number of machines, and the effort required is large because you have to compromise a system on the network path for each victim, and monitor all traffic waiting for a few credentials to pass by. With a DNS-based man-in-the-middle attack, you just have to set up a proxy and poison a cache at one of the large ISPs and you can have literally hundreds of thousands of victims. The DNS-based attack can be targeted at the institutions you want credentials for, and you don't have to look at unrelated packets; the only traffic you see is directly related to the information you're looking for.
To me, it's obvious that the man-in-the-middle attack is a far, far larger threat, and I suspect the decision at Mozilla was informed at least in part by some advance knowledge of the Kaminsky DNS attack.
The caller ID spoofing bit of the phone attack I described isn't that difficult at all actually
Spoofing Caller ID was just one of the challenges in the attack you described. The attacker also has to be able to intercept calls and mimic at least two voices. If you want to talk about a scenario where the only authenticator is caller ID, then yes, I would agree that's somewhat like using a self-signed cert, though still perhaps more difficult to pull off than an SSL man-in-the-middle attack.
Kaminsky's presentation from Black Hat makes it abundantly clear that still we have a long way to go in terms of DNS remediation. Until then, man-in-the-middle attacks continue to be quite easy to accomplish.
You are correct, my mistake, there were two different people to who I replied in the same thread.
I suspected as much. It happens...
I meant the user in this case being the recipient, not the sender. The recipient received an encrypted mail (using his public key) that was unsigned. Must he disregard the content under all circumstances? Or could it possibly be that the encryption was meant to keep prying eyes from reading the content instead of serving another purpose?
I'm still not sure the example is what you intended. If someone sends me an unsigned, encrypted email, and I can read it, then the sender is using the correct public key, and no one else but me can read the message. The opportunity for subterfuge in this kind of scenario is that an attacker may give the sender a forged public key for my email address, and the person who uses that public key will generate an email which I can't read, but which the attacker can.
In the SSL scenario, the recipient is the SSL server, and whatever entity is connected to the server will use the public key the server sends in the Server Hello. A man in the middle could substitute a different public key in that step, but the conversation would stop when the server couldn't decrypt the client's message. As far as signing, unless you're using client certificates, the SSL process doesn't authenticate the sender; if the server requires authentication this is typically accomplished using a password at the application layer. If a bank didn't require you to authenticate somehow, and let someone transfer money out of your account, that would be a problem, just as it would be if someone sent me unsigned instructions, and I followed them without requiring some other form of authentication in the content of the message.
If you agree with all of those assertions how can you call encryption without authentication useless? They are two different problems, and solving one problem is better than solving none.
The confusion arises because the term "encryption" by itself is too unspecific, and is being used as shorthand for what's really going on. "Encryption" between two parties is fine, but that presumes that those parties have already established a shared key. That is, the point of encryption is privacy, and to have privacy, some method must be used to establish a key that only the parties in question possess. Publishing an encrypted document along with its private key doesn't accomplish anything useful, even though the document be properly encrypted.
The problem here is with the key establishment phase, because there is no evidence that you are establishing a shared key with the party that you want to talk to, rather than a malicious third party. Yes, "encryption" and "authentication" are two different things, but you can't do what "encryption" is short for in this context without having to authenticate first.
Similarly, in the pitch black room, you have "privacy" when you whisper your secret to the person who walks up to you—only you and that person know the secret. That privacy is useless, though, because you don't know whom you were being private with.
Wouldn't it be more akin to calling John via cell phone (self cert SSL) instead of yelling out what you want to say for all to hear (plain text)? Sure, somebody (at the phone company) could re-route the call and maybe they could also mimick John's voice, and maybe they later call John and spoof your caller ID and mimick your voice and relay to him what you said,
The difference is that doing all the things you describe is difficult, and there aren't publicly available tools for it. Being a man-in-the-middle in an SSL session established with an untrusted cert is easy. There are readily available tools for hijacking SSL sessions, and these tools keep getting better. Positioning oneself as a man in the middle is now easier than eve
Your single occasion getting a server cert from Verisign must either have involved getting an extended validation cert, or have occurred quite a few years ago. For regular certs, they may still ask for phone number and address, but they don't use them for anything. Dunn & Bradstreet number? Business incorporation number? I've never needed such things with any CA.
The principle authentication measure the CAs use these days is a cleartext email to an address in the domain, containing a token. In cases where your registrar is also a CA, you may be able to get a cert using the same authentication procedure needed for domain administration.
Historically, very few bogus certs have been issued by the standard CAs. That may change, however, especially as DNS continues to get weaker.
SSH is the example of a protocol that encrypts and doesn't have a CA behind it that we discussed earlier.
You appear to be confusing me with someone else. I haven't discussed ssh with you. In any case, trusting ssh host keys without verifying them is something that you shouldn't do, and the ssh client suitably warns you when you are about to do so, just as Firefox warns you when you are about to use a self-signed cert you haven't previously asserted as trustworthy.
In the future, hopefully, ssh host key validation will be automated using DNSSEC.
Sending an encrypted email to somebody using their public key but not signing the message with your own private key would be another example,
No, that's not an example, unless you failed to validate the public key of the recipient. You are confusing authentication of the peer with authentication to the peer. And even if you do sign the email, the peer still has to validate your public key before you've authenticated to him. This sort of confusion is a good example of why general users need to be sternly warned about self-signed certs—it's easy to get mixed up when you're trying to do crypto.
I agree in principle with all of your assertions. What's missing is how those assertions can lead you to conclude that Firefox should be more tolerant of self-signed certs than it is.
Beating a DNS server's response is only trivial because you need it to be for your argument to make any sense.
Beating a DNS server's response on a local network is only trivial because it's trivial. What do you imagine makes it the least bit difficult? Even if you didn't have better latency than the real nameserver, the real nameserver has to ask someone. You don't--your lie is ready to transmit as soon as you see the request.
You clearly have never done any this. I haven't even mentioned, oh, say, using a rogue DHCP server...
The fact is if all network traffic were encrypted without authentication (a method on which many protocols operate, as you even provided examples of), there would be a net gain in security.
No, there would be net gains in CPU utilization and difficulty of debugging network problems, both of which would lower security. Encryption without authentication is useless. You walk into a crowded, pitch black room and say "John, come over here; I want to tell you a secret." Someone comes over, and you whisper your secret to him or her. Well done!
I don't know what examples of protocols that encrypt without authentication you think I provided examples of.
You have yet to address my primary points in any of these responses, clearly you simply don't have an answer.
Perhaps you could indicate which points you consider primary, so that I can correct any additional errors you may have made there as well.
No, I assure you that I am not wrong, dns and arp poisoning are unreliable at best between peer nodes, dns poisoning is really only used effectively upstream. The reason for this is that the victim machine effectively spoofs it right back, so they become competing traffic (or in the case of DNS receives two replies, then timing becomes an issue).
And I assure you that you are indeed wrong. You only need to win these races once and you can remain interposed as long as you like. In fact, you don't need to win a race at all with arp spoofing. A targeted gratuitous arp will generally do the trick, and the host you're spoofing won't even know it happened because it never sees it. Hosts only arp when arp entries expire from cache, which is easy to prevent—just keep sending traffic to the respective hosts.
As for DNS spoofing, it's trivial to beat the DNS server at answering a resolution request.
I agree that a CA signed cert is "better" than self-signed, though still not perfect and not uncompromisable, just "better".
Sure, "better", in the same sense that "useful" is "better" than "useless".
A peer node can't modify your packets, it's not a matter of just using different software.
If, by "peer node" you mean a node in the same broadcast domain, you are 100% wrong. A "peer node" can very easily put itself in the middle, via arp spoofing, DNS spoofing, etc.
If you don't recognize that peer nodes are the largest threat (compared to ISP infrastructure) then you're not living in the real world.
"Peer nodes" have the most direct access to your traffic. That doesn't make them the largest threat for most people, since for most people there are relatively few attackers on "peer nodes". DNS cache poisoning can be effected by the much larger population of remote attackers.
They simply have to set up a listening server on port 443 with the same virtual domain setup they have, and put a * cert on that.
Any CA that signs a cert for * should have its CA cert revoked.
Frankly, anyone that uses a wildcard cert should have his ears boxed a few times. Wildcard certs are a moronic devolution that is driven by the economic model of the broken X.509 PKI we're using. We can do better.
The problem with IPsec is, frankly, it is never going to actually happen.
But the reason IPsec has not become commonplace is the lack of universal PKI.
In any case, IPsec is not necessary to replace TLS. A modified TLS-like encryption layer can use DNSSEC (or whatever ubiquitous PKI) to acquire public keys securely; they don't have to be signed by a CA as long as there is some other trust chain available. The key is to make it cost nothing to set up this trust chain for each host. Since DNSSEC is needed anyway to solve DNS cache poisoning, we might as well use it to provide universal PKI. It would be silly to pay a CA to try to prove, via cleartext email, that you control a domain, so they can sign your public key, when you could instead simply add it to the DNS.
Ha, I wish I had as much authority over my server as you. There's no way I could justify breaking everyone's mail connection...again.
All you need to do is adopt a policy that all credentials have to be encrypted in transit, and then you have the leverage you need. Any company that considers its proprietary information to be private should have a hard time arguing with that. And it's easy enough to demonstrate to management bozos how trivial it is to sniff passwords off the wire.
I doubt I can use the same logic for unencrypted connections. If it's not broken don't fix it is the motto at most companies, and definitely don't fix it in a way that breaks current setup for people.
You don't have to break it, initially. You can just auto-nag all the users that use cleartext ports until they stop, then disable the cleartext ports.
That way it could be, like you say, a layer on top of the application. You'd probably get it free with sockets in libc. Stick a flag on the socket when you make it, and it only accepts SSL.
This is the sort of thing we could have with opportunistic encryption using IPsec. But for that we need universal PKI. With universal PKI, every system can have one or more public keys. Authentication can then be mutual between systems. The application protocols could be, as you suggest, almost completely oblivious to this; they will simply require a secure socket and an IPsec tunnel is created automatically.
If we ever get this, we may regret all the work that has been done to munge protocols with TLS awareness.
A big reason I advocate DNSSEC is because it has the capability to provide this universal PKI at no per-system cost to the domain owner. Once you have a signed domain, CAs are no longer needed because you have a superior chain of trust right there in the DNS.
what's actually going on is that almost none of the population is using SSL ports at all
I recognize that that's the status quo, but it's easy enough to fix. Admins just need to disable the cleartext ports and publish instructions for their users (not necessarily in that order;^). Every one of my mail users uses IMAPS, because port 993 is the only protocol available. And even if they were to muck up the client config by changing the port to 993 without checking the SSL/TLS box, they wouldn't be able to get to the point of sending IMAP credentials in the clear, because the IMAP client won't be able to read a server hello.
Yes, a couple of years ago, this wasn't workable for the little guys. But with $20/year certs available now, it's kind of inexcusable to do anything else.
Sure it would. The telnet protocol [iana.org] allows both ends to specify requirements, and results in a disconnect if the other end doesn't support it. (In fact, it appears to already support SSL, but I suspect that doesn't include certs.
Nonetheless, what I described—the client cannot talk to the server in the clear at all because the corresponding port is not listening—is not possible.
Furthermore, a switching system entangles application protocols with the constantly mutating TLS, which would make maintenance of both more difficult.
I don't know what you mean by that. SSL negotiates itself quite well between different versions.
I mean that every protocol has to define a unique way to start TLS negotiation: LDAP sends a particular OID, SMTP uses STARTTLS, IMPP uses a <starttls...> tag, etc. Then the protocol has handle various failures gracefully.
With the separate port method, TLS is just a layer on top of the application protocol and the application protocol can focus on doing what is was designed to do. In addition, each application that adopts TLS as a native feature locks us in deeper to TLS, both in code added to implementations and in TLS-specific error handling. This makes it harder to swap TLS out for something better if/when that comes along.
Furthermore, SSL's being a mixed binary and ASN.1 protocol makes it very squirrelly when a line-based protocol such as IMAP or SMTP switches it on. At best, it's, shall we say, aesthetically displeasing.
clients cannot state what website they are actually connecting to, so the server cannot present the correct certificate for that web site. Which is why HTTPS sites need their own IP.
That's a defect in the original design of SSL, which should give you an idea as to how well thought out it was (not very). This problem is addressed with the extended Client Hello, which is gradually being adopted in client software. Within a year or so, hopefully, virtually hosted SSL sites will be commonplace.
I mean, type the wrong domain name in, and who knows where it will send your credentials!
True, but domain name, unlike TLS/STARTTLS settings in a client, is relatively hard for Joe User to get wrong. And if he succeeds, the eavesdropper doesn't automatically know what host the credentials are for.
Whereas, with a two port system, all clients are going to default to the unencrypted port, which means they will have no security at all.
Unless the server isn't even listening on the cleartext port, which is how I configure my systems. This way the client can't establish a connection to the non-SSL version, let alone send credentials or other data in the clear. This wouldn't be possible in the switching system you advocate for.
Furthermore, a switching system entangles application protocols with the constantly mutating TLS, which would make maintenance of both more difficult.
And, of course, nothing would stop clients from offering a 'refuse to send credentials until encrypted' toggle.
There'd be no harm in having such a toggle for clients, but as server admin, I don't get to make sure it's set. So I prefer a method where I can keep the client from talking to the server unless SSL is already negotiated.
An alternative to the status quo that might satisfy both of us would be to do away with cleartext IMAP and POP altogether. But for services like SMTP, HTTP, and LDAP, a parallel cleartext version is less dispensible.
Although a more logical default, especially for mail clients, would just be to store a cert, for each connection, when they get it, and warn if it changes.
Certificates change regularly for legitimate reasons. I see no reason to confuse users by alerting them when this happens.
I'm not sure what problems you think having TLS-wrapped port designations causes.
Well, um, there's exactly what we're talking about, with HTTPS connections.
Yes, what specific problem are you talking about? HTTP is for anything that doesn't require a secret (mod Digest auth); HTTPS is for everything else. What's the problem?
reading other people here talking about unauthenticated HTTPS, we are apparently required to assume there are dozens of MitM attempting to hijack our connections
If you assume otherwise, you get what you deserve.
Writing all protocols where you first connect in plaintext, and then switch to an encrypted connection, would have been infinitely more sensible.
I disagree. With STARTTLS, it's much easier for a misconfigured client to send credentials in the clear. Server policy may prevent those credentials from being honored before TLS establishment, but by then they've already been exposed.
I'm not sure what problems you think having TLS-wrapped port designations causes.
Everyone's switching over now, with things like STARTTLS and the new virtual hosts for HTTPS (I believe that starts unencrypted and sends the hostname, and then flips to encrypted, but I could be wrong.)
The client uses an extended TLS Hello that contains the desired hostname. It's not encrypted, since it precedes key establishment. As far as I know, this is not in wide deployment as of yet.
Slashdot Mirror
We agree on that.
DNSSEC as proposed ends up with a single root trust anchor, which is the easiest possible configuration as far as key distribution is concerned. There aren't any rollover problems that I know of; what's currently missing is the capability of most registrars to authenticate and sign DS records, which affects initial establishment and rollover of key-signing keys, and a clear plan from Verisign to sign .com and .net. Several ccTLDs have things in place already, and .gov and .org are close to deployment, and ICANN plans to sign the root by the end of the year.
This aspect is no different from the status quo.
At the time, there was no valid technical reason against it, so adding source port randomization was speculative. You seem to be having a hard time understanding that speculative measures require luck in order to pan out. That's why they're speculative.
You sound a lot like the guy djb was responding to in the post you cited... which is my point exactly. It may not help every scenario, but it adds log2(number of addresses) bits of entropy. And some systems may not have a lot of free UDP ports, so source port randomization doesn't help in every scenario either. It's a judgment call where you draw the line on adding speculative countermeasures, and djb made a lucky call on this one, as far as we know.
I don't know where you are getting your statistics, but I definitely mean "may", since there always may be vulnerabilities. Depending on the deployment scenario, there certainly are. For example, running a heavily used source-port-randomizing nameserver on a system that also needs to generate lots of SSL keys may be detrimental to the quality of those keys if it starves the entropy pool. Running a heavily used source-port-randomizing nameserver on systems that also issue a lot of RPC calls may impair performance if enough queries are outstanding that file descriptors or UDP ports are unavailable for the RPC clients to use. Just a couple of examples off the top of my head. And in any particular implementation, there may be problems people haven't discovered yet. That's what got us here, after all.
Your statistical oracle is off here too. The multi-vendor patch was known to cause performance problems on Solaris at the time of release. Your oracle will advise you that performance is "damn near certainly" part of the gestalt measure known as "security".
The solution to DNS cache poisoning has a name: DNSSEC. Source port randomization is a band-aid on top of another band-aid. Until recently, it was a speculative band-aid on top of a necessary band-aid.
The entropy of query IDs was thought to be adequate to defend against all known methods of blind collision. Of course, adding entropy in the source port makes it harder, but that's not a reason to do so by itself. You could also, for example, note when a nameserver has multiple IP addresses and have it randomize source address as well, but djb didn't do that, nor did he demonstrate that defending against speculative blind collision methods was worth the cost in system entropy and code complexity.
If there's any disingenuity here, it's in how you keep ignoring the effect additional complexity has on analyzing the security of the implementation, and that the approach djb chose may in fact have created vulnerabilities in other areas. To pretend that luck was not a factor here is absurd—even the best poker players need a little luck.
It's obvious no one knew about this attack until recently. Attacks don't stay secret for 7 years. A few weeks, sure, even a month or two, perhaps.
I'm not being disingenuous at all. Needless complexity is the enemy of security, and until you describe an attack, the complexity of source port randomization is needless. What's disingenuous is to pretend that djb wasn't adding complexity speculatively. Anyone can toss additional complexity into an implementation; this is usually considered "security through obscurity". The more complex implementation is trickier to audit, and may have obscure degenerate failure modes. It doesn't become useful security until someone finds an attack it defends against, and even then it may turn out to be the wrong approach in the long run.
Your quotation attributed to djb doesn't seem to make much sense, and you don't indicate where you found it.
These statements appear mutually contradictory. Presumably the "privacy leaks" are the enumeration via NSEC of zone data, which some people think should be private (one wonders how much security they think they get out of that tactic, or why they put "private" information in a publicly accessible system). Yes, NSEC3 solves this problem. The FUD that it will "almost never be successful", like most FUD, comes without any example of a weakness in NSEC3.
Really? That's news to me. You can see how plausible that claim is to Schneier here.
Certainly I wouldn't rely on 1024-bit RSA for the long haul, but of course, regular key rotation is part of the DNSSEC operational guidelines—months for zone signing keys, and 1-2 years for key signing keys. So if 1024-bit keys do become factorable, one simply switches to 2048-bit keys on the next rotation.
The "serious speed problems" claim is exactly the sort of FUD that keeps coming up. Yet no one ever cites any recent research, or quotes any actual numbers. I wonder why that is.
Yet, they are the current standard for providing end-to-end security. So how mainstream to you think your level of doubt is?
Mind you, I don't trust the CAs either, which is why I want DNSSEC, since it can provide a superior mechanism with far fewer vectors for subversion, which I can control for my own domains, and which also is not vulnerable to cache poisoning.
I would trust ICANN for the root. Obviously, you can't please everyone in the world, nor do you have to. For the TLDs, the current gTLD registry operators also happen to be CAs, so they can subvert both DNS and SSL already. Have you ever heard of a case of a CA subverting SSL security by deliberately issuing a false cert?
Yes, those independent sources are called "trust anchors". From your somewhat vague statement I presume you mean you'd like to make your trust anchor some form of composite, perhaps a web of trust of some kind. So then it would require some form of conspiracy to subvert the trust anchor. And you think that's superior to having a single trust anchor, which would require some form of conspiracy to subvert it.
And how do you propose that Joe User assess whether the DNS answer he gets is trustworthy in such a system, let alone come up with an initial set of trust anchors for his web of trust?
Again you are vague; it's unclear what single point would fail in DNSSEC. Presumably the scenario you have in mind would be the root or TLD operators' subverting DNSSEC. Do you really think that's a plausible scenario? If so, why isn't it happening already with the CAs, any one of which could accomplish the same thing. Again, some CAs are also TLD operators, and many more of them can subvert DNS. Yet we don't have any evidence that this has happened.
That's your argument? Wordplay?
Or maybe the problem is in the FUD that people keep promulgating about the idea.
Really? If it's so easy, let's hear your design.
Of course, it's easy to claim that designs have obvious flaws without presenting actual examples. Would you care to describe these obvious flaws in DNSSEC? What vulnerabilities exist, what are the plausible threat models, and how do those threat models compare to those of the status quo, or the easily designed system you have in mind?
If deploying SSL had required proving to all the tin-foil hats in the world that CAs wouldn't be able to subvert the security of the system (of course, they are), it never would have gotten off the ground. Would you have the designers cater to every marginal threat in order to design a system that would be unwieldy beyond measure, impossible for a regular user to understand, and which still fails to provide perfect security?
That's because there's a significant performance hit associated with:
Given all of that additional overhead and complexity, and not yet knowing a specific attack that this behavior will defend against, it's not a clearly superior way to behave. You're slowing the system down and chewing up entropy for no clear gain.
So, yes, djb is lucky in that someone found an attack that this behavior defended against, and no one has so far found an attack that is exacerbated by this behavior.
More FUD. It's hard to imagine how DNS could be less reliable than it is now, and port randomization actually decreases performance significantly without even assuring security; effective port randomization additionally starves the system for entropy making everything else the system does less secure.
DNSSEC is the only alternative currently on the table that actually addresses cache poisoning head-on. It would be nice if influential people would either state clearly what the vulnerabilities are so they can be addressed properly, or just keep their opinions to themselves. Even better would be for them to, say, implement DNSSEC in their widely used resolving code, where applicable.
3. Attackers find a way to remotely deploy and control malware on hundreds of thousands of computers in some sort of "malnet" or "botweb" or something.
Oh, wait...
People who are interested in signing their zones may want to read up on how things work at www.dnssec.net and take a look at the Sparta tools. It's really not difficult, and there is a lot of information out there.
The third party hierarchical trust you disdain is one of the primary benefits of DNSSEC, because DNSSEC can eventually replace certificates for distribution of public keys. Currently, the only PKI we have is from a third-party non-hierarchical trust—the CAs—who are really not that trustworthy. DNS, however, is already hierarchical, and it makes a lot more sense to use a hierarchical system of trust—the same system in fact—to validate it. Do you really think having hundreds of trust anchors makes more sense than having a single trust chain?
What hampers DNSSEC, more than anything, is all the FUD about it. It's really not difficult to implement, and there are tools for nameserver operators to use. If people would start actually practicing signing domains, even without the trust chain, a lot of their fears would be allayed. What is technically standing in the way is the failure to plan for it on the part of the major registrars, who need to provide a mechanism for signing the DS records. Of course, a lot of those those registrars also happen to make a lot of money on the side as CAs, and one of them in particular also operates the .com and .net TLDs. You do the math—who benefits the most both from FUD about DNSSEC and from the insecurity of traditional DNS?
People need to set aside their paranoia about DNSSEC and understand that the worst case, most fantastical, trust violation scenarios for DNSSEC are still better than the status quo. And the best case is that everyone ends up with ubiqitous PKI with no per-unit cost. You could securely publish all your public keys, ssh host keys, personal public keys, etc. for the simple cost of getting a domain. If people can start seeing the possibilities for a single distributed, redundant, hierarchical, secure network database, there will be more community pressure on the registrars to get with the program. ICANN already plans to have a signed root by the end of the year and there are several ccTLDs that are already signing their zones. What excuse do we have for not even having a plan for .com? It's infuriating that we are facing the current situation, after all these years, and people are still questioning whether DNSSEC is a good idea.
But presumably you've already added that certificate to your local store so it's trusted. And if you're providing that service for a number of users, why don't you buy a $15 cert from a cheap CA?
Again, Eve has to be on the network path, which few attackers are. Mallory can be anywhere if he can poison your DNS. Getting the DSniff stuff working is not difficult at all, and you don't even need that—a couple of stunnels connected by a logging script is sufficient. It's 20 minutes' work to set up. You don't even need to log both directions; client-to-server is where the credentials and credit card numbers are.
Understanding the threat requires considering more than the superficial difference in difficulty level between plain sniffing and setting up a man-in-the-middle attack. The potential reward to the attacker and the amount of effort required are important factors. With sniffing, the reward is small because you only have visibility on a small number of machines, and the effort required is large because you have to compromise a system on the network path for each victim, and monitor all traffic waiting for a few credentials to pass by. With a DNS-based man-in-the-middle attack, you just have to set up a proxy and poison a cache at one of the large ISPs and you can have literally hundreds of thousands of victims. The DNS-based attack can be targeted at the institutions you want credentials for, and you don't have to look at unrelated packets; the only traffic you see is directly related to the information you're looking for.
To me, it's obvious that the man-in-the-middle attack is a far, far larger threat, and I suspect the decision at Mozilla was informed at least in part by some advance knowledge of the Kaminsky DNS attack.
Spoofing Caller ID was just one of the challenges in the attack you described. The attacker also has to be able to intercept calls and mimic at least two voices. If you want to talk about a scenario where the only authenticator is caller ID, then yes, I would agree that's somewhat like using a self-signed cert, though still perhaps more difficult to pull off than an SSL man-in-the-middle attack.
Kaminsky's presentation from Black Hat makes it abundantly clear that still we have a long way to go in terms of DNS remediation. Until then, man-in-the-middle attacks continue to be quite easy to accomplish.
I suspected as much. It happens...
I'm still not sure the example is what you intended. If someone sends me an unsigned, encrypted email, and I can read it, then the sender is using the correct public key, and no one else but me can read the message. The opportunity for subterfuge in this kind of scenario is that an attacker may give the sender a forged public key for my email address, and the person who uses that public key will generate an email which I can't read, but which the attacker can.
In the SSL scenario, the recipient is the SSL server, and whatever entity is connected to the server will use the public key the server sends in the Server Hello. A man in the middle could substitute a different public key in that step, but the conversation would stop when the server couldn't decrypt the client's message. As far as signing, unless you're using client certificates, the SSL process doesn't authenticate the sender; if the server requires authentication this is typically accomplished using a password at the application layer. If a bank didn't require you to authenticate somehow, and let someone transfer money out of your account, that would be a problem, just as it would be if someone sent me unsigned instructions, and I followed them without requiring some other form of authentication in the content of the message.
The confusion arises because the term "encryption" by itself is too unspecific, and is being used as shorthand for what's really going on. "Encryption" between two parties is fine, but that presumes that those parties have already established a shared key. That is, the point of encryption is privacy, and to have privacy, some method must be used to establish a key that only the parties in question possess. Publishing an encrypted document along with its private key doesn't accomplish anything useful, even though the document be properly encrypted.
The problem here is with the key establishment phase, because there is no evidence that you are establishing a shared key with the party that you want to talk to, rather than a malicious third party. Yes, "encryption" and "authentication" are two different things, but you can't do what "encryption" is short for in this context without having to authenticate first.
Similarly, in the pitch black room, you have "privacy" when you whisper your secret to the person who walks up to you—only you and that person know the secret. That privacy is useless, though, because you don't know whom you were being private with.
The difference is that doing all the things you describe is difficult, and there aren't publicly available tools for it. Being a man-in-the-middle in an SSL session established with an untrusted cert is easy. There are readily available tools for hijacking SSL sessions, and these tools keep getting better. Positioning oneself as a man in the middle is now easier than eve
Your single occasion getting a server cert from Verisign must either have involved getting an extended validation cert, or have occurred quite a few years ago. For regular certs, they may still ask for phone number and address, but they don't use them for anything. Dunn & Bradstreet number? Business incorporation number? I've never needed such things with any CA.
The principle authentication measure the CAs use these days is a cleartext email to an address in the domain, containing a token. In cases where your registrar is also a CA, you may be able to get a cert using the same authentication procedure needed for domain administration.
Historically, very few bogus certs have been issued by the standard CAs. That may change, however, especially as DNS continues to get weaker.
You appear to be confusing me with someone else. I haven't discussed ssh with you. In any case, trusting ssh host keys without verifying them is something that you shouldn't do, and the ssh client suitably warns you when you are about to do so, just as Firefox warns you when you are about to use a self-signed cert you haven't previously asserted as trustworthy.
In the future, hopefully, ssh host key validation will be automated using DNSSEC.
No, that's not an example, unless you failed to validate the public key of the recipient. You are confusing authentication of the peer with authentication to the peer. And even if you do sign the email, the peer still has to validate your public key before you've authenticated to him. This sort of confusion is a good example of why general users need to be sternly warned about self-signed certs—it's easy to get mixed up when you're trying to do crypto.
I agree in principle with all of your assertions. What's missing is how those assertions can lead you to conclude that Firefox should be more tolerant of self-signed certs than it is.
Beating a DNS server's response on a local network is only trivial because it's trivial. What do you imagine makes it the least bit difficult? Even if you didn't have better latency than the real nameserver, the real nameserver has to ask someone. You don't--your lie is ready to transmit as soon as you see the request.
You clearly have never done any this. I haven't even mentioned, oh, say, using a rogue DHCP server...
No, there would be net gains in CPU utilization and difficulty of debugging network problems, both of which would lower security. Encryption without authentication is useless. You walk into a crowded, pitch black room and say "John, come over here; I want to tell you a secret." Someone comes over, and you whisper your secret to him or her. Well done!
I don't know what examples of protocols that encrypt without authentication you think I provided examples of.
Perhaps you could indicate which points you consider primary, so that I can correct any additional errors you may have made there as well.
And I assure you that you are indeed wrong. You only need to win these races once and you can remain interposed as long as you like. In fact, you don't need to win a race at all with arp spoofing. A targeted gratuitous arp will generally do the trick, and the host you're spoofing won't even know it happened because it never sees it. Hosts only arp when arp entries expire from cache, which is easy to prevent—just keep sending traffic to the respective hosts.
As for DNS spoofing, it's trivial to beat the DNS server at answering a resolution request.
Sure, "better", in the same sense that "useful" is "better" than "useless".
If, by "peer node" you mean a node in the same broadcast domain, you are 100% wrong. A "peer node" can very easily put itself in the middle, via arp spoofing, DNS spoofing, etc.
"Peer nodes" have the most direct access to your traffic. That doesn't make them the largest threat for most people, since for most people there are relatively few attackers on "peer nodes". DNS cache poisoning can be effected by the much larger population of remote attackers.
Any CA that signs a cert for * should have its CA cert revoked.
Frankly, anyone that uses a wildcard cert should have his ears boxed a few times. Wildcard certs are a moronic devolution that is driven by the economic model of the broken X.509 PKI we're using. We can do better.
But the reason IPsec has not become commonplace is the lack of universal PKI.
In any case, IPsec is not necessary to replace TLS. A modified TLS-like encryption layer can use DNSSEC (or whatever ubiquitous PKI) to acquire public keys securely; they don't have to be signed by a CA as long as there is some other trust chain available. The key is to make it cost nothing to set up this trust chain for each host. Since DNSSEC is needed anyway to solve DNS cache poisoning, we might as well use it to provide universal PKI. It would be silly to pay a CA to try to prove, via cleartext email, that you control a domain, so they can sign your public key, when you could instead simply add it to the DNS.
All you need to do is adopt a policy that all credentials have to be encrypted in transit, and then you have the leverage you need. Any company that considers its proprietary information to be private should have a hard time arguing with that. And it's easy enough to demonstrate to management bozos how trivial it is to sniff passwords off the wire.
You don't have to break it, initially. You can just auto-nag all the users that use cleartext ports until they stop, then disable the cleartext ports.
This is the sort of thing we could have with opportunistic encryption using IPsec. But for that we need universal PKI. With universal PKI, every system can have one or more public keys. Authentication can then be mutual between systems. The application protocols could be, as you suggest, almost completely oblivious to this; they will simply require a secure socket and an IPsec tunnel is created automatically.
If we ever get this, we may regret all the work that has been done to munge protocols with TLS awareness.
A big reason I advocate DNSSEC is because it has the capability to provide this universal PKI at no per-system cost to the domain owner. Once you have a signed domain, CAs are no longer needed because you have a superior chain of trust right there in the DNS.
I recognize that that's the status quo, but it's easy enough to fix. Admins just need to disable the cleartext ports and publish instructions for their users (not necessarily in that order ;^). Every one of my mail users uses IMAPS, because port 993 is the only protocol available. And even if they were to muck up the client config by changing the port to 993 without checking the SSL/TLS box, they wouldn't be able to get to the point of sending IMAP credentials in the clear, because the IMAP client won't be able to read a server hello.
Yes, a couple of years ago, this wasn't workable for the little guys. But with $20/year certs available now, it's kind of inexcusable to do anything else.
Nonetheless, what I described—the client cannot talk to the server in the clear at all because the corresponding port is not listening—is not possible.
I mean that every protocol has to define a unique way to start TLS negotiation: LDAP sends a particular OID, SMTP uses STARTTLS, IMPP uses a <starttls...> tag, etc. Then the protocol has handle various failures gracefully.
With the separate port method, TLS is just a layer on top of the application protocol and the application protocol can focus on doing what is was designed to do. In addition, each application that adopts TLS as a native feature locks us in deeper to TLS, both in code added to implementations and in TLS-specific error handling. This makes it harder to swap TLS out for something better if/when that comes along.
Furthermore, SSL's being a mixed binary and ASN.1 protocol makes it very squirrelly when a line-based protocol such as IMAP or SMTP switches it on. At best, it's, shall we say, aesthetically displeasing.
That's a defect in the original design of SSL, which should give you an idea as to how well thought out it was (not very). This problem is addressed with the extended Client Hello, which is gradually being adopted in client software. Within a year or so, hopefully, virtually hosted SSL sites will be commonplace.
True, but domain name, unlike TLS/STARTTLS settings in a client, is relatively hard for Joe User to get wrong. And if he succeeds, the eavesdropper doesn't automatically know what host the credentials are for.
Unless the server isn't even listening on the cleartext port, which is how I configure my systems. This way the client can't establish a connection to the non-SSL version, let alone send credentials or other data in the clear. This wouldn't be possible in the switching system you advocate for.
Furthermore, a switching system entangles application protocols with the constantly mutating TLS, which would make maintenance of both more difficult.
There'd be no harm in having such a toggle for clients, but as server admin, I don't get to make sure it's set. So I prefer a method where I can keep the client from talking to the server unless SSL is already negotiated.
An alternative to the status quo that might satisfy both of us would be to do away with cleartext IMAP and POP altogether. But for services like SMTP, HTTP, and LDAP, a parallel cleartext version is less dispensible.
Certificates change regularly for legitimate reasons. I see no reason to confuse users by alerting them when this happens.
Yes, what specific problem are you talking about? HTTP is for anything that doesn't require a secret (mod Digest auth); HTTPS is for everything else. What's the problem?
If you assume otherwise, you get what you deserve.
I disagree. With STARTTLS, it's much easier for a misconfigured client to send credentials in the clear. Server policy may prevent those credentials from being honored before TLS establishment, but by then they've already been exposed.
I'm not sure what problems you think having TLS-wrapped port designations causes.
The client uses an extended TLS Hello that contains the desired hostname. It's not encrypted, since it precedes key establishment. As far as I know, this is not in wide deployment as of yet.