From pde at eff.org Thu Dec 1 09:47:48 2011 From: pde at eff.org (Peter Eckersley) Date: Thu, 1 Dec 2011 09:47:48 -0800 Subject: [Sovereign Keys] First post / objectives for this list Message-ID: <20111201174748.GA27022@xylophonic> This is a mailing list for discussing the Sovereign Keys proposal and implementations of it: https://eff.org/sovereign-keys As well as its advantages and disadvantages when compared to related proposals. -- Peter Eckersley pde at eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 From pde at eff.org Thu Dec 1 10:22:55 2011 From: pde at eff.org (Peter Eckersley) Date: Thu, 1 Dec 2011 10:22:55 -0800 Subject: [Sovereign Keys] The captive portal problem (and a solution?) Message-ID: <20111201182255.GB26806@xylophonic> (Thanks to agl for pointing out the seriousness of the second half of this problem) There are at least two layers to the captive portal problem. 1. The first is that if we implement secure HTTPS-only semantics for most major websites, captive portals' attempts to hijack their users will fail. That makes it hard for unsophisticated users to supply the credentials/ransom that these networks request. We have this problem today with HSTS and HTTPS Everywhere. It would get worse if DANE, Sovereign Keys, or some of the other proposed TLS authentication enhancements were deployed. We need to build a user interface that notices hijacking attempts in a reasonable way, and says something like "this network is preventing a secure connection to google.com. Would you like to make an insecure connection to hijack-me.com instead?" 2. Any TLS authentication enhancement that requires a side-channel (DANE with client verification, Sovereign Keys, Perspectives, Convergence, etc) must either fail unsafe, or will be deadlocked if a captive portal tries to use HTTPS for its authentication process. The one side channel that we know still works in this situation is the X.509 cert chain itself. Except that isn't a safe communications method, because attackers can strip your special certs off the end of the chain and just show you a simple chain signed by a compromised CA. Perhaps one day we could build clients that /demand/ new things in the X.509 chain, and fail if they're absent, but that's not going to happen this decade. My current proposed solution to the side-channel/captive portal deadlock problem is to build and maintain a whitelist of the domains that captive portals hijack users to. We could use the Decentralized SSL Observatory, or better yet, instrumentation in a major browser, to collect this (it's the set of domains that many other domains are 302'd to on certain networks only). The whitelist needs to be used in such a way that it never decreases the security of any real (non-captive portal) websites. With Sovereign Keys that's fairly easy: if you ever see a Sovereign Key registration for a domain on the whitelist, you immediately remove it from the whitelist. https://git.eff.org/?p=sovereign-keys.git;a=blob;f=issues/captive-portals.txt;hb=HEAD -- Peter Eckersley pde at eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 From pde at eff.org Tue Dec 6 15:29:40 2011 From: pde at eff.org (Peter Eckersley) Date: Tue, 6 Dec 2011 15:29:40 -0800 Subject: [Sovereign Keys] [SSL Observatory] Frequent cert issuers and an estimate for Sovereign Keys protocol alteration bound against DOS In-Reply-To: <4EDB150D.8050509@nic.cz> References: <4EDB150D.8050509@nic.cz> Message-ID: <20111206232940.GB23430@xylophonic> On Sun, Dec 04, 2011 at 07:37:01AM +0100, Ondrej Mikle wrote: > The issuing frequency might be a good lead for setting DOS-protection limit of > allowed protocol changes per time unit in Sovereign Keys implementation > (original draft had 5 changes per month, IIRC). Note that in the current Sovereign Keys draft design doc, changes to the operational keys on a webserver would not require any writing to the SK timeline. So long as each new operational key/X.509 chain was cross-signed by the Sovereign Key, it would work. The only time you write to the timeline is if you need to revoke or renew the offline Sovereign Key, or change what protocols (HTTP, SMTP, POP, IMAP, XMPP, etc) it is active for. A somewhat relevant aside: the cross-signatures would be embedded in their own extraneous X.509 certs, so the Sovereign Key operator could choose what if any revocation mechanisms they wanted to use for their operational keys (OCSP, CRLs, short-lived cross signatures, or null). > > One additional consideration for "pinning cert protocols" (DANE, Sovereign Keys, > Auditable CAs, ...) is that such a frequent change must reflect fast to relying > clients. Shouldn't be really a problem, just a point to note. > -- Peter Eckersley pde at eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 From ondrej.mikle at nic.cz Sun Dec 18 15:23:48 2011 From: ondrej.mikle at nic.cz (Ondrej Mikle) Date: Mon, 19 Dec 2011 00:23:48 +0100 Subject: [Sovereign Keys] Evidence for claim - CA-signed certificate Message-ID: <4EEE7604.3060101@nic.cz> Hi, I'm a bit puzzled by the option of using CA-signed certificate to claim control of DNS name. Despite having re-read the text couple of times, I think I'm not understading it correctly. According to my interpretation, owner of domain example.com can create additional RSA/ECC sovereign key and obtain a CA-signed certificate that has the key in SubjectPublicKeyInfo and domain's FQDN in CN/SAN. Though this would create a loophole: if an attacker gains control of any CA (or uses other tricks), he can issue himself a CA-certificate with key of his choosing and use that certificate for claim of domain's ownership. What am I missing? Ondrej From 4brad at templetons.com Sun Dec 18 15:47:33 2011 From: 4brad at templetons.com (Brad Templeton) Date: Sun, 18 Dec 2011 15:47:33 -0800 Subject: [Sovereign Keys] New and old domains and SKs In-Reply-To: <4EEE7604.3060101@nic.cz> References: <4EEE7604.3060101@nic.cz> Message-ID: <4EEE7B95.2050104@templetons.com> My main area of concern with sovereign keys, as I have expressed to Peter, is the danger of their use as a denial of service attack on sites that are not aware of the SK system but get compromised. The attacker uses control of the site to generate an SK known only to him, and now the site can be held for permanent ransom to this key, due to the irrevocable nature of SKs. (A second concern is loss of all copies of the SK, which in spite of how diligent we make people be will still happen.) I believe that without care, negative consequences of SKs will outnumber the instances of avoidance of domain hijacking by those who can control CAs. To wit: a) It should be much harder to get an SK for a well established domain, particularly one with high pagerank (pagerank can be queried.) If one gets an SK for such a domain, it should take time (at least a month) before the key is irrevocable. b) There should be short-term revocation schemes, which might well involve CAs. This allows somebody who controls a CA to revoke your SK if it is fairly new, but the older it is, the harder it is. c) Age should require use of the key, ie. not just how long since the key was created but how long since it has been actively in use at the targeted domain. "In use" checks must not come from predictable sources lest attackers make the domain appear to be in use only to the SK test servers. d) A browser plugin should be made available where a user can declare "I wish to pay special attention to domains matching this pattern." In this event, any security events -- such as creation and use of SKs for such domains, changes in certificates, reductions in TLS security levels -- all generate special warnings. Thus it is harder for attackers to surprise you by playing games with your domain. Strict warnings cause false alarms for users and thus don't work, but being very strict on domains you own yourself is a good idea. e) Creation of an SK for highly valuable domains should involve several out of band efforts to confirm with sysadmins, getting progressively annoying. (If they confirm immediately there is no problem.) This includes mail to contact addresses, as well as root/postmaster addresses. Confirmation should involve access to something beyond the machine itself (an attacker can probably read mail on a machine etc.) such as the DNS whois record -- changing it in some way. Other possible confirmations might involve control of a higher level domain if it's clear that's not all hosted on the same machine -- though this is still vulnerable to a full network takeover. f) On the other hand, for a freshly created domain, the creation of an irrevocable SK can be instant -- in fact it can be done as part of the domain registration process with a registrar that supports this. g) A protocol might be arranged so that another machine which is holding an escrowed copy of your private key can confirm that it is doing so. That way, when I create an SK, I can send it to the trusted escrower (or a collection who only hold a fragment each and are in different countries.) I can report who my escrow agents are and they can be queried to prove I really did escrow the key. Or I can check a box to say, "I am a fool, and am handling my own offsite backup of my key." From pde at eff.org Sun Dec 18 16:10:48 2011 From: pde at eff.org (Peter Eckersley) Date: Sun, 18 Dec 2011 16:10:48 -0800 Subject: [Sovereign Keys] Evidence for claim - CA-signed certificate In-Reply-To: <4EEE7604.3060101@nic.cz> References: <4EEE7604.3060101@nic.cz> Message-ID: <20111219001048.GA10973@xylophonic> On Mon, Dec 19, 2011 at 12:23:48AM +0100, Ondrej Mikle wrote: > Hi, > > I'm a bit puzzled by the option of using CA-signed certificate to claim > control of DNS name. Despite having re-read the text couple of times, I > think I'm not understading it correctly. > > According to my interpretation, owner of domain example.com can create > additional RSA/ECC sovereign key and obtain a CA-signed certificate that has > the key in SubjectPublicKeyInfo and domain's FQDN in CN/SAN. > > Though this would create a loophole: if an attacker gains control of any CA > (or uses other tricks), he can issue himself a CA-certificate with key of > his choosing and use that certificate for claim of domain's ownership. What > am I missing? If there is already a Sovereign Key for this domain, this attack is useless because there is already an entry for this domain in the timeline. But what if there is no Sovereign Key for the domain yet? Protecting against a compromised CA creating a SK could be achieved using methods like repeatedly asking https://domain.com over Tor if it really wants to make an SK (you could use a header or a magic URL for this question). But there is a worse version of the attack, where the attacker does not compromise a CA but instead compromises the HTTPS webserver itself, and then tries to make a Sovereign Key. That attack, and proposed protections, are discussed in this file: https://git.eff.org/?p=sovereign-keys.git;a=blob;f=issues/transitional-considerations.txt;h=fa3b1591820baf1f2f62740f1f0e8b7998c29174;hb=HEAD But as Brad points out, there may be other precautions and procedures that should be added to that file. > > Ondrej -- Peter Eckersley pde at eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 From 4brad at templetons.com Sun Dec 18 18:28:37 2011 From: 4brad at templetons.com (Brad Templeton) Date: Sun, 18 Dec 2011 18:28:37 -0800 Subject: [Sovereign Keys] Evidence for claim - CA-signed certificate In-Reply-To: <20111219001048.GA10973@xylophonic> References: <4EEE7604.3060101@nic.cz> <20111219001048.GA10973@xylophonic> Message-ID: <4EEEA155.2050000@templetons.com> > That attack, and proposed protections, are discussed in this file: > > https://git.eff.org/?p=sovereign-keys.git;a=blob;f=issues/transitional-considerations.txt;h=fa3b1591820baf1f2f62740f1f0e8b7998c29174;hb=HEAD > > But as Brad points out, there may be other precautions and procedures that > should be added to that file. >> More to the point, I think it's vital the key for any established web site be verified through some sort of out of band channel, one that is not readily available to somebody who has pwned the server. I see two such channels. a) The whois record or other records at the domain registrar. To compromise this you would tend to need to have done things like intercept or keylog a login session there -- not impossible, but harder. A magic string could be inserted in the whois, even temporarily. For example changing an admin contact to somelongalias at yourdomain.com where the alias also is a hash of the key. This is not trivial to automate, of course. b) DNS records for the domain, if and only if we can verify that the DNS server is on an independent machine. This is non-trivial, but if we can, a new DNS record for the domain can be added verifying the key. c) A phone call to the number in a whois record. Alas, email and anything that is verified with email are not out of band. A scripted attack would possibly get them all. It's a valuable attack. Find a valuable site with no SK. Create an SK for it. Contact the owner and say, "Pay us $$$$ and we'll give you the private key, otherwise your domain is toast." Well worth scripting and doing again and again. From octagram at bluebottle.com Wed Dec 28 18:03:28 2011 From: octagram at bluebottle.com (=?KOI8-R?B?7MXXwdvF1yDp18HO?=) Date: Thu, 29 Dec 2011 09:03:28 +0700 Subject: [Sovereign Keys] NameCoin Message-ID: <60399307-F7C1-4FDF-BBE7-BAF08550CABC@bluebottle.com> Hello! There is a project having something in common with Sovereign Keys. NameCoin is a distributed DNS or, more generally it's a cryptocurrency with a built-in JSON storage. For instance, it can be used to store GPG keys as well. It took me 3 month to mine 1 NMC on CPU, and I can buy ~5 entries now. Pretty affordable, I think. Of course, NMC can be bought, the price is low. Entries expire but renewal is free. All the history of operations is available on every node. However, merkle trees make it possible to omit detailed information in a particular NameCoin implementation. NameCoin has a built-in SSL verification method: issue self-signed certificate and store hash in the NameCoin blockchain. However, browsers and other software are not modified to operate this way. I think NameCoin might be useful for Sovereign Keys as well. NameCoin is also an append-only database and there are lots of nodes around already. Timeline servers are still needed to ensure evidence of control in the DNS. If there will ever be a browser supporting this feature, I'd like it to support .bit native SSL verification method as well. .bit domain owners are going to have first-class service. Conventional TLD owners ought to rely on trusted 3rd party servers to verify evidence of control. P. S. Please mirror this mailing list in GMANE. It is inconvenient to read from mail or web. NNTP is better. Even with regards to web, GMANE interface is superior. -- If you want to get to the top, you have to start at the bottom