Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)
On 11 September 2011 16:55, Bjørn Mork <bjorn@mork.no> wrote:
You can rewrite that: Trust is the CA business. Trust has a price. If the CA is not trusted, the price increases.
Yes, they may end up out of business because of that price jump, but you should not neglect the fact that trust is for sale here.
The CA model is fundamentally flawed in the fact that you have CAs whose sole "trustworthiness" is the fact that they paid for an audit (for Microsoft, lower requirements for others), they then issue intermediate certificates to other companies (many web hosts and other minor companies have them) whose sole "trustworthiness" is the fact that they paid for an intermediate certificate, all of those companies/organisations/people are then considered trustworthy enough to confirm the identity of my web server despite the fact that none of them have any connection at all to me or my website. There is already a chain of trust down the DNS tree, if that is compromised then my SSL is already compromised (if they control my domain, they can "verify" they are me and get a certificate), what happened to RFC4398 and other such proposals? EV certificates have a different status and probably still need the CA model, however with "standard" SSL certificates the only validation done these days is checking someone has control over the domain. DNSSEC deployment is advanced enough now to do that automatically at the client. We just need browsers to start checking for certificates in DNS when making a HTTPS connection (and if one is found do client side DNSSEC validation - I don't trust my ISPs DNS servers to validate something like that, considering they are the ones likely to be intercepting my connections in the first place!). It will take a while to get updated browsers rolled out to enough users for it do be practical to start using DNS based self-signed certificated instead of CA-Signed certificates, so why don't any browsers have support yet? are any of them working on it? - Mike
There's an app^W^Wa Working Group for that. <http://tools.ietf.org/wg/dane/> On Sun, Sep 11, 2011 at 2:44 PM, Mike Jones <mike@mikejones.in> wrote:
On 11 September 2011 16:55, Bjørn Mork <bjorn@mork.no> wrote:
You can rewrite that: Trust is the CA business. Trust has a price. If the CA is not trusted, the price increases.
Yes, they may end up out of business because of that price jump, but you should not neglect the fact that trust is for sale here.
The CA model is fundamentally flawed in the fact that you have CAs whose sole "trustworthiness" is the fact that they paid for an audit (for Microsoft, lower requirements for others), they then issue intermediate certificates to other companies (many web hosts and other minor companies have them) whose sole "trustworthiness" is the fact that they paid for an intermediate certificate, all of those companies/organisations/people are then considered trustworthy enough to confirm the identity of my web server despite the fact that none of them have any connection at all to me or my website.
There is already a chain of trust down the DNS tree, if that is compromised then my SSL is already compromised (if they control my domain, they can "verify" they are me and get a certificate), what happened to RFC4398 and other such proposals? EV certificates have a different status and probably still need the CA model, however with "standard" SSL certificates the only validation done these days is checking someone has control over the domain. DNSSEC deployment is advanced enough now to do that automatically at the client. We just need browsers to start checking for certificates in DNS when making a HTTPS connection (and if one is found do client side DNSSEC validation - I don't trust my ISPs DNS servers to validate something like that, considering they are the ones likely to be intercepting my connections in the first place!).
It will take a while to get updated browsers rolled out to enough users for it do be practical to start using DNS based self-signed certificated instead of CA-Signed certificates, so why don't any browsers have support yet? are any of them working on it?
- Mike
I'm pretty fond of the idea proposed by gpgAuth.One key to rule them all (and one password) combined with the client verifying the server.It's still in its infancy, but it works. -A (Full disclosure: I work with the creator of gpgAuth in our day jobs) On Sun, Sep 11, 2011 at 11:47, Richard Barnes <richard.barnes@gmail.com> wrote:
There's an app^W^Wa Working Group for that. <http://tools.ietf.org/wg/dane/>
On Sun, Sep 11, 2011 at 2:44 PM, Mike Jones <mike@mikejones.in> wrote:
On 11 September 2011 16:55, Bjørn Mork <bjorn@mork.no> wrote:
You can rewrite that: Trust is the CA business. Trust has a price. If the CA is not trusted, the price increases.
Yes, they may end up out of business because of that price jump, but you should not neglect the fact that trust is for sale here.
The CA model is fundamentally flawed in the fact that you have CAs whose sole "trustworthiness" is the fact that they paid for an audit (for Microsoft, lower requirements for others), they then issue intermediate certificates to other companies (many web hosts and other minor companies have them) whose sole "trustworthiness" is the fact that they paid for an intermediate certificate, all of those companies/organisations/people are then considered trustworthy enough to confirm the identity of my web server despite the fact that none of them have any connection at all to me or my website.
There is already a chain of trust down the DNS tree, if that is compromised then my SSL is already compromised (if they control my domain, they can "verify" they are me and get a certificate), what happened to RFC4398 and other such proposals? EV certificates have a different status and probably still need the CA model, however with "standard" SSL certificates the only validation done these days is checking someone has control over the domain. DNSSEC deployment is advanced enough now to do that automatically at the client. We just need browsers to start checking for certificates in DNS when making a HTTPS connection (and if one is found do client side DNSSEC validation - I don't trust my ISPs DNS servers to validate something like that, considering they are the ones likely to be intercepting my connections in the first place!).
It will take a while to get updated browsers rolled out to enough users for it do be practical to start using DNS based self-signed certificated instead of CA-Signed certificates, so why don't any browsers have support yet? are any of them working on it?
- Mike
https://bugzilla.mozilla.org/show_bug.cgi?id=647959 --- SNIP --- This is a request to add the CA root certificate for Honest Achmed's Used Cars and Certificates. The requested information as per the CA information checklist is as follows: 1. Name Honest Achmed's Used Cars and Certificates 2. Website URL www.honestachmed.dyndns.org 3. Organizational type Individual (Achmed, and possibly his cousin Mustafa, who knows a bit about computers). 4. Primary market / customer base Absolutely anyone who'll give us money. 5. Impact to Mozilla Users Achmed's business plan is to sell a sufficiently large number of certificates as quickly as possible in order to become too big to fail (see "regulatory capture"), at which point most of the rest of this application will become irrelevant. --- SNIP --- On Sun, Sep 11, 2011 at 5:20 PM, Aaron C. de Bruyn <aaron@heyaaron.com> wrote:
I'm pretty fond of the idea proposed by gpgAuth.One key to rule them all (and one password) combined with the client verifying the server.It's still in its infancy, but it works. -A (Full disclosure: I work with the creator of gpgAuth in our day jobs) On Sun, Sep 11, 2011 at 11:47, Richard Barnes <richard.barnes@gmail.com> wrote:
There's an app^W^Wa Working Group for that. <http://tools.ietf.org/wg/dane/>
On Sun, Sep 11, 2011 at 2:44 PM, Mike Jones <mike@mikejones.in> wrote:
On 11 September 2011 16:55, Bjørn Mork <bjorn@mork.no> wrote:
You can rewrite that: Trust is the CA business. Trust has a price. If the CA is not trusted, the price increases.
Yes, they may end up out of business because of that price jump, but you should not neglect the fact that trust is for sale here.
The CA model is fundamentally flawed in the fact that you have CAs whose sole "trustworthiness" is the fact that they paid for an audit (for Microsoft, lower requirements for others), they then issue intermediate certificates to other companies (many web hosts and other minor companies have them) whose sole "trustworthiness" is the fact that they paid for an intermediate certificate, all of those companies/organisations/people are then considered trustworthy enough to confirm the identity of my web server despite the fact that none of them have any connection at all to me or my website.
There is already a chain of trust down the DNS tree, if that is compromised then my SSL is already compromised (if they control my domain, they can "verify" they are me and get a certificate), what happened to RFC4398 and other such proposals? EV certificates have a different status and probably still need the CA model, however with "standard" SSL certificates the only validation done these days is checking someone has control over the domain. DNSSEC deployment is advanced enough now to do that automatically at the client. We just need browsers to start checking for certificates in DNS when making a HTTPS connection (and if one is found do client side DNSSEC validation - I don't trust my ISPs DNS servers to validate something like that, considering they are the ones likely to be intercepting my connections in the first place!).
It will take a while to get updated browsers rolled out to enough users for it do be practical to start using DNS based self-signed certificated instead of CA-Signed certificates, so why don't any browsers have support yet? are any of them working on it?
- Mike
-- ^[:wq^M
On Sun, 11 Sep 2011 15:20:51 PDT, "Aaron C. de Bruyn" said:
I'm pretty fond of the idea proposed by gpgAuth.One key to rule them all (and one password) combined with the client verifying the server.It's still in its infancy, but it works.
Yes, but it needs to be something that either (a) Joe Sixpack never sees, or (b) Joe Sixpack actually understands. Are either of those true?
Neither at the moment--but it's close. -A On Sun, Sep 11, 2011 at 15:52, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 11 Sep 2011 15:20:51 PDT, "Aaron C. de Bruyn" said:
I'm pretty fond of the idea proposed by gpgAuth.One key to rule them all (and one password) combined with the client verifying the server.It's still in its infancy, but it works.
Yes, but it needs to be something that either (a) Joe Sixpack never sees, or (b) Joe Sixpack actually understands. Are either of those true?
On Sun, Sep 11, 2011 at 2:44 PM, Mike Jones <mike@mikejones.in> wrote:
EV certificates have a different status and probably still need the CA model
what's the real benefit of an EV cert? (to the service owner, not the CA, the CA benefit is pretty clearly $$) -chris (I've never seen the value in EV or even DV certs really... so I'm actually curious what the value other see in them is)
On Sun, Sep 11, 2011 at 9:08 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
what's the real benefit of an EV cert? (to the service owner, not the CA, the CA benefit is pretty clearly $$)
The benefit is to the end user. They see a green address bar with the company's name displayed. Yeah, company's name displayed -- individuals cannot apply for EVSSL certs. With normal certs, the end user doesn't see a green address bar, and instead of the company's name displayed "(unknown)" is displayed and "This web site does not supply ownership information." is displayed. If you ask me, hiding the company's name even when present on a non-EVSSL cert is tantamount to saying "Only EV-SSL certs are really trusted anyways". So maybe instead of these shenanigans browser makers should have just started displaying a "don't trust this site" warning for any non-EVSSL cert. -- -JH
On Sun, Sep 11, 2011 at 10:23 PM, Jimmy Hess <mysidia@gmail.com> wrote:
On Sun, Sep 11, 2011 at 9:08 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
what's the real benefit of an EV cert? (to the service owner, not the CA, the CA benefit is pretty clearly $$)
The benefit is to the end user. They see a green address bar with the company's name displayed.
Yeah, company's name displayed -- individuals cannot apply for EVSSL certs.
this isn't really a benefit though, is it? isn't the domain-name in the location bar doing the same thing?
On Sep 11, 2011, at 9:44 PM, "Christopher Morrow" <morrowc.lists@gmail.com> wrote:
On Sun, Sep 11, 2011 at 10:23 PM, Jimmy Hess <mysidia@gmail.com> wrote:
On Sun, Sep 11, 2011 at 9:08 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
what's the real benefit of an EV cert? (to the service owner, not the CA, the CA benefit is pretty clearly $$)
The benefit is to the end user. They see a green address bar with the company's name displayed.
Yeah, company's name displayed -- individuals cannot apply for EVSSL certs.
this isn't really a benefit though, is it? isn't the domain-name in the location bar doing the same thing?
No. As a counter example... How may domain names do Wells Fargo and Citibank (Citi Corp? Citi Group?) operate respectively? I'm a customer, and I can't keep it straight. Companies that wrap their services with generic domain names (paymybills.com and the like) have no one to blame but themselves when they are targeted by scammers and phishing schemes. Even EV certificates don't help when consumers are blinded by subsidiary companies and sister companies daily (Motorola Mobility a.k.a. Google vs. Motorola Solutions.) NOTICE TO RECIPIENT: The information contained in this message from Great River Energy and any attachments are confidential and intended only for the named recipient(s). If you have received this message in error, you are prohibited from copying, distributing or using the information. Please contact the sender immediately by return email and delete the original message.
On Sun, Sep 11, 2011 at 11:06 PM, Hughes, Scott GRE-MG <SHughes@grenergy.com> wrote:
Companies that wrap their services with generic domain names (paymybills.com and the like) have no one to blame but themselves when they are targeted by scammers and phishing schemes. Even EV certificates don't help when consumers are blinded by subsidiary companies and sister companies daily (Motorola Mobility a.k.a. Google vs. Motorola Solutions.)
So, part of my point here about ev/dv/etc certs is that in almost all cases of consumer fraud and protection, HTTPS is never used. Hell, half the spams I get are http://IP_ADDRESS/somethign/something/something.php ... Falling back on the 'well ev certs are there to provide protection to the consumer' is just FUD (I think). again, not seeing a benefit here... -chris
On 9/11/11 11:28 PM, Christopher Morrow wrote:
On Sun, Sep 11, 2011 at 11:06 PM, Hughes, Scott GRE-MG <SHughes@grenergy.com> wrote:
Companies that wrap their services with generic domain names (paymybills.com and the like) have no one to blame but themselves when they are targeted by scammers and phishing schemes. Even EV certificates don't help when consumers are blinded by subsidiary companies and sister companies daily (Motorola Mobility a.k.a. Google vs. Motorola Solutions.)
So, part of my point here about ev/dv/etc certs is that in almost all cases of consumer fraud and protection, HTTPS is never used. Hell, half the spams I get are http://IP_ADDRESS/somethign/something/something.php ... Falling back on the 'well ev certs are there to provide protection to the consumer' is just FUD (I think).
again, not seeing a benefit here...
Normally, I heart my Mac. But Apple in its infinite wisdom decided that EV certificates are so much better, they refused to honor my edit of my own system keychain! So, negative benefit for the consumer.
On Sep 11, 2011, at 11:06 PM, Hughes, Scott GRE-MG wrote:
Companies that wrap their services with generic domain names (paymybills.com and the like) have no one to blame but themselves when they are targeted by scammers and phishing schemes. Even EV certificates don't help when consumers are blinded by subsidiary companies and sister companies daily (Motorola Mobility a.k.a. Google vs. Motorola Solutions.)
GE Money Bank is notorious for this… from a retail store's main page they redirect you to https://www3.onlinecreditcenter6.com. (No-EV certificate, either.) -cjp
Mike, On Sun, Sep 11, 2011 at 8:44 PM, Mike Jones <mike@mikejones.in> wrote:
It will take a while to get updated browsers rolled out to enough users for it do be practical to start using DNS based self-signed certificated instead of CA-Signed certificates, so why don't any browsers have support yet? are any of them working on it?
Chrome v 14 works with DNS stapled certificates, sort of a hack. ( http://www.imperialviolet.org/2011/06/16/dnssecchrome.html ) There are other proposals/ideas out there, completely different to DANE / DNSSEC, like http://perspectives-project.org/ / http://convergence.io/ . Regard, Martin
On Mon, 12 Sep 2011 12:12:08 +0200 Martin Millnert <millnert@gmail.com> wrote:
Mike,
On Sun, Sep 11, 2011 at 8:44 PM, Mike Jones <mike@mikejones.in> wrote:
It will take a while to get updated browsers rolled out to enough users for it do be practical to start using DNS based self-signed certificated instead of CA-Signed certificates, so why don't any browsers have support yet? are any of them working on it?
Chrome v 14 works with DNS stapled certificates, sort of a hack. ( http://www.imperialviolet.org/2011/06/16/dnssecchrome.html )
There are other proposals/ideas out there, completely different to DANE / DNSSEC, like http://perspectives-project.org/ / http://convergence.io/ .
I.e. instead of a set of trusted CAs there will be one distributed net of servers, that act as a cert storage? I do not see how that could help... Well, I do not even see how can one trust any certificate that is issued by commercial organization. -- With best regards, Gregory Edigarov
Gregory, On Mon, Sep 12, 2011 at 1:23 PM, Gregory Edigarov <greg@bestnet.kharkov.ua> wrote:
On Mon, 12 Sep 2011 12:12:08 +0200 Martin Millnert <millnert@gmail.com> wrote:
Mike,
On Sun, Sep 11, 2011 at 8:44 PM, Mike Jones <mike@mikejones.in> wrote:
It will take a while to get updated browsers rolled out to enough users for it do be practical to start using DNS based self-signed certificated instead of CA-Signed certificates, so why don't any browsers have support yet? are any of them working on it?
Chrome v 14 works with DNS stapled certificates, sort of a hack. ( http://www.imperialviolet.org/2011/06/16/dnssecchrome.html )
There are other proposals/ideas out there, completely different to DANE / DNSSEC, like http://perspectives-project.org/ / http://convergence.io/ .
I.e. instead of a set of trusted CAs there will be one distributed net of servers, that act as a cert storage? I do not see how that could help... Well, I do not even see how can one trust any certificate that is issued by commercial organization.
As I understand it the idea is that you would have the power/capability to assign trust yourself to friends, CAs and your cat. This then forms some form of (washed out word-warning) web of trust, when you connect up with others and get their one-step-away-trust imported. Outsourcing trust is a pretty hard problem... there's no way to get around it, really, so this approach (as per my limited research) at least gives you some power to control it. Regards, Martin
-----Original Message----- From: Gregory Edigarov [mailto:greg@bestnet.kharkov.ua] I.e. instead of a set of trusted CAs there will be one distributed net of servers, that act as a cert storage? I do not see how that could help... Well, I do not even see how can one trust any certificate that is issued by commercial organization.
There should be a government body to issue certificates then ;-) But Gregory is right, you cannot really trust anybody completely. Even the larger and more respectable commercial organisations will be unable to resist <insert intel organisation here> when they ask for dodgy certs so they can intercept something.. No, as soon as you have somebody who is not yourself in control without any third party verifiably independent oversight then you have to carefully define what you mean by trust. -- Leigh Porter ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
But Gregory is right, you cannot really trust anybody completely. Even the larger and more respectable commercial organisations will be unable to resist <insert intel organisation here> when they ask for dodgy certs so they can intercept something..
No, as soon as you have somebody who is not yourself in control without any third party verifiably independent oversight then you have to carefully define what you mean by trust.
i am having trouble with all this. i am supposed to only trust myself to identify citibank's web site? and what to i smoke to get that knowledge? let's get real here. with dane, i trust whoever runs dns for citibank to identify the cert for citibank. this seems much more reasonable than other approaches, though i admit to not having dived deeply into them all. randy
Randy Bush wrote:
But Gregory is right, you cannot really trust anybody completely. Even the larger and more respectable commercial organisations will be unable to resist <insert intel organisation here> when they ask for dodgy certs so they can intercept something..
No, as soon as you have somebody who is not yourself in control without any third party verifiably independent oversight then you have to carefully define what you mean by trust.
i am having trouble with all this. i am supposed to only trust myself to identify citibank's web site? and what to i smoke to get that knowledge? let's get real here.
with dane, i trust whoever runs dns for citibank to identify the cert for citibank. this seems much more reasonable than other approaches, though i admit to not having dived deeply into them all.
It seems to me that this depends a lot on how much you can tolerate single points of failure. The current de-trusting is certainly going to cause trouble for whoever used that CA, but the internet didn't roll over and die either. If the root DNS keys were compromised in an all DNS rooted world... unhappiness would ensue in great volume. Mike, poison and choices...
with dane, i trust whoever runs dns for citibank to identify the cert for citibank. this seems much more reasonable than other approaches, though i admit to not having dived deeply into them all. If the root DNS keys were compromised in an all DNS rooted world... unhappiness would ensue in great volume.
as eliot pointed out, to defeat dane as currently written, you would have to compromise dnssec at the same time as you compromised the CA at the same time as you ran the mitm. i.e. it _adds_ dnssec assurance to CA trust. randy
Randy Bush wrote:
with dane, i trust whoever runs dns for citibank to identify the cert for citibank. this seems much more reasonable than other approaches, though i admit to not having dived deeply into them all. If the root DNS keys were compromised in an all DNS rooted world... unhappiness would ensue in great volume.
as eliot pointed out, to defeat dane as currently written, you would have to compromise dnssec at the same time as you compromised the CA at the same time as you ran the mitm. i.e. it _adds_ dnssec assurance to CA trust.
Yes, I saw that. It also drives up complexity too and makes you wonder what the added value of those cert vendors is for the money you're forking over. Especially when you consider the criticality of dns naming for everything except web site host names using tls. And how long would it be before browsers allowed self-signed-but-ok'ed-using-dnssec-protected-cert-hashes? Mike
as eliot pointed out, to defeat dane as currently written, you would have to compromise dnssec at the same time as you compromised the CA at the same time as you ran the mitm. i.e. it _adds_ dnssec assurance to CA trust. Yes, I saw that. It also drives up complexity too and makes you wonder what the added value of those cert vendors is for the money you're forking over. Especially when you consider the criticality of dns naming for everything except web site host names using tls. And how long would it be before browsers allowed self-signed-but-ok'ed-using-dnssec-protected-cert-hashes?
agree
On 13/09/11 01:12, Randy Bush wrote:
as eliot pointed out, to defeat dane as currently written, you would have to compromise dnssec at the same time as you compromised the CA at the same time as you ran the mitm. i.e. it _adds_ dnssec assurance to CA trust. Yes, I saw that. It also drives up complexity too and makes you wonder what the added value of those cert vendors is for the money you're forking over. Especially when you consider the criticality of dns naming for everything except web site host names using tls. And how long would it be before browsers allowed self-signed-but-ok'ed-using-dnssec-protected-cert-hashes?
agree
I would have thought that was a perfectly acceptable end point. The multiple CA's go away (oops), replaced with everyone being able to publish and authenticate their own certificates. The DNS has to be compromised to publish certificates, but if they've managed to do that, it doesn't matter what certificate you had in the first place. There are already public keys in the DNS for DKIM which work quite well. It lowers the cost for getting an SSL cert for your domain, but certainly not the security. Getting a cert for a domain is laughable these days. It's either too easy, or stupendously hard and ridiculous. EV certs are a joke as demonstrated by the thousands of people still getting phished since end users don't look at the address bar anyway. So long as it's encrypted and in some way secured against the domain, it's good enough isn't it?
Martin Millnert wrote:
On Mon, Sep 12, 2011 at 5:09 PM, Michael Thomas <mike@mtcc.com> wrote:
And how long would it be before browsers allowed self-signed-but-ok'ed-using-dnssec-protected-cert-hashes?
As previously mentioned, Chrome >= v14 already does.
The perils of coming in late in a thread :) Mike
with dane, i trust whoever runs dns for citibank to identify the cert for citibank. this seems much more reasonable than other approaches, though i admit to not having dived deeply into them all. If the root DNS keys were compromised in an all DNS rooted world... unhappiness would ensue in great volume.
Compromise of DNSSEC == compromise of one or more DNS registries. This is a fate sharing situation. A few single points of failure rather than hundreds. Note that a big weak point in the DNS is the interface between the registrars and the registry. If you have a domain you have to trust the registry to impose suitable restrictions on its registrars to prevent a dodgy registrar from stealing your domain. Another, of course, is the interface between a registrar and its customers.
It also drives up complexity too and makes you wonder what the added value of those cert vendors is for the money you're forking over.
During rollout the cert vendors will be providing backwards compatibility.
Especially when you consider the criticality of dns naming for everything except web site host names using tls.
If a website using TLS loses its DNS then (a) you can't reach it, and (b) the attacker can trivially obtain a new domain validated certificate. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Fisher, German Bight, Humber, Thames, Dover: Southwest 7 to severe gale 9. Rough or very rough, becoming high in Fisher. Showers. Moderate or good.
On Mon, Sep 12, 2011 at 11:00:47PM +0100, Tony Finch wrote:
Note that a big weak point in the DNS is the interface between the registrars and the registry. If you have a domain you have to trust the registry to impose suitable restrictions on its registrars to prevent a dodgy registrar from stealing your domain. Another, of course, is the interface between a registrar and its customers.
Just in case anybody missed it, ups.com, theregister.co.uk, and others were hijacked in this way last week. http://www.theregister.co.uk/2011/09/05/dns_hijack_service_updated/ Marcus
On Mon, 12 Sep 2011 07:53:57 -0700 Michael Thomas <mike@mtcc.com> wrote:
Randy Bush wrote:
But Gregory is right, you cannot really trust anybody completely. Even the larger and more respectable commercial organisations will be unable to resist <insert intel organisation here> when they ask for dodgy certs so they can intercept something..
No, as soon as you have somebody who is not yourself in control without any third party verifiably independent oversight then you have to carefully define what you mean by trust.
i am having trouble with all this. i am supposed to only trust myself to identify citibank's web site? and what to i smoke to get that knowledge? let's get real here.
with dane, i trust whoever runs dns for citibank to identify the cert for citibank. this seems much more reasonable than other approaches, though i admit to not having dived deeply into them all.
It seems to me that this depends a lot on how much you can tolerate single points of failure. The current de-trusting is certainly going to cause trouble for whoever used that CA, but the internet didn't roll over and die either. If the root DNS keys were compromised in an all DNS rooted world... unhappiness would ensue in great volume.
Mike, poison and choices...
let me state clearly what am I writing about: ok, suppose, there is a site on the internet, that has a certificate issued by one of the major CAs. how could one know, that certificate wasn't issued to forged identity?
On Mon, 12 Sep 2011, Gregory Edigarov wrote:
On Mon, 12 Sep 2011 12:12:08 +0200 Martin Millnert <millnert@gmail.com> wrote:
Mike,
On Sun, Sep 11, 2011 at 8:44 PM, Mike Jones <mike@mikejones.in> wrote:
It will take a while to get updated browsers rolled out to enough users for it do be practical to start using DNS based self-signed certificated instead of CA-Signed certificates, so why don't any browsers have support yet? are any of them working on it?
Chrome v 14 works with DNS stapled certificates, sort of a hack. ( http://www.imperialviolet.org/2011/06/16/dnssecchrome.html )
There are other proposals/ideas out there, completely different to DANE / DNSSEC, like http://perspectives-project.org/ / http://convergence.io/ .
I.e. instead of a set of trusted CAs there will be one distributed net of servers, that act as a cert storage? I do not see how that could help...
The point of perspectives and convergence is this. The browser says:
From my point of view site X has a certificate with fingerprint Y, what do you guys all see from your points of view?
If the perspectives/convergence servers see a different certificate then you know that you are the victim of a mitm attack.. I.E. the perspectives and convergence system does not attempt to assert anything about a sites identity, just that everyone sees the same cert for a site. (of course if the mitm is happening close enough to the site networktopologicly speaking than all the perspectives/convergence servers will see the same, fake, cert and your out of luck).
Well, I do not even see how can one trust any certificate that is issued by commercial organization.
perspectives and convergence don't issue certs. -- [http://pointless.net/] [0x2ECA0975]
I.e. instead of a set of trusted CAs there will be one distributed net of servers, that act as a cert storage? I do not see how that could help... More lines of defense on top of the CA model. Consider instead of abandoning the CA model altogether, you utilize DNSSEC binding of the certificate
On Mon, Sep 12, 2011 at 6:23 AM, Gregory Edigarov <greg@bestnet.kharkov.ua> wrote: that must also be signed by a CA. If _either_ the DNSSEC record isn't present, doesn't validate, OR the certificate is not properly signed by a CA, then the certificate is considered invalid. In this manner, DNSSEC protects you against interception by a rogue CA -- chances are the rogue CA has not also discovered your DNSSEC secret keys, and the CA signature protects you against a compromise of the DNS, or an attack by your domain registrar -- your domain registrar is probably not a CA and doesn't have the right paperwork, therefore can't get a CA signed certificate with your company's name. The browsers then just need to revise their trust model to require no CA be affiliated with or owned by any organization affiliated with a provider of domain registration or DNS hosting services, to ensure there's no domain registrar entrusted to sign certs, and no CA entrusted to maintain DNSSEC data. -- -JH
Mike Jones <mike@mikejones.in> wrote:
DNSSEC deployment is advanced enough now to do that automatically at the client.
Sadly not quite. DNSSEC does have the potential to provide an alternative public key infrastructure, and I'm keen to see that happen. But although it works well between authoritative servers and recursive resolvers, there are a lot of shitty DNS forwardersin CPE and captive portals and so on which do not understand DNSSEC. And DNSSEC does not work unless all the forwarders and recursors that you are using support it. So DNSSEC on the client has a long way to go. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Hebrides, Southeast Bailey: Westerly 5 to 7 until later in south Hebrides, otherwise northwesterly 3 or 4, increasing 5 to 7. Rough or very rough, occasionally high in south Hebrides. Rain or showers. Good, occasionally poor.
participants (19)
-
Aaron C. de Bruyn -
Christopher J. Pilkington -
Christopher Morrow -
Gregory Edigarov -
Hughes, Scott GRE-MG -
James Harr -
Jasper Wallace -
Jimmy Hess -
Leigh Porter -
Marcus Reid -
Martin Millnert -
Michael Thomas -
Mike Jones -
Randy Bush -
Richard Barnes -
Ted Cooper -
Tony Finch -
Valdis.Kletnieks＠vt.edu -
William Allen Simpson