Sorry, I got Peter and Moxie mixed up there, Jet lag. Sovereign keys and Convergence both suffered from the assumption that you can change the internet by just throwing a project over the wall and waiting for people to implement. The details are slightly different though.
On Tue, Apr 15, 2014 at 8:23 PM, Phillip Hallam-Baker <hal...@gmail.com> wrote: > On Tue, Apr 15, 2014 at 7:08 PM, Daniel Veditz <dved...@mozilla.com> wrote: >> On 4/15/2014 7:43 AM, nobody wrote: >>> >>> I just wondered... what is the pull back regarding Convergence to put it >>> in >>> the webbrowsers by default? > > Well one very big problem was that Peter was not prepared to do the > work of engaging in the standards area himself. Which is an almost > certain way to ensure that a proposal isn't going to thrive. > > Another problem that most PKI alternatives suffer from is the > 'hydrogen car' mentality. According to a popular Internet meme the > reason that we aren't driving hydrogen cars RIGHT NOW is that the evil > Detroit car companies are desperate to kill it at any cost. Now > imagine that you are a startup trying to build a hydrogen car, would > that be a productive mindset to base business assumptions on? I think > it is pretty clear that approaching the problem of building a hydrogen > car from the point of view that all advice from GM and Ford was > ill-intentioned attempts at sabotage would cut the startup off from > essential knowledge. > > So Peter's approach of beginning his proposal with a canard against > existing CAs and refusing to correct the public impression he gave was > not a good start. > > The DNSSEC crowd suffer from this as well. I keep telling them that > until they start signing the root with something more secure than > RSA1024 then all they are doing is an extended science project. > Unfortunately the only way I can get them to change is to raise this > issue at senior US policy levels which has the unfortunate side effect > of reinforcing the (entirely justified) belief that ICANN is just a US > govt. proxy. > > >> The main issue is who are the notaries? If they're simply reflecting back >> "Yup, I see this valid CA cert" then they aren't adding a whole lot of value >> for the amount of risk they introduce, and if they're making their own >> judgement about the validity of the certificates on some other ground they >> just become a type of Certificate Authority themselves. Who pays for that >> infrastructure, and what is their motive? > > And that leads to the second problem of how reliable is that notary > infrastructure going to be. > > >> Firefox and Chrome are both working on implementing "key pinning" (and >> participating in the standardization process for it) which won't "free us >> from the CA system" but will at least ameliorate one of the worst aspects >> which is that any two-bit CA anywhere in the world can issue a certificate >> for any site, anywhere. > > And don't forget that we should deploy CAA as part of that solution. > > I am also working on ways of bringing the key pinning information into > the DNS space so that we can get a 'secure on first use'. That is the > reason I am interested in DNS Encryption. It is a change to the DNS > ecosystem which will break the ludicrous practice of taking DNS > service from the resolver advertised in DHCP. Which opens up the > opportunity for ditching a bunch of legacy DNS stupid (500 byte > message limit for instance). > > >> The IETF is working on standardizing "Certificate Transparency", Chrome is >> implementing it, and at least one CA is participating. This again doesn't >> free us from the CA system, but it does make the public certificates >> auditable so that mis-issuance could theoretically be detected. > > There is certainly a lot of functional overlap. I think that CT has > pretty much addressed the major use case used to justify Convergence. > But it does not meet the real goal of Convergence > > > > > > -- > Website: http://hallambaker.com/ -- Website: http://hallambaker.com/ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
