Re: CABForum place in the world
Jean-Marc Desperrier wrote: > Michael Ströder a écrit : >> I think that the attitude of not bothering >> the end user with technical details is the wrong direction because >> people with technical knowledge need the details to help the end user. >> Especially since there's not always face-to-face support. > > IMO there's almost always a solution to change the technical details > into something the user can understand. > > Maybe just talking with peoples who don't have a technical background, > testing various pages, to find out what kind of language is confusing > and which one is useful would help. But if the user writes the ticket to the helpdesk the problem already happened. It is annoying for the user that the helpdesk staff has to ask back later for more technical details and it wastes more helpdesk time (additional turn-around). Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Michael Ströder a écrit : I think that the attitude of not bothering the end user with technical details is the wrong direction because people with technical knowledge need the details to help the end user. Especially since there's not always face-to-face support. IMO there's almost always a solution to change the technical details into something the user can understand. Maybe just talking with peoples who don't have a technical background, testing various pages, to find out what kind of language is confusing and which one is useful would help. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Johnathan Nightingale wrote: > So, I will make the assertion that at least 80% of our users are not > going to benefit from the technical details we include in that error > message, and that while we could do another round of wording > improvements to try to finesse that, the issue goes deeper. 80% of > users don't want to know what a certificate is, or how it is used to > secure a TLS channel, and the wording in the rest of that error page is > already an attempt to make the issue more concrete, without delving into > the specifics. > > There were calls in fact, in 3.0 and 3.1, to just remove the technical > details altogether, but people like Nelson persuaded me that this was an > essential debugging tool for support, even if end users couldn't make > heads or tails of it. And Nelson is right on that! I think that the attitude of not bothering the end user with technical details is the wrong direction because people with technical knowledge need the details to help the end user. Especially since there's not always face-to-face support. > In that vein, the 3.1 error pages have a happy > quirk where, even when the technical details are collapsed, selecting > the error page text and copying will include them, suitable for pasting > into tech support emails. I'd really prefer if the user would not have to click on yet another button/link or whatever to obtain the technical details of an error. End users tend to send screenshot of the first error message to the helpdesk. > I know you likely already know this, but do keep in mind as well that if > you are someone who *does* understand this information, flipping the > browser.xul.error_pages.expert_bad_cert pref in about:config will show > the details sections by default. Sigh... Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Jean-Marc Desperrier wrote: > Michael Ströder a écrit : >> [...] >> A couple of days ago I've received a phishing spam e-mail with a >> detailed description "how to accept the new more secure EV cert" of a >> banking site. Obviously the goal was to trick the user to access a >> phishing site. I didn't examine it any further. > > Michael, if you received such an email, it sounds *very* interesting and > worthy of looking exactly what kind of attack it was. It seemed to be the usual click-here-and-enter-some-confidential-data attack. The migration to an EV cert was used as argument to convince the user to step into the trap. As said I did not examine it thoroughly. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Michael Ströder a écrit : [...] A couple of days ago I've received a phishing spam e-mail with a detailed description "how to accept the new more secure EV cert" of a banking site. Obviously the goal was to trick the user to access a phishing site. I didn't examine it any further. Michael, if you received such an email, it sounds *very* interesting and worthy of looking exactly what kind of attack it was. Up to now there has been almost no phishing attack using SSL, so if they start to do it, it's very interesting. This being said as I tried to explain once on Verisign's Tim Callan blogs, the trouble with EV is that if user trust it as much as he claims, it becomes a target of choice for attackers, one that they might end up using extraordinary means to attack, and I doubt they won't find some weak point in the armor. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Nelson B Bolyard wrote: > The problem is that ANYTHING that you can put into the content area can > also be put there as content. If you condition the user to accept large > but vanishing yellow letters saying "good connections", the content can > do that, too, and phishers will be quick to imitate it. A couple of days ago I've received a phishing spam e-mail with a detailed description "how to accept the new more secure EV cert" of a banking site. Obviously the goal was to trick the user to access a phishing site. I didn't examine it any further. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 13/1/09 00:02, Nelson B Bolyard wrote: In chronological order, Julien wrote: If you follow the KCM logic, you would have to give an application warning, which is completely unwarranted under current standards. Ian G replied: If the new cert is unauthentic, then it would cause some form of alert that would be entirely warranted. Currently, a false cert will slip through without any change. On 9/1/09 21:05, Julien R Pierre wrote: For what definition of false ? Ian G wrote, On 2009-01-10 10:14: Indeed a good question. Who do we ask? Ian, You chose the word "false" in your reply, quoted above. I believe Julien was asking YOU to clarify what YOU meant by that word. Ah. Well, in that context, "false" meant, anything that slipped through, so a circular definition. To be more linear: a CA-signed cert that should not have been issued a forged cert with an MD5 sig a cert for a root that shouldn't be in the root list a CA-signed cert issued to a real but bad company a stolen but unrevoked/unexpired cert could all be possible reasons. The reason KCM would be interesting here is that it could be set to warn when a cert for a different *CA* was seen. That would likely generate a warning for most of the above (and deal with the "server-farm" nightmare). The reason this works is because of lawsuits. If a VeryFine certificate ends up being "false" and used against a VeryFine customer, then the lawsuit is simple: all sue VeryFine. (Also, the control is much easier.) If on the other hand, a false KoFuddy cert is used against a ComfoPro customer, then who sues who? It is hard to sue KoFuddy, because there is no standing. ComfoPro did nothing wrong, so it is pointless to sue ComfoPro. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
In chronological order, Julien wrote: If you follow the KCM logic, you would have to give an application warning, which is completely unwarranted under current standards. >> Ian G replied: >>> If the new cert is unauthentic, then it would cause some form of alert >>> that would be entirely warranted. Currently, a false cert will slip >>> through without any change. > On 9/1/09 21:05, Julien R Pierre wrote: >> For what definition of false ? Ian G wrote, On 2009-01-10 10:14: > Indeed a good question. Who do we ask? Ian, You chose the word "false" in your reply, quoted above. I believe Julien was asking YOU to clarify what YOU meant by that word. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 01/10/2009 08:14 PM, Ian G: I have been reading most the december threads this week as I came back from vacation. Not every line, but most. And I have to agree that some CAs are broken. And in those cases, the solution may be to distrust as wel. It was a longgg... thread and came at the wrong time. Ahhh, that's a good one for a change. This reminds me incidentally about someone from the organization you are affiliated with...which went something like: "But what do you want? We are just a non-profit organization working for the good of others and I'm only a volunteer giving my free time. But I have only X hours I can spend on these activities because I have to clean my car, go shopping...etc. You should be grateful for what we do and not complain." There is always the right time! Mozilla (and CAs as well obviously) must be prepared always, all the time, anytime. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Hi Julien,
to address your very relevant points:
On 9/1/09 21:05, Julien R Pierre - Sun Microsystems wrote:
Ian,
Ian G wrote:
If you follow the KCM logic, you would have to give an application
warning, which is completely unwarranted under current standards.
If the new cert is unauthentic, then it would cause some form of alert
that would be entirely warranted. Currently, a false cert will slip
through without any change.
For what definition of false ?
Indeed a good question. Who do we ask? And if we get it wrong and do
not alert for a false cert, we have really caused a problem
Who takes responsibility for Mozilla getting it wrong?
This is why high security systems in active areas *always include the
end-user*. It's kind of a law of security, and it's one that "secure
browsing" breaks.
Right. But look at the end-user's question in another thread. It isn't
being answered. The issue here is that Firefox is acting like a
blackbox, and can't be seen inside. The equation is too complex.
Well, that black box is still open source and you can still tell what
it's doing if you care about every level of detail.
Open source is only open to developers; Which is convenient for
developer-led organisations like Mozilla, but pretty much closed to
anyone else.
Just like audit reports, really.
If the answer is, "use the source, luke" then this is the same as saying
"we don't talk to anyone but our fellow jedi."
(Not sure what happened after that in the movies, but it was pretty
exciting, and it took many new releases to sort out :)
Were you following the threads of December? Approximately three cases
of trickiness. I'm not saying that the PKI is about to meltdown, but
some of the flaws in the system that we've know for a long time became
apparent. And no solution in site, except more of the "trust me"
rhetoric.
I have been reading most the december threads this week as I came back
from vacation. Not every line, but most. And I have to agree that some
CAs are broken. And in those cases, the solution may be to distrust as wel.
It was a longgg... thread and came at the wrong time.
It is policy, more or less, that end-users don't get to trust a
particular CA. They only get to trust Firefox's black box magic, and
if they lose, they lose. Just how inspiring is that?
You have to come up with a default. Any default list of CA certs is
better than none.
That's fine. The question here is not about whether the default exists,
but whether there are options to change the default; and whether those
options are made deliberately hard ("because average users will screw
them up") or whether they are made easier and more effective ("average
users can be warned away, support people can start to train them").
Where do you expect the average user to obtain the
list of CA certs they want to trust externally ?
Same place they do in every standard place in life. Support people, the
market, opinion leaders, the brands, TV, chatrooms, newspapers, the
corner shop, society, gossip circles.
I know this is anathema to the core developers who believe that they can
do great stuff with open source; but unfortunately, only some things
can be done with code. Complex things require human interaction.
Security is complex by definition, because it includes an active
attacker. If you do not include the end-user, then the result is
brittle; it works for a while, then stops.
It is policy, more or less, that *any* CA's cert is good.
Not at all. That's why there is a Mozilla CA policy, and some CAs are
shut out. You need to have at least some audits. Not saying that those
are perfect - obviously they can miss things, but they are usually still
better than nothing.
Right, I meant, any CA in the root list.
This is why we also had a fierce debate about dropping a CA from the
root list. My simplistic claim: no CA can be dropped from the root list.
That's why we are having a fierce debate about how useful the audit is.
My simplistic claim: it depends!
What does that do to the model?
If the audits are worthless, then there is a
problem and better auditors need to be found ...
Broader defence of the humble auditor, in other post.
It is policy, more or less, that nobody accepts the responsibility for
this.
Do you believe in all that?
No, it shouldn't be. Certainly the CAs should accept some responsibility
for the certification services they offer and charge for.
This is why I say: the industry standard is to set liability to zero.
WebTrust agrees. Audit reports implicitly maybe confirm it for you.
RPAs are written in english, and at least one popular CA makes it very
exceedingly clear. It's the first loud paragraph.
(Things have changed a little under EV, but if possible, let's establish
the standard before we look at how EV changes things.)
I believe some
do contractually.
Please, let's see those contracts ?!
iang
Re: CABForum place in the world
On 9/1/09 21:05, Julien R Pierre - Sun Microsystems wrote: Not at all. That's why there is a Mozilla CA policy, and some CAs are shut out. You need to have at least some audits. Not saying that those are perfect - obviously they can miss things, but they are usually still better than nothing. If the audits are worthless, then there is a problem and better auditors need to be found ... Possibly I am over reacting here, but your angst as directed at the auditors is I feel unfair. IMHO, and based on my experiences on both sides of this fence: Auditors do the job that you gave them to do. Actually, they do it fairly well, within the circumstances. If there is a problem, it is right here. You, the wider downstream part of pki, don't understand the process. More precisely, we ask the auditor to report, without understanding the language of the report and the nature of the process. So, when the auditor reports weaknesses (as seen recently), nobody notices. If every auditor reports weaknesses in every CA, is there any reason why anyone would notice? If an auditor were to report that the CA isn't any good for *your* reliance but ok for my reliance, you would not notice. Nor would I. The wider flaw is an assumption of perfection. It is a shared belief of the Pki industry that the audit report is some binary stamp or magic permit of goodness in the business of certificates, for all and sundry. It is not, not even close. It needs massive care and a fair swathe of experience to interpret. It takes years to understand how to cryptanalyse a crypto function or protocol; audits are no different. That's not to say that the audit is useless or does not have a benefit. They aren't useless, they have benefits, it is just that the downstream relying parties have no easy grip on what they might be. Caveat emptor. If you don't read and interpret the results then, to use the language of PKI, you have failed to carry out the steps of reliance, as documented in the auditor's "CPS". In general, I see no way that any auditor can be blamed for the failures in reliance. iang, currently auditor for CAcert. A very slow job! ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Ian, Ian G wrote: If you follow the KCM logic, you would have to give an application warning, which is completely unwarranted under current standards. If the new cert is unauthentic, then it would cause some form of alert that would be entirely warranted. Currently, a false cert will slip through without any change. For what definition of false ? Right. But look at the end-user's question in another thread. It isn't being answered. The issue here is that Firefox is acting like a blackbox, and can't be seen inside. The equation is too complex. Well, that black box is still open source and you can still tell what it's doing if you care about every level of detail. Were you following the threads of December? Approximately three cases of trickiness. I'm not saying that the PKI is about to meltdown, but some of the flaws in the system that we've know for a long time became apparent. And no solution in site, except more of the "trust me" rhetoric. I have been reading most the december threads this week as I came back from vacation. Not every line, but most. And I have to agree that some CAs are broken. And in those cases, the solution may be to distrust as wel. It is policy, more or less, that end-users don't get to trust a particular CA. They only get to trust Firefox's black box magic, and if they lose, they lose. Just how inspiring is that? You have to come up with a default. Any default list of CA certs is better than none. Where do you expect the average user to obtain the list of CA certs they want to trust externally ? It is policy, more or less, that *any* CA's cert is good. Not at all. That's why there is a Mozilla CA policy, and some CAs are shut out. You need to have at least some audits. Not saying that those are perfect - obviously they can miss things, but they are usually still better than nothing. If the audits are worthless, then there is a problem and better auditors need to be found ... It is policy, more or less, that nobody accepts the responsibility for this. Do you believe in all that? No, it shouldn't be. Certainly the CAs should accept some responsibility for the certification services they offer and charge for. I believe some do contractually. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Johnathan Nightingale wrote: [...] - By making the default exception permanent instead of temporary (and bound to the host, port, cert tuple) we set up a situation where most "normal" users, who are not using their friend's self-signed webmail server or their company's web-staging site, are unlikely to see more than a handful of these in their browsing lifetime. [...] As I complained here quite noisily a pair of month before, "normal" users are completely unable to go beyond the error screen and *they* *start* *IE* *instead*. But let's put that flamethrower aside. - All of this would be better with KCM, which is why I filed this bug to discuss the possibility. Hum, I didn't notice earlier this bug was that old. Your reasonning IIUC is based on the idea users will mostly encounter the following two kind of ssl sites : - professional sites intended for ecommerce - sites intended to protect sensitive information of a closed community and that the problem mostly is that the second kind can/won't afford a professional SSL cert, so the user needs to add an exception and remember it. Or use KCM for them. I think that you are missing the fact that there's a large number of sites around that are *playing* with SSL, and using SSL with no real reason to protect actually sensitive information. And it's those sites who are the most frequently badly configured. In my usage, most of the time when I need to add an exception it's for one of those sites and I should not remember the exception. So, I will make the assertion that at least 80% of our users are not going to benefit from the technical details we include in that error message, and that while we could do another round of wording improvements to try to finesse that, the issue goes deeper. 80% of users don't want to know what a certificate is, or how it is used to secure a TLS channel, and the wording in the rest of that error page is already an attempt to make the issue more concrete, without delving into the specifics. If we bury them under technical words they don't understand, yes of course it's a bad idea. I am thinking about bringing them useful information in a form they can understand. And the kind of information they need would depend of the kind of error. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: OCSP and privacy concerns (was: CABForum place in the world)
On 9-Jan-09, at 9:38 AM, Michael Ströder wrote: Johnathan Nightingale wrote: To give you a somewhat recent example, we were strong proponents of mandatory OCSP support by 2010 because we think it's better for the health of the net to have high-availability revocation information available for high-assurance certs, despite the arguments from some quarters that it would be too costly to support on high-traffic sites. Can OCSP still be disabled? Personally I have strong privacy concerns since when checking for a server cert via OCSP the OCSP responder knows which server you try to access (because the FQDN is in the server cert's subject DN). You can disable it, although EV certs will stop being treated as EV in that case (since bug 405139). You may also be interested in the work on OCSP-stapling, so that no third party learns about your browsing, but you still get a CA-signed OCSP response. The CAs are interested in this too, since it takes the load off of them for high-traffic sites. Cheers, J --- Johnathan Nightingale Human Shield john...@mozilla.com ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
OCSP and privacy concerns (was: CABForum place in the world)
Johnathan Nightingale wrote: > To give you a > somewhat recent example, we were strong proponents of mandatory OCSP > support by 2010 because we think it's better for the health of the net > to have high-availability revocation information available for > high-assurance certs, despite the arguments from some quarters that it > would be too costly to support on high-traffic sites. Can OCSP still be disabled? Personally I have strong privacy concerns since when checking for a server cert via OCSP the OCSP responder knows which server you try to access (because the FQDN is in the server cert's subject DN). Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 9/1/09 03:52, Julien R Pierre - Sun Microsystems wrote: If a server changes to a new cert with a new key, how will KCM work "much better" ? If the new cert is authentic, then this will cause some form of alert, which would be this case: If you follow the KCM logic, you would have to give an application warning, which is completely unwarranted under current standards. If the new cert is unauthentic, then it would cause some form of alert that would be entirely warranted. Currently, a false cert will slip through without any change. Think of a bookmark. Add a cert. add a few whizzbangs in the bookmark manager, go from there It doesn't matter whether you type it or not when you are talking about SSL. Only what's on the network matters, ie. the cert that the server sends. The content of the cert is supposed to confirm the identity of the server. Right. Tell it to the UI guys. The content of the cert does not confirm the identity of the server, because only now are we seeing prominent displays. The problem is well-hashed. The SSL stuff was supposed to just "work", so the UI guys dropped all the info. This meant it was easy to trick, something the original designers knew well, but apparently was not really appreciated. There has to be *integration* between the user's actions and the site's actions. End-to-end. Bookmarks would be (are) one way of doing this. You can think of a bookmark+cert as similar or like a poor-man's client certificate if you like. Much like, when you call somebody over the phone, their voice print (usually) confirm who you are talking to. URLs get redirected, phone numbers change. In all cases authentication is needed, whether somebody has fat fingers or is using bookmarks, or the redial button on a phone, whether somebody has a bad cold and sounds significantly different than using (their key changed :)). You still have to do your authentication. You may have a particular expectation of what key or what person is on the other end, but still you don't normally start communicating before you have confirmed the identity. Right. But look at the end-user's question in another thread. It isn't being answered. The issue here is that Firefox is acting like a blackbox, and can't be seen inside. The equation is too complex. The difference between an old phone and a new Firefox is that the white box that is the phone has two analogue wires, a dialtone, and a telco at the other end with various protections. It was possible to reliably show what was going on, even without an electrical engineering degree, and generate some security that all was well. Now, however, we have a question whereby Firefox generates the key, sends the CSR for signing, gets back the cert, displays various cert indications, includes special features for key escrow, tells you the connection is secure ... all within a black box. It feel rather annoyed if I'd have to confirm every new cert encountered. Yes, on the web we usually cannot do that ourselves, that's why we trust CAs to do the work for us. If we aren't happy with a particular CA's job, we don't have to trust them... Were you following the threads of December? Approximately three cases of trickiness. I'm not saying that the PKI is about to meltdown, but some of the flaws in the system that we've know for a long time became apparent. And no solution in site, except more of the "trust me" rhetoric. It is policy, more or less, that end-users don't get to trust a particular CA. They only get to trust Firefox's black box magic, and if they lose, they lose. Just how inspiring is that? It is policy, more or less, that *any* CA's cert is good. Gee. It is also policy, more or less, that CAs work to identity and control, and identity fraud and tricking computer systems is a crook's dream. It is policy, more or less, that nobody accepts the responsibility for this. Do you believe in all that? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Kyle Hamilton wrote: "Legitimate sites will never ask you for your credit card, national ID number, or any other sensitive information after asking you to add an exception." So what we need *instead* of an exception is a special browsing mode in which you are reminded that you should not enter any sensitive information on the current site. I in fact loved the "httpst:// (security theater)" , "httpwf:// (warm fuzzy)", "mitm://" or "Flashing pink chrome", "Empty wallet icon", "The whistling sounds associated with falling things" suggestions by Nelson back in this message http://groups.google.com/group/mozilla.dev.tech.crypto/msg/eda04af2c6370179 . This is the kind of thing that's required. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Ian, Ian G wrote: On 8/1/09 23:35, Eddy Nigg wrote: On 01/08/2009 11:44 PM, Ian G: Well, what Firefox does is cert-exception-click-thru-ordeal; whereas people are asking for key-continuity-management, with perhaps the emphasis on the last word. Well, is it than an endorsement for self-signed certs? Oh, no, we are down on advocacy this week :) Actually KCM works much better with CA-signed certs, because they help (quite a lot) with the "first visit" problem. How ? KCM is counter to everything in X.509 ? If a server changes to a new cert with a new key, how will KCM work "much better" ? If you follow the KCM logic, you would have to give an application warning, which is completely unwarranted under current standards. Otherwise I can't see the difference between what's requested and what already exists. The only thing which would change perhaps is the case when ANY certificate changes its state (replaced). Is this what is advocated? Well, back in the old days, we all had to type in URLs and email addersses manually. These days we have smart programs to remember what we do, what we accept, what we authorise. Think of a bookmark. Add a cert. add a few whizzbangs in the bookmark manager, go from there It doesn't matter whether you type it or not when you are talking about SSL. Only what's on the network matters, ie. the cert that the server sends. The content of the cert is supposed to confirm the identity of the server. Much like, when you call somebody over the phone, their voice print (usually) confirm who you are talking to. URLs get redirected, phone numbers change. In all cases authentication is needed, whether somebody has fat fingers or is using bookmarks, or the redial button on a phone, whether somebody has a bad cold and sounds significantly different than using (their key changed :)). You still have to do your authentication. You may have a particular expectation of what key or what person is on the other end, but still you don't normally start communicating before you have confirmed the identity. It feel rather annoyed if I'd have to confirm every new cert encountered. Yes, on the web we usually cannot do that ourselves, that's why we trust CAs to do the work for us. If we aren't happy with a particular CA's job, we don't have to trust them... ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Ian, Ian G wrote: On 8/1/09 21:12, Eddy Nigg wrote: On 01/08/2009 09:58 PM, Ben Bucksch: On 08.01.2009 14:46, Johnathan Nightingale wrote: - All of this would be better with KCM, which is why I filed this bug to discuss the possibility. https://bugzilla.mozilla.org/show_bug.cgi?id=kcm Thank you! Fantastic proposal, thanks for having the guts to challenge status quo and seriously suggest that. I hope this is carried forward and implemented and does not just die out. Isn't this what Firefox already does? E.g. store the remembered decision permanently? Besides, I realized that the flag to remember is set by default on and is easily forgotten (judging from some exceptions I'd rather have not remembered). Well, what Firefox does is cert-exception-click-thru-ordeal; whereas people are asking for key-continuity-management, with perhaps the emphasis on the last word. Of course, you do realize that the X.509 and PKIX standards perfectly allow keys to be changed by an entity in new certificates. In fact, one entity can have multiple certificates with separate keys, for different purposes. You can have an LDAPS server with one cert and key, an HTTPS server with another cert and key, etc. All with the same subject name / DNS name. And they can all be valid at the same time. Mote that the certs are not linked to a particular TCP port. Also, a server farm may use, for whatever reason (one of them, keeping the key in hardware), different certs and keys on each server of the server farm, and each of these certs could have the same subject/DNSname, but different keys . These are just a couple of examples on the top of my head. If you are going to implement "key continuity management", that would imply that you will want firefox to warn in all those cases that are today perfectly legitimate uses of the X.509 PKI with SSL . IMO, you cannot define application behavior for the KCM cases unless there is a clear way for both the users and the browser to determine in which cases KCM is desired or not desired. Currently the standards say there is no KCM in X.509 . From what I have read of the discussion so far, the use case seems to be "because somebody was too cheap to get a $10 DV cert". This should be a rather exceptional situation, not the rule, and as such, I think the model of "cert-exception-click" is perfectly fit. As for it being an ordeal to trust the cert after establishing the connection, it should be. I personally I don't even think it's hard enough. IMO, before trusting any self-signed cert, the browser should prompt the user for a few bytes of the fingerprint of the server cert, without showing the server cert's fingerprint, and if it matches, allow the connection to go through. SSH could be made to work that way too. Instead of typing "yes" blindly, how about asking for the fingerprint ? This would allow people who are playing with their self signed certs, or only trust their keys, to exchange this data out of bounds. And if they want key continuity, well, they can always set an expiration date 100 years in the future in their cert :) . Why would they want another cert then ? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
the longer a key is used the better the chances of getting compromised, isn't it? It doesn't make a difference whether you have one key for two years on a system or two keys for one year each, one after the other. The longer a key is on a system, the chances are higher for compromise I think. yes, this is in fact the case. Particularly if the key is used in any sort of volume site. The assumption that one key for 2 years is as secure as 2 keys for one year each does not bare out in real world cryptography. Here's why: 1) An attacker has more time to 'attack' the first key. Cryptographic attacks only get better, never worse. These attacks can come from the following: a. mathematical attacks on the key itself (e.i. factoring than RSA modulus) - usually the minor of the possible attacks assuming the security of the key is large enough with respect to the validity period, though becoming a consideration with 1024 RSA. Keys with longer lives *SHOULD* be more cryptographically secure (I'm worried about the number of 1024 bit CA certs floating around right now). b. oracle attacks. Attacks in which the attacker learns information by asking a the owner of the key to perform private key operations (Blechenbaucher I against symmetric keys are one example). c. accidental or intentional compromise from someone inside, particularly if it goes undetected. d. possible compromise through a hardware glitch. RSA is particularly prone to compromise if a mistake is made in one stage of the operation. Such mistakes are exceedingly rare, but on a high traffic site, the risk increases the longer the key is in use (NSS actually protects against this case by never releasing data the doesn't 'invert' with the public key). 2) The world changes. New attacks are discovered. Weak keys are identified. The new key generated 1 year later can take these new events into account. Revocation is good for the onesy-twosy type key compromised. All the revocation schemes fall over in the massive revocation case. Not changing out the key periodically leads to a more brittle solution than changing it. If your system is over designed, you can get away with it, but then you could simply have started using longer expiration times. bob ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Ben Bucksch wrote: On 08.01.2009 23:35, Eddy Nigg wrote: On 01/08/2009 11:44 PM, Ian G: Well, what Firefox does is cert-exception-click-thru-ordeal; whereas people are asking for key-continuity-management, with perhaps the emphasis on the last word. Well, is it than an endorsement for self-signed certs? It's not an *endorsement*, but making it possible to use them without fat warning and without risking CA-verfied sites with that. At least that's one part. For the average user, "making it possible to use them without fat warning" is counter to any goal of securing the network. Self-signed certs are part of the problem. The fat warning is the only thing that makes this palatable. For the average user, there should be no ability to override. bob ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 01/09/2009 02:24 AM, Ian G: Well, is it than an endorsement for self-signed certs? Oh, no, we are down on advocacy this week :) Actually KCM works much better with CA-signed certs, because they help (quite a lot) with the "first visit" problem. I could see some use case for this, specially when used as you mentioned with the non-self-signed-certificates-advocacy! However I'm afraid that reality is far away from having this implemented anytime soon because all major server software and CAs create usually new keys for every new certificate. Well, the ones which issue certs for ten years would be in a comfortable position...(or not :S ) Think of a bookmark. Add a cert. add a few whizzbangs in the bookmark manager, go from there Mmmhhh, well, I can't remember when I saw bookmarks the first time. Must have been some time in the nineties, no? I run NoScript. It means I have to confirm every site I see, and decide whether to let it do stuff. For me, this is ok (I'm not suggesting it for everyone) because I don't like websites going mad, and I have no idea what all that javascript is doing. NoScript is for geeks really...or better said, it's used by geeks only. JavaScript is becoming these days ever more important and browser vendors are literally investing huge effort to make it faster and secure...I think it's not fun browsing with NoScript. But yes, confirming every site would be annoying for me... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 01/09/2009 02:08 AM, Ben Bucksch: On 01/09/2009 01:12 AM, Ben Bucksch: It's not an *endorsement*, but making it possible to use them without fat warning Which is exactly the same thing... No. "Make it possible" and "endorse" are two entirely different things. OK, let us disagree on that one for now. My opinion is, that it is made possible and provides the technical details to do that securely (That is for FF 3.1, not discussing FF 3.0 anymore). the longer a key is used the better the chances of getting compromised, isn't it? It doesn't make a difference whether you have one key for two years on a system or two keys for one year each, one after the other. The longer a key is on a system, the chances are higher for compromise I think. If you want to change keys nevertheless, you can still do that. Just make sure you authorize the new one, by signing the new key with the old one. Errr...this isn't PGP, besides, I don't want to sign anything new with something old, otherwise I wouldn't need the new one in first place, no? I did, I know this bug from long time ago. Perhaps help me understand what I'm apparently missing here. As I already explicitly said in the bug, there would be no warning. The private key does not change, or the new key is signed with the old one. You mean the same public key in form of a CSR is signed by the CA once again and a new certificate issued in which case no new action should be required. If the key changes than an error is issued. If this is correct, it would be very inconvenient for the majority of users since web sites 98% change the keys every while (after certificate expiration). CAs which issue more frequently (shorter life-time) would be at disadvantage - I stated it before. What happens on first visit? A message to acknowledge the new key? Or will it be silently accepted? As per your comment in the bug I assume that to be the case - most likely accepting self-signed certs silently on the way too I guess. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 8/1/09 23:35, Eddy Nigg wrote: On 01/08/2009 11:44 PM, Ian G: Well, what Firefox does is cert-exception-click-thru-ordeal; whereas people are asking for key-continuity-management, with perhaps the emphasis on the last word. Well, is it than an endorsement for self-signed certs? Oh, no, we are down on advocacy this week :) Actually KCM works much better with CA-signed certs, because they help (quite a lot) with the "first visit" problem. Otherwise I can't see the difference between what's requested and what already exists. The only thing which would change perhaps is the case when ANY certificate changes its state (replaced). Is this what is advocated? Well, back in the old days, we all had to type in URLs and email addersses manually. These days we have smart programs to remember what we do, what we accept, what we authorise. Think of a bookmark. Add a cert. add a few whizzbangs in the bookmark manager, go from there It feel rather annoyed if I'd have to confirm every new cert encountered. I run NoScript. It means I have to confirm every site I see, and decide whether to let it do stuff. For me, this is ok (I'm not suggesting it for everyone) because I don't like websites going mad, and I have no idea what all that javascript is doing. But, yes, I understand that users want their "rich experience." Personally I would recommend everyone to use something like NoScript, but it is too complicated to explain to users. So they have to suffer. Specially those which issue for relative short life-time would be again in disadvantage (despite doing the right thing). Yes, this is an extra step. TANSTAAFL. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 01/09/2009 01:12 AM, Ben Bucksch: It's not an *endorsement*, but making it possible to use them without fat warning Which is exactly the same thing... No. "Make it possible" and "endorse" are two entirely different things. the longer a key is used the better the chances of getting compromised, isn't it? It doesn't make a difference whether you have one key for two years on a system or two keys for one year each, one after the other. If you want to change keys nevertheless, you can still do that. Just make sure you authorize the new one, by signing the new key with the old one. It feel rather annoyed if I'd have to confirm every new cert encountered. Please read the bug before commenting, thanks. I did, I know this bug from long time ago. Perhaps help me understand what I'm apparently missing here. As I already explicitly said in the bug, there would be no warning. The private key does not change, or the new key is signed with the old one. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 01/09/2009 01:12 AM, Ben Bucksch: Well, is it than an endorsement for self-signed certs? It's not an *endorsement*, but making it possible to use them without fat warning Which is exactly the same thing... For me, the more important part is *continuity*. For me, it's important that the key stays the same (or signs the new key) and I don't have to re-establish trust relationships all the time (via CAs). Isn't that bad practice? I mean, the longer a key is used the better the chances of getting compromised, isn't it? It feel rather annoyed if I'd have to confirm every new cert encountered. Please read the bug before commenting, thanks. I did, I know this bug from long time ago. Perhaps help me understand what I'm apparently missing here. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 08.01.2009 23:35, Eddy Nigg wrote: On 01/08/2009 11:44 PM, Ian G: Well, what Firefox does is cert-exception-click-thru-ordeal; whereas people are asking for key-continuity-management, with perhaps the emphasis on the last word. Well, is it than an endorsement for self-signed certs? It's not an *endorsement*, but making it possible to use them without fat warning and without risking CA-verfied sites with that. At least that's one part. Otherwise I can't see the difference between what's requested and what already exists. For me, the more important part is *continuity*. For me, it's important that the key stays the same (or signs the new key) and I don't have to re-establish trust relationships all the time (via CAs). It feel rather annoyed if I'd have to confirm every new cert encountered. Please read the bug before commenting, thanks. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 01/08/2009 11:44 PM, Ian G: Well, what Firefox does is cert-exception-click-thru-ordeal; whereas people are asking for key-continuity-management, with perhaps the emphasis on the last word. Well, is it than an endorsement for self-signed certs? Otherwise I can't see the difference between what's requested and what already exists. The only thing which would change perhaps is the case when ANY certificate changes its state (replaced). Is this what is advocated? It feel rather annoyed if I'd have to confirm every new cert encountered. Specially those which issue for relative short life-time would be again in disadvantage (despite doing the right thing). -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 8/1/09 21:12, Eddy Nigg wrote: On 01/08/2009 09:58 PM, Ben Bucksch: On 08.01.2009 14:46, Johnathan Nightingale wrote: - All of this would be better with KCM, which is why I filed this bug to discuss the possibility. https://bugzilla.mozilla.org/show_bug.cgi?id=kcm Thank you! Fantastic proposal, thanks for having the guts to challenge status quo and seriously suggest that. I hope this is carried forward and implemented and does not just die out. Isn't this what Firefox already does? E.g. store the remembered decision permanently? Besides, I realized that the flag to remember is set by default on and is easily forgotten (judging from some exceptions I'd rather have not remembered). Well, what Firefox does is cert-exception-click-thru-ordeal; whereas people are asking for key-continuity-management, with perhaps the emphasis on the last word. Petnames and Trustbar are good place to look at for models. Store the continuity info as a bookmark, and then manage the arrangement from there. Validate the cert and domain once, as a bookmark, and manage it later on when something changes. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 01/08/2009 09:58 PM, Ben Bucksch: On 08.01.2009 14:46, Johnathan Nightingale wrote: - All of this would be better with KCM, which is why I filed this bug to discuss the possibility. https://bugzilla.mozilla.org/show_bug.cgi?id=kcm Thank you! Fantastic proposal, thanks for having the guts to challenge status quo and seriously suggest that. I hope this is carried forward and implemented and does not just die out. Isn't this what Firefox already does? E.g. store the remembered decision permanently? Besides, I realized that the flag to remember is set by default on and is easily forgotten (judging from some exceptions I'd rather have not remembered). -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 08.01.2009 14:46, Johnathan Nightingale wrote: - All of this would be better with KCM, which is why I filed this bug to discuss the possibility. https://bugzilla.mozilla.org/show_bug.cgi?id=kcm Thank you! Fantastic proposal, thanks for having the guts to challenge status quo and seriously suggest that. I hope this is carried forward and implemented and does not just die out. So, I will make the assertion that at least 80% of our users are not going to benefit from the technical details we include in that error message Agreed. I do think that these 20% are important, though. It's still 30 million people. (And they're the ones giving advise to the other 80%.) ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 8-Jan-09, at 7:48 AM, Jean-Marc Desperrier wrote: I wish I manage to find the time to make some constructive suggestions about it. Meanwhile it would be great if you were more active on the group here, because I think it's much adequate than blog post (and more visible, so more open, that a bug entry) for such discussion (as long as it doesn't turn into a flame war :-( ). I agree, though I'll confess, it would help if I were able to be in a lot more places at once. :) Nevertheless, I'll try to lurk a little less and speak a little more. The error is that you decided to hid from the user most of the information about what kind of error was encountered. This is really bad because the *major* problem with the SSL error screen is that at least 90% of the time when the user encounters it, it's a false positive. Nobody is *really* actively trying to attack him. I absolutely agree that most untrusted cert errors will not represent MitM attacks. However, a couple points to keep in mind: - By making the default exception permanent instead of temporary (and bound to the host, port, cert tuple) we set up a situation where most "normal" users, who are not using their friend's self-signed webmail server or their company's web-staging site, are unlikely to see more than a handful of these in their browsing lifetime. Certainly, they may have some intranet site or favourite forum that uses one, but once they add that exception, they aren't likely to see many more. When they do, particularly on a site that didn't used to have one - our hope is that they will stop and consider. - All of this would be better with KCM, which is why I filed this bug to discuss the possibility. https://bugzilla.mozilla.org/show_bug.cgi?id=kcm I then ended up helping out our mobile team for several months, which limited my ability to drive that kind of thing, but there are also several concerns raised in that bug that would need to be addressed before we could get the behaviour it describes (what does the first-visit experience look like? do we KCM-ify certs for subelements of a page, or only top level loads, &c.) One thing people in this forum could be really helpful with is nailing down those issues so that we have something concrete to implement. There will be a problem with SSL error screen as long as 90% of those screen are false positive, but displaying the info about the nature of the problem at least helps the user to figure out why he got the screen so why there was a false positive, so trust the screen more, and not just ignore it the day where it's not a false positive. So, I will make the assertion that at least 80% of our users are not going to benefit from the technical details we include in that error message, and that while we could do another round of wording improvements to try to finesse that, the issue goes deeper. 80% of users don't want to know what a certificate is, or how it is used to secure a TLS channel, and the wording in the rest of that error page is already an attempt to make the issue more concrete, without delving into the specifics. There were calls in fact, in 3.0 and 3.1, to just remove the technical details altogether, but people like Nelson persuaded me that this was an essential debugging tool for support, even if end users couldn't make heads or tails of it. In that vein, the 3.1 error pages have a happy quirk where, even when the technical details are collapsed, selecting the error page text and copying will include them, suitable for pasting into tech support emails. I know you likely already know this, but do keep in mind as well that if you are someone who *does* understand this information, flipping the browser.xul.error_pages.expert_bad_cert pref in about:config will show the details sections by default. Cheers, Johnathan --- Johnathan Nightingale Human Shield john...@mozilla.com ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Johnathan Nightingale wrote: [...] I doubt it will surprise you to know that Kyle isn't the first person to throw such stones. What is comparatively rarer is helpful, balanced suggestions for moving forward.[...] I wish I manage to find the time to make some constructive suggestions about it. Meanwhile it would be great if you were more active on the group here, because I think it's much adequate than blog post (and more visible, so more open, that a bug entry) for such discussion (as long as it doesn't turn into a flame war :-( ). I appreciate that the recent change in Firefox 3.1 SSL error screen show that you wish to enhance it, but I regret that a good part of the change is in the wrong direction. The error is that you decided to hid from the user most of the information about what kind of error was encountered. This is really bad because the *major* problem with the SSL error screen is that at least 90% of the time when the user encounters it, it's a false positive. Nobody is *really* actively trying to attack him. There will be a problem with SSL error screen as long as 90% of those screen are false positive, but displaying the info about the nature of the problem at least helps the user to figure out why he got the screen so why there was a false positive, so trust the screen more, and not just ignore it the day where it's not a false positive. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 07.01.2009 17:16, Ian G wrote: That is, if Phishing and Malware and XSS and website hacks and identity-is-credit and any number of other things are causing so many losses in the good ol' US of A and the other identity-fraught markets ... so much so that the FBI bothers to measure them ... then ... Why is there only one guy? That's not entriely true. There are at least 3 ;-P. There is the security team, including Daniel Veditz and Jesse Ruderman and others, which are busy running after the security exploits/bugs instead of chatting here. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 07.01.2009 17:16, Ian G wrote: That is, if Phishing and Malware and XSS and website hacks and identity-is-credit and any number of other things are causing so many losses in the good ol' US of A and the other identity-fraught markets ... so much so that the FBI bothers to measure them ... then ... Why is there only one guy? That's not entriely true. There are at least 3 ;-P. There is the security team, including Daniel Veditz and Jesse Ruderman and others, which are busy running after the security exploits/bugs instead of chatting here. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 6/1/09 23:40, Johnathan Nightingale wrote: Hey Ian, I appreciate the understanding of the situation, but I'm not quite ready to call the job impossible just yet, despite the array of forces being very much as you describe them. :) My point was very much oriented to the embarrassment of ONE GUY being an entire human shield. That is, if Phishing and Malware and XSS and website hacks and identity-is-credit and any number of other things are causing so many losses in the good ol' US of A and the other identity-fraught markets ... so much so that the FBI bothers to measure them ... then ... Why is there only one guy? Which digit in BILLIONS does Mozilla have trouble understanding? What is comparatively rarer is helpful, balanced suggestions for moving forward. Well. As we all know, the situation is *very complex*. Fixing it is rather difficult. It is ok for us outsiders to point out obvious flaws, but that only goes so far. Outsiders cannot see all the picture. One reason for that might be Mozilla's old policy of having an "invite only" security group. Those who are critical, and those who come from a different school of thought, simply don't get invited to join. After a while, inevitably, this results in the monoculture trap, and then those with different views don't actually want to be invited to join such a narrow group. Insiders don't see all the picture either. Just one example is that Mozilla does not see the liability aspects, which is unsurprising given that developers don't tend to have legal experience, and no lawyer would accept any invite. (I should say that the monoculture trap is either explicitly or implicitly run by pretty much all open source groups. Mozilla has no monopoly on monoculture.) In the meantime though, it's worth remembering that Firefox 3.1, when it comes out, will have private browsing mode, better clear private data support, That sounds positive, I am keen! Right now, to log into my online bank, I do this: * I use a Mac computer that does nothing else, * with a user that does nothing else. * I shut down Firefox before and after, * and I clear all the data before and after, If I could think of another way to firewall it safely I'd do it. I've experimented with different users on the Mac but this is too much of a pain. The worst part of it all is that I cannot possibly advise users to do this, it's too technical. My desk is now covered with postit notes, I need three postit notes to log into my bank, and a dongle. We've come full circle... SSL errors that interrupt user workflow explicitly instead of being ignored away, anti-malware and anti-phishing protection, Now I'm listening! fewer "You are submitting a search to Google" useless dialog boxes, an identity indicator that actually calls out the names of CAs issuing certs, and a much better mixed mode detection story than we had a little while ago, among others. OK, that all sounds good, but... I want KCM. I see no mention of KCM. Tell us about KCM? I want to be able to lock my online bank's SSL cert down. The online bank puts the whole liability on ME. There's no way that I can recommend that people risk their own money on some green box on a display. However, if KCM allows me to isolate and tie down one green cert, that could work. We are always short-staffed on this stuff though, so it's great to see people like Kyle eager to help. I think the ball is in Mozilla's court, and has been for all the time I've known it. People do want to code up the stuff, but they want to code up the stuff they believe in. While Mozilla pursues a monoculture model to security architecture, it's difficult to attract the guys who see other stuff. I would rather spend time on the exciting work that is being done in the p2p world, if I still coded, because security is an architecture issue there. It's really up to you who you invite in... Perhaps if we express an open invitation to code up the next generation KCM modules then this might get more attention? So Jon goes to CAB Forum with a mandate to speak for the end-users, without any input from Mozilla, the browser vendor? Obviously I'm there representing a browser, but Mozilla's interests tend to align with end users most of the time. I think this is a great description. It avoids the unfortunate marketing nonsense of the security industry (who wouldn't know a user if they married one). We are who we are, hopefully we can deal with our biases, but it starts with recognising them. We don't, for instance, have a profit motive creating potential conflicts of interest. To give you a somewhat recent example, we were strong proponents of mandatory OCSP support by 2010 because we think it's better for the health of the net to have high-availability revocation information available for high-assurance certs, despite the arguments from some q
Re: CABForum place in the world
On 2-Jan-09, at 2:00 AM, Ian G wrote: On 2/1/09 03:44, Kyle Hamilton wrote: If he's a security and user interface expert, why is the security UI so appallingly *bad*? Not answering for gerv, but I would say: he is the human shield, against all influences, inside and outside! He's only one guy, and he has the entire battle field to deal with. Every time he moves to the left, the right mobs him. Every time he moves to the right, the left undermines him. The result is bad, but it isn't his fault, it's the fault of the situation he is in. However, at least we have a result! Before he was there, the only thing we had was random experimentation (like Gerv's much missed yellow bar) and corporate denial of the issue. Hey Ian, I appreciate the understanding of the situation, but I'm not quite ready to call the job impossible just yet, despite the array of forces being very much as you describe them. I doubt it will surprise you to know that Kyle isn't the first person to throw such stones. What is comparatively rarer is helpful, balanced suggestions for moving forward. In the meantime though, it's worth remembering that Firefox 3.1, when it comes out, will have private browsing mode, better clear private data support, SSL errors that interrupt user workflow explicitly instead of being ignored away, anti-malware and anti-phishing protection, fewer "You are submitting a search to Google" useless dialog boxes, an identity indicator that actually calls out the names of CAs issuing certs, and a much better mixed mode detection story than we had a little while ago, among others. We are always short-staffed on this stuff though, so it's great to see people like Kyle eager to help. So Jon goes to CAB Forum with a mandate to speak for the end-users, without any input from Mozilla, the browser vendor? Obviously I'm there representing a browser, but Mozilla's interests tend to align with end users most of the time. We don't, for instance, have a profit motive creating potential conflicts of interest. To give you a somewhat recent example, we were strong proponents of mandatory OCSP support by 2010 because we think it's better for the health of the net to have high-availability revocation information available for high-assurance certs, despite the arguments from some quarters that it would be too costly to support on high- traffic sites. Johnathan --- Johnathan Nightingale Human Shield john...@mozilla.com ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 01/05/2009 02:49 AM, Nelson Bolyard: And right next to the lock icon is the DNS name that matched the cert. This solves one problem with confusing URLs. I view the padlock and the DNS name in that area completly superfluous. It serves no real purpose and is so90's really. Browsers really advanced since...or do you look up and down just to compare the URL in the address bar and then what's listed in the status bar? It's however inconvenient and I personally never look there. Instead I set browser.identity.ssl_domain_display to 1 in about:config. That's also a good indicator. Setting it to 2 makes it show the same value as shown down by the lock icon, the verified DNS name. Yes, but it makes it sometimes too long. Additionally I like to know the base domain since www.paypal.com.some.more.sub.domain.com/?p=sdlfhkd can become confusing too. I was thinking of the "scheme" in the address bar, e.g. https:// :-) Welltry to tell that to my mother -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Eddy Nigg wrote, On 2009-01-04 14:48: > On 01/05/2009 12:42 AM, Nelson B Bolyard: >> Eddy Nigg wrote, On 2009-01-04 14:28: >>> On 01/04/2009 09:32 PM, Nelson B Bolyard: do that, too, and phishers will be quick to imitate it. The main point of "chrome" is that content cannot effectively mimic it. It's unspoofable. (It wasn't, always, but browsers have finally gotten wise to that.) >>> And what about this? https://blog.startcom.org/?attachment_id=90 >> If the blue shading around the "favicon" was the ONLY indication that a >> page was served via https, then I would agree that that's too weak to be >> considered unspoofable (or even noticeable). But IIRC, there are at least >> two other non-spoofable indicators. > > I know about the padlock in the lower right bottom in the status bar. And right next to the lock icon is the DNS name that matched the cert. This solves one problem with confusing URLs. > It's however inconvenient and I personally never look there. Instead I > set browser.identity.ssl_domain_display to 1 in about:config. That's also a good indicator. Setting it to 2 makes it show the same value as shown down by the lock icon, the verified DNS name. > But what is the second indicator? I was thinking of the "scheme" in the address bar, e.g. https:// ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 01/05/2009 12:42 AM, Nelson B Bolyard: Eddy Nigg wrote, On 2009-01-04 14:28: On 01/04/2009 09:32 PM, Nelson B Bolyard: do that, too, and phishers will be quick to imitate it. The main point of "chrome" is that content cannot effectively mimic it. It's unspoofable. (It wasn't, always, but browsers have finally gotten wise to that.) And what about this? https://blog.startcom.org/?attachment_id=90 If the blue shading around the "favicon" was the ONLY indication that a page was served via https, then I would agree that that's too weak to be considered unspoofable (or even noticeable). But IIRC, there are at least two other non-spoofable indicators. I know about the padlock in the lower right bottom in the status bar. It's however inconvenient and I personally never look there. Instead I set browser.identity.ssl_domain_display to 1 in about:config. But what is the second indicator? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Eddy Nigg wrote, On 2009-01-04 14:28: > On 01/04/2009 09:32 PM, Nelson B Bolyard: >> do that, too, and phishers will be quick to imitate it. The main point of >> "chrome" is that content cannot effectively mimic it. It's unspoofable. >> (It wasn't, always, but browsers have finally gotten wise to that.) > > And what about this? https://blog.startcom.org/?attachment_id=90 If the blue shading around the "favicon" was the ONLY indication that a page was served via https, then I would agree that that's too weak to be considered unspoofable (or even noticeable). But IIRC, there are at least two other non-spoofable indicators. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 01/04/2009 09:32 PM, Nelson B Bolyard: do that, too, and phishers will be quick to imitate it. The main point of "chrome" is that content cannot effectively mimic it. It's unspoofable. (It wasn't, always, but browsers have finally gotten wise to that.) And what about this? https://blog.startcom.org/?attachment_id=90 -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Ian G wrote, On 2009-01-03 19:19: > On 3/1/09 23:40, Nelson B Bolyard wrote: >> There's a great deal of anecdotal evidence (and some serious studies) >> that suggest that anything that goes on outside of the "content" area >> of the browser, and that does not actively engage the user, will be >> ignored by a huge percentage of users. There are many users who, >> anecdotal evidence shows, ignore all "chrome" completely and pay no >> attention to anything except "content". Because of the fact that good >> phishers always reproduce the desired content EXACTLY, users who >> ignore chrome and only examine content will ALWAYS be victims to >> phishers UNLESS we interrupt their view of the "content" with something >> that they must deal with when the site's credentials are "phishy". >> That's why warnings and clicks are different than all the other stuff >> you describe above. > > OK, so some discussion on how to display the info. Bringing the two > together, the info that is considered relevant might be pasted over the > entire page. Paste info for "good connections" over the entire page as a > shadow display, with all there in big letters, and allow it to fade away > after 2-3 seconds. Pink or mild yellow? The problem is that ANYTHING that you can put into the content area can also be put there as content. If you condition the user to accept large but vanishing yellow letters saying "good connections", the content can do that, too, and phishers will be quick to imitate it. The main point of "chrome" is that content cannot effectively mimic it. It's unspoofable. (It wasn't, always, but browsers have finally gotten wise to that.) > The point being if the "chrome" is ignored, we go where it isn't ignored? > (I really liked the addition of the top and bottom bars in light grey, > within the content part.) That can all be mimicked. > If it is important, we can interrupt the user's info. If it isn't > important enough for that, then it isn't important. That's the entire rationale for the current bad cert "error pages", which replaced the old error dialogs. The also found that users would dismiss any dialogs to get to that precious content, so the only solution was to replace the content entirely. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 3/1/09 23:40, Nelson B Bolyard wrote: Ian G wrote, On 2009-01-03 06:22: Good question! On 3/1/09 06:43, Kyle Hamilton wrote: The only thing that we can do is make sure that the user has as much (relevant) information as possible. So what is the relevant info? My list of relevant info: the name of the CA [1] the name that the CA signs the previous acceptance status of the cert (e.g., number of visits<==> petnames). the absence of the above (e.g., we are in OFF mode) My list of irrelevant info: the cert details the warnings the clicks the status of the connection (e.g., padlock) All these are too complex for users. There's a great deal of anecdotal evidence (and some serious studies) that suggest that anything that goes on outside of the "content" area of the browser, and that does not actively engage the user, will be ignored by a huge percentage of users. There are many users who, anecdotal evidence shows, ignore all "chrome" completely and pay no attention to anything except "content". Because of the fact that good phishers always reproduce the desired content EXACTLY, users who ignore chrome and only examine content will ALWAYS be victims to phishers UNLESS we interrupt their view of the "content" with something that they must deal with when the site's credentials are "phishy". That's why warnings and clicks are different than all the other stuff you describe above. OK, so some discussion on how to display the info. Bringing the two together, the info that is considered relevant might be pasted over the entire page. Paste info for "good connections" over the entire page as a shadow display, with all there in big letters, and allow it to fade away after 2-3 seconds. Pink or mild yellow? Paste info for "bad connections" over the entire page, and leave it there until a click is done? Make it bright red, or grey, make it flash, I don't know... The point being if the "chrome" is ignored, we go where it isn't ignored? (I really liked the addition of the top and bottom bars in light grey, within the content part.) If it is important, we can interrupt the user's info. If it isn't important enough for that, then it isn't important. The question here is more about important info. What to do with it is interesting. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Ian G wrote, On 2009-01-03 06:22: > Good question! > > On 3/1/09 06:43, Kyle Hamilton wrote: > >> The only thing that we can do is make sure that the user has as much >> (relevant) information as possible. > > > So what is the relevant info? > > My list of relevant info: > >the name of the CA [1] >the name that the CA signs >the previous acceptance status of the cert > (e.g., number of visits <==> petnames). >the absence of the above > (e.g., we are in OFF mode) > > My list of irrelevant info: > >the cert details >the warnings >the clicks >the status of the connection (e.g., padlock) > > All these are too complex for users. There's a great deal of anecdotal evidence (and some serious studies) that suggest that anything that goes on outside of the "content" area of the browser, and that does not actively engage the user, will be ignored by a huge percentage of users. There are many users who, anecdotal evidence shows, ignore all "chrome" completely and pay no attention to anything except "content". Because of the fact that good phishers always reproduce the desired content EXACTLY, users who ignore chrome and only examine content will ALWAYS be victims to phishers UNLESS we interrupt their view of the "content" with something that they must deal with when the site's credentials are "phishy". That's why warnings and clicks are different than all the other stuff you describe above. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Ian G wrote: >> On Thu, Jan 1, 2009 at 1:29 PM, Gervase Markham wrote: >>> Ian G wrote: My personal view of Mozilla is this: the ecosystem is developer-led. >>> But "the ecosystem" isn't our representative on the CAB Forum. Our >>> current representative is Johnathan Nightingale, our "Human Shield" and >>> security and user experience expert. > > So Jon goes to CAB Forum with a mandate to speak for the end-users, > without any input from Mozilla, the browser vendor? That's not what I said - where did you get that idea? Johnathan reads this forum, and I'm sure he takes on board all the input he receives. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
* Kyle Hamilton: > "Legitimate sites will never ask you for your credit card, national ID > number, or any other sensitive information after asking you to add an > exception." What about sites which use ActiveX? They ask for an exception, too. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Good question! On 3/1/09 06:43, Kyle Hamilton wrote: The only thing that we can do is make sure that the user has as much (relevant) information as possible. So what is the relevant info? My list of relevant info: the name of the CA [1] the name that the CA signs the previous acceptance status of the cert (e.g., number of visits <==> petnames). the absence of the above (e.g., we are in OFF mode) My list of irrelevant info: the cert details the warnings the clicks the status of the connection (e.g., padlock) All these are too complex for users. Others are encouraged to comment :) We can use our own experiences to identify what information is most relevant. We can even ask CPAs and attorneys (hello, Mozilla general counsel) what information is relevant, after providing them the list of information that is compiled. And we can ask users to help figure out how the information should be presented. Sure! This is a research programme that Mozilla could fund, and likely the security people would be happy to undertake. I would propose the following groups: * the security UI people * the legal / class action people * the finance people ... What we can do -- and all we can do -- is provide relevant information that the user can use to make her own decision. What we can't do is protect the user from the consequences of his own stupidity. Arguably, we shouldn't even try. This question turns on whether you want light grade security or high grade security. If you want high grade security, you should follow the learnings of the security world. That means: * all threats must be validated, not imagined * no absolutes exist * we need a steady stream of failures to inform us * the user must be part of the system * the system must be very simple * we are part of the system iang [1] Disclosure + reminder: this "position" of the CA's name substantially predates my current work with CAs. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 3/1/09 03:17, Nelson B Bolyard wrote: Ian G wrote, On 2009-01-02 01:28 PST: Lots of very small stores try to do the right thing and set up self-signed certs with their cousin or friend doing the website. They get their cousin or friend to set up a web site for them, because they don't know anything about web sites except that they must have one. Their cousin/friend tells them "Your choices are to either pay $1000 per year for a certificate or else let me make you a certificate for free." He does not tell them "you also have choices to get certs that will work in all browsers for less than $50/year", perhaps because he himself does not know that. Sure, there are thousands of stories. Once I did a very informal scan of credit card and FORM in google, and through some scratch calculations that something like 5% of merchants took credit card numbers through HTTP (unreliable, anecdotal number). Millions of stories :) Then they discover that nobody can use the site, the admin wants more money, [...] so they back off and use HTTP instead of HTTPS. Yes, I agree, that does happen. But the answer is not to use self-signed certs. It is to use cost effective CA issued certs. Unfortunately not. If that is the answer then we wouldn't permit self-signed certs at all. Old debate... We permit self-signed certs and we have forgotten to add convenient management of certs (KCM). But neither of us will win the debate today! "Please be aware that this website is not fully protected with third party claims by Certification Authorities. You may not be talking to who you think you are talking to, be careful to check in other ways. The problem with that is that the average user has NO IDEA WHATEVER of any way to verify who he is talking to than to look at the CONTENT of the site, and see if it looks like the content he expects from the real site. So, he does that, and thinks that he has "been careful", just as the suggested warning advises him, and he gets phished. It is probably an accepted fact that the user doesn't understand this OR ANY OTHER WORDS or any other actions that are required. The choice is between: a) including the user b) hiding it from the user Choose a or b. (And, consult your legal counsel about your choice.) Whatever you do, don't choose both. Right now, Mozilla is at both :) It includes the user sometimes (expects her to check the HTTPS display) but not other times (expects her not to do anything else). The choice between a and b probably rests on whether you want light security or strong security. If strong security, it has to be a., as from the discipline of security learnings, we know that the user is the end of an end-to-end security system. (c.f., Kerckhoffs 6th, Shamir's 3rd.) (Cunning thinkers of security will notice that Skype is clearly at b, and SSH is at a.) There are some (few) users who have become aware of the advice that they must check that the certificate belongs to the intended party, but they still have no concept of a MITM attack, so they look at the subject name in the self-signed cert, and see that it bears the name of the company they expect it to name, and they conclude that they have verified that the cert is correct and proper, and they get phished. Right. And some people who get phished by chrome replacements. And some people who get phished from a cert that is from "bank-security.com" or similar. And some people who get phished through CA issued certs. And some people get phished from XSS attacks. And some people get taken through malware. And some people get taken from nigerian 401 scams. And... The problem is one of economic balance in the face of false negatives and false positives, not of absolutes and static models. Either way, the people who get phished, after thinking that they've taken due care, conclude that there is no effective security on the internet. OK. That would be in accord with the security conclusions of any security team that worked through the full analysis in the late 90s when online banking was starting up [1]. The market over-rode their recommendations ... both at the micro level of each bank and the sector level of countries versus countries. So we would all be in agreement at that point. But they should conclude that there is no effective security on the internet WHEN YOU OVERRIDE the security precautions that were put there to protect them. We do not help them by further watering down the security warnings. Eyes off the microscope! The problem is a wider ecosystem or systemic problem in that the model only protects when the user checks the security precautions that are in place, on and perfectly in place. As the system has both OFF and ON modes, and as the system's ON mode is complicated to show, there is an obvious bypass attack. The result is that the ON community are working on making the ON button "new, brighter and better," the attack
Re: CABForum place in the world
On Fri, Jan 2, 2009 at 6:17 PM, Nelson B Bolyard wrote: > There are some (few) users who have become aware of the advice that they > must check that the certificate belongs to the intended party, but they > still have no concept of a MITM attack, so they look at the subject name > in the self-signed cert, and see that it bears the name of the company > they expect it to name, and they conclude that they have verified that > the cert is correct and proper, and they get phished. > > Either way, the people who get phished, after thinking that they've taken > due care, conclude that there is no effective security on the internet. > But they should conclude that there is no effective security on the > internet WHEN YOU OVERRIDE the security precautions that were put there > to protect them. We do not help them by further watering down the > security warnings. This is not a PEBKAC error, this is a PEBK (problem exists behind keyboard) error. The problem is this: we have all sorts of definitions of what technical operations can be done with keys (keyUsage), and the types of technical entities which are 'approved' to use them (web servers, web clients, etc -- eKU)... but there's absolutely nothing about what kind of *social* operations which can be done by any given entity which is authenticated by keys. We do not serve the interests of users by hiding the identity of the CA. We do not serve the interests of users by hiding the level to which a given CA is trusted (WebTrust versus WebTrust EV). We do not serve the interests of users by arbitrarily warning them about things which, if they apply the same level of due diligence that they would for non-Web interactions, would not pose a security threat. We do not serve the interests of users by spreading Fear, Uncertainty, and Doubt. The only thing that we can do is make sure that the user has as much (relevant) information as possible. We can use our own experiences to identify what information is most relevant. We can even ask CPAs and attorneys (hello, Mozilla general counsel) what information is relevant, after providing them the list of information that is compiled. And we can ask users to help figure out how the information should be presented. We can even state Mozilla's opinion of whether a given CA is trustworthy for financial or fiscal data protection (including governmental entities). What we can do -- and all we can do -- is provide relevant information that the user can use to make her own decision. What we can't do is protect the user from the consequences of his own stupidity. Arguably, we shouldn't even try. -Kyle H ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Ian G wrote, On 2009-01-02 01:28 PST: > Lots of very small stores try to do the right thing and set > up self-signed certs with their cousin or friend doing the website. They get their cousin or friend to set up a web site for them, because they don't know anything about web sites except that they must have one. Their cousin/friend tells them "Your choices are to either pay $1000 per year for a certificate or else let me make you a certificate for free." He does not tell them "you also have choices to get certs that will work in all browsers for less than $50/year", perhaps because he himself does not know that. > Then they discover that nobody can use the site, the admin wants more > money, [...] so they back off and use HTTP instead of HTTPS. Yes, I agree, that does happen. But the answer is not to use self-signed certs. It is to use cost effective CA issued certs. > "Please be aware that this website is not fully protected with third > party claims by Certification Authorities. You may not be talking to > who you think you are talking to, be careful to check in other ways. The problem with that is that the average user has NO IDEA WHATEVER of any way to verify who he is talking to than to look at the CONTENT of the site, and see if it looks like the content he expects from the real site. So, he does that, and thinks that he has "been careful", just as the suggested warning advises him, and he gets phished. There are some (few) users who have become aware of the advice that they must check that the certificate belongs to the intended party, but they still have no concept of a MITM attack, so they look at the subject name in the self-signed cert, and see that it bears the name of the company they expect it to name, and they conclude that they have verified that the cert is correct and proper, and they get phished. Either way, the people who get phished, after thinking that they've taken due care, conclude that there is no effective security on the internet. But they should conclude that there is no effective security on the internet WHEN YOU OVERRIDE the security precautions that were put there to protect them. We do not help them by further watering down the security warnings. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
"Legitimate sites will never ask you for your credit card, national ID
number, or any other sensitive information after asking you to add an
exception."
-Kyle H
On Fri, Jan 2, 2009 at 12:16 AM, Daniel Veditz wrote:
> Kyle Hamilton wrote:
>> ("legitimate sites will never ask you to add an exception" my ass.)
>
> If we shorten the phrase to
> "Legitimate banks and stores will not ask you to do this"
> would you not agree that is true enough as far as the average non-expert
> user need be concerned?
>
> The furor seems to be over the "and other public sites" bit, which I
> believe to be an attempt to cover things like government sites,
> charities and the like -- and as such that's pretty much still a true
> statement as well. Public, as opposed to private sites which might
> legitimately use a self-signed.
>
> Can you suggest better wording that would help our roughly 200 million
> users make the right choice?
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 2/1/09 09:16, Daniel Veditz wrote:
Kyle Hamilton wrote:
("legitimate sites will never ask you to add an exception" my ass.)
If we shorten the phrase to
"Legitimate banks and stores will not ask you to do this"
would you not agree that is true enough as far as the average non-expert
user need be concerned?
Not for me. Lots of very small stores try to do the right thing and set
up self-signed certs with their cousin or friend doing the website.
Then they discover that nobody can use the site, the admin wants more
money, and it's all pointless anyway ... so they back off and use HTTP
instead of HTTPS.
They are still legitimate, just small.
The giveaway clue is the word "legitimate". Whenever that is used in a
conversation, we can be sure that someone is trying to sell us something
without giving us the full picture. As a complete generalism, good
advertising does not use the word "legitimate" because real legitimacy
is self-evident or checkable or branded or somehow subject to real feedback.
The furor seems to be over the "and other public sites" bit, which I
believe to be an attempt to cover things like government sites,
charities and the like -- and as such that's pretty much still a true
statement as well. Public, as opposed to private sites which might
legitimately use a self-signed.
Can you suggest better wording that would help our roughly 200 million
users make the right choice?
How about:
"Please be aware that this website is not fully protected with third
party claims by Certification Authorities. You may not be talking to
who you think you are talking to, be careful to check in other ways. We
support the rights of smaller websites to use cryptography, but this
carries additional risks."
iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 1/1/09 22:34, Gervase Markham wrote: Ian G wrote: 2. In general, such a group will reject any proposal that appears to favour one member against another; but they will accept any proposal that requires the same amount of additional work, and increases the power of the group. In other words, rejection of internal competition, promotion of joint franchise power. Not necessarily. For example, EV could have been said to favour larger CAs (who are able to offer a global service), and CAs which already had the infrastructure in place for doing detailed identity vetting. Yet it was approved. Well, first point is that it is a model in economics. How each instance deals with the ramifications of the model does vary. 2nd point would be that, within the model again, the larger players try and cartelise within the cartel. The study of these groupings is literally the study for market power, so all sorts of games go on. Instead they need to find a strategy that provides for joint and individual benefit, in exchange for the work. Commonly, this is (a) create a brand, (b) sell the brand, (c) compete against other brands, and (d) deny the brand to non-members. This achieves both group benefit and individual membership. Well, if you are seeing EV as a brand, then in this case there aren't really other brands to compete against, Yes, indeed, in this particular case. But, consider the next bunch of guys who come along and want something like a different colour... and they can't deny the brand to non-members, because anyone can take the audits The key thing here is that the CAB Forum asserts its brand, or can assert its brand, or can do whatever it likes. This is "business code" for "its ours" and most serious business people will realise the message within. If the CAB Forum were serious about anyone using it, they would have a regime listed for non-members to use it; and clear and free licences, like open source. The fact that they don't says "treat as owned." Also, "anyone can take the audits" is an odd way of looking at an open process. and anyway, EV status is in the gift of the browser manufacturers, not the forum. Well, unless that is stated in a fairly serious fashion, no serious business person or lawyer would take that at face value. I'd like to see the open licence for it! 4. What is notable about the above is that at no time or place is the user or purchaser necessarily brought into the basic structural economics. This is why (the theory predicts that) such associations deliver so little to the *user* in comparison to the relatively large benefit to the incumbents; the economics doesn't require it, and in fact the economics fights against it, because to share any bounty with the users adds more complications for the model. Of course. Hence, marketing is a strong component of all such associations, because there is a strong need for perception. Except that the CAB Forum does no marketing. Well, all virtual entities do nothing, you can't shake hands with Mozilla either. Their members do something on behalf. Some member runs the website and another member writes the text of the PR, and yet another member writes emails on lists defending the actions of the group, and absorbing and neutralising criticisms. That's marketing! 10. I speak as an interested party of course. My biases are all the more poignant because the CABForum and its members and criteria directly and explicitly rule out the activities of myself as an auditor and the CA I audit. C.f., to join CABForum, you must have a WebTrust audit; Not so; there is a list of acceptable audit criteria. It includes ETSI. Right, WebTrust or ETSI. To be clear, I haven't looked at ETSI. However this does not materially change what I wrote. But, having commented on those errors of fact, I can't quite see what you are saying apart from "industry standards bodies are bad". Is that it? Your question was something like "what is this overwork trap?" I think To the bare minimum, it would be something like: Forums that have no buyer representation will naturally tend to increase the price at the expense of the buyers. This can be shown in various economic ways as their likely incentives (c.f., game theory, etc). This goes on until something breaks. E.g., financial markets or meltdown or a competitive break through like p2p. So in analysing the CABForum's place in the commercial world, or any similar organisation, we would have to ask why they don't include buyer representation. Why they include the vendors is obvious; they need the "gift" you speak of. But the vendors aren't the buyers. In analysing CABForum's place in the open source and Internet world, we would have to ask, why aren't they open? It worked for us, why are they so different? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.
Re: CABForum place in the world
Kyle Hamilton wrote:
> ("legitimate sites will never ask you to add an exception" my ass.)
If we shorten the phrase to
"Legitimate banks and stores will not ask you to do this"
would you not agree that is true enough as far as the average non-expert
user need be concerned?
The furor seems to be over the "and other public sites" bit, which I
believe to be an attempt to cover things like government sites,
charities and the like -- and as such that's pretty much still a true
statement as well. Public, as opposed to private sites which might
legitimately use a self-signed.
Can you suggest better wording that would help our roughly 200 million
users make the right choice?
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 2/1/09 03:44, Kyle Hamilton wrote: If he's a security and user interface expert, why is the security UI so appallingly *bad*? Not answering for gerv, but I would say: he is the human shield, against all influences, inside and outside! He's only one guy, and he has the entire battle field to deal with. Every time he moves to the left, the right mobs him. Every time he moves to the right, the left undermines him. The result is bad, but it isn't his fault, it's the fault of the situation he is in. However, at least we have a result! Before he was there, the only thing we had was random experimentation (like Gerv's much missed yellow bar) and corporate denial of the issue. On Thu, Jan 1, 2009 at 1:29 PM, Gervase Markham wrote: Ian G wrote: My personal view of Mozilla is this: the ecosystem is developer-led. But "the ecosystem" isn't our representative on the CAB Forum. Our current representative is Johnathan Nightingale, our "Human Shield" and security and user experience expert. So Jon goes to CAB Forum with a mandate to speak for the end-users, without any input from Mozilla, the browser vendor? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 1/1/09 6:44 PM, Kyle Hamilton wrote: If he's a security and user interface expert, why is the security UI so appallingly *bad*? *plonk* Justin ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Industry standards bodies are bad, when they shut out input the people
who they're supposed to be benefitting. (Who are, really, the
ultimate stakeholders.)
A perfect example (outside of the current debate) is the Bluetooth
consortium. I, as an individual developer and researcher, can't get
access to the protocol specifications since they restrict those to the
membership, and the membership to accredited organizations (which
appears to be schools for research and corporations for development).
I realize that it sounds like a "wah, why not me?" argument, but part
of the reason the Internet actually works is because the standards are
freely available to the public. Without the IETF and the IETF
meetings, would we be able to have this conversation?
In this case, the CAs and browsers are colluding to make things easier
for themselves... without looking at what's happening in the real
world. The CA/B forum is closed to people who want to have a dialogue
with the browser vendors about concepts of CAs that don't involve
WebTrust/ETSI requirements simply because they don't have any reason
to provide financial levels of identity -- and so, the browser vendors
are given the impression that *only* WebTrust/ETSI matters.
This leads to situations like we currently have, where the barrier of
"security roadblocks" is so high that nobody can educate their users
what they're doing when they're clicking various buttons in the UI.
("legitimate sites will never ask you to add an exception" my ass.)
-Kyle H
On Thu, Jan 1, 2009 at 1:34 PM, Gervase Markham wrote:
>
> But, having commented on those errors of fact, I can't quite see what
> you are saying apart from "industry standards bodies are bad". Is that it?
>
> Gerv
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
If he's a security and user interface expert, why is the security UI so appallingly *bad*? -Kyle H On Thu, Jan 1, 2009 at 1:29 PM, Gervase Markham wrote: > Ian G wrote: >> My personal view of Mozilla is this: the ecosystem is developer-led. > > But "the ecosystem" isn't our representative on the CAB Forum. Our > current representative is Johnathan Nightingale, our "Human Shield" and > security and user experience expert. > > Gerv > ___ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Ian G wrote: > 2. In general, such a group will reject any proposal that appears to > favour one member against another; but they will accept any proposal > that requires the same amount of additional work, and increases the > power of the group. In other words, rejection of internal competition, > promotion of joint franchise power. Not necessarily. For example, EV could have been said to favour larger CAs (who are able to offer a global service), and CAs which already had the infrastructure in place for doing detailed identity vetting. Yet it was approved. > Instead they need to find a strategy that provides for joint and > individual benefit, in exchange for the work. Commonly, this is (a) > create a brand, (b) sell the brand, (c) compete against other brands, > and (d) deny the brand to non-members. This achieves both group benefit > and individual membership. Well, if you are seeing EV as a brand, then in this case there aren't really other brands to compete against, and they can't deny the brand to non-members, because anyone can take the audits and anyway, EV status is in the gift of the browser manufacturers, not the forum. > 4. What is notable about the above is that at no time or place is the > user or purchaser necessarily brought into the basic structural > economics. This is why (the theory predicts that) such associations > deliver so little to the *user* in comparison to the relatively large > benefit to the incumbents; the economics doesn't require it, and in > fact the economics fights against it, because to share any bounty with > the users adds more complications for the model. Of course. Hence, > marketing is a strong component of all such associations, because there > is a strong need for perception. Except that the CAB Forum does no marketing. > 10. I speak as an interested party of course. My biases are all the > more poignant because the CABForum and its members and criteria directly > and explicitly rule out the activities of myself as an auditor and the > CA I audit. C.f., to join CABForum, you must have a WebTrust audit; Not so; there is a list of acceptable audit criteria. It includes ETSI. But, having commented on those errors of fact, I can't quite see what you are saying apart from "industry standards bodies are bad". Is that it? Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Ian G wrote: > My personal view of Mozilla is this: the ecosystem is developer-led. But "the ecosystem" isn't our representative on the CAB Forum. Our current representative is Johnathan Nightingale, our "Human Shield" and security and user experience expert. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 30/12/08 23:25, Gervase Markham wrote: Ian G wrote: ... nor to resist the trap of increasing work loads and complexity, and reducing availability and delivered security. I am having trouble extracting meaning from that last sentence. In mostly general terms: 1. When any industry group of peers forms, they will be thinking of how they work as a model, what the representative member does, and how it makes money. They will as a group reject any project that reduces their own overall apparent position. They will as a group favour any proposal that increases their own overall position. 2. In general, such a group will reject any proposal that appears to favour one member against another; but they will accept any proposal that requires the same amount of additional work, and increases the power of the group. In other words, rejection of internal competition, promotion of joint franchise power. 3. Because of the game theory that goes on here, they are likely to adopt unified proposals that accept more work, as long as the result is an increase in the power of the group *and* they all benefit individually. So for example, we can conclude that the group would not simply document the standard and insist that everyone follow it, because that creates only downside for them, individually and as a group. That is, more work, not necessarily any more sales. Instead they need to find a strategy that provides for joint and individual benefit, in exchange for the work. Commonly, this is (a) create a brand, (b) sell the brand, (c) compete against other brands, and (d) deny the brand to non-members. This achieves both group benefit and individual membership. 4. What is notable about the above is that at no time or place is the user or purchaser necessarily brought into the basic structural economics. This is why (the theory predicts that) such associations deliver so little to the *user* in comparison to the relatively large benefit to the incumbents; the economics doesn't require it, and in fact the economics fights against it, because to share any bounty with the users adds more complications for the model. Of course. Hence, marketing is a strong component of all such associations, because there is a strong need for perception. 5. Hence: *any association of one sector alone* is considered to be an "anti-trust" issue on the face of it. The economics are clearly against the interests of other parties. I know some will find this offensive; I can only stress that this is well known and standard in the regulatory field, where serious money is on the table, and the regulators can afford to employ economists who look at these structures. 6. This structure then is widely rejected where competition works to regularly surface solutions (and standards come after competitive success). It only tends to work where there are network effects, such as found in the Internet. However, this doesn't change the economics, it just creates a counterbalancing benefit that overweighs the losses, at some point. 7. Once in place and powerful, there is then the obvious trap. Work and complexity will increase. As a result, or perhaps as the point, the cost rises to the end-user. Which necessarily raises the bar for delivery of the product, which means less people get them, and smaller competitors are forced out [1]. Applying to certs, unless each higher-priced product pays off in increased protection, there is a reduction in overall security. This is fairly simple maths, and it applies right now because we still live in times where the difference between the alternates is practically negligable (notwithstanding marketing etc). It would change dramatically if we saw actual damages. (E.g., Mozilla is absolutely right to insist on continued delivery of the bottem-end certs, for this reason.) 8. So there are two clear challenges for any association of suppliers, where the peers might act against the interests of their buyers: a. One is to address the anti-trust economics equation. One simple mistake: Words and marketing don't do it, except in rare circumstances (e.g., notably for students of anti-trust, diamonds / de Beers is the classic case). For normal goods, words are not enough. Actions are needed, e.g.: * totally open membership * totally open forum discussions * buyer voice in decisions. * create partnerships with the buyer organisations. * testable mission statements. b. A second is to avoid the trap of overwork. Think of it like a drug; the work increases, the short term benefits improve for the *incumbents*, so everything is good. We can do that again and again, and will do so, the more power we have. However at some stage the system breaks. For example, if we look at Sarbanes-Oxley and other increased audit regimes popular over the last decade, they have basically killed the foreign IPO mar
Re: CABForum place in the world
On 30/12/08 23:25, Gervase Markham wrote: Ian G wrote: A tightly closed membership, oriented to CAs in their chosen segment. As CAs, they incline towards including two other groups, being the upstream audit organisations who provide the WebTrust, and the downstream browsers who consume the WebTrust. Which is not unexpected. A group concerned with CA certificates will have members who provide the certificates, and members who consume them. (Browser vendors - they use them to provide trust indicators or other user interface to their users.) However, they include no other stakeholder groups. Of especial concern, nobody who speaks for the end-user, even though they clearly intend as a group to sell to these end-users. Certainly not selling "as a group" - several CAs are very touchy about anti-trust. :-) Certainly they will say that in words :) We (the browser vendors) like to think we speak for the end users. We all like to think it, but it is harder than we think :) We all generally speak for our own interests. For e.g., Microsoft, it is revenues (and to their credit, they state that in the CA policy directly). My personal view of Mozilla is this: the ecosystem is developer-led. When Mozilla speaks, it is for the developer, or as a developer speaking. It has a great deal of difficulty thinking outside the developer box. There are quite a few positive points which improve this situation, and Mozilla has been working for a couple of years to deal with the bias: a good set of managers who aren't developers; a mission that clearly identifies the end-user, a vocal community. These are good starts, but my view is that Mozilla speaks as developers, and not for the end-user. Others will no doubt speak about how they view me :) Even I find it hard to disentangle the unclear interests in my person: CAcert, audits, security, end-users, architecture, finance, world peace.. Given such a structure, it is hard to see how they can avoid the fate of protecting the franchise. Although I'm sure they do careful work in documenting the current thinking, OK so far, probably. EV guidelines is a good documentation. it is not reasonable to expect them to do new thinking and to think about the new threat environment, This bit should be clear; no CA can change the security environment of PKI (Verisign was trying to do it for years, trying the same things as I talk about and other security people talk about, but the structure doesn't support change). nor to resist the trap of increasing work loads and complexity, and reducing availability and delivered security. I am having trouble extracting meaning from that last sentence. Yes, sorry, I was drifting into cartel and game theory. This is the standard approach in economics to analysing associations, forums, etc. Consider OPEC as an example. I know this is controversial in this audience (developers and CAs), all I can say is, the approach is totally standard in economics and other places where they think anti-trust thoughts. See other mail for long explanation, sliced off for convenience. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
Ian G wrote: > A tightly closed membership, oriented to CAs in their chosen segment. As > CAs, they incline towards including two other groups, being the upstream > audit organisations who provide the WebTrust, and the downstream > browsers who consume the WebTrust. Which is not unexpected. A group concerned with CA certificates will have members who provide the certificates, and members who consume them. (Browser vendors - they use them to provide trust indicators or other user interface to their users.) > However, they include no other stakeholder groups. Of especial concern, > nobody who speaks for the end-user, even though they clearly intend as a > group to sell to these end-users. Certainly not selling "as a group" - several CAs are very touchy about anti-trust. :-) We (the browser vendors) like to think we speak for the end users. > Given such a structure, it is hard to see how they can avoid the fate of > protecting the franchise. Although I'm sure they do careful work in > documenting the current thinking, it is not reasonable to expect them to > do new thinking and to think about the new threat environment, nor to > resist the trap of increasing work loads and complexity, and reducing > availability and delivered security. I am having trouble extracting meaning from that last sentence. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
CABForum place in the world (was: words from comodo)
On 30/12/08 04:22, Nelson B Bolyard wrote: Ian G wrote, On 2008-12-29 16:59: As far as I heard, the CABForum was also formed or inspired from a similar group of vendors (browsers) that got together at the invite of the Konqueror guy to talk about phishing one day ... I think Mozilla's own Mr. Gervase Markham had something to do with the transformation of the CA Forum into the CAB Forum. Maybe he can tell us something of that history. (Could be! We should be careful of the history, thought. It is really only mildly interesting for serious students of how things came to pass. Such things tend to be a distraction to how things are, now, today. I am guilty of that same mistake...) Question for now: is the CABForum still a closed group? My understanding is that CAB Forum is a membership organization, with specific qualifications for members. The qualifications are published http://cabforum.org/forum.html (bottom of page). There is no membership fee (AFAIK), but members seem to be expected to take turns hosting the Forum's periodic face-to-face meetings. Ah, thanks for posting that link. CABForum has 33 CAs and 5 vendors. * Issuing CA:- The member organization operates a certification authority that has a current and successful WebTrust for CAs audit, or ETSI 102042 or ETSI 101456 audit report prepared by a properly-qualified auditor, and that actively issues certificates to Web servers that are openly accessible from the Internet using any one of the mainstream browsers. * Root CA:- The member organization operates a certification authority that has a current and successful WebTrust for CAs, or ETSI 102042 or ETSI 101456 audit report prepared by a properly-qualified auditor, and that actively issues certificates to subordinate CAs that, in turn, actively issue certificates to Web servers that are openly accessible from the Internet using any one of the mainstream browsers. * Browser:- The member organization produces a software product intended for use by the general public for browsing the Web securely. AND In addition to the above entities, members of the Information Security Committee of the American Bar Association Section of Science & Technology Law and the Canadian Institute of Chartered Accountants have participated in developing the standards for Extended Validation SSL certificate procedures and standards. My thoughts only (but note that as I am part of the excluded peoples, these words should be treated as potentially biased): A tightly closed membership, oriented to CAs in their chosen segment. As CAs, they incline towards including two other groups, being the upstream audit organisations who provide the WebTrust, and the downstream browsers who consume the WebTrust. However, they include no other stakeholder groups. Of especial concern, nobody who speaks for the end-user, even though they clearly intend as a group to sell to these end-users. Given such a structure, it is hard to see how they can avoid the fate of protecting the franchise. Although I'm sure they do careful work in documenting the current thinking, it is not reasonable to expect them to do new thinking and to think about the new threat environment, nor to resist the trap of increasing work loads and complexity, and reducing availability and delivered security. Relying parties should not look to them for that. Old chinese curse: be careful what you wish for. iang [1] For further info, check their mission and their mailing lists for open discussion and open subscription. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
