Draft 11 of CA certificate policy
Frank Hecker
find it at the usual place:
http://www.hecker.org/mozilla/ca-certificate-policy
Major changes in the draft are as follows (in order of occurrence in the
document):
* Strengthened the language in paragraph 4 to cover rejecting CA
requests if we believe it's appropriate to do so.
* Modified paragraph 6 to add requirements relating to verification of
certificate signing requests.
* Added a new paragraph 7 to describe minimum verification requirements
for each type of certificate. (Renumbered succeeding paragraphs
accordingly.) The requirements are as I've outlined them previously.
* Added a new paragraph 14 noting that the Mozilla Foundation will
designate someone to handle CA requests. I used the term "module owner"
rather than "CA coordinator" as suggested by Ian G for consistency with
terminology used elsewhere in the Mozilla project.
As always, comments, questions, and suggested changes are welcome. The
changes in this draft were primarily intended to address putting a
minimum "floor" in place regarding requirements on CA, particularly for
audit regimes like WebTrust where some have contended that no such floor
is actually present. (Note that I added language regarding authorized
agents, as previously promised.)
I've previously explained my reasons for choosing the particular
requirements I've included, so I won't repeat those comments here. I
realize that some may see the language regarding "reasonable measures"
as unnecessarily subjective, however I don't want to try to anticipate
(and more important, provide policy language for) all the different ways
in which CAs might vet subscribers. I'll include examples and additional
guidance on this subject in the policy details FAQ.
"Hope springs eternal...", as they say, but I really do believe that
this draft (or something very close to it) is suitable for submission to
the Mozilla Foundation for consideration as a 1.0 policy. If you
strongly object please let me know.
Frank
--
Frank Hecker
hec...@hecker.org
Frank Hecker
> I've done a new draft 11 of the proposed CA certificate policy; you can
> find it at the usual place:
>
> http://www.hecker.org/mozilla/ca-certificate-policy
My apologies, I forgot to add a diff listing of the detailed changes
from draft 10 to draft 11; please see the attached file.
Nelson B
> <p>This is the official Mozilla Foundation policy for CA certificates
> -that it distributes with its software products:</p>
> +that we distributes with our software products:</p>
"we distributes" reminds me of the old Popeye cartoons. :)
Popeye talked like that.
Two questions about this draft:
1. Does this floor address the "Click Yes to continue" phenomenon?
Should it?
2. Recently I encountered an SSL server cert from a low-assurance CA
in which the cert's entire subject name consisted of the
"Common Name" which was the server's domain name. There was no other
information at all about the person/organization behind that cert.
That seems like something mozilla's policy ought to address in its floor.
IMO, that's not good enough for an SSL CA in mozilla's CA list. Agreed?
--
Nelson B
Frank Hecker
> Frank Hecker wrote:
>
> > <p>This is the official Mozilla Foundation policy for CA certificates
> > -that it distributes with its software products:</p>
> > +that we distributes with our software products:</p>
>
> "we distributes" reminds me of the old Popeye cartoons. :)
> Popeye talked like that.
OK, ok, you know I'm *usually* pretty good about keeping typos out of
these drafts :-)
> Two questions about this draft:
>
> 1. Does this floor address the "Click Yes to continue" phenomenon?
> Should it?
I'm guessing you mean what was previously discussed about misleading
names in certs, in object signing certs in particular IIRC. I'm hesitant
to try to craft policy language on this; exactly how would one
"legislate" against this particular practice?
> 2. Recently I encountered an SSL server cert from a low-assurance CA
> in which the cert's entire subject name consisted of the
> "Common Name" which was the server's domain name. There was no other
> information at all about the person/organization behind that cert.
> That seems like something mozilla's policy ought to address in its floor.
> IMO, that's not good enough for an SSL CA in mozilla's CA list. Agreed?
No, I respectfully disgree: IMO this is a legitimate use case. If the
domain in the cert matches the domain as requested, and if the CA has
verified that the "cert owner" is the same as the "domain owner", then
the basic anti-phishing protection has been provided. Beyond that one
might justify additional identity verification using something like
Gerv's argument ("we need names and addresses so we can track down
phishers and hold them accountable"), but IMO this is likely to be
ineffective in practice against real phishers (due to the relative ease
of creating fraudulent ID documents) and imposes verification
requirements (and consequent costs) that are arguably overkill for
various legitimate use cases involving SSL server certs (e.g.,
password-protected "friends and family" personal sites).
What I included in the draft policy is meant to be a true "floor", i.e.,
absolutely minimum requirements that are compatible with all possible
legitimate use cases. The policy is not meant as a "best practices"
recommendation.
Ian G
> "Hope springs eternal...", as they say, but I really do believe that
> this draft (or something very close to it) is suitable for submission
> to the Mozilla Foundation for consideration as a 1.0 policy. If you
> strongly object please let me know.
Looks good to me!
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Ian G
> Frank Hecker wrote:
>
> > <p>This is the official Mozilla Foundation policy for CA certificates
> > -that it distributes with its software products:</p>
> > +that we distributes with our software products:</p>
>
> "we distributes" reminds me of the old Popeye cartoons. :)
> Popeye talked like that.
>
> Two questions about this draft:
>
> 1. Does this floor address the "Click Yes to continue" phenomenon?
> Should it?
That's a thorny issue. The company's name was indeed
that, in Canada. In that case, as the company's name,
there is a well established precedent to use that name.
In company naming there are a few things you can't do,
such as use rude words and use others' names. Also,
most countries have restrictions on the national labels.
But using a branding or advertising slogan is fine. Using
a common expression is fine - as long as nobody got their
first.
At the extreme, "Click Yes to continue" would even have a
plausible complaint against any company that declined
to accept its name!
Which is not to say that I think it's right or wrong, but
that dealing with this issue in policy terms is real tough.
> 2. Recently I encountered an SSL server cert from a low-assurance CA
> in which the cert's entire subject name consisted of the
> "Common Name" which was the server's domain name. There was no other
> information at all about the person/organization behind that cert.
> That seems like something mozilla's policy ought to address in its floor.
> IMO, that's not good enough for an SSL CA in mozilla's CA list. Agreed?
>
My perspective on this is taken from years of doing
issuance contracts in an unregulated field. The
natural tendency is to expect there to be a standard
and for everyone to follow it. But in practice, there
often isn't much of a standard, and that which is
there isn't of any help; in fact in terms of addressing
fraud, most standards hinder more than they help.
In order to address this, I developed a simple rule:
tell the truth. Everything that was written into a
contract should be the truth. The digital signature
should attest to that. Now, this might seem quite
basic, but I had a lot of trouble getting people to
follow this rule in writing contracts... in contrast,
there was rarely any problem with readers of
contracts. As soon as they read the document,
the knew when things were missing, in general.
So as long as whatever is in that cert is the truth,
I don't see an issue. That's just me, tho!
Nelson B
> My perspective on this is taken from years of doing
> issuance contracts in an unregulated field. The
What is an issuance contract? (just curious)
> In order to address this, I developed a simple rule:
> tell the truth. Everything that was written into a
> contract should be the truth. The digital signature
> should attest to that.
> So as long as whatever is in that cert is the truth,
> I don't see an issue. That's just me, tho!
Ian, You're the anti-phisher guy. I would expect you to want
certs to contain more info to help fight phishing. Just how does
a cert that contains only CN=pay.pal.com help avoid phishing?
--
Nelson B
Frank Hecker
> Ian, You're the anti-phisher guy. I would expect you to want
> certs to contain more info to help fight phishing. Just how does
> a cert that contains only CN=pay.pal.com help avoid phishing?
Not to speak for Ian, but it permits the basic check that Gerv recommends:
http://www.gerv.net/security/stay-safe/
assuming of course that the user can recognize that "pay.pal.com" !=
"paypal.com". And if they can't recognize that, I doubt very much
they're going to be clicking on the lock and checking the information in
the cert.
So the question is, what is the purpose of the O and OU information in
SSL certs? If the values of these fields are not exposed in the standard
browser interface by default then it seems to me that (unlike CN) they
have minimal or no relevance when it comes to protecting the security of
typical users.
Frank Hecker
<comments on usefulness of SSL cert info beyond CN snipped>
Incidentally, I want to correct a possible misapprehension that might
arise from my comments here and elsewhere:
I am quite interested in seeing Firefox, Thunderbird, and our other
products implement effective anti-phishing strategies. I just don't
think that the SSL protocol and the CA infrastructure can bear all or
even most of the burden of protecting users from phishing. I think basic
SSL checks related to domain name have to be supplemented and
coordinated with other measures, which might include site blacklists,
automated comparisons of site names with a whitelist of common phishing
targets, and other heuristics designed to present the user with a
qualified determination that "yes, this site is likely legitimate" or
"no, it's no legitimate".
I would compare the role of PKI in the context of web site phishing
attacks to the role of Sender Policy Framework (SPF) and related schemes
in preventing spam: Neither are complete solutions (although often
touted as such in a "marketing" context) but rather must be supplemented
by other measures, and both impose costs that have the potential to
negatively impact perfectly legitimate use cases.
Gervase Markham
> I am quite interested in seeing Firefox, Thunderbird, and our other
> products implement effective anti-phishing strategies. I just don't
> think that the SSL protocol and the CA infrastructure can bear all or
> even most of the burden of protecting users from phishing. I think basic
> SSL checks related to domain name have to be supplemented and
> coordinated with other measures, which might include site blacklists,
> automated comparisons of site names with a whitelist of common phishing
> targets, and other heuristics designed to present the user with a
> qualified determination that "yes, this site is likely legitimate" or
> "no, it's no legitimate".
Just in case anyone was wondering, I'd endorse all of those principles
and most of those practices (except perhaps the "common phishing"
whitelist; I think we can do better).
Gerv
Ian G
> Ian G wrote:
>
>> My perspective on this is taken from years of doing
>> issuance contracts in an unregulated field. The
>
>
> What is an issuance contract? (just curious)
A contract for issuance of value. There is a contract
underlying Paypal's money for example, but they way
they do things is pretty ropey, they change their
contract every time some old lady phones up and
complains. E-gold is another issuance, and famously,
in late 2000, they changed their contract of issuance
from "you own the gold" to "you don't own the gold..."
In brief, take a contract, stick a few program-readable
terms in there, cleartext sign it, and then hash it. The
hash becomes the identifier for the units of issue, and
the accounting system manages hashs. By this means,
people have issued dollars, gold and other units, and
then run payment systems denominated in these units.
The benefit of doing it this way is that the contract
is fairly shared between the user and the issuer, and
the issuer can't arbitrarily change the contract without
breaking the accounting and every payment that was
ever made. The hash for my dollar contract is:
SHA:e3b445c2a6d82df81ef46b54d386da23ce8f3775
and that SHA1 hash is bound into every signed payment
and signed receipt, so the contract is set in stone.
http://www.webfunds.org/ricardo/contracts/systemics/
http://www.webfunds.org/ricardo/contracts/webfunds/
Is a couple of pages of issuance contracts. The second
group are 'toys' and the first group are 'real' But the
same rule applies; if you hold some units of the toy
contracts, the issuers are bound to follow them. If
you mail them you'll find they take their responsibilities
seriously, I hope :-)
>> In order to address this, I developed a simple rule:
>> tell the truth. Everything that was written into a
>> contract should be the truth. The digital signature
>> should attest to that.
>
>
>> So as long as whatever is in that cert is the truth,
>> I don't see an issue. That's just me, tho!
>
>
> Ian, You're the anti-phisher guy. I would expect you to want
> certs to contain more info to help fight phishing. Just how does
> a cert that contains only CN=pay.pal.com help avoid phishing?
>
The only value in a cert is provided by the CAs
willingness to sign it. If the CA signs on a
CN=pay.pal.com then that's the only value
that is there!
It matters not whether the additional info is
in there. There could be addresses, phone
numbers, there could be corporate numbers
and even the attorney's name. But in the real
world of hard and crooked commerce, the
question is not what info is there, but what
the CA was willing to sign off on.
In this sense, forcing more information into
the cert actually does the reverse of what you
want; it creates a false sense of security based
on the presence of additional uncertain info.
Making rules and insisting on CAs following
standards raises costs for honest cert owners,
and it lowers security for honest relying parties,
*if* they are fooled by the extra info.
The most important thing is *which CA*. After
that, the 2nd most important thing is which
root cert was used, because that tells the user
what level of assurance that CA was promising.
Finally, once the user establishes the reliability
of the cert, she can factor that in to whether
she hands over her credit card to no-risk-porn.com
as signed by the Gambino CA, or whether she
decides to go with something signed off on by
VeriSign or QuoVadis or etc etc.
Ian G
> Nelson B wrote:
>
>> Ian, You're the anti-phisher guy. I would expect you to want
>> certs to contain more info to help fight phishing. Just how does
>> a cert that contains only CN=pay.pal.com help avoid phishing?
>
>
> Not to speak for Ian, but it permits the basic check that Gerv
> recommends:
>
> http://www.gerv.net/security/stay-safe/
Ha! I didn't know about that page... excellent,
it rounds out the Top Tips on Security on my
blog. Added, thanks.
> assuming of course that the user can recognize that "pay.pal.com" !=
> "paypal.com". And if they can't recognize that, I doubt very much
> they're going to be clicking on the lock and checking the information
> in the cert.
Right. The only security for the average user is
what is displayed - and this is why the Amir&Ahmad
trustbar displays logos. The average user can get
a very very quick security impression from a logo
of Verisign, and can ally that to a logo of Paypal,
both of which are secured by the browser.
(I'm hoping that in the interim Gervase or someone
will add the name of the CA on to that little status
bar thing.)
Has anyone looked at the new Opera browser? I
saw the press release about their anti-phishing
SSL cert display, but I don't have a copy myself.
> So the question is, what is the purpose of the O and OU information in
> SSL certs? If the values of these fields are not exposed in the
> standard browser interface by default then it seems to me that (unlike
> CN) they have minimal or no relevance when it comes to protecting the
> security of typical users.
Right. The obvious thing is to display them. But
then we run into 'too much information." So what
are the essentials?
For me, the domain name and the CA (and the root
cert if more than one).
After that, a petname or a logo approach would be
fantastic, because if a user knows the site and needs
more security, she can make a small quick decision
on that basis, and she can use all the info in the cert
for that decision, if it helps.
Gervase Markham
> Ha! I didn't know about that page... excellent,
> it rounds out the Top Tips on Security on my
> blog. Added, thanks.
I currently think it's mostly true - it's certainly good advice.
However, we may be changing that spec for 1.1.
> (I'm hoping that in the interim Gervase or someone
> will add the name of the CA on to that little status
> bar thing.)
I've been thinking about this. Say we did add the name. Say some company
screwed up, and got a bad reputation. Say lots of other sites changed to
buy certs from someone else. Wouldn't that cause a lot of false
concerns? "Hang on a minute, I think this is ebay.com, but ebay.com are
signed by USERTRUST, and this site is signed by Verisign...". (Let's
leave aside for a minute that my Grandfather couldn't think like that in
a million years.)
We're back onto an issue that I think we've discussed before - how does
the user benefit from having the CA name there? If they want to visit a
particular shop, they have a choice of doing so while protected by
SUPERTRUST, or not at all. They can't say "Hmm, I don't trust
SUPERTRUST, I want Verisign to protect me."
In the absence of even the ability (never mind the understanding and the
will) to make that choice, I'm not convinced that adding the CA name is
worth the real estate and added UI complexity.
> Has anyone looked at the new Opera browser? I
> saw the press release about their anti-phishing
> SSL cert display, but I don't have a copy myself.
I hope to soon.
Gerv
Ian G
> Ian G wrote:
>
>> Ha! I didn't know about that page... excellent,
>> it rounds out the Top Tips on Security on my
>> blog. Added, thanks.
>
>
> I currently think it's mostly true - it's certainly good advice.
> However, we may be changing that spec for 1.1.
>
>> (I'm hoping that in the interim Gervase or someone
>> will add the name of the CA on to that little status
>> bar thing.)
>
>
> I've been thinking about this. Say we did add the name. Say some
> company screwed up, and got a bad reputation. Say lots of other sites
> changed to buy certs from someone else. Wouldn't that cause a lot of
> false concerns? "Hang on a minute, I think this is ebay.com, but
> ebay.com are signed by USERTRUST, and this site is signed by
> Verisign...". (Let's leave aside for a minute that my Grandfather
> couldn't think like that in a million years.)
Well, for a start, think it through. Most sites will not
change their certs. Only a few will actually waste the
remaining time .. until renewal. But some will; and
these some will cause the pressure on the company.
New companies will go somewhere else, as the scandal
is fresh in mind. That's the pressure we want.
Secondly, what you are pointing at is a *derivative*
problem. The primary problem is that the CA issued
a duff cert. How do you solve that? Well, there has
to be some pain somewhere, and the closer it is to
the users, the more likely the pain will actually respond
to user security needs. So, yes, some users are
going to have some pain. That's part of the process.
Thirdly, your grandfather could think like that, and
probably does - ask him what car brands he knows.
Then ask him if he knows anyone who buys Ford
every time ... and ask him what would happen if
he saw the guy go and buy a renault or a seat?
Fourthly, what exactly are you saying in terms of not
showing the cert? Are you saying that you believe that
when a company screws up, it should be dealt with
behind the scenes? That the users shouldn't know
that UserBust is continuing to issue duff certs, and
it is stuck in the root list of 90% of issued product?
> We're back onto an issue that I think we've discussed before - how
> does the user benefit from having the CA name there? If they want to
> visit a particular shop, they have a choice of doing so while
> protected by SUPERTRUST, or not at all. They can't say "Hmm, I don't
> trust SUPERTRUST, I want Verisign to protect me."
Right. But, bear in mind - their relationship with
their site is far greater than with any CA. What
happens is if the site is an online bank, they decide
they want one or two or three CAs. If it is a record
shop, then maybe half a dozen. If it is an online mail
service, then *any* cert will do.
Somebody's going to establish themselves as the
"safe enough for online banking" CA. Others will
dominate the mail space. Yet others will concentrate
on small internal sites.
Users are capable of analysing what it means to
use a recognised cert and and when not to. They
just have to be given the chance, and get comfortable,
make a few mistakes, etc.
> In the absence of even the ability (never mind the understanding and
> the will) to make that choice, I'm not convinced that adding the CA
> name is worth the real estate and added UI complexity.
They have the ability. They use it every purchase
of they make. Ask anyone who is in marketing.
>> Has anyone looked at the new Opera browser? I
>> saw the press release about their anti-phishing
>> SSL cert display, but I don't have a copy myself.
>
>
> I hope to soon.
Gervase Markham
> Secondly, what you are pointing at is a *derivative*
> problem. The primary problem is that the CA issued
> a duff cert. How do you solve that? Well, there has
> to be some pain somewhere, and the closer it is to
> the users, the more likely the pain will actually respond
> to user security needs. So, yes, some users are
> going to have some pain. That's part of the process.
>
> Thirdly, your grandfather could think like that, and
> probably does - ask him what car brands he knows.
> Then ask him if he knows anyone who buys Ford
> every time ... and ask him what would happen if
> he saw the guy go and buy a renault or a seat?
You've made such analogies before; but I again repeat they the brand
visibility is vastly different in both cases, and note that "the CA I
use to protect my connection to Amazon" is not a consumer choice like
"the car I buy".
> Fourthly, what exactly are you saying in terms of not
> showing the cert? Are you saying that you believe that
> when a company screws up, it should be dealt with
> behind the scenes? That the users shouldn't know
> that UserBust is continuing to issue duff certs, and
> it is stuck in the root list of 90% of issued product?
Fundamentally, when we had no market share, we had no leverage. When we
have some, we'll have some. So how about this for an idea to kick around:
- CA Foo issues a bunch of duff certs to phishers
- People lose money
- The MF decides, pragmatically, that CA Foo has sold too many certs to
yank their root cert, due to user inconvenience.
- The MF instead declares that CA Foo's root cert will be yanked in 6
months, unless they clean up their act, and that sites should not rely
on CA Foo's certs working in 15% of browsers 12 months from now.
- The resultant storm of publicity and uncertainty and doubt causes CA
Foo registrations to drop, and CA Foo to clean up their act, and beg us
to issue a joint press release to that effect.
It might work...
>> In the absence of even the ability (never mind the understanding and
>> the will) to make that choice, I'm not convinced that adding the CA
>> name is worth the real estate and added UI complexity.
>
> They have the ability. They use it every purchase
> of they make. Ask anyone who is in marketing.
I meant the ability to choose the CA who protects their connection to a
particular site - an ability which you've admitted they don't have.
Gerv
Ian G
> Ian G wrote:
>
>> Secondly, what you are pointing at is a *derivative*
>> problem. The primary problem is that the CA issued
>> a duff cert. How do you solve that? Well, there has
>> to be some pain somewhere, and the closer it is to
>> the users, the more likely the pain will actually respond
>> to user security needs. So, yes, some users are
>> going to have some pain. That's part of the process.
>>
>> Thirdly, your grandfather could think like that, and
>> probably does - ask him what car brands he knows.
>> Then ask him if he knows anyone who buys Ford
>> every time ... and ask him what would happen if
>> he saw the guy go and buy a renault or a seat?
>
>
> You've made such analogies before; but I again repeat they the brand
> visibility is vastly different in both cases, and note that "the CA I
> use to protect my connection to Amazon" is not a consumer choice like
> "the car I buy".
The point I am making is that users understand
branding. Their understanding of branding gives
them information that they can use. You're right
to point out that that will use this branding info
in different ways.
In this case, they can use the information to understand
the risks. We're not asking anyone to "choose a CA".
Instead, we're asking the users to a) choose to avoid
CAs and merchants where the CAs have a bad rep,
and also to notice when a CA changes. If a CA changes,
that's a signal that they may be being spoofed.
If they're being spoofed via the same CA, then the
reputation issues kick in. But they will only kick in
if the user has a reason to get upset at the CA,
which means it must be branded to them, in their
minds, on the chrome.
>> Fourthly, what exactly are you saying in terms of not
>> showing the cert? Are you saying that you believe that
>> when a company screws up, it should be dealt with
>> behind the scenes? That the users shouldn't know
>> that UserBust is continuing to issue duff certs, and
>> it is stuck in the root list of 90% of issued product?
>
>
> Fundamentally, when we had no market share, we had no leverage. When
> we have some, we'll have some. So how about this for an idea to kick
> around:
>
> - CA Foo issues a bunch of duff certs to phishers
> - People lose money
> - The MF decides, pragmatically, that CA Foo has sold too many certs
> to yank their root cert, due to user inconvenience.
> - The MF instead declares that CA Foo's root cert will be yanked in 6
> months, unless they clean up their act, and that sites should not rely
> on CA Foo's certs working in 15% of browsers 12 months from now.
> - The resultant storm of publicity and uncertainty and doubt causes CA
> Foo registrations to drop, and CA Foo to clean up their act, and beg
> us to issue a joint press release to that effect.
>
> It might work...
Sure, something like that.
>>> In the absence of even the ability (never mind the understanding and
>>> the will) to make that choice, I'm not convinced that adding the CA
>>> name is worth the real estate and added UI complexity.
>>
>>
>> They have the ability. They use it every purchase
>> of they make. Ask anyone who is in marketing.
>
>
> I meant the ability to choose the CA who protects their connection to
> a particular site - an ability which you've admitted they don't have.
The reason for showing them the CA is not to
"give them choice in CAs" but to allow them to
develop a sense of the risks they are taking. If
the see SafeCA being used at a bookshop then
they will put their details in a form... if they see
DodgyCA then they may decide it's not worth
the risk; maybe they know DodgyCA is bad, or
maybe they know it wasn't there last time and
that's a bad signal.
Gervase Markham
> The point I am making is that users understand
> branding. Their understanding of branding gives
> them information that they can use. You're right
> to point out that that will use this branding info
> in different ways.
>
> In this case, they can use the information to understand
> the risks. We're not asking anyone to "choose a CA".
> Instead, we're asking the users to a) choose to avoid
> CAs and merchants where the CAs have a bad rep,
I am highly sceptical that we can ever raise a user's CA branding
awareness and security awareness to a point where they will choose not
to shop with their preferred retailer when they otherwise would, merely
because of the CA that retailer has chosen.
Earlier, you pointed out the branding success of Intel. Intel has had
correctness scares in the past over bugs in Pentiums, and privacy scares
over things like chip ID; however, no-one goes into an Internet cafe and
demands an AMD computer because an Intel chip might get calculations
wrong on their machine and corrupt their email, or might send copies of
it to Intel.
> and also to notice when a CA changes. If a CA changes,
> that's a signal that they may be being spoofed.
It's also a signal that the merchant concerned has heard of problems
with their original CA and switched.
Therefore, a "good thing" (merchants switching CAs), as defined by this
strategy, has almost exactly the same UI effect as a "bad thing"
(spoofing). This is deeply concerning.
>> Fundamentally, when we had no market share, we had no leverage. When
>> we have some, we'll have some. So how about this for an idea to kick
>> around:
>>
>> - CA Foo issues a bunch of duff certs to phishers
>> - People lose money
>> - The MF decides, pragmatically, that CA Foo has sold too many certs
>> to yank their root cert, due to user inconvenience.
>> - The MF instead declares that CA Foo's root cert will be yanked in 6
>> months, unless they clean up their act, and that sites should not rely
>> on CA Foo's certs working in 15% of browsers 12 months from now.
>> - The resultant storm of publicity and uncertainty and doubt causes CA
>> Foo registrations to drop, and CA Foo to clean up their act, and beg
>> us to issue a joint press release to that effect.
>>
>> It might work...
>
> Sure, something like that.
Note that this plan doesn't require and end user action, or CA names in
chrome.
Gerv
Ian G
> Ian G wrote:
>
>> The point I am making is that users understand
>> branding. Their understanding of branding gives
>> them information that they can use. You're right
>> to point out that that will use this branding info
>> in different ways.
>>
>> In this case, they can use the information to understand
>> the risks. We're not asking anyone to "choose a CA".
>> Instead, we're asking the users to a) choose to avoid
>> CAs and merchants where the CAs have a bad rep,
>
>
> I am highly sceptical that we can ever raise a user's CA branding
> awareness and security awareness to a point where they will choose not
> to shop with their preferred retailer when they otherwise would,
> merely because of the CA that retailer has chosen.
We are not asking them to choose not to shop
with their preferred retailer. We are simply
making them aware of the risks when they do
so. It's a different thing.
> Earlier, you pointed out the branding success of Intel.
Yes. Branding works. It works for ordinary
people; it works for non-technical users.
> Intel has had correctness scares in the past over bugs in Pentiums,
> and privacy scares over things like chip ID; however, no-one goes into
> an Internet cafe and demands an AMD computer because an Intel chip
> might get calculations wrong on their machine and corrupt their email,
> or might send copies of it to Intel.
Right. We aren't asking them to "change CA."
We are asking them to be aware that when
they shop at their favourite shop, that the
choice includes a component of risk towards
the CA, as well as towards the retailer.
Right now, they are unaware of that risk, and
they can't understand why the phishing occurs.
Part of the deal with addressing phishing is
getting the real security information to them;
such that users can assess whether a phishing
attempt is underway.
As a short term phase, it is important to move
secure form filling across to SSL. So that the
users know and work with this. That means
making it much more obvious ...
As a next term phase, we have to be ready
for when phishers attack HTTPS. They will
do this easily by simply buying Shmoo-like cert.
The system will hide the switch.
To get users to appreciate the switch from one
good cert to either another dodgy one, or none,
we need to get them looking at the CA. And if
the same CA issues the dodgy cert, well, then,
they are on the hook for both ends.
>> and also to notice when a CA changes. If a CA changes,
>> that's a signal that they may be being spoofed.
>
>
> It's also a signal that the merchant concerned has heard of problems
> with their original CA and switched.
>
> Therefore, a "good thing" (merchants switching CAs), as defined by
> this strategy, has almost exactly the same UI effect as a "bad thing"
> (spoofing). This is deeply concerning.
Right, it is up to the merchant to manage that
process, and the user to be aware of better
branding. There will be a tendency to get a
decently branded cert, and to stick with the
same supplier.
A switch from bad cert to good cert is similar
in general appearance to good --> bad. This
means we have a good signal, and a bad signal.
That's in exchange for no signal. The system
isn't perfect, no system is. It's just what we can
do with the system we've got.
>>> Fundamentally, when we had no market share, we had no leverage. When
>>> we have some, we'll have some. So how about this for an idea to kick
>>> around:
>>>
>>> - CA Foo issues a bunch of duff certs to phishers
>>> - People lose money
>>> - The MF decides, pragmatically, that CA Foo has sold too many certs
>>> to yank their root cert, due to user inconvenience.
>>> - The MF instead declares that CA Foo's root cert will be yanked in
>>> 6 months, unless they clean up their act, and that sites should not
>>> rely on CA Foo's certs working in 15% of browsers 12 months from now.
>>> - The resultant storm of publicity and uncertainty and doubt causes
>>> CA Foo registrations to drop, and CA Foo to clean up their act, and
>>> beg us to issue a joint press release to that effect.
>>>
>>> It might work...
>>
>>
>> Sure, something like that.
>
>
> Note that this plan doesn't require and end user action, or CA names
> in chrome.
Sure. It also gets MF sued because they shipped a
browser that users can trust in, and it hid the true
risks from them. By hiding the true risks, and by
allowing a 12 month window in which CA Foo and
its dodgy mates rip of thousands of customers, the
degree of harm is somewhat unlimited.
Neither of those are tractable. It isn't possible for
MF to respond to CA Foo fast enough to limit
damages - because users don't patch. And, it isn't
possible to avoid the liability implied by "if the padlock
is set, you are safe."
This is why the original security model had the CA
on the chrome. That got dropped because there was
no threat, and nobody thought it worthwhile. Now
there's a threat, and now people are losing money.
Nelson B
> Fundamentally, when we had no market share, we had no leverage. When we
> have some, we'll have some. So how about this for an idea to kick around:
>
> - CA Foo issues a bunch of duff certs to phishers
> - People lose money
Very little of this has happened historically because the existing CAs
now in mozilla's list have been very very good at not issuing "duff"
certs. As evidence of this truth, I offer the HUGE amount of press
(not to mention postings in this group) that a *single* duff cert incident
got a few years ago. The press held that CA up to high standards
precisely because that CA already had a reputation for doing a good
job of avoiding "duff" certs.
However, mozilla is now considering changing its standards for admission
to mozilla's trusted CA list. I think there is substantial risk of
increased "duff" certs (especially SSL certs) from this plan.
> - The MF decides, pragmatically, that CA Foo has sold too many certs to
> yank their root cert, due to user inconvenience.
This says to me that MF needs to hold a high standard before admitting
certs to the list, because it's too difficult to take them out later.
> - The MF instead declares that CA Foo's root cert will be yanked in 6
> months, unless they clean up their act, and that sites should not rely
> on CA Foo's certs working in 15% of browsers 12 months from now.
MF might declare that, but I doubt it would ever enact the threat.
Doing so would only hurt mozilla.
When something that previously worked stops working in a browser,
end-users' perceptions are always "that darn buggy browser is junk",
never "that web site's admin hasn't got a clue about security".
Too many users live in caves. They wouldn't learn about the CA cert
removal until their web pages stopped working. Then they'd gripe
en-masse about mozilla. Not about the duff CA, but about mozilla.
BTW, where do you think mozilla would tell the world about such a
plan to remove a CA cert? If the IDN issue couldn't make it onto
www.mozilla.org's front page, what chance has CA news of getting
onto ANY mozilla.org web page?
> - The resultant storm of publicity and uncertainty and doubt causes CA
> Foo registrations to drop, and CA Foo to clean up their act, and beg us
> to issue a joint press release to that effect.
--
Nelson B
Ram0502
the opinions I express are mine personally and should not be taken as
representing my current or previous employers unless I explicitly state
otherwise.
Comments inline...
That's insightful. Given MF's hesitation to establish direct explicit
criteria for inclusion in the root list (please don't take this as a
dig but rather an observation) there is reason to suspect MF would be
hesitant to formulate similar rules for removal from the root list.
Let's say the current expectation for security defects repair from
detection/advisement to patch distribution is on the order of two
months. It is hard to reconcile those two months against an arguably
reasonable six month tolerance period for a roots removal (given the
potential complexity of the software, process changes, customer
management etc that a CA may need to make as well as a time for the
various secure site operators to enroll for new certificates and roll
them out). It seems there is a mismatch between these expectations
which I see as supporting the notion of raising the bar on admission in
practical terms. I think it is also important to evaluate the existing
root list as critically as candidate roots rather than rely on their
existing records exclusively for the same reason.
Frank Hecker
> Gervase Markham wrote:
>> - CA Foo issues a bunch of duff certs to phishers
>> - People lose money
>
> Very little of this has happened historically because the existing CAs
> now in mozilla's list have been very very good at not issuing "duff"
> certs.
> However, mozilla is now considering changing its standards for admission
> to mozilla's trusted CA list. I think there is substantial risk of
> increased "duff" certs (especially SSL certs) from this plan.
This is a serious question, and I think it's worth looking in more depth
into the extent to which this might be true; otherwise some might
mistake your statement as simply FUD, and I don't believe you intended
it that way.
First, what's a "duff cert" in this context? A cert issued by a CA in
violation of its own policies (i.e., CP and CPS)? A cert issued by a CA
to someone that the CA "should have known" might use it for fraudulent
purposes? A cert issued by a CA to someone who turns out to use the cert
in the context of fraudulent activity (whether the CA "should have
known" this or not)? These are not really the same definitions. Which
one did you (and Gerv) intend?
Second, you seem to be saying that under the past and current policies
for adding certs to the Mozilla default set (as implemented by Netscape
and then myself) there has been minimal issuance of "duff certs"
(however defined), but that under the proposed new policy the issuance
of "duff certs" could be substantially increased. The implies (at least
to me) that such an increase in "duff certs" would be specifically
caused by adopting the new policy, to the exclusion of other factors. Am
I reading you right here?
Let's consider this: The proposed new policy differs in at least three
ways from prior policies, at least from the "WebTrust or equivalent"
policies I've been following:
1. It adds some additional acceptable criteria to WebTrust. (This
formalizes the "or equivalent" part of the current "WebTrust or
equivalent" policy.)
2. It permits approval of CAs based on evaluations by independent
parties who aren't official CA auditors or security test labs. (This
might include us, i.e., people in the Mozilla project, if we want to
take on such tasks.)
3. It puts some minimal requirements on validation procedures that CAs
have to do for SSL, email, and object signing certs respectively.
Let's take these in order:
1. I suspect that adding the other criteria (X9.79 and ETSI TS 101 456
and 102 042) is not at issue, because the other criteria are
substantially similar to the WebTrust criteria, and if anything go
beyond the WebTrust criteria in placing some additional requirements on
CAs that the WebTrust criteria do not. Do you agree with my assessment,
or do you think that adding the additional criteria will significantly
increase the risk that "duff certs" will be issued? If so, why?
2. Permitting "non-traditional" evaluation of CAs is certainly something
that one could imagine increasing risks, if the people doing the
evaluation don't do a good job. On the other hand, I suspect that if and
when any such "non-traditional" evaluation does take place (e.g., like
what's been proposed for CAcert.org, and perhaps for future CAs as
well), that the level of public scrutiny of such evaluation will be very
high (if I can judge by the controversy this has already stirred up),
which will likely minimize the risk of a bad evaluation being done and
approved. (Certainly I'd be hesitant to approve a CA based on a
non-traditional evaluation if there were significant questions raised
about it, until/unless such questions could be resolved to pretty much
everybody's satisfaction.)
But this may or may not be at the root of your concern, so let me ask
directly: In your opinion, would permitting such "non-traditional"
evaluations contribute to the increased risk you perceive? If so, is it
the only factor increasing risk? A major factor? Just a contributing
factor relative to other factors (like the one I'll discuss next)?
If you do believe that permitting non-traditional evaluations would
increase the risk of "duff certs" being issued, what would you recommend
we do? Tighten the requirements on when we'd allow such evaluations? Or
drop the idea entirely, and require that all evaluations be done by
authorized auditors and test labs?
The consequence of the latter would be to keep CAcert.org out of the
list permananently, or at least until they could afford a WebTrust or
other audit. It would also keep other CAs out that haven't undergone
WebTrust or equivalent audits; for example, I think there's a CA
associated with a German university/research consortium that would be
affected by this, and I think a couple of others as well.
3. Regarding requirements on CA validation of their customers, I
certainly don't have any such requirements in my current "WebTrust or
equivalent" policy, so in that sense the proposed new policy is more
stringent than the old policy. Did Netscape have such requirements? I
have no idea. However with regard to SSL certs in particular I will note
that there are already CAs issuing "domain-validated" certs, e.g., the
Thawte ssl123 and Go Daddy TurboSSL services, and to my knowledge such
CAs are already in the default Mozilla set and usable with Firefox, etc.
(There may also be other CAs like this as well, but I haven't had time
to do a thorough check.) Has this resulted in significant issuance of
"duff certs"? Apparently not, or I presume you would have mentioned this.
So, I ask you: In your opinion, would explicitly permitting such
"domain-validated" certs (as opposed to the implicit permission we've
apparently had previously) contribute to the increased risk you
perceive? If so, is it the only factor increasing risk? A major factor?
Just a contributing factor relative to other factors (like the issue
with non-traditional evaluations)?
If you do believe that explicitly permitting domain-validated SSL certs
would increase the risk of "duff certs" being issued, what would you
recommend we do? Prohibit domain-validated certs, and require that CAs
do more thorough identity verification of subscribers? Require that CAs
do additional due diligence (over and above identity verification) to
determine if subscribers might intend to use their certs for fraudulent
purposes? Would you also recommend not permitting issuance of email
certs based only on email account verification (i.e., not checking
identity)?
The consequence of prohibiting domain-validated SSL certs is that I
would reject the request that Go Daddy currently has submitted (in bug
284677) for adding new root CA certs. To be consistent we would also
remove from the default cert list the existing root CA certs for Thawte,
Go Daddy, and anyone else currently issuing domain-validated certs. If
we want to prohibit "account-validated" email certs then we'd also have
to remove root CA certs associated with those services as well. (As a
side note, I don't believe that prohibiting domain-validated certs would
affect CAcert.org, since IIRC they don't issue such certs; Duane or
someone else, please correct me if I'm wrong about this.)
Finally, let me consider some larger issues. Forgive me if I'm missing
something, but I'm getting contradictory impressions here. On the one
hand I get the impression that you and others believe that historically
there have been minimal problems (and hence minimal risks to users)
resulting from CA practices and the selection of CAs to be included in
the Mozilla default set. Now that I'm proposing this new policy I get
the impression that you and others believe it will result in significant
problems and significant risks to users, even though the sorts of CAs
and CA practices permitted under the new policy are AFAICT basically the
same sorts of CAs and CA practices that were permitted under the old policy.
(The major exception to this is the possibility of including CAs like
CAcert.org based on non-traditional evaluations; but I'm not clear there
whether non-traditional evaluations are the sorts of your concern or
whether it's domain-validated SSL certs and other low-assurance certs.)
The only way I can personally resolve this contradiction is to conclude
that it's not the policy in isolation which is at issue, it's the policy
in combination with the new environment in which protecting against
phishing has become a top priority. In other words, while existing
policies (which in practice permitted things like domain-validated SSL
certs) may have been good enough way back when, any new policy has to be
more stringent in order to counter the increased threat; it's not good
enough for us to just continue and formalize existing de facto
practices, we have to add some more requirements over and above what has
been done in the past.
Is this what you and others are arguing? If so, it's a perfectly
legitimate argument to make. But if you and others want to make this
argument (i.e., that policy needs to be more stringent in this new
environment) then I believe it's incumbent on you and others to a)
propose in some level of details what more stringent requirements we
should actually impose, and b) explain how those requirements will
actually reduce the risks experienced by ordinary users.
I think such a detailed justification is necessary because there are
consequences to adopting more stringent policies: We're talking about
eliminating (i.e., no longer accepting as valid) uses of things like
domain-validated certs that are currently in use (with apparently no
problems resulting), and closing off the possibility of such uses in the
future. We're in essence saying that use of SSL in e-commerce and
financial applications is our primary concern, that the risks associated
with SSL in such applications require us to adopt as stringent a set of
rules as we can, and that all other uses of SSL have to play by the same
rules, whether they make sense in other contexts or not.
I know you're busy and don't have time to create such a detailed
justification, but I certainly wish someone would.
Ian G
> Gervase Markham wrote:
>
>> Fundamentally, when we had no market share, we had no leverage. When
>> we have some, we'll have some. So how about this for an idea to kick
>> around:
>>
>> - CA Foo issues a bunch of duff certs to phishers
>> - People lose money
>
>
> Very little of this has happened historically because the existing CAs
> now in mozilla's list have been very very good at not issuing "duff"
> certs.
Right. But you are misinterpreting the causes and
effects. Very little duff issuance has occurred because
it isn't valuable. There is and there remains no value
in duff issuance, because phishing works without
certs.
This is the problem, pure and simple: attacks on value
bypass the CAs and certs. Response? Force them to
use HTTPS; Corollary? Certs will *then* be attacked
and duff certs *will* be issued.
> As evidence of this truth, I offer the HUGE amount of press
> (not to mention postings in this group) that a *single* duff cert
> incident
> got a few years ago. The press held that CA up to high standards
> precisely because that CA already had a reputation for doing a good
> job of avoiding "duff" certs.
I take anything written in the press with a grain of
salt. I'm sure they bought into the whole "perfect
security" myth and thought it was fun to write about...
Even though the Shmoo cert was obviously a bit odd,
it got issued. But no crook bothers to do that, unless
there is money to be made.
> However, mozilla is now considering changing its standards for admission
> to mozilla's trusted CA list. I think there is substantial risk of
> increased "duff" certs (especially SSL certs) from this plan.
There is a substantial, even huge risk of duff certs
being issued. On that we are agreed. But the _cause_
is that they will become valuable. And that only
happens when Gervase and HJ and others start
putting the cert domain name and cert signer on
the chrome.
When users start defending themselves from phishing,
then the certs will be valuable... then they'll be attacked.
Not before. Why attack a cert-protected site when you
can hack in and steal the database? Why bother with
any of that when you can apply to join ChoicePoint's
open search service?
It's a chess game, thinking several moves ahead.
>> - The MF decides, pragmatically, that CA Foo has sold too many certs
>> to yank their root cert, due to user inconvenience.
>
>
> This says to me that MF needs to hold a high standard before admitting
> certs to the list, because it's too difficult to take them out later.
"needs to hold a high standard..." Well, this is like
saying "let's ban guns!" To which the answer is,
"then only criminals will have guns."
Nothing that MF can do will slow down a crook.
Crooks laugh at those sorts of things (well, they
would if they knew about HTTPS ...)
>> - The MF instead declares that CA Foo's root cert will be yanked in 6
>> months, unless they clean up their act, and that sites should not
>> rely on CA Foo's certs working in 15% of browsers 12 months from now.
>
>
> MF might declare that, but I doubt it would ever enact the threat.
> Doing so would only hurt mozilla.
Right. I must admit I'm somewhat bemused by the
threat that MF would pull a root cert. But, in the
scheme of things, I don't see it makes a difference
to the security of the users, one way or another,
so I don't bother to think too hard on it.
> When something that previously worked stops working in a browser,
> end-users' perceptions are always "that darn buggy browser is junk",
> never "that web site's admin hasn't got a clue about security".
>
> Too many users live in caves. They wouldn't learn about the CA cert
> removal until their web pages stopped working. Then they'd gripe
> en-masse about mozilla. Not about the duff CA, but about mozilla.
Yup. Once it's out there, that's it.
Jean-Marc Desperrier
> "needs to hold a high standard..." Well, this is like
> saying "let's ban guns!" To which the answer is,
> "then only criminals will have guns."
Lot of countries demonstrate banning gun works rather well, so the
argument weakens the demonstration, besides being totally unrelated.
Gervase Markham
> Gervase Markham wrote:
>> Therefore, a "good thing" (merchants switching CAs), as defined by
>> this strategy, has almost exactly the same UI effect as a "bad thing"
>> (spoofing). This is deeply concerning.
>
> Right, it is up to the merchant to manage that
> process, and the user to be aware of better
> branding.
But the merchant can't manage the process, because the user is supposed
to be using the cert to assess the trustworthiness of the merchant's
statements. After all, how would you react to a website which said
"Don't worry that your browser now says Foo CA - we've switched CAs!
Honest!".
Or do you envisage a bank paper mailing all its customers to notify them
of the CA switch?
> A switch from bad cert to good cert is similar
> in general appearance to good --> bad. This
> means we have a good signal, and a bad signal.
And both signals are very similar - unless the user is so CA brand-aware
that they know that CAs A, B and C are currently considered dodgy, but
D, E and F are riding high, so A -> D is good but F -> C is bad.
The level of brand and market awareness you are requiring from an
average web user is far above their awareness of almost any market, even
ones in which they are deeply involved.
Gerv
Gervase Markham
> First, what's a "duff cert" in this context? A cert issued by a CA in
> violation of its own policies (i.e., CP and CPS)? A cert issued by a CA
> to someone that the CA "should have known" might use it for fraudulent
> purposes? A cert issued by a CA to someone who turns out to use the cert
> in the context of fraudulent activity (whether the CA "should have
> known" this or not)? These are not really the same definitions. Which
> one did you (and Gerv) intend?
For my part, a "duff cert" is one which is used for fraudulent activity.
That's a somewhat circular definition, indeed - but I wasn't thinking in
terms of the risk or otherwise from the policy changes.
> We're in essence saying that use of SSL in e-commerce and
> financial applications is our primary concern, that the risks associated
> with SSL in such applications require us to adopt as stringent a set of
> rules as we can, and that all other uses of SSL have to play by the same
> rules, whether they make sense in other contexts or not.
This rather falls out of the current binary security UI. (I should say
that I'm very sceptical that it's possible to change that; this is
merely an observation.)
Gerv
Gervase Markham
> Very little of this has happened historically because the existing CAs
> now in mozilla's list have been very very good at not issuing "duff"
> certs. As evidence of this truth, I offer the HUGE amount of press
> (not to mention postings in this group) that a *single* duff cert incident
> got a few years ago. The press held that CA up to high standards
> precisely because that CA already had a reputation for doing a good
> job of avoiding "duff" certs.
Indeed - I agree that the sky is definitely not falling. However, this
happening was the starting point for the scenario under discussion, so
that's why I started with it.
> However, mozilla is now considering changing its standards for admission
> to mozilla's trusted CA list. I think there is substantial risk of
> increased "duff" certs (especially SSL certs) from this plan.
I share your concern; we need to be very careful about what the policy
says. I applaud your work in this area.
>> - The MF decides, pragmatically, that CA Foo has sold too many certs
>> to yank their root cert, due to user inconvenience.
>
> This says to me that MF needs to hold a high standard before admitting
> certs to the list, because it's too difficult to take them out later.
Absolutely.
>> - The MF instead declares that CA Foo's root cert will be yanked in 6
>> months, unless they clean up their act, and that sites should not rely
>> on CA Foo's certs working in 15% of browsers 12 months from now.
>
> MF might declare that, but I doubt it would ever enact the threat.
> Doing so would only hurt mozilla.
Well, it would depend on whether the CA cleaned up their act, and
whether people migrated away from their certs. Absolutely, it's a game
of chicken.
I'm not saying it's a good solution to CA cert removal, but I'm hard
pressed to think of a better one. You are right - removing CA certs is
very, very hard.
Gerv
Ram0502
> Nelson B wrote:
> > Gervase Markham wrote:
<snip>
> Finally, let me consider some larger issues. Forgive me if I'm
I think there are potential applications of PKI outside phishing
prevention and further that PKI by itself is not a perfect solution.
There are plenty of things that could be done to improve the safety of
netizens; some risks or aspects of risks can be mitigated by use of
public key technologies. Different approaches and different
applications could have different requriements.
The root list management approach to date in MF and Microsoft has been,
more or less, to identify the CA legal entity and require that they
document their policies and practices and undergo an audit. Both
Microsoft and Netscape used to charge a huge amount for inclusion in
their root lists which ensured the CAs had something to lose if their
brand was tarnished, but it also kept smaller CAs off the list (it may
be worth noting that quite a few of the CAs commonly trusted have been
bought or sold or gone bankrupt - what policies and practices survive
change of ownership?).
An advocate in nmpc suggests driving broader adoption of SSL by
changing the trust model in combination with loading additional
financial exposure on the CAs (ie make their brand/reputation suffer
for their mistakes and weaknesses). Others advocate raising the bar for
entry into the root list through other means. I think there is merit to
both approaches.
It seems to me that internet use is increasing and therefor so is the
value to be garnered by criminals. I expect the approach criminals take
will be path of least resistance and that the particular attacks will
vary substantially to work around changes in the landscape. So what do
we do? I don't expect we will find one new technology or enhancement to
an existing technology that will solve all our problems. I think the
right approach is to be practical and improve things even imperfectly.
So to the topic at hand - what about the MF policy for PK root
inclusion. My opinion is that there are many approaches we could take
to improve the security proposition some will require a lot of work
others less. The following are a few of my thoughts and suggestions.
For practical reasons I think it is easier to be tougher on the
admission and more lenient on the removal side as it is much more
difficult to orchestrate a reasonable removal without unduly damaging
innocents such as web site operators who chose a CA that was later
removed from the trust list.
I don't believe the bar can be set high enough on admission to the root
list that it can be left unmaintained nor do I believe that any CA is
capable of operating perfectly against strong policies such that thinks
like revocation don't matter.
I propose a requirement that every CA whose certificates will identify
ecommerce sites or software publishers must support revocation checking
through standard means, say a CRL or OCSP pointer in every certificate.
This could have an SLA aspect such that the OCSP or CRL not lapse (the
CRL pointer should never point at a CRL whose next-udate time is three
days ago).
I think presentation of the CA logo leverages natural human and market
systems to drive quality up for the consumer but practically this seems
to be difficult as there is a UI real-estate issue - perhaps in time we
will see the UI issue resolved through client software competition.
Showing the user the vetted organization name when present does a lot
to prevent homoglyph (homosymbol?) type attacks (one for el, zero for
oh, and the IDN and unicode versions). Within this contex and to the
question of whether strong authentication of the organization is the
best approach or if it is better to issue broadly and revoke quickly I
claim that the economics of revocation status services will drive a
practical shift to stronger up front authentication given an active
system of high enough value and volume to be part of the attack space.
Finally I think there is merit to having different requirements for
different applications of PKI. Compare the risks of interacting with
your bank, installing software, and logging into your favorite internet
portal so it recalls your content preferences. In the banking case I
really care about authentication and encryption as does the bank. If
you interact with your bank from your computer than you (and your bank)
both care about what software you install. A few good keylogging
attacks in the press and we may see the priority of software publishing
security increase.
Frank Hecker
> For my part, a "duff cert" is one which is used for fraudulent activity.
> That's a somewhat circular definition, indeed - but I wasn't thinking in
> terms of the risk or otherwise from the policy changes.
It's also an "after the fact" definition, and of course here we're
having to make decisions before the fact, based on hypotheses on what is
likely to happen in the future. Not a straightforward task.
>> We're in essence saying that use of SSL in e-commerce and financial
>> applications is our primary concern, that the risks associated with
>> SSL in such applications require us to adopt as stringent a set of
>> rules as we can, and that all other uses of SSL have to play by the
>> same rules, whether they make sense in other contexts or not.
>
> This rather falls out of the current binary security UI. (I should say
> that I'm very sceptical that it's possible to change that; this is
> merely an observation.)
Fair enough. So let me ask a specific question: If the level of cert
assurance is the key issue, do you believe that the binary security UI
in combination with potential threats of phishing attacks justifies
rejecting CAs that issue "domain validation only" certs, and removing
any such CAs' root certs from the current default set? If so, how would
you justify doing this? (By which I mean, what is the detailed argument
that would lead to this conclusion, expressed in terms appropriate for
publicly justifying such a policy to everyone who might be affected by it?)
A couple of other notes on the "binary security model" issue: First,
it's possible that some root CAs in the current default set have
multiple subordinate CAs underneath them, where one subordinate CA
issues "identity-validation" certs and another subordinate issues
"domain-validation-only" certs. This is something we'd have to look
into, since in removing root CA certs we might face the choice of
disabling more than just "domain-validation-only" CAs.
Second, as a future point we *do* have two independent products now,
Firefox and Thunderbird, with two separate application domains, and even
if we have a binary security model in terms of any given product it's
not out of the question that we could have different models for
different products, e.g., have a different default set of CA certs for
Firefox than for Thunderbird. This might help address the issue of
separating the HTTP/SSL use cases from email-related SSL use cases
(e.g., IMAP/SSL), at least in a gross way. But of course like many other
suggestions this too depends on future product changes that we'd have to
find developers to implement...
Frank Hecker
> You are right - removing CA certs is very, very hard.
Actually, I don't believe that the statement "removing CA certs is hard"
is true as a general proposition. When people say this I suspect that
they usually mean "removing CA certs associated with major e-commerce
sites is hard". But we have on the order of 100 CAs in the default set,
and if we look at CA market share (as reported by E-Soft just this past
week):
http://www.securityspace.com/s_survey/sdata/200502/certca.html
we see that once you get past the top six CAs (excluding self-signed
certs, which are #4 in the list), no other CA has more than 1% of the
market for SSL server certs or more than a thousand or so servers using
its certs.
(This also gives an idea of the business prospects for a new CA issuing
SSL certs for the public Internet: a few hundred servers times a few
hundred dollars US per server per year equals annual revenue of USD 100K
to 1M at best. This is not a attractive business proposition IMO. It
makes more sense to run a CA as an "add-on" offering to other services,
like domain registration, to try to crack other markets beyond SSL
servers on the public Internet, or to run a CA as a nonprofit enterprise
to serve some public purpose. See also my comments below on the types of
new CAs I'm seeing.)
My conclusion is that outside of the top CAs we could remove any CA in
our list and the immediate consequences would be pretty limited. (The
only exception would be if a major site happened to be using one of
these low-market-share CAs, but I suspect most if not all of the major
sites just go for a cert from one of the well-known CAs. And according
to Nelson at least the major CAs have not been a problem historically,
and this may continue to be the case. So in practice any problems we see
in terms of "duff certs" may be confined solely to CAs outside the major
ones.
(Incidentally, what I'm seeing in terms of new CAs requesting approval
is that many of them are "specialty" CAs that serve a particular
geographic area, e.g., the various European and Asian CAs that have
applied or a particular subset of users, e.g.,
university/research-affiliated CAs.) The geographic CAs are either
government-affiliated (e.g., the Staat der Nederlanden CA affiliated
with the Dutch government) or are presumably content with trying to
achieve a big share of a limited national market (e.g., Unizeto CERTUM
in Poland).
I think a more important barrier to removing CAs may be actually finding
developers to patch NSS and get those patches into distributed versions
of Firefox et.al; this has certainly be an ongoing issue with getting
CAs *into* the default set. (And there's also the work of reviewing
existing CAs for possible exclusion, which also needs people willing and
able to do it.)
Ian G
> Ian G wrote:
>
>> Gervase Markham wrote:
>>
>>> Therefore, a "good thing" (merchants switching CAs), as defined by
>>> this strategy, has almost exactly the same UI effect as a "bad
>>> thing" (spoofing). This is deeply concerning.
>>
>>
>> Right, it is up to the merchant to manage that
>> process, and the user to be aware of better
>> branding.
>
>
> But the merchant can't manage the process, because the user is
> supposed to be using the cert to assess the trustworthiness of the
> merchant's statements. After all, how would you react to a website
> which said "Don't worry that your browser now says Foo CA - we've
> switched CAs! Honest!".
Yes. The merchant is going to be annoyed by
this process because there is no easy way to
do it. This is a big deal. But so is the security
of the user. The more this hurts the merchant,
the more the merchant is going to kick up a
storm, and the more the CA is going to make
sure it never happens again.
That's the point - feedback requires pain. No
gain without pain. No security without feedback.
And no feedback unless the user is part of the
loop.
> Or do you envisage a bank paper mailing all its customers to notify
> them of the CA switch?
It's a possibility. It may even be required by
law, if the reason for switching is related to
potential breaches. California now has laws
related to security breaches, and that law has
now been spread by default to most other
states. Ref: Choicepoint.
>> A switch from bad cert to good cert is similar
>> in general appearance to good --> bad. This
>> means we have a good signal, and a bad signal.
>
>
> And both signals are very similar - unless the user is so CA
> brand-aware that they know that CAs A, B and C are currently
> considered dodgy, but D, E and F are riding high, so A -> D is good
> but F -> C is bad.
Right. Now you think that is a problem. I see
it as the whole point: the user is notified that
a change has happened, and they should take
extra care.
> The level of brand and market awareness you are requiring from an
> average web user is far above their awareness of almost any market,
> even ones in which they are deeply involved.
Gervase, you'd have to be living on a desert
island to be unaware of the top brands in the
top areas of user interest.
Most users of cars are aware of
the brands of the cars. Most users of kitchen
appliances are aware of the brands of the
kitchen appliances. In fact, in just about any
sector where the user is faced with brands,
you can find that most consumers will know
(recognise) the top three brands.
I'm not sure what your objection to brand is?
It certainly works; it is an integral part of
all marketing, and it is also an important
part (albeit subtle) for all payment systems.
Let me put it another way. What would be
the damage of putting the brand of the CA
on the chrome? What would be the hurt?
A loss of real estate? If that's the only loss,
I have to admit I really have a problem in
dealing with that, because phishing costs
a billion a year and rising. I'm not sure it's
on the same scale of importance as the
billion or so that browser users are using.
Nelson B
> Nelson B wrote:
>> Very little of this has happened historically because the existing CAs
>> now in mozilla's list have been very very good at not issuing "duff"
>> certs.
>> However, mozilla is now considering changing its standards for admission
>> to mozilla's trusted CA list. I think there is substantial risk of
>> increased "duff" certs (especially SSL certs) from this plan.
> This is a serious question, and I think it's worth looking in more depth
> into the extent to which this might be true; otherwise some might
> mistake your statement as simply FUD, and I don't believe you intended
> it that way.
You're right, I didn't. I appreciate your confidence in that.
You asked a very poignant set of questions, well written, pretty
concise. Good work. Wish I could do that as fast as you seem to!
> First, what's a "duff cert" in this context?
I apologize for using that term. I used it merely because the message
to which I replied used it.
I consider a duff cert to be any of the kinds of certs that have caused
me (and the NSS group) trouble over the years, including (but not limited
to) these:
1. certs with technical flaws, e.g.
- duplicate issuer names and serial numbers.
- invalid public keys (e.g. DSA cert with 2kbit primes,
RSA certs with public exponent == 1).
- incorrect extensions (e.g. SSL certs that exclude SSL usage, or
authority key IDs that include BOTH the key ID *AND* the
issuer's issuer name and serial number.
- invalid dates
- ASN.1 DER encoding errors.
2. Certs with false (and therefore inadequately verified) information
about the identify of the party to whom the cert is issued, info
that was verifiably false at the time of issuance.
3. Certs with NO INFORMATION about the party to whom the cert is
issued, except an email address or a domain name, or other
info that doesn't identify the party.
[see "binary UI security model" below for more on this.]
4. (recent addition) certs used with phishing, including:
- certs with names confusingly similar to other domains, e.g.
paypal-security.com
- certs with IDN/punycode names that look like well known names
but aren't exactly.
All these problems were present in the certs at the time they were
issued. A CA who does adequate technical validity checking and
adequate due diligence about the requestor's credentials will
pass all these tests.
IMO, a CA that issues certs that are technically invalid, or that
lack all credible identity info, should never be admitted to mozilla's
list ever, neither as "high assurance" nor as "low assurance".
You will note that points 2-3 relate to the issue of "high assurance"
vs. "low assurance". This is a crucial part of the issue, and I
will address it below.
> Second, you seem to be saying that under the past and current policies
> for adding certs to the Mozilla default set (as implemented by Netscape
> and then myself) there has been minimal issuance of "duff certs"
> (however defined), but that under the proposed new policy the issuance
> of "duff certs" could be substantially increased. The implies (at least
> to me) that such an increase in "duff certs" would be specifically
> caused by adopting the new policy, to the exclusion of other factors. Am
> I reading you right here?
Yes. Now before I respond to any more questions, I must speak to the
"binary UI security model", because it is crucial to my answers.
Sorry if this is a bit long winded.
Today, the mozilla products have a binary UI security model. The padlock
is either open or closed. Period. And for SSL, users understand the
closed padlock to mean "good enough for banking". In other words,
high assurance *and* strong crypto.
As long as that remains true, as long as the padlock is either open or
closed, and no other info is presented to the user IN THE MAIN WINDOW
on which the user can judge the quality of the cert/CA, then IMO the
standard for closing the lock on a web page is, and must remain,
"good enough for banking", and "high assurance". It would be UNETHICAL
for us to allow low assurance CAs to be treated identically to high
assurance CAs (appearing to be "good enough for banking"), yet the
present UIs provide no way for a distinction to be presented.
WHEN the UI can effectively represent in a way that's obvious at a
glance to all users, including the color blind, that a cert is
"good enough for banking", or merely "good enough for writing to your
old high school friend Joe, but not good enough for banking", *then*
(and not until then) it will be sensible to allow the root CA list to
include both high and low assurance CAs for SSL server usage.
MAJOR POINT, that binary UI model is strictly the result of UI decisions
made by the browsers, and not the result of NSS. The UI people MUST
be willing to devote more screen real-estate to security info before
the binary security model can be eliminated.
History: The model has not always been binary. In Netscape Navigator 3,
the browser used a key icon that had 3 states:
- broken
- short, with one tooth
- long, with two teeth.
Two teeth meant "good enough for banking", and one tooth meant
"better than nothing, but not good enough for banking".
Users really understood that distinction. Netscape users outside the
USA, who had to use "export" browsers which were not permitted to use
strong crypto, and hence never showed two teeth, those users were
alarmed at the lack of teeth, and refused to use the browsers for
banking when the bank's web site showed only one tooth.
In response to that, Netscape invented SSL Step-Up, which allowed
export browsers to use strong crypto (and show two teeth) for banking
web sites. This was a HUGE win for everyone. SSL Step-Up first
appeared in Communicator 4.02 (IIRC), but about that time, the UI people
decided that the key was too big, and too complicated (3 states instead
of merely two), so they replaced it with a lock that looked JUST LIKE
IE's LOCK (oh Joy!). And we've been stuck with that damned lock and
its two states ever since.
There are a variety of ways that this problem could be solved in the UI.
The UI could:
a) go back to a iconic model that has clearly 3 or more states, which
are OBVIOUS to users in the chrome of the MAIN WINDOW, without the user
needing to click or move the mouse to see the info,
b) go to a model that identifies the CA, and allow the user to decide
for him/her self whether the CA is high or low assurance. The CA could
be identified by text (a name) and/or a "FavIcon" as web sites are now.
The browser could help the user remember his decision, and allow him to
change it.
The first method is visually the most simple, but requires someone to
make a judgment call on the user's behalf concerning the assurance
level of the CA. I think this is least confusing for the users, but
more work for MF and NSS.
The second method requires the users to grow their awareness of CAs
(of which they know nothing today). It also requires more window
real-estate. But it keeps MF out of the judgment business, which is
a business that MF seems particularly loath to do.
Next point: The problems described above have seldom ever been a
problem with the CAs already in the list, the ones who had to pay
$$$$ (either to Netscape or to WebTrust) to get it. I do not know
exactly why that is, (I'm sure someone here will be glad to tell us)
but here are some observations about it.
Most of the problems with technically erroneous certs have come from
the CAs that are free, mostly users of OpenSSL, many from universities.
The CAs with money don't have these problems, not very often.
CAs with money have not (in my experience) tried to issue certs that
completely hide the identity of the party to whom the certs are issued.
Yet many free CAs seem to want to do that all. It seems that they want
to provide anonymity more than assurance.
CAs with money have generally not (with one notable exception, in my
experience) issued certs with invalid public keys in them. People
trying to run free CAs seem to have this problem a lot.
In the last month, I have seen certs from one free CA that:
- had an invalid key
- had NO name but the DNSName, which technically belongs not in
the cert subject name, but in the "subject alt name". Had that
DNSName been where it belonged, the cert's subject name would have
been empty!
In that time, I have seen no keys from any other CAs with these failings.
Now, why is this? Why is the distribution of problem certs so one sided?
Perhaps the CA operators with money at risk want to take the time to
get it right, and the freebies want to cut corners to remain low cost.
Perhaps the CAs with money are able to hire people who have learned
the standards and appreciate the value of standards conformance,
while the freebies think that OpenSSL *IS* the standard. :(
My point is this: the past policies of charging money or requiring a
stamp of approval that costs money have (IMO) served the mozilla community
well, in terms of keeping "duff" certs out. MF has not historically
set forth my "duff" criteria above, nor required that CAs avoid them,
yet magically, mozilla's trusted CAs have managed to rarely issue
duff certs!
Now, MF is apparently doing everything in its power to take away the
one thing that (IMO) has kept the standards of certs high, usably high.
IMO, MF needs to raise standards in other areas to keep the duff certs out.
If money is no longer a barrier, then the standards of quality must be
stated in other ways, perhaps technically detailed ways, to keep the
issuers of duff certs out.
It will simply be a disaster if more duff certs start to be encountered
by mozilla users in large numbers. In the past I have replied to
hundreds of bugs reports by ignorant OpenSSL users who accused mozilla
of being buggy because their invalid certs didn't work with mozilla.
But I'm all done with that. I simply won't do in any more.
If issuers of duff certs are admitted, the flood gates will open.
products associated with a list that includes duff issuers will be a laughingstock.
Frank, will *YOU* answer all those bug reports, explaining what's wrong
with their certs? If not, who will? Not me.
Now, I want to summarize this. IMO, it turns out that COST has been the
only factor responsible for the apparent success of PKI, having kept the
issuers of duff certs out, and having allowed the issuers of good certs
in. It wasn't the WebTrust criteria that kept them out, it wasn't the
ETSI TS 101, it wasn't nosy auditors, it was cost.
Perhaps cost has also kept out some potential issuers of good certs.
That is unfortunate. But in the security business, I think we have to
err on the side of caution, on the side of security. This isn't
"innocent until proven guilty". This is "untrusted until established
as trustworthy". The only value that PKI/crypto offers is trustworthiness.
If we lose that, we've lost the war.
If you eliminate cost as a barrier, you MUST erect another barrier that
will be as good as cost in keeping the duff issuers out (while the
binary model remains).
At present, Draft 11 doesn't seem to keep out issuers of certs that
have invalid keys, empty cert names, etc. Those things were kept out
by COST in the past. What will keep them out in the future?
Will Draft 11 keep out an issuer of certs with names empty except for
DNS names? Will draft 11 keep out issuers of certs with invalid keys?
> 1. I suspect that adding the other criteria (X9.79 and ETSI TS 101 456
> and 102 042) is not at issue,
Certainly those criteria are no weaker than WebTrust. Maybe even
stronger. But will they keep out issuers of certs with invalid keys,
with empty names? with invalid combinations of cert extensions?
> 2. Permitting "non-traditional" evaluation of CAs is certainly something
> that one could imagine increasing risks, if the people doing the
> evaluation don't do a good job.
Doing a "good job" has to be defined in such a way that a good job
keeps out duff issuers. I'm less worried that a non-traditional
evaluator will be dishonest than that he will not know what to look
for to keep out the duff. Certainly no financial auditor would.
> But this may or may not be at the root of your concern, so let me ask
> directly: In your opinion, would permitting such "non-traditional"
> evaluations contribute to the increased risk you perceive? If so, is it
> the only factor increasing risk? A major factor? Just a contributing
> factor relative to other factors (like the one I'll discuss next)?
> If you do believe that permitting non-traditional evaluations would
> increase the risk of "duff certs" being issued, what would you recommend
> we do? Tighten the requirements on when we'd allow such evaluations? Or
> drop the idea entirely, and require that all evaluations be done by
> authorized auditors and test labs?
Well, my first goal is: keep duff cert issuers out.
Now, if we can accomplish that by tighter requirements (and I think
that is possible), then that seems very desirable. That would be
my first choice.
If we cannot or are unwilling to take that approach, then yes, I'd
advocate continuing to require that all evaluations be done by
authorized auditors and test labs. We'd be falling back on the old
tried and true method of keeping duff issuers out. But that's not my
first choice.
> The consequence of the latter would be to keep CAcert.org out of the
> list permananently, or at least until they could afford a WebTrust or
> other audit. It would also keep other CAs out that haven't undergone
> WebTrust or equivalent audits; for example, I think there's a CA
> associated with a German university/research consortium that would be
> affected by this, and I think a couple of others as well.
It seems to me that the parties who would be CAs fall loosely into
two camps:
Camp a) the people who understand that being a CA isn't merely about
running OpenSSL to make certs, but that it's about trustworthiness,
about telling the truth to the people who would rely on them.
These people take the time to do it right.
From the outset their efforts appear to be well done, technically done
right, causing no problems for browsers, email clients, whathaveyou, etc.
They promote themselves on the good job they do, and the due diligence
in the verification of subjects' identities, in the trustworthiness of
the certs they issue, and (eventually) on their good track record.
Camp b) the people who don't understand that the value of a CA is its
trustworthiness. They think that CAs who charge money are just taking
money for nothing more than running OpenSSL. They think anyone who
can run OpenSSL can and should be a CA, making certs, and their certs
should be universally accepted, etc. Offering assurance is less
important to them than having and offering free certs.
From the outset, these people's certs have lots of problems. Invalid
keys, invalid extensions, invalid cert names, duplicated serial
numbers. They demonstrate unfamiliarity with and unawareness of the
standards. They seem unaware of the kinds of attacks that might
easily undermine their lax authentication, etc. But they're determined
to make their certs and be accepted alongside the folks in group a above.
They say "I haven't yet read the cert standards, but I demand to be
treated as an equal with Verisign, Thawte, Comodo, etc.".
They promote themselves on the basis that they don't charge money,
they can run OpenSSL as well an anyone else, they're not corporations,
they're lost cost, they're non-profit, (did I mention free?), and
even on their egalitarian ideals, but NOT on their expertise, nor
their taking of care, nor their due diligence, etc.
The ideal is to let all persons in group a in, regardless of the money
they have or the money they charge (or don't charge), and keep all
persons in group b out, also regardless of the money they have (or
don't have) and charge (or don't).
> 3. Regarding requirements on CA validation of their customers, I
> certainly don't have any such requirements in my current "WebTrust or
> equivalent" policy, so in that sense the proposed new policy is more
> stringent than the old policy.
Somewhat, yes.
> Did Netscape have such requirements?
No, they required $$$$. Ever notice how the supply of PSM developers
ended at about the same time as the trusted CA money stopped? Hmmm.
> However with regard to SSL certs in particular I will note
> that there are already CAs issuing "domain-validated" certs, e.g., the
> Thawte ssl123 and Go Daddy TurboSSL services, and to my knowledge such
> CAs are already in the default Mozilla set and usable with Firefox, etc.
I don't know what you mean by "domain-validated". Sorry. So I cannot
speak to the worthiness of "domain validated" cert issuers. However,
I will say that I think domain registrars are almost ideal candidates
to be SSL CAs. They need to do due diligence, but they're already
getting the registrant's info. If they can verify it, and if
registering the domain isn't a problem (e.g. with phishing), then
who better than they to certify that so-and-so owns the XXX.XXX domain?
> (There may also be other CAs like this as well, but I haven't had time
> to do a thorough check.) Has this resulted in significant issuance of
> "duff certs"? Apparently not, or I presume you would have mentioned this.
The only problems with GoDaddy certs that have been reported to me is
that many of their cert holders have not been instructed on the
necessity of installing their full server cert chains into their
servers, so they serve incomplete cert chains, and get cert chain
validation errors. This is merely a user education issue, not a
security vulnerability.
> So, I ask you: In your opinion, would explicitly permitting such
> "domain-validated" certs (as opposed to the implicit permission we've
> apparently had previously) contribute to the increased risk you
> perceive?
I cannot answer that question without knowing all the implications
of the term "domain-validated certs". Sorry. You asked lots of
good questions about the relevance of domain-validated certs, and
I just don't know what that term means. So, I'm deleting the
paragraphs of questions about that term.
> Finally, let me consider some larger issues. Forgive me if I'm missing
> something, but I'm getting contradictory impressions here. On the one
> hand I get the impression that you and others believe that historically
> there have been minimal problems (and hence minimal risks to users)
> resulting from CA practices and the selection of CAs to be included in
> the Mozilla default set. Now that I'm proposing this new policy I get
> the impression that you and others believe it will result in significant
> problems and significant risks to users, even though the sorts of CAs
> and CA practices permitted under the new policy are AFAICT basically the
> same sorts of CAs and CA practices that were permitted under the old
> policy.
I understand. I submit that the COST of the old policies had the
mysterious and wonderful, desirable and yet coincidental, side effect
of admitting only serious rather-competent CAs, even though the old
policy lacked technical specifics related to identifying and prohibiting
duff behavior.
In the absence of that protective factor (which was undesirable in
many ways), MUCH MORE needs to be done (IMO) to draw a clear line
against which duff cert issuers may not cross.
> (The major exception to this is the possibility of including CAs like
> CAcert.org based on non-traditional evaluations; but I'm not clear there
> whether non-traditional evaluations are the sorts of your concern or
> whether it's domain-validated SSL certs and other low-assurance certs.)
I have nothing in principle against free CAs, nor against CAs who use
web of trust (if done right and taken seriously). Indeed, I would
hold up Thawte as an example of such a CA that is apparently done
very well. I would like very much to see another free CA
> The only way I can personally resolve this contradiction is to conclude
> that it's not the policy in isolation which is at issue, it's the policy
> in combination with the new environment in which protecting against
> phishing has become a top priority. In other words, while existing
> policies (which in practice permitted things like domain-validated SSL
> certs) may have been good enough way back when,
Existing policies have succeeded largely (IMO) due to a component they
did not explicitly state: cost. The rest of the requirements were
less important than that one. With that removed, the rest of the
remaining (previously stated) requirements are not (IMO) good enough
to assure that a cert is "good enough for banking".
Regarding phishing: Phishing is merely one aspect of the problem of
lack of authentication with network peers. A victim of phishing is
dealing with someone over the net, while having a mistaken understanding
of who he is dealing with. This is the same problem as the MITM attack
presents, exactly the same. You think you're dealing with Alice, but
you're dealing with Evil Eve.
At the same time that phishing (one form of attack based on inadequate
authentication) is getting so much press, some who tout SSL to be a big
part of the solution have also called for allowing self signed certs to
be treated as equals with certs from high assurance CAs. Oy!
I'm not more interested in SSL as a solution to phishing than for SSL
authentication as an ongoing assurance provider for banking at home.
In fact, I'm more concerned for the latter.
In any case, as long as the binary UI model remains, I want mozilla users
to have no doubt about using SSL with their bank.
> any new policy has to be
> more stringent in order to counter the increased threat; it's not good
> enough for us to just continue and formalize existing de facto
> practices, we have to add some more requirements over and above what has
> been done in the past.
Yes, I agree with that. At least as long as the binary model remains
the only model in the UI.
> Is this what you and others are arguing? If so, it's a perfectly
> legitimate argument to make. But if you and others want to make this
> argument (i.e., that policy needs to be more stringent in this new
> environment) then I believe it's incumbent on you and others to a)
> propose in some level of details what more stringent requirements we
> should actually impose, and b) explain how those requirements will
> actually reduce the risks experienced by ordinary users.
The users have benefited from the high levels of assurance offered
by the existing trusted CAs. They have come to expect that level of
assurance. To lower that level of assurance without providing any
notice to the users of same is IMO unethical, and will hurt users.
> I think such a detailed justification is necessary because there are
> consequences to adopting more stringent policies: We're talking about
> eliminating (i.e., no longer accepting as valid) uses of things like
> domain-validated certs that are currently in use (with apparently no
> problems resulting), and closing off the possibility of such uses in the
> future.
I think you're assuming that my position is anti-domain-validated certs.
Since I don't know what those are, I am not (presently) against them. :)
> We're in essence saying that use of SSL in e-commerce and
> financial applications is our primary concern, that the risks associated
> with SSL in such applications require us to adopt as stringent a set of
> rules as we can, and that all other uses of SSL have to play by the same
> rules, whether they make sense in other contexts or not.
The binary UI model causes that. We're (er, I'm) saying that as long as
the UI model remains binary, the standard must be "good enough for banking",
because that is what all users understand it to be. When the UI model
allows a clear indication of "not good enough for banking", then let the
low-assurance CAs in.
> I know you're busy and don't have time to create such a detailed
> justification, but I certainly wish someone would.
The person who is missing from these debates is the person responsible
for mozilla browser crypto security, the PSM guy, who doesn't exist.
Sigh.
It's late, I'm tired, eyes aren't really focusing here. I apologize
for typos.
Disclaimer: All descriptions of persons or groups of persons above
are based on composites of descriptions of many people. Any similarity
to any particular person, living or dead, is purely coincidental.
--
Nelson B
Frank Hecker
<snip>
First, thank you for taking my comments in the spirit in which they were
intended, and for responding to them in such depth. I don't have time to
respond to you in depth right now, but I do want to clear up one key
point, as noted below.
> > However with regard to SSL certs in particular I will note
> > that there are already CAs issuing "domain-validated" certs, e.g., the
> > Thawte ssl123 and Go Daddy TurboSSL services, and to my knowledge such
> > CAs are already in the default Mozilla set and usable with Firefox, etc.
>
> I don't know what you mean by "domain-validated". Sorry. So I cannot
> speak to the worthiness of "domain validated" cert issuers.
By "domain-validated" certs I mean SSL certificates for which the CA
verifies that the cert holder owns the domain for which the cert is
issued, but does not do identity verification beyond requesting a name,
credit card number and expiration date, and billing address for the
card, and then doing some basic checking of that information: Is the
card valid? Does the info match the info from the Whois database? Does
someone verify the request's validity in response to an email sent to
the administrative/technical contact for the domain? Typically this
whole process is automated, with no humans in the loop, and certs can be
issued within a matter of minutes.
Again, see the Thawte SSL123 and Go Daddy TurboSSL web pages for
real-life examples of such services:
http://www.thawte.com/ssl123/
https://www.godaddy.com/gdshop/ssl/ssl.asp
> However,
> I will say that I think domain registrars are almost ideal candidates
> to be SSL CAs. They need to do due diligence, but they're already
> getting the registrant's info. If they can verify it, and if
> registering the domain isn't a problem (e.g. with phishing), then
> who better than they to certify that so-and-so owns the XXX.XXX domain?
As it happens, I agree with you 100% on this point, and for various
other reasons I believe that eventually most if not all commercial CA
services will end up "embedded" into domain name registration services,
and there will be few if any stand-alone commercial CAs anymore. I'll
say more about this in my reply to Ram0502 (hopefully tonight), and may
blog about it as well.
Ian G
> 4. (recent addition) certs used with phishing, including:
> - certs with names confusingly similar to other domains, e.g.
> paypal-security.com
> - certs with IDN/punycode names that look like well known names
> but aren't exactly.
One might add to that category:
- certs with names that are confusing but have no
apparent hook to the target: compliance-center.com
Or maybe it's a new category.
> > Second, you seem to be saying that under the past and current policies
> > for adding certs to the Mozilla default set (as implemented by Netscape
> > and then myself) there has been minimal issuance of "duff certs"
> > (however defined), but that under the proposed new policy the issuance
> > of "duff certs" could be substantially increased. The implies (at least
> > to me) that such an increase in "duff certs" would be specifically
> > caused by adopting the new policy, to the exclusion of other
> factors. Am
> > I reading you right here?
>
> Yes. Now before I respond to any more questions, I must speak to the
> "binary UI security model", because it is crucial to my answers.
> Sorry if this is a bit long winded.
>
> Today, the mozilla products have a binary UI security model. The padlock
> is either open or closed. Period. And for SSL, users understand the
> closed padlock to mean "good enough for banking". In other words,
> high assurance *and* strong crypto.
>
> As long as that remains true, ...
Unfortunately "users understand..." is not true and demonstrably
not followed. Phishing tricks lots of people. Not all the users
check the padlock. Whether this is 10% .. 50% .. 90%
of users of banking ... I don't know. Whether we can
"save" them I also don't know.
What is true is that the binary UI security model is
essentially what's on offer today, modulo various
improvements in the the recent flush of browsers.
> as long as the padlock is either open or
> closed, and no other info is presented to the user IN THE MAIN WINDOW
> on which the user can judge the quality of the cert/CA, then IMO the
> standard for closing the lock on a web page is, and must remain,
> "good enough for banking", and "high assurance". It would be UNETHICAL
> for us to allow low assurance CAs to be treated identically to high
> assurance CAs (appearing to be "good enough for banking"), yet the
> present UIs provide no way for a distinction to be presented.
OK, I see where you are going. In the face of the
facts that a) the padlock is not often checked, and
b) that it is easily bypassed by non-SSL phishing,
I personally wouldn't be comfortable with any
argument that relied on the padlock as a standard.
Given, c) it is apparently easily bypassed for SSL
phishing (c.f., Shmoo), I would say that the padlock
only represents your "low assurance" grade.
> MAJOR POINT, that binary UI model is strictly the result of UI decisions
> made by the browsers, and not the result of NSS. The UI people MUST
> be willing to devote more screen real-estate to security info before
> the binary security model can be eliminated.
Yes. I think we are all agreed on that. It's for
this reason - that tough painful statement - that
we are somewhat stalled on this until some
MF wide approach is taken.
[Toothy history chomped :]
> a) go back to a iconic model that has clearly 3 or more states, which
> are OBVIOUS to users in the chrome of the MAIN WINDOW, without the user
> needing to click or move the mouse to see the info,
The problem with this is that while you suggest that
the 2-n extra states had semantic meanings like "good
enough for banking," no such real security statement
applied. Historically, this was a case of the crypto
warriors capturing finance as a pithy way to say that we
wanted 128-bit-or-die. But in actual security systems,
it makes no difference whether it is 40 bit or 128 bit
for banking as an application. The difference in security
for banking is all in the CA and cert and identity questions,
and not in the strength of the on-the-wire crypto.
> b) go to a model that identifies the CA, and allow the user to decide
> for him/her self whether the CA is high or low assurance. The CA could
> be identified by text (a name) and/or a "FavIcon" as web sites are now.
> The browser could help the user remember his decision, and allow him to
> change it.
>
> The first method is visually the most simple, but requires someone to
> make a judgment call on the user's behalf concerning the assurance
> level of the CA. I think this is least confusing for the users, but
> more work for MF and NSS.
Yes, this is true as well. Not just more work, but also
more involvement than is advisable. Also, given the
contentious nature of the statement that it's good
enough for banking, that suggests non-trivial risk.
> The second method requires the users to grow their awareness of CAs
> (of which they know nothing today). It also requires more window
> real-estate. But it keeps MF out of the judgment business, which is
> a business that MF seems particularly loath to do.
Yes. It is somewhat the case that there is no painless
way forward. Someone somewhere is going to hurt.
> ....
> Now, why is this? Why is the distribution of problem certs so one sided?
>
> Perhaps the CA operators with money at risk want to take the time to
> get it right, and the freebies want to cut corners to remain low cost.
> Perhaps the CAs with money are able to hire people who have learned
> the standards and appreciate the value of standards conformance,
> while the freebies think that OpenSSL *IS* the standard. :(
>
> My point is this: the past policies of charging money or requiring a
> stamp of approval that costs money have (IMO) served the mozilla
> community
> well, in terms of keeping "duff" certs out. MF has not historically
> set forth my "duff" criteria above, nor required that CAs avoid them,
> yet magically, mozilla's trusted CAs have managed to rarely issue
> duff certs!
This is potentially true. Problem is, this "barrier to entry"
as it is known has also served to keep valid cert usage
down as well.
> It will simply be a disaster if more duff certs start to be encountered
> by mozilla users in large numbers. In the past I have replied to
> hundreds of bugs reports by ignorant OpenSSL users who accused mozilla
> of being buggy because their invalid certs didn't work with mozilla.
> But I'm all done with that. I simply won't do in any more.
> If issuers of duff certs are admitted, the flood gates will open.
> products associated with a list that includes duff issuers will be a
> laughingstock.
>
> Frank, will *YOU* answer all those bug reports, explaining what's wrong
> with their certs? If not, who will? Not me.
This is definately an issue. I'm not sure I see it as
a killer issue though, it seems that this sort of issue
exists with all software.
> Now, I want to summarize this. IMO, it turns out that COST has been the
> only factor responsible for the apparent success of PKI, having kept the
> issuers of duff certs out, and having allowed the issuers of good certs
> in. It wasn't the WebTrust criteria that kept them out, it wasn't the
> ETSI TS 101, it wasn't nosy auditors, it was cost.
Well, I have a different perspective. As you know,
I consider PKI to be a stunning failure, partly because
it is so expensive that its usage rates are down in the
noise level, and partly because it set itself up to defend
a threat that never eventuated. That isn't the CAs
fault. Well, maybe, maybe not, but the blame game
helps no-one.
What we have now is that the PKI is in place with all
browsers and all web servers. That's a fact. So it is
the starting point to addressing the security failure
of secure browsing. We can use the PKI certs to deal
with phishing to a substantial extent, but it requires
some changes...
Getting back to the cost issue. If we decrease the
cost of certs, then we decrease the cost of duff
certs. I'd hazard a guess that the cost of a duff
cert (for phishing) is about $100 - $1000; this will
lower it to $10, say. As phishing is pulling in a billion
or so every year, I don't see this as a big deal.
However, what is a big deal is how we move from
"no user interaction" to "user-based security model."
Lowering the cost of all certs will help that. I think
it will focus attention on the problem, and the faster
that happens, the better. Preferably faster than
the phishers switch to SSL; as once they do that,
the waters get very murky very quickly. IMHO.
> Regarding phishing: Phishing is merely one aspect of the problem of
> lack of authentication with network peers. A victim of phishing is
> dealing with someone over the net, while having a mistaken understanding
> of who he is dealing with. This is the same problem as the MITM attack
> presents, exactly the same. You think you're dealing with Alice, but
> you're dealing with Evil Eve.
Right.
> At the same time that phishing (one form of attack based on inadequate
> authentication) is getting so much press, some who tout SSL to be a big
> part of the solution have also called for allowing self signed certs to
> be treated as equals with certs from high assurance CAs. Oy!
:-) I detect my name hidden there. I think the
debate over self-signed certs is way too complex
for here, so I've left it alone. A full security
analysis of the self-signed cert v. CA-signed
cert is a rather complex business, and not
helped by the heated opinions.
But one can say that they are not equal and
should preferably not be treated as equal.
(Presenting both self-signed certs and CA-
signed certs to the user would be one way
in not treating them as equal!)
iang
PS: This also is a rushed post, I'm in Austria
at the moment, and happen to be jacked in at
the offices where the NSA scandal broke. A
total accident, I assure you! Here, it is huge
news, we are currently listening to a long
interview on national radio about the NSA,
but it's in German and therefore I can only
hear the remotest snippets.
While I'm on the subject, those who are interested
in the identity debate should check out the story
because the breached information includes a lot
of political background. Search on "datamining
the NSA" or check slashdot.
Frank Hecker
> I think there are potential applications of PKI outside phishing
> prevention and further that PKI by itself is not a perfect solution.
> There are plenty of things that could be done to improve the safety of
> netizens; some risks or aspects of risks can be mitigated by use of
> public key technologies. Different approaches and different
> applications could have different requriements.
Thanks for your comments; it's always good to see new perspectives in
these discussions.
> The root list management approach to date in MF and Microsoft has been,
> more or less, to identify the CA legal entity and require that they
> document their policies and practices and undergo an audit. Both
> Microsoft and Netscape used to charge a huge amount for inclusion in
> their root lists which ensured the CAs had something to lose if their
> brand was tarnished, but it also kept smaller CAs off the list (it may
> be worth noting that quite a few of the CAs commonly trusted have been
> bought or sold or gone bankrupt - what policies and practices survive
> change of ownership?).
Also worth noting is that buying an existing CA was one way in which new
CAs could enter the market and have their certs automatically accepted,
rather than having to go through the process of trying to get each and
every browser vendor to include their own (new) root certs. Another way
to bypass the browser vendors was to get yourself set up as a
subordinate CA to a root CA whose cert was already in all the browsers.
In effect what we had (and still have to some extent) was a situation
where the browser vendors artificially constrained supply in the CA
market, and companies had economic incentives to find ways to evade
those constraints. I also think these artificial limits on competition
in the CA market caused prices for certs to remain higher than they
otherwise might have.
In many ways the dynamic playing out in the CA market today reminds me
of what happened to the domain registration market over the past few
years: moving from a near-monopoly situation to a more fragmented market
as artificial constraints on the market are gradually removed. This
prospect may be alarming to some people ("what? CAs descend to the level
of domain name registrars?") but I think it could actually be to our
benefit, for reasons I alluded to previously: a fragmented market with
low market share for any given CA makes it easier to remove CAs if
needed without causing excessive disruption to users.
In any case I think there are powerful economic forces driving this
transformation of the CA market, most notably forces driving commercial
for-profit CA services to become just one of many ancillary services
offered by integrated "web presence" vendors, along with domain name
registration, web site hosting, email service, blogging systems,
e-commerce hosting and back-end payment processing, etc. I hope to blog
more on this soon (plus see my comments below).
> An advocate in nmpc suggests driving broader adoption of SSL by
> changing the trust model in combination with loading additional
> financial exposure on the CAs (ie make their brand/reputation suffer
> for their mistakes and weaknesses). Others advocate raising the bar for
> entry into the root list through other means. I think there is merit to
> both approaches.
I think a lot of this debate comes down to the following: Do we try to
hold on the traditional notions of what a CA is and does, or do we try
to adapt to how the role of CAs might change as time goes on? Clearly
there is a lot of sentiment in this forum that things like
only-domain-ownership-validated SSL certs and low-assurance email certs
represent a falling away from the traditional standards that CAs should
meet, and may be the source of potential security risks (e.g., those
related to phishing). As I've said before, this is a perfectly
legitimate position to take.
On the other hand I think domain-validated SSL certs and other
lower-assurance certs are not going to go away, and if anything I think
they'll become more popular, because they meet the needs of a big
portion of the potential customer base for certs. The thoughts on
branding put forth by Ian and others to some extent represent proposals
on how to manage this market transition in a controlled way, by making
the CA market more like a "normal" market where people make their
decisions based on their perception of vendors and their brands, as
influenced by advertising, independent evaluations (e.g., Consumer
Reports, J.D. Powers, etc.), and others' experiences.
However I don't think Ian is going far enough in his thinking. My
hypothesis is that in a few years there may not be a CA market in the
traditional sense. Instead it may be subsumed into the broader market
for "web presence", and "CA branding" really becomes proxy branding for
web presence providers. Consider a situation where a person or small
business goes to "WebPresence Inc." and does the following:
* registers a domain
* signs up for web site hosting
* contracts for various add-on services from a menu of services:
* IMAP and/or webmail accounts
* blogging facility (to create public and/or private blogs)
* chat room(s) (for public or private chat)
* streaming media service (to serve up audio or video content)
* advertising service (to serve up contextual ads)
* Internet storefront
* back-end payment processing
* and so on...
Oh, and by the way, they sign up for an SSL cert for their domain, and
maybe also email certs for their bundled email accounts.
What does "CA branding" do then? It shows that "www.mylittlewebsite.com"
is a "WebPresence site"; in other words, it advertises "WebPresence
Inc." to every person viewing the site, each of whom represents a
potential customer for "WebPresence Inc." IMO this significantly changes
the terms of the debate between Ian and Gerv about how end users might
respond to CA branding (e.g., by switching their custom from one
Internet store to another based on the first store using a dodgy CA),
because it changes the purpose of the branding from a "Seal of Approval"
model to a "Powered by Foo" model.
From this point of view "CA branding" becomes the web equivalent of the
email signature tags inserted into messages by Hotmail and other
providers. (And we all recall the great success of that practice in
marketing Hotmail and other services.) And like those tags, "CA
branding" doesn't depend on the site owner doing something (like
inserting a "Powered by WebPresence Inc." graphic), the branding "just
happens".
(Again, this whole topic of "CA branding" and how it might evolve is
something else I hope to find time to blog about.)
> It seems to me that internet use is increasing and therefor so is the
> value to be garnered by criminals. I expect the approach criminals take
> will be path of least resistance and that the particular attacks will
> vary substantially to work around changes in the landscape. So what do
> we do? I don't expect we will find one new technology or enhancement to
> an existing technology that will solve all our problems. I think the
> right approach is to be practical and improve things even imperfectly.
I will go further and state that our goal should be to adapt to changes
occuring in CA market, as opposed to trying to hold back the tide, and
to do so in a way that provides a smooth "glide path" to whatever the CA
business will look like in the future. This means:
* putting standards in place that are consistent with the way CAs
currently operate and are likely to operate in the future (as opposed to
the way CAs were envisioned back in the dawn of the web)
* encouraging (not discouraging) more competition in the CA market and
welcoming new entrants as long as they meet our minimum standards, in
order to reduce the dominance of any one CA and make it easier to "turn
off" a CA if this is ever needed (remember -- a threat that can't be
carried out is not a credible threat)
* looking at some sort of "CA branding" scheme that provides something
for users, CAs, and us
> So to the topic at hand - what about the MF policy for PK root
> inclusion. My opinion is that there are many approaches we could take
> to improve the security proposition some will require a lot of work
> others less. The following are a few of my thoughts and suggestions.
>
> For practical reasons I think it is easier to be tougher on the
> admission and more lenient on the removal side as it is much more
> difficult to orchestrate a reasonable removal without unduly damaging
> innocents such as web site operators who chose a CA that was later
> removed from the trust list.
Agreed, but removal becomes easier as average CA market share drops.
Also, we have options short of actual removal; for example, we can put
in "informational bars" (not popups) with warnings to the user.
> I don't believe the bar can be set high enough on admission to the root
> list that it can be left unmaintained nor do I believe that any CA is
> capable of operating perfectly against strong policies such that thinks
> like revocation don't matter.
>
> I propose a requirement that every CA whose certificates will identify
> ecommerce sites or software publishers must support revocation checking
> through standard means, say a CRL or OCSP pointer in every certificate.
> This could have an SLA aspect such that the OCSP or CRL not lapse (the
> CRL pointer should never point at a CRL whose next-udate time is three
> days ago).
These are good suggestions. The only problem is that Mozilla-related
products do not enable CRL or OCSP checking by default, so this is
irrelevant for typical users who do not change the default settings.
(Apparently there are code issues preventing us from pre-loading CRL
information; CRLs currently have to be downloaded "by hand". The
long-term solution is presumably parsing and acting upon CRL-related
information in certs, e.g., the CrlDistributionPoint extension or
whatever it is. There may also be a kludgier short-term way to turn this
on using, e.g., a Firefox extension. But again, "we need a patch", as
the saying goes.)
> I think presentation of the CA logo leverages natural human and market
> systems to drive quality up for the consumer but practically this seems
> to be difficult as there is a UI real-estate issue - perhaps in time we
> will see the UI issue resolved through client software competition.
It's quite possible that it will take inclusion of "CA branding" in IE
(assuming Microsoft does this as part of an overall anti-phishing
strategy) to prompt Firefox developers to take a closer look at this.
That's not necessarily a bad thing; Firefox has certainly looked to
other browsers in the past for ideas about new features, and is none the
worse for having done so.
> Finally I think there is merit to having different requirements for
> different applications of PKI. Compare the risks of interacting with
> your bank, installing software, and logging into your favorite internet
> portal so it recalls your content preferences. In the banking case I
> really care about authentication and encryption as does the bank. If
> you interact with your bank from your computer than you (and your bank)
> both care about what software you install. A few good keylogging
> attacks in the press and we may see the priority of software publishing
> security increase.
We also IMO have some work to do in this area as well, for example doing
a better job of protecting the integrity of mozilla.org software
downloads and updates, using digital signatures and other techniques.
Gervase Markham
> Fair enough. So let me ask a specific question: If the level of cert
> assurance is the key issue, do you believe that the binary security UI
> in combination with potential threats of phishing attacks justifies
> rejecting CAs that issue "domain validation only" certs, and removing
> any such CAs' root certs from the current default set?
Would it be possible for the browser to programmatically tell when an
SSL connection is secured by a "domain validation only" cert? (I suspect
not, but it's worth asking.)
One thing I've become more convinced of over the last few weeks is that
our UI needs a "site identity verified" indicator which is separate from
the SSL indicator. Site identity could be verified by SSL, but also if
we used DNSSec to look up the name. DNS attacks are the next step in
phishing as users get wiser.
So perhaps the solution is to stop showing the lock for such certs, and
merely show the "site identity verified" indicator.
(FWIW, the indicator might be making the domain name in the status bar
bold - but that's just off the top of my head; there may well be better
UIs.)
> If so, how would
> you justify doing this? (By which I mean, what is the detailed argument
> that would lead to this conclusion, expressed in terms appropriate for
> publicly justifying such a policy to everyone who might be affected by it?)
Thinking about it, it's certainly hard to justify maintaining both a
binary security UI and keeping such CA root certs.
> Second, as a future point we *do* have two independent products now,
> Firefox and Thunderbird, with two separate application domains, and even
> if we have a binary security model in terms of any given product it's
> not out of the question that we could have different models for
> different products, e.g., have a different default set of CA certs for
> Firefox than for Thunderbird.
Very good point.
> But of course like many other
> suggestions this too depends on future product changes that we'd have to
> find developers to implement...
If the Foundation is serious about the security push this year, it
should be hiring developers to work in this area. If we end up with a
list of bugs they should fix and an order, so much the better.
Gerv
Gervase Markham
> I'm not sure what your objection to brand is?
You continue to assert that I "object to brand". I'm well aware of the
power of branding in people's lives; I'm also aware that very often
brand perception doesn't match reality, that branding favours those with
large marketing budgets.
Several people on the list have commented that Verisign have not behaved
well as a CA. Regardless of the truth of those claims, I assert that if
CAs were strongly branded in the browser UI, and someone did a survey,
Verisign would be the brand with the highest level of trust, because
they have the marketing dollars to send that message.
That's not my only objection, mind you - you can add that one to the
previous ones I've outlined about user confusion when something changes.
> Let me put it another way. What would be
> the damage of putting the brand of the CA
> on the chrome? What would be the hurt?
>
> A loss of real estate?
That's one key factor. There's limited room in the status bar, and I
want to try and restrict the security UI to that area to get a good
balance between security needs and the needs of web apps. If there's
other information we want to be displaying (the words "first visit" or
"new site", for example).
Note that ideally our security UI would be fully visible on the smallest
possible popup, which I believe is either 100 or 150px wide.
> If that's the only loss,
It's not. The other loss is in increased complexity. The longer a user
has to consider the security UI, the less likely they are to bother to
look at it at all.
> I have to admit I really have a problem in
> dealing with that, because phishing costs
> a billion a year and rising.
That's a straw man - you're assuming that this will have an effect, and
it would have a greater effect on phishing than other things we could do
in that space.
Gerv
Gervase Markham
> Given, c) it is apparently easily bypassed for SSL
> phishing (c.f., Shmoo), I would say that the padlock
> only represents your "low assurance" grade.
Do not use the Shmoo Group IDN exploit as an example of "being easily
bypassed". The community has reacted very strongly to this problem for a
reason; I don't think you will see many IDN exploits in the future,
because the browsers are going to lock things down on a per-TLD basis so
each TLD has to convince them (or a trusted third party, perhaps) that
they have sufficient anti-homograph policies in place.
Gerv
Gervase Markham
<a great deal of sense>
The meta-message Nelson's post gives me is that we would be highly
foolish to ignore his expertise and experience and implement a CA
certificate policy with which he was unhappy.
Gerv
Gervase Markham
> My conclusion is that outside of the top CAs we could remove any CA in
> our list and the immediate consequences would be pretty limited.
Given the very interesting data you've shown; I'd concur. I was thinking
of the big ones when I made that comment.
Gerv
Frank Hecker
> Would it be possible for the browser to programmatically tell when an
> SSL connection is secured by a "domain validation only" cert? (I suspect
> not, but it's worth asking.)
This is difficult for a couple of reasons:
* There is no uniform mechanism by which CAs indicate in the cert itself
what level of assurance (or alternately, what type of subscriber
validation) is associated with the cert. Some have suggested that CAs
standardize on a way to do this, but this is a future possibility not a
present reality. We could attempt to look at each root CA and make an
individual determination as to what type of validation they were
performing, and then make our own classification (e.g., through our
keeping a separate list mapping CAs to assurance levels or validation
types), but ...
* Often CAs will have a single root CA cert and then multiple
intermediate CAs under that root to actually issue certs to end users,
with one intermediate CA issuing "low-assurance" certs and another
(under the same root) issuing "high-assurance" certs. This makes it more
difficult to create a CA "assurance level" list as described in the
previous item, and also makes it difficult to reject a CA due to their
issuing low-assurance certs without also rejecting their high-assurance
certs as well.
(One way around this is to explicitly store intermediate CA certs in the
built-in list. Nelson and others have previously been against this idea
for various good reasons, but we may have to end up looking at this.)
Frank Hecker
> The meta-message Nelson's post gives me is that we would be highly
> foolish to ignore his expertise and experience and implement a CA
> certificate policy with which he was unhappy.
Gerv, if you review the discussions on n.p.m.crypto over the past few
months, plus the iterated drafts of the proposed CA certificate policy,
I believe you will find that I have tried to address Nelson's concerns
as well as those of others who have participated in the discussion. (And
if Nelson or anyone else believes that this is not the case, then they
are perfectly welcome to speak up and say otherwise, either in this
forum or through private communication to you and others on mozilla.org
staff. I don't mind people complaining if they believe they have valid
complaints, and in fact I encourage people to do so.)
However the problem is (and I don't mean to single Nelson out in this
regard) that we can't have a policy that basically amounts to "we will
approve or reject a CA based on how happy Nelson (or Gerv, or Frank, or
whoever) is with including it". IMO we have to have a policy that takes
the concerns people have and transforms them into policy guidelines that
can be reasonably applied without resorting to too much personal
subjectivity, and can be justified as reasonable given the circumstances
in which we find ourselves.
That is why I am trying to pin down people (including Nelson, but others
as well) as to the exact nature of their concerns and how exactly those
concerns might be reflected in policy. I can understand if as a result
some might perceive me as being skeptical or dismissive of people's
concerns. I certainly don't mean to be dismissive, but I will definitely
plead guilty to being skeptical at times--not to be contrary but rather
to try to get clarity on the various questions at issue here.
Frank Hecker
Understood. However as Nelson notes (and I agree with him) the big CAs
have not historically been a source of problems, and hence I suspect the
likelihood of having to remove one of their certs is probably pretty low.
Ram0502
umbrella policy (VeriSign, Valicert and others seem to do this with
their 'class' markings)
Alex Wight
This is very cost-prohibitive for CAs because of the amount of money
required to set up and maintain Root Cas, especially when they're offline
Roots, as many are. I would highly doubt you would ever get them to change
their business model over something like this.
-a
Alex Wight
_______________________________________________
mozilla-crypto mailing list
mozilla...@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-crypto
Ram0502
the topic you may be able to salvage this post as bed time reading.
Frank Hecker wrote:
> Ram0502 wrote:
> > I think there are potential applications of PKI outside phishing
> > prevention and further that PKI by itself is not a perfect
solution.
> > There are plenty of things that could be done to improve the safety
of
> > netizens; some risks or aspects of risks can be mitigated by use of
> > public key technologies. Different approaches and different
> > applications could have different requriements.
>
> Thanks for your comments; it's always good to see new perspectives in
> these discussions.
My pleasure.
Totally agree. Perhaps this suggests requiring that the WebTrust (or
other audits) are repeated regularly (every N years depending on the
trust-bits) and on certain trigger events (within X months of transfer
of ownership/control of the keys) if the audit/conformance is part of
the MF inclusion policy.
>
> In effect what we had (and still have to some extent) was a situation
> where the browser vendors artificially constrained supply in the CA
> market, and companies had economic incentives to find ways to evade
> those constraints. I also think these artificial limits on
competition
> in the CA market caused prices for certs to remain higher than they
> otherwise might have.
I disagree but I think it would be hard to base a position exclusively
on fact. My opinion is that because of the way the safety of website
interaction is presented to users there may have been and may still see
a backlash against software that doesn't maintain the bar for admission
at a level such that the low point in the fence is not the
authentication of the site. Further that the reasons authentication has
not been attacked very much are adoption rates of ecommerce,
transaction sizes, easy of other (criminal) attacks especially due to
the novice nature of most internet participants. This has been slowly
changing and may reach tipping point in the next year or three
especially as the existing weak points are bolstered through any
variety of means.
>
> In many ways the dynamic playing out in the CA market today reminds
me
> of what happened to the domain registration market over the past few
> years: moving from a near-monopoly situation to a more fragmented
market
> as artificial constraints on the market are gradually removed. This
> prospect may be alarming to some people ("what? CAs descend to the
level
> of domain name registrars?") but I think it could actually be to our
> benefit, for reasons I alluded to previously: a fragmented market
with
> low market share for any given CA makes it easier to remove CAs if
> needed without causing excessive disruption to users.
I agree that a small subscriber base makes a root CA easier to remove;
I doubt that VeriSign (or others in the top tiers) will be caught
'below the line' so I don't see this as a practical concern.
>
> In any case I think there are powerful economic forces driving this
> transformation of the CA market, most notably forces driving
commercial
> for-profit CA services to become just one of many ancillary services
> offered by integrated "web presence" vendors, along with domain name
> registration, web site hosting, email service, blogging systems,
> e-commerce hosting and back-end payment processing, etc. I hope to
blog
> more on this soon (plus see my comments below).
I disagree. I think the reason we are seeing new lower assurance
services appearing is that there are no consequences yet..
I think that the reason the CAs that maintain higher standards (include
revocation pointers in certificates they issue, perform more stringent
authentication, have more secure data centers, and higher SLAs) is that
they have customers to whom it does matter even if their relying
parties don't realize they may want to care. How many banks offer
banking services in non-SSL sites? I suspect that if and when
revocation is turned on by default in IE banks may be less likely to
allow browsers that don't have it enabled where easy (i.e. because the
pointer is in the certificates). I agree with notion that the
expectation the market has set for users is that the padlock or gold
key or gold address bar etc means a site is good enough for commerce
and banking. Being a software publisher that goes along with this
expectation might impose a responsibility to operate under policies
that ensure that expectation is not completely off target. I am not
stating there is a legal responsibility; frankly I have no idea what
the legal grounding of this statement is in any country. I think it is
clear what user base expects and since MF wants to be a user focused
entity I think that statement should already be taken as true.
I don't think control-of-domain certificates nor other low-assurance
certificates are going away. I don't think that control-of-domain and
low assurance are necessarily bound. Consider a company that does heavy
authentication of the ownership of a domain before issuing a
certificate to the domain controller (i.e. making sure it really is
"Mickey Mouse" at "1122 Boogie Woogie Avenue" per the who-is
data ;) - this would of course be more expensive the lower
authentication offering. We may see DNSEC drive domain validation
certificate adoption (assuming the community can agree to deploy
DNSSEC) - I don't' think that changes the nature of the discussion,
what keys will be trusted for DNSSEC? If the requirements for
authentication of a domain name + certificate bundle is high we may see
a very familiar discussion. In any case I think, to your point, there
is a pent up demand for low assurance certificates that can't be
correctly addressed and that the cropping up of low assurance TLS
certificate providers will force the hand of software providers to
change the user expectation and interaction model.
If the bundling is as broad as you propose in this example than I'm
guessing the customer is spending a whole lot of money and is less
likely to be fleeting and so it can live and die by its own brand. If
unbundled offerings are still available and a bad guy can buy (or other
wise get) a low assurance fully trusted by software TLS server
certificates that will be a more cost effective attack that cannot be
prevented without high authentication and cannot be efficiently
recovered from without proper revocation checking and SLAs.
I think I agree with all these points but I would caution that just
because things have been pretty good to date does not mean the current
system is good. I think there is an opportunity to capture the more
price-sensitive would be customers of SSL server certificates that is
driving the change and that this change will result in a demand to
change the model presented in software. This is what I see as the
market force that will drive the alignment of technology with
expectation. To reiterate I don't think that eliminating low
assurance or low service robustness or low SLA roots is the solution as
that eliminates much potential value to society, I think that the
current models in web browsers is not sustainable in the face of the
greater applicability of PKI to society and the distinct needs of
I'll pick banks compared to folks who want to send encrypted personal
email.
>
> > So to the topic at hand - what about the MF policy for PK root
> > inclusion. My opinion is that there are many approaches we could
take
> > to improve the security proposition some will require a lot of work
> > others less. The following are a few of my thoughts and
suggestions.
> >
> > For practical reasons I think it is easier to be tougher on the
> > admission and more lenient on the removal side as it is much more
> > difficult to orchestrate a reasonable removal without unduly
damaging
> > innocents such as web site operators who chose a CA that was later
> > removed from the trust list.
>
> Agreed, but removal becomes easier as average CA market share drops.
> Also, we have options short of actual removal; for example, we can
put
> in "informational bars" (not popups) with warnings to the user.
Today most of the lower bar CAs have little adoption. There are a
handful of CA roots that are responsible for 95% of the market (I'm
guessing) - these CAs are likely to be willing to defend their position
by providing at least best practices in terms of the base technology
like revocation.
>
> > I don't believe the bar can be set high enough on admission to the
root
> > list that it can be left unmaintained nor do I believe that any CA
is
> > capable of operating perfectly against strong policies such that
thinks
> > like revocation don't matter.
> >
> > I propose a requirement that every CA whose certificates will
identify
> > ecommerce sites or software publishers must support revocation
checking
> > through standard means, say a CRL or OCSP pointer in every
certificate.
> > This could have an SLA aspect such that the OCSP or CRL not lapse
(the
> > CRL pointer should never point at a CRL whose next-udate time is
three
> > days ago).
>
> These are good suggestions. The only problem is that Mozilla-related
> products do not enable CRL or OCSP checking by default, so this is
> irrelevant for typical users who do not change the default settings.
This is IMO a failure to take advantage of what's out there - it raises
the bar on those CAs willing to pay the cost of service revocation
information and does no harm to a CA who wants to operate at very low
costs as they would simply not publish CRL nor OCSP pointers in their
certificates. What is the reason MF software doesn't have revocation
turned on by default for at least the automated type of revocation
checking? I've been turning this on for a few years without much issue.
Everyone once in a while I find a site operating with a revoked cert or
with a cert that points at OCSP or CRL but the URL is unavailable.
There is one nasty case that I'm aware of - that of the WISP who uses
TLS/SSL for initial login but doesn't allow access to CRL/OCSP to
authenticate the server credential.
>
> (Apparently there are code issues preventing us from pre-loading CRL
> information; CRLs currently have to be downloaded "by hand". The
> long-term solution is presumably parsing and acting upon CRL-related
> information in certs, e.g., the CrlDistributionPoint extension or
> whatever it is. There may also be a kludgier short-term way to turn
this
> on using, e.g., a Firefox extension. But again, "we need a patch", as
> the saying goes.)
That's ok because CAs can include HTTP or LDAP URLs in certificates
that point at current CRLs or OCSP responders.
>
> > I think presentation of the CA logo leverages natural human and
market
> > systems to drive quality up for the consumer but practically this
seems
> > to be difficult as there is a UI real-estate issue - perhaps in
time we
> > will see the UI issue resolved through client software competition.
>
> It's quite possible that it will take inclusion of "CA branding" in
IE
> (assuming Microsoft does this as part of an overall anti-phishing
> strategy) to prompt Firefox developers to take a closer look at this.
> That's not necessarily a bad thing; Firefox has certainly looked to
> other browsers in the past for ideas about new features, and is none
the
> worse for having done so.
Totally agree. This is a natural and common occurrence. I was proposing
leading change in what I see as being in the web-client users'
interest.
>
> > Finally I think there is merit to having different requirements for
> > different applications of PKI. Compare the risks of interacting
with
> > your bank, installing software, and logging into your favorite
internet
> > portal so it recalls your content preferences. In the banking case
I
> > really care about authentication and encryption as does the bank.
If
> > you interact with your bank from your computer than you (and your
bank)
> > both care about what software you install. A few good keylogging
> > attacks in the press and we may see the priority of software
publishing
> > security increase.
>
> We also IMO have some work to do in this area as well, for example
doing
> a better job of protecting the integrity of mozilla.org software
> downloads and updates, using digital signatures and other techniques.
Totally agree. IMO one of the critical issues here is revocation.
Gervase Markham
> Gerv, if you review the discussions on n.p.m.crypto over the past few
> months, plus the iterated drafts of the proposed CA certificate policy,
> I believe you will find that I have tried to address Nelson's concerns
> as well as those of others who have participated in the discussion.
Sure. Apologies if my message wasn't clear - it wasn't meant to make a
judgement on whether his concerns are or are not being met in the
current draft.
> However the problem is (and I don't mean to single Nelson out in this
> regard) that we can't have a policy that basically amounts to "we will
> approve or reject a CA based on how happy Nelson (or Gerv, or Frank, or
> whoever) is with including it".
That's not what I'm saying - I was talking about approving or rejecting
the policy, not individual CAs.
Sorry for any confusion.
Gerv
Frank Hecker
> Please excuse the length of this post. If you're not interested in
> the topic you may be able to salvage this post as bed time reading.
Actually I typically read (and respond to) n.p.m.crypto postings in the
early morning before I get up to get showered and dressed :-)
[re CA acquisitions and related events]
> Totally agree. Perhaps this suggests requiring that the WebTrust (or
> other audits) are repeated regularly (every N years depending on the
> trust-bits) and on certain trigger events (within X months of transfer
> of ownership/control of the keys) if the audit/conformance is part of
> the MF inclusion policy.
We could certainly consider that. However there are a lot of CAs out
there which appear to be perfectly reputable but at the same time don't
seem to have updated their WebTrust documentation for a while. (They may
have done the audits, but that's not clear from their public
information.) I think for now I'd like to take this item under
advisement for a future version of the policy, as opposed to addressing
it in the 1.0 version.
In any case I want to go back and look at CA certs already included and
determine their status, and that would be a good time to look at the
current state of audits for those CAs and see what existing practices
really are.
[on my contention that artificial constraints on supply have kept cert
prices artificially high]
> I disagree but I think it would be hard to base a position exclusively
> on fact. My opinion is that because of the way the safety of website
> interaction is presented to users there may have been and may still see
> a backlash against software that doesn't maintain the bar for admission
> at a level such that the low point in the fence is not the
> authentication of the site.
As you say, it's difficult to say. It's not clear to me that users have
reacted negatively in the past to software with a low "bar for
admission" -- has any such software actually been released in the
browser/email space? As to what the future will hold, I guess we'll see.
However I should note that there's another possible explanation for
relatively high SSL cert prices (beyond the fact that CAs incur
relatively high costs to provide a certain level of assurance): that the
past and current target market for SSL certs has not been especially
price-sensitive, since a few hundred dollars is a relatively low price
in the context of putting together an e-commerce site. (Of course this
is a tautology, since the price in effect determines the market, drving
away potential customers who are in fact price-sensitive.)
> Further that the reasons authentication has
> not been attacked very much are adoption rates of ecommerce,
> transaction sizes, easy of other (criminal) attacks especially due to
> the novice nature of most internet participants. This has been slowly
> changing and may reach tipping point in the next year or three
> especially as the existing weak points are bolstered through any
> variety of means.
I agree that this is a real possibility, as I think do most if not all
of the people who've posted here. My only caveat is that I don't
necessarily see authentication of SSL cert holders as the last line of
defense, which if breached would lead to defeat; rather I think it's one
element in an overall strategy that should include multiple elements and
address not only prevention of attacks but also detection and response.
(Your comments about CRLs and OCSP are germane here, as are discussions
of how we could quickly remove CA certs, update whitelists or
blacklists, and so on.)
[re my contention that economic forces will drive greater emphasis on
lower assurance certs]
> I disagree. I think the reason we are seeing new lower assurance
> services appearing is that there are no consequences yet..
This is an point of discussion, and I think the future of the CA
industry (including any potential for real growth) will hinge upon it.
I see at least three possibilities going forward:
1. There continue to be no serious issues with low assurance certs
(i.e., "no consequences" as you put it). In this case the growth of low
assurance services is purely constrained by customer demand (and I
should add that I do think there are constraints on this demand, as
noted below).
2. There are in fact serious consequences with low assurance certs, and
browser and email vendors react by refusing to accept them (i.e.,
removing low-assurance CAs from their root lists or otherwise
blacklisting such certs). This in turns kills any future possibility of
low assurance services getting off the ground.
3. There are consequences with low assurance certs, but they get
addressed by changes that allow browser and email vendors and their
customers to differentiate between types of certs in a reasonable way.
This puts us back in the case where low assurance services can grow if
there is in fact customer demand.
> I agree with notion that the
> expectation the market has set for users is that the padlock or gold
> key or gold address bar etc means a site is good enough for commerce
> and banking.
I think the reverse is true as well: The expectation has been set that
only commerce and banking sites need concern themselves with using SSL
and SSL certificates. I think this is probably the key demand-side
constraint on the growth of low assurance certificate services.
> Being a software publisher that goes along with this
> expectation might impose a responsibility to operate under policies
> that ensure that expectation is not completely off target.
To "ensure that expectation is not completely off target" doesn't sound
quite as positive as "to ensure that expectation is met" :-) The simple
fact is that for quite some time now browsers have accepted
low-assurance SSL certs. In your opinion, by doing so have the browser
vendors acted in accordance with their responsibility as you've outlined
it above? Or is it simply that if times change and there are serious
consequences to accepting low assurance certs, that browser vendors have
a responsibility to change their policies?
> I don't think control-of-domain certificates nor other low-assurance
> certificates are going away.
Incidentally, is "control-of-domain" the standard "term of art" in the
CA industry for this? I've been using "domain validated" but IIRC I just
pulled that out of thin air. If there's a term already in common use I'd
prefer to use that instead.
> I don't think that control-of-domain and
> low assurance are necessarily bound. Consider a company that does heavy
> authentication of the ownership of a domain before issuing a
> certificate to the domain controller (i.e. making sure it really is
> "Mickey Mouse" at "1122 Boogie Woogie Avenue" per the who-is
> data ;) - this would of course be more expensive the lower
> authentication offering.
But see, I would consider this a full-blown "identity-authenticated" SSL
certificate, assuming that the CA took some additional measures to
verify the identity of the domain controller, e.g., asking for and
reviewing ID documents.
I think in practice the major dividing line may not be "low assurance"
vs. "high assurance" or "control-of-domain" vs. "identity verification"
but rather whether the verification process can be fully automated (at
least from the CA's end) or not. After all, in the end this is what is
going to drive a CA's marginal cost to issue each new cert, and hence
will determine how low CAs can price certs and how they position cert
offerings from a marketing point of view.
> In any case I think, to your point, there
> is a pent up demand for low assurance certificates that can't be
> correctly addressed and that the cropping up of low assurance TLS
> certificate providers will force the hand of software providers to
> change the user expectation and interaction model.
Not to contradict myself, but is there really such a pent-up demand? As
I noted above I think that CAs and others have set users' expectations
such that potential cert customers may believe that SSL and SSL certs
are only for banks and e-commerce sites, not for them.
To echo something I wrote in a recent blog post on Clayton Christensen's
"disruptive innovation" theories, I think that in order to grow
significantly CAs will really have to "compete against nonconsumption",
and that entails finding new things that ordinary users want to do for
which SSL and certs are the answer, or at least a key component of the
answer.
[re my thoughts on "CA branding" in the context of integrated "web
presence" vendors]
> If the bundling is as broad as you propose in this example than I'm
> guessing the customer is spending a whole lot of money and is less
> likely to be fleeting and so it can live and die by its own brand. If
> unbundled offerings are still available and a bad guy can buy (or other
> wise get) a low assurance fully trusted by software TLS server
> certificates that will be a more cost effective attack that cannot be
> prevented without high authentication and cannot be efficiently
> recovered from without proper revocation checking and SLAs.
Good points all. On second thought the problem with my thesis is that
there will always be unbundled cert offerings, for two reasons:
* for large e-commerce sites the various components (hosting, SSL certs,
etc.) will almost always be acquired from separate vendors (or they'll
just self-host)
* even in the market for individual web presence the vendors will offer
unbundled cert offerings as ways to make an initial sale to new
customers currently hosted elsewhere, just as domain registrars offer
low-cost domains as loss leaders to get new business, with the hope that
they can then sell add-on services later.
So the bottom line is that any "CA branding" will still have a strong
element of "third party endorsement" as opposed to "powered by".
> To reiterate I don't think that eliminating low
> assurance or low service robustness or low SLA roots is the solution as
> that eliminates much potential value to society, I think that the
> current models in web browsers is not sustainable in the face of the
> greater applicability of PKI to society and the distinct needs of
> I'll pick banks compared to folks who want to send encrypted personal
> email.
This is pretty much my position as well, and one shared by others too. I
think the problem is a) figuring out what the new models in web browsers
(and email software) should be, especially given the UI constraints
we're working under (limited screen space, desire not to confuse users);
and b) getting the browser developers to implement these new models.
> Today most of the lower bar CAs have little adoption. There are a
> handful of CA roots that are responsible for 95% of the market (I'm
> guessing) - these CAs are likely to be willing to defend their position
> by providing at least best practices in terms of the base technology
> like revocation.
I actually don't expect that "lower bar" CAs will be able to take
customers from "higher bar" CAs. I think the only possibility of "lower
bar" CAs is to compete against nonconsumption by finding new customers
that the "higher bar" CAs are not addressing and would not be likely to
pursue.
[re cert validation not being turned on by default in Mozilla, etc.]
> This is IMO a failure to take advantage of what's out there - it raises
> the bar on those CAs willing to pay the cost of service revocation
> information and does no harm to a CA who wants to operate at very low
> costs as they would simply not publish CRL nor OCSP pointers in their
> certificates.
I agree, I don't like it either, and I don't think anyone associated
with Mozilla/NSS crypto development does either.
> What is the reason MF software doesn't have revocation
> turned on by default for at least the automated type of revocation
> checking?
We've discussed this before, but I'd prefer to let the developers answer
directly because I can't remember all the relevant issues. However I
think in the end it comes down to a lack of developer resources to
implement features like CrlDistributionPoint, etc., and this in turn is
because neither corporations nor the Mozilla Foundation are currently
funding crypto development specifically targeted at the browser and
email clients -- development of the NSS crypto library is focused on the
crypto needs of server software (e.g., SunONE Directory Server, etc.),
and development of PSM (the browser/email client component mediating
between NSS and the user) is currently stalled for lack of people to do it.
Ian G
> Ian G wrote:
>
>> I'm not sure what your objection to brand is?
>
>
> You continue to assert that I "object to brand". I'm well aware of the
> power of branding in people's lives; I'm also aware that very often
> brand perception doesn't match reality, that branding favours those with
> large marketing budgets.
OK, but those are only objections to branding if
you can suggest a better way... No system is
perfect, all systems have flaws. The flaws in
the current system - security that is so trivial
to bypass that phishers don't even use SSL in
their phishing - would seem to be improved by
using branding. If the branding is only available
for HTTPS then that should help.
> Several people on the list have commented that Verisign have not behaved
> well as a CA. Regardless of the truth of those claims, I assert that if
> CAs were strongly branded in the browser UI, and someone did a survey,
> Verisign would be the brand with the highest level of trust, because
> they have the marketing dollars to send that message.
Possibly. What would be more likely is that when
Verisign mucks up, then it would hurt their brand.
Now, when Verisign mucks up, they can get away with
it because their brand is not tied to the product.
There is literally no feedback mechanism from Verisign's
actions to their customers to their brand. Until that
changes, until the brand of the signer is linked in
the user's mind, expect Verisign to act as a 'bad
corporate citizen' and expect their brand to be as
good as the amount of money they decide to pay for it.
The two aren't related, and in the current situation,
it is the case that Verisign continues to be allowed
to be a bad citizen behind the protective shield of
MF's brand. If you don't like that, then change it:
fix it so the brand is linked in people's minds.
> That's not my only objection, mind you - you can add that one to the
> previous ones I've outlined about user confusion when something changes.
Oh, sure. I think all these are fair negative points.
But, none of them seem to be that serious, compared
to phishing. The average cost of a phishing hit is
somewhere around $5000. It's generally well in excess
of $1000, and a lot of that cost is the "rebuild credit"
cost that people have to go through. It can take a long
time and a lot of hassle.
So, when amazon forgets to tell their users that they
just switched CAs, I think that's a small thing to ask
that the users put up with that and learn about it, if
they are to avoid phishing.
>> Let me put it another way. What would be
>> the damage of putting the brand of the CA
>> on the chrome? What would be the hurt?
>>
>> A loss of real estate?
>
>
> That's one key factor. There's limited room in the status bar, and I
> want to try and restrict the security UI to that area to get a good
> balance between security needs and the needs of web apps. If there's
> other information we want to be displaying (the words "first visit" or
> "new site", for example).
>
> Note that ideally our security UI would be fully visible on the smallest
> possible popup, which I believe is either 100 or 150px wide.
Well, putting the brand in the status bar would be
nice, good, an improvement. But to be really effective
it has to be the visual / logo representation, because
we need customers to learn of its presence in a way
that words simply don't do as well. Still, any work
towards that end is welcome.
>> If that's the only loss,
>
>
> It's not. The other loss is in increased complexity. The longer a user
> has to consider the security UI, the less likely they are to bother to
> look at it at all.
Sure. That's why we are suggesting brand and gfx. It is
a compressed piece of information. It's a logo sitting
on the chrome. It takes milliseconds to process, the
brain is very good at dealing with simple brand pictures
that should be there. This will be far easier than any
popup, and far easier to process than any status bar
thing.
>> I have to admit I really have a problem in
>> dealing with that, because phishing costs
>> a billion a year and rising.
>
>
> That's a straw man - you're assuming that this will have an effect, and
> it would have a greater effect on phishing than other things we could do
> in that space.
Some limited research has been done on these matters
directly in the browsing field, and it supports the
use of logos and brand in a security setting. I'm
also drawing from the last several decades of security
and payments practice in hardware based tokens (cards,
etc). Logos and brand form part of the trusted hardware
security model.
So, yes, I can't predict the future. But I'm not just
suggesting these things in a vacuum.
Ian G
>> I agree with notion that the
>> expectation the market has set for users is that the padlock or gold
>> key or gold address bar etc means a site is good enough for commerce
>> and banking.
>
>
> I think the reverse is true as well: The expectation has been set that
> only commerce and banking sites need concern themselves with using SSL
> and SSL certificates. I think this is probably the key demand-side
> constraint on the growth of low assurance certificate services.
Right. I'm not sure what the foundation of that
expectation is. And I'm not sure why MF particularly
thinks it important to believe in "only commerce and
banking" for security, given that most of the people
who work on it are volunteers, and are explicitly not
part of any commercial process, and the product is
neither sold for those processes nor sold at all.
But it is a pervasive assumption that extends all the
way across the PKI/x.509 field. Apache for example.
Thunderbird's S/MIME assumes a commercial model of cert
sales. Presumably S/MIME just took the lead from SSL.
But, it doesn't extend beyond the SSL/PKI/x.509 field to
any great measure; most of the other crypto publishers
that I know of bend over backwards and tie ourselves in
knots to get non-commercial people to use the software.
(E.g., Peter Guttman, PGP, Cryptix, BouncyCastle,
CryptoRights, OpenSSH,....)
Ian G
> Frank Hecker wrote:
> we used DNSSec to look up the name. DNS attacks are the next step in
> phishing as users get wiser.
It looks like it already started. I read something
the other day that suggested this was called 'pharming'.
Ian G
Yes, that may lock down the homograph thing, but it
does nothing to address the wider class of attacks.
I'm confused by one thing. Why is it that the Shmoo
IDN bypassing was so strongly reacted to, when the
whole phishing thing has been going on for years now,
and has not received even a tenth as much recognition
as Shmoo achieved in a weekend?
AFAICS, Shmoo was just a small example of the class
of domain spoofing attacks.
(So, when I say "Shmoo" I mean ... that class of
attacks, which remains easy and unaddressed. Shmoo
just happens to be a label that we know of as the
most clear expression of the class of attacks.)
iang
Nelson B
> Frank Hecker wrote:
> Would it be possible for the browser to programmatically tell when an
> SSL connection is secured by a "domain validation only" cert? (I suspect
> not, but it's worth asking.)
That info is not presently encoded in a cert in any uniform way.
It is humanly feasible for NSS to store that info along with trust,
but that's not done today.
The big problem appears to me to be that in some cases a single
root CA cert is used as the root of both lower assurance and high
assurance certs. In such a case, I think we have no choice but to
brand the entire CA cert as low assurance. Then people who have paid
that CA for a high assurance cert will be unhappy with the CA, and
that problem (CAs that use a common cert for both) may be self
correcting over time.
> One thing I've become more convinced of over the last few weeks is that
> our UI needs a "site identity verified" indicator which is separate from
> the SSL indicator. Site identity could be verified by SSL, but also if
> we used DNSSec to look up the name. DNS attacks are the next step in
> phishing as users get wiser.
>
> So perhaps the solution is to stop showing the lock for such certs, and
> merely show the "site identity verified" indicator.
SSL is site identity verification PLUS encrytion. Site identity
verification, by itself, is NOT "good enough for banking".
> Thinking about it, it's certainly hard to justify maintaining both a
> binary security UI and keeping such CA root certs.
I'm delighted to "hear you say that". You're one of the first people
with real influence on the mozilla UI to have appreciated these
security implications. Please continue! :)
> If the Foundation is serious about the security push this year, it
I don't believe they are. Not yet.
Consider bugs 272901 272902 and 272903. Frank filed these bugs in
November, asking the Aviary branch maintainers to take the NSS cert DB
changes onto their newly create branch, so that FF 1.0.1 would have
the new certs. The new certs were checked into NSS in December.
4 months later, FF 1.0.1 was released without any new certs. No one
who works on FF and maintains that branch thought it was important
enough to work on that.
As long as that situation (FF branch keeps think certs are unimportant)
remains true, I don't think anyone from MoFo can seriously say that
MoFo is serious about this stuff.
> should be hiring developers to work in this area. If we end up with a
> list of bugs they should fix and an order, so much the better.
Hiring developers MAY help. But I believe it is thr responsibility
of branch creators to maintain the security of their own branches.
It is simply wrong for every branch creator to assume that he can
burden the maintainers of other code in mozilla's repository with
porting all their fixes to his new branch.
--
Nelson B
Gervase Markham
> Concurr. Google is an oddball exception here, gmail reading is
> protected
I suspect that might be to be more firewall and proxy-compatible;
neither of those things can mess with the HTTPS data stream.
Gerv
Gervase Markham
> Yes, that may lock down the homograph thing, but it
> does nothing to address the wider class of attacks.
Indeed not. Did I say it was the only solution? I was merely commenting
on your use of the Shmoo example.
> I'm confused by one thing. Why is it that the Shmoo
> IDN bypassing was so strongly reacted to, when the
> whole phishing thing has been going on for years now,
> and has not received even a tenth as much recognition
> as Shmoo achieved in a weekend?
In a nutshell, because the Shmoo group exploit makes this:
http://www.gerv.net/security/stay-safe/
not true. For that reason, "the Shmoo attack" is _not_ a shorthand for a
whole wider class of attacks.
Gerv
Ram A M
>> Ram A M:
> [on my contention that artificial constraints on supply have kept
cert
> prices artificially high]
>> I disagree but I think it would be hard to base a position
exclusively
>> on fact. My opinion is that because of the way the safety of website
>> interaction is presented to users there may have been and may still
see
>> a backlash against software that doesn't maintain the bar for
admission
>> at a level such that the low point in the fence is not the
>> authentication of the site.
> However I should note that there's another possible explanation for
> relatively high SSL cert prices (beyond the fact that CAs incur
> relatively high costs to provide a certain level of assurance): that
the
> past and current target market for SSL certs has not been especially
> price-sensitive, since a few hundred dollars is a relatively low
price
> in the context of putting together an e-commerce site. (Of course
this
> is a tautology, since the price in effect determines the market,
drving
> away potential customers who are in fact price-sensitive.)
I basically agree. I would say that for high-assurance (auth.)
high-service (SLA, feature robustness - revocation) the price could be
much higher; FIs are used to paying big bucks to mitigate risk, large
etailers make tremendous amounts of money and would probably be willing
to pay much more. The current price is probably lower than the
threshold for these entites because there is no support for quality
differentiation in the client base and so FIs cannot be offered a great
product for USD5000 with small ecommerce sites getting a USD200 service
and my having access to a $50 service. This is IMO closer to what is
demanded today and potentially the model we end up at in a few years as
market pressures drive changes here and there until we navigate to a
stable point.
>> Further that the reasons authentication has
>> not been attacked very much are adoption rates of ecommerce,
>> transaction sizes, easy of other (criminal) attacks especially due
to
>> the novice nature of most internet participants. This has been
slowly
>> changing and may reach tipping point in the next year or three
>> especially as the existing weak points are bolstered through any
>> variety of means.
> I agree that this is a real possibility, as I think do most if not
all
> of the people who've posted here. My only caveat is that I don't
> necessarily see authentication of SSL cert holders as the last line
of
> defense, which if breached would lead to defeat; rather I think it's
one
> element in an overall strategy that should include multiple elements
and
> address not only prevention of attacks but also detection and
response.
I don't think things will ever be so dire for internet security as to
have to rely on last lines of defense. I do think that the current
client models can't last.
> [re my contention that economic forces will drive greater emphasis on
> lower assurance certs]
I agree with this statement.
>> I disagree. I think the reason we are seeing new lower assurance
>> services appearing is that there are no consequences yet..
What I disagree with is that the market will allow low assurance
certificates to be used for high risk scenarios in an otherwise robust
system. For completeness I'll restate that eventually this will be a
worthwhile vector and that, at the latest, when well see responses from
software providers.
>> I agree with notion that the
>> expectation the market has set for users is that the padlock or gold
>> key or gold address bar etc means a site is good enough for commerce
>> and banking.
> I think the reverse is true as well: The expectation has been set
that
> only commerce and banking sites need concern themselves with using
SSL
> and SSL certificates. I think this is probably the key demand-side
> constraint on the growth of low assurance certificate services.
Concurr. Google is an oddball exception here, gmail reading is
protected while Y! allows protected logins (though it won't remember
you want them) but Y! mail is read uprotected; I'm not taking a
position on either approach just pointing out an odd case.
>> Being a software publisher that goes along with this
>> expectation might impose a responsibility to operate under policies
>> that ensure that expectation is not completely off target.
> To "ensure that expectation is not completely off target" doesn't
sound
> quite as positive as "to ensure that expectation is met" :-)
Touche!
> The simple
> fact is that for quite some time now browsers have accepted
> low-assurance SSL certs. In your opinion, by doing so have the
browser
> vendors acted in accordance with their responsibility as you've
outlined
> it above? Or is it simply that if times change and there are serious
> consequences to accepting low assurance certs, that browser vendors
have
> a responsibility to change their policies?
I think MF will always do the right thing and therefor will always have
"at least as good as" security as the next guy. This means at a minimum
reacting to the changing landscape.
The way it looks to me many of the discussions in this group are really
about what kind of taste MF has for making things better be it
reactive, conservative, innovative, or aggressive. And the debates are
about which changes would be considered which with the assumption that
if a change is agreed to be good even from a conservative point of view
then it remains a matter of prioritization to get the work done and in
the build.
>> I don't think control-of-domain certificates nor other low-assurance
>> certificates are going away.
> Incidentally, is "control-of-domain" the standard "term of art" in
the
> CA industry for this? I've been using "domain validated" but IIRC I
just
> pulled that out of thin air. If there's a term already in common use
I'd
> prefer to use that instead.
I just made it up. I prefer this term because it talks to the attribute
that CA issuance, to some degree, attests to. I also prefer homoglyph
to homograph so there you go.
>> I don't think that control-of-domain and
>> low assurance are necessarily bound. Consider a company that does
heavy
>> authentication of the ownership of a domain before issuing a
>> certificate to the domain controller (i.e. making sure it really is
>> "Mickey Mouse" at "1122 Boogie Woogie Avenue" per the who-is
>> data ;) - this would of course be more expensive the lower
>> authentication offering.
> But see, I would consider this a full-blown "identity-authenticated"
SSL
> certificate, assuming that the CA took some additional measures to
> verify the identity of the domain controller, e.g., asking for and
> reviewing ID documents.
I did a poor job of expressing myself - I think Mickey Mouse probably
has a ton of DNS names. I was sarcastically pointing out that whois
information is typically bunk because registrars are not willing to
spend the $$ to validate the information they get and registrar
customers often don't want to provide accurate information - remember
how few commerce sites there are and how many domain names are
registered. If they do in fact check for validity of identying
documents (articles of incorporation) and uses other methods (out of
band contact of corporate offices to confirm enrollee employment etc.)
then it would be high assurance.
Ultimately my point was that a CA cannot reasonably leverage mass
market registrars for authentication to provide high assurance services
since registrars cannot be expected to operate only high assurance
registration services - the price points don't allow it.
> I think in practice the major dividing line may not be "low
assurance"
> vs. "high assurance" or "control-of-domain" vs. "identity
verification"
> but rather whether the verification process can be fully automated
(at
> least from the CA's end) or not. After all, in the end this is what
is
> going to drive a CA's marginal cost to issue each new cert, and hence
> will determine how low CAs can price certs and how they position cert
> offerings from a marketing point of view.
VeriSign has four classes of policies. The weakest authentication
("class 1") is striclty automated authentication (this is what the free
and pay for personal S/MIME certs are). For quite a while there was a
retail class 2 offering which was more expensive to operate but still
automated from VeriSign's perspective - this is also what VeriSign
managed PKI customers issue to their employees or customers (envisioned
for higher assurace S/MIME and lower assurance software/document
publishing). Class 3 involves both manual and automated aspects and
provides higher assurances still. No one talk about class 4.
Customers with differnet needs will have different price points.
Clearly the FIs are more concerned and therefor willing to pay more to
defend their wallets, brand, and customers against MITM attacks than I
am to protect my webmail interactions.
>> In any case I think, to your point, there
>> is a pent up demand for low assurance certificates that can't be
>> correctly addressed and that the cropping up of low assurance TLS
>> certificate providers will force the hand of software providers to
>> change the user expectation and interaction model.
> Not to contradict myself, but is there really such a pent-up demand?
As
> I noted above I think that CAs and others have set users'
expectations
> such that potential cert customers may believe that SSL and SSL certs
> are only for banks and e-commerce sites, not for them.
>
> To echo something I wrote in a recent blog post on Clayton
Christensen's
> "disruptive innovation" theories, I think that in order to grow
> significantly CAs will really have to "compete against
nonconsumption",
> and that entails finding new things that ordinary users want to do
for
> which SSL and certs are the answer, or at least a key component of
the
> answer.
I agree in part. I think CAs would love to see broader adoption of
certificates at a variety of assurance levels and that because the
software providers do not have a direct incentive to support this that
the system is taking the path it is - introduce lower cost lower
assurance certificates since they appear to provide the same value
(padlock) which I think will enable the backlash I suggested earlier.
>> Today most of the lower bar CAs have little adoption. There are a
>> handful of CA roots that are responsible for 95% of the market (I'm
>> guessing) - these CAs are likely to be willing to defend their
position
>> by providing at least best practices in terms of the base technology
>> like revocation.
> I actually don't expect that "lower bar" CAs will be able to take
> customers from "higher bar" CAs. I think the only possibility of
"lower
> bar" CAs is to compete against nonconsumption by finding new
customers
> that the "higher bar" CAs are not addressing and would not be likely
to
> pursue.
I don't know how many levels of bars there needs to be but I see a risk
to the user in presenting the less robust or lower auth offerings to
the user in such a way that they recognize it as a 'safe for banking.'
Personally I turn on revocation checking where I can and float over the
lock or checkout the TrustBar and I feel much better about logging into
my bank, broker, or healthcare site.
ram
Gervase Markham
> OK, but those are only objections to branding if
> you can suggest a better way...
There have been a whole bunch of ideas about mitigating the phishing
problem floating around, several of which have been suggested by me. :-)
> But, none of them seem to be that serious, compared
> to phishing. The average cost of a phishing hit is
> somewhere around $5000. It's generally well in excess
> of $1000, and a lot of that cost is the "rebuild credit"
> cost that people have to go through. It can take a long
> time and a lot of hassle.
You're quite close here to the fallacy of "Something must be done! This
is something. Therefore we must do this."
> Some limited research has been done on these matters
> directly in the browsing field, and it supports the
> use of logos and brand in a security setting.
What you mean is "Someone decided to do some research into branding, and
concluded that it helped". It doesn't mean that it's the _most_ helpful
thing we can do, nor does it mean that it automatically gains a place in
our arsenal.
To take an obvious example, the guy who suggested making people retype
domain names every time they visited a new site. Now that really would
help - but it doesn't mean we do it.
Gerv
Ian G
> I basically agree. I would say that for high-assurance (auth.)
> high-service (SLA, feature robustness - revocation) the price could be
> much higher; FIs are used to paying big bucks to mitigate risk, large
> etailers make tremendous amounts of money and would probably be willing
> to pay much more. The current price is probably lower than the
> threshold for these entites because there is no support for quality
> differentiation in the client base and so FIs cannot be offered a great
> product for USD5000 with small ecommerce sites getting a USD200 service
> and my having access to a $50 service. This is IMO closer to what is
> demanded today and potentially the model we end up at in a few years as
> market pressures drive changes here and there until we navigate to a
> stable point.
Right. And, the current situation - compressing the
cert market into one-size-fits-all - is unlikely to
change until branding is introduced. See my rant on
'discrimination' in the cert market at:
http://iang.org/ssl/dr_self_signed.html
>>Incidentally, is "control-of-domain" the standard "term of art" in
>
> the
>
>>CA industry for this? I've been using "domain validated" but IIRC I
>
> just
>
>>pulled that out of thin air. If there's a term already in common use
>
> I'd
>
>>prefer to use that instead.
>
>
> I just made it up. I prefer this term because it talks to the attribute
> that CA issuance, to some degree, attests to. I also prefer homoglyph
> to homograph so there you go.
That's a good point. It is control of domain that is
being tested, at the most fundamental level. Using
the term "domain validated" opens the question as to
just what has been validated.
> Ultimately my point was that a CA cannot reasonably leverage mass
> market registrars for authentication to provide high assurance services
> since registrars cannot be expected to operate only high assurance
> registration services - the price points don't allow it.
I would agree with that basic point; although there
have been many proposals to ask the registrars to
control things like IDNs.
>>>In any case I think, to your point, there
>>>is a pent up demand for low assurance certificates that can't be
>>>correctly addressed and that the cropping up of low assurance TLS
>>>certificate providers will force the hand of software providers to
>>>change the user expectation and interaction model.
>
>
>>Not to contradict myself, but is there really such a pent-up demand?
Sure, count me in. I want a low assurance cert for
every one of my websites. I and the readers of the
site don't care so much about being hit with an MITM
or being spoofed by a phisher, they would just rather
enjoy reading the stuff without anyone knowing which
pages and what text and so forth they are reading.
It is fairly low assurance stuff, but some people who
work in fairly high profile jobs like to comment on
my FC posts; currently, they are inhibited from
doing that as the posts are all in the clear and
their sysadmins could snoop them. As we are talking
financial services, sysadmin snooping is a real and
present issue, and it's often mandated.
> I agree in part. I think CAs would love to see broader adoption of
> certificates at a variety of assurance levels and that because the
> software providers do not have a direct incentive to support this that
> the system is taking the path it is - introduce lower cost lower
> assurance certificates since they appear to provide the same value
> (padlock) which I think will enable the backlash I suggested earlier.
Right. Again, check that rant. I think certain architects
who were involved in the early construction of the PKI got
it backwards and now we are all paying the price.
> I don't know how many levels of bars there needs to be but I see a risk
> to the user in presenting the less robust or lower auth offerings to
> the user in such a way that they recognize it as a 'safe for banking.'
Yes, Branding solves all that. I'm not sure how it
will pan out in the end, as right now there is some
discussion about hierarchies of certs. But it doesn't
seem insolvable.
Gervase Markham
> SSL is site identity verification PLUS encrytion. Site identity
> verification, by itself, is NOT "good enough for banking".
Sure. Maybe I wasn't clear:
Site-ID-verified-by-DNSSec: "site identity verified" indicator
low-assurance cert: "site identity verified" indicator
high-assurance cert: lock and "site identity verified" indicator
Gerv
Ian G
> Ian G wrote:
>
>> Yes, that may lock down the homograph thing, but it
>> does nothing to address the wider class of attacks.
>
>
> Indeed not. Did I say it was the only solution? I was merely commenting
> on your use of the Shmoo example.
OK. To declare: when I mention the Shmoo thing I mean
as an example of the wider attack. IMO mentioning the
Shmoo thing with only relevence to IDN is silly, as the
IDN thing has never been attacked by aggressive people
looking to steal money. It's way too new to be relevent,
and there are easy pickings elsewhere.
>> I'm confused by one thing. Why is it that the Shmoo
>> IDN bypassing was so strongly reacted to, when the
>> whole phishing thing has been going on for years now,
>> and has not received even a tenth as much recognition
>> as Shmoo achieved in a weekend?
>
>
> In a nutshell, because the Shmoo group exploit makes this:
> http://www.gerv.net/security/stay-safe/
> not true. For that reason, "the Shmoo attack" is _not_ a shorthand for a
> whole wider class of attacks.
I can think of 3 other ways that the above page is
"not true."
1. paypal's CA issues a false cert
2. any other CA issues a false cert
3. any CA issues a cert to paypa1.com,
or anything that looks the same in the font,
like wwwpaypal.com
4. user doesn't notice the change
That's a class of attacks. Shmoo just happened to do it
one way. So I feel my question remains unanswered, but
the night is young :-)
Ram A M
hours and hasn't shown up. I took the liberty of fixing a few things
too :)
> Frank Hecker:
>> Ram A M:
> [on my contention that artificial constraints on supply have kept
cert
> prices artificially high]
>> I disagree but I think it would be hard to base a position
exclusively
>> on fact. My opinion is that because of the way the safety of website
>> interaction is presented to users there may have been and may still
see
>> a backlash against software that doesn't maintain the bar for
admission
>> at a level such that the low point in the fence is not the
>> authentication of the site.
> However I should note that there's another possible explanation for
> relatively high SSL cert prices (beyond the fact that CAs incur
> relatively high costs to provide a certain level of assurance): that
the
> past and current target market for SSL certs has not been especially
> price-sensitive, since a few hundred dollars is a relatively low
price
> in the context of putting together an e-commerce site. (Of course
this
> is a tautology, since the price in effect determines the market,
drving
> away potential customers who are in fact price-sensitive.)
I basically agree. I would say that for high-assurance (auth.)
high-service (SLA, feature robustness - revocation) the price could be
much higher; FIs are used to paying big bucks to mitigate risk, large
etailers make tremendous amounts of money and would probably be willing
to pay much more. The current price is probably lower than the
threshold for these entitles because there is no support for quality
differentiation in the client base and so FIs cannot be offered a great
product for USD5000 with small ecommerce sites getting a USD200 service
and my having access to a $50 service. This is IMO closer to what is
demanded today and potentially the model we end up at in a few years as
market pressures drive changes here and there until we navigate to a
stable point.
>> Further that the reasons authentication has
>> not been attacked very much are adoption rates of ecommerce,
>> transaction sizes, easy of other (criminal) attacks especially due
to
>> the novice nature of most internet participants. This has been
slowly
>> changing and may reach tipping point in the next year or three
>> especially as the existing weak points are bolstered through any
>> variety of means.
> I agree that this is a real possibility, as I think do most if not
all
> of the people who've posted here. My only caveat is that I don't
> necessarily see authentication of SSL cert holders as the last line
of
> defense, which if breached would lead to defeat; rather I think it's
one
> element in an overall strategy that should include multiple elements
and
> address not only prevention of attacks but also detection and
response.
I don't think things will ever be so dire for internet security as to
have to rely on last lines of defense. I do think that the current
client models can't last.
> [re my contention that economic forces will drive greater emphasis on
> lower assurance certs]
I agree with this statement.
>> I disagree. I think the reason we are seeing new lower assurance
>> services appearing is that there are no consequences yet..
What I disagree with is that the market will allow low assurance
certificates to be used for high risk scenarios in an otherwise robust
system. For completeness I'll restate that eventually this will be a
worthwhile vector and that, at the latest, is when well see responses
from software providers.
>> I agree with notion that the
>> expectation the market has set for users is that the padlock or gold
>> key or gold address bar etc means a site is good enough for commerce
>> and banking.
> I think the reverse is true as well: The expectation has been set
that
> only commerce and banking sites need concern themselves with using
SSL
> and SSL certificates. I think this is probably the key demand-side
> constraint on the growth of low assurance certificate services.
Concur.
>> Being a software publisher that goes along with this
>> expectation might impose a responsibility to operate under policies
>> that ensure that expectation is not completely off target.
> To "ensure that expectation is not completely off target" doesn't
sound
> quite as positive as "to ensure that expectation is met" :-)
Touche!
> The simple
> fact is that for quite some time now browsers have accepted
> low-assurance SSL certs. In your opinion, by doing so have the
browser
> vendors acted in accordance with their responsibility as you've
outlined
> it above? Or is it simply that if times change and there are serious
> consequences to accepting low assurance certs, that browser vendors
have
> a responsibility to change their policies?
I think MF will always do the right thing and therefore will always
have "at least as good as" security as the next guy. This means at a
minimum reacting to the changing landscape.
The way it looks to me many of the discussions in this group are really
about what kind of taste MF has for making things better be it
reactive, conservative, innovative, or aggressive. And the debates are
about which changes would be considered which with the assumption that
if a change is agreed to be good even from a conservative point of view
then it remains a matter of prioritization to get the work done and in
the build.
>> I don't think control-of-domain certificates nor other low-assurance
>> certificates are going away.
> Incidentally, is "control-of-domain" the standard "term of art" in
the
> CA industry for this? I've been using "domain validated" but IIRC I
just
> pulled that out of thin air. If there's a term already in common use
I'd
> prefer to use that instead.
I just made it up. I prefer this term because it talks to the attribute
that CA issuance, to some degree, attests to. I also prefer homoglyph
to homograph so there you go.
>> I don't think that control-of-domain and
>> low assurance are necessarily bound. Consider a company that does
heavy
>> authentication of the ownership of a domain before issuing a
>> certificate to the domain controller (i.e. making sure it really is
>> "Mickey Mouse" at "1122 Boogie Woogie Avenue" per the who-is
>> data ;) - this would of course be more expensive the lower
>> authentication offering.
> But see, I would consider this a full-blown "identity-authenticated"
SSL
> certificate, assuming that the CA took some additional measures to
> verify the identity of the domain controller, e.g., asking for and
> reviewing ID documents.
I did a poor job of expressing myself - I think Mickey Mouse probably
has a ton of DNS names. I was sarcastically pointing out that who-is
information is typically bunk because registrars are not willing to
spend the $$ to validate the information they get and registrar
customers often don't want to provide accurate information - remember
how few commerce sites there are and how many domain names are
registered. If they do in fact check for validity of identifying
documents (articles of incorporation) and uses other methods (out of
band contact of corporate offices to confirm enrollee employment etc.)
then it would be high assurance.
Ultimately my point was that a CA cannot reasonably leverage mass
market registrars for authentication to provide high assurance services
since registrars cannot be expected to operate only high assurance
registration services - the price points don't allow it.
> I think in practice the major dividing line may not be "low
assurance"
> vs. "high assurance" or "control-of-domain" vs. "identity
verification"
> but rather whether the verification process can be fully automated
(at
> least from the CA's end) or not. After all, in the end this is what
is
> going to drive a CA's marginal cost to issue each new cert, and hence
> will determine how low CAs can price certs and how they position cert
> offerings from a marketing point of view.
VeriSign has four classes of policies. The weakest authentication
("class 1") is strictly automated authentication (this is what the free
and pay for personal S/MIME certs are). For quite a while there was a
retail class 2 offering which was more expensive to operate but still
automated from VeriSign's perspective - this is also what VeriSign
managed PKI customers issue to their employees or customers (envisioned
for higher assurance S/MIME and lower assurance software/document
publishing). Class 3 involves both manual and automated aspects and
provides higher assurances still. No one talk about class 4.
Customers with different needs will have different price points.
Clearly the FIs are more concerned and therefore willing to pay more to
defend their wallets, brand, and customers against MITM attacks than I
am to protect my web-mail interactions.
>> In any case I think, to your point, there
>> is a pent up demand for low assurance certificates that can't be
>> correctly addressed and that the cropping up of low assurance TLS
>> certificate providers will force the hand of software providers to
>> change the user expectation and interaction model.
> Not to contradict myself, but is there really such a pent-up demand?
As
> I noted above I think that CAs and others have set users'
expectations
> such that potential cert customers may believe that SSL and SSL certs
> are only for banks and e-commerce sites, not for them.
>
> To echo something I wrote in a recent blog post on Clayton
Christensen's
> "disruptive innovation" theories, I think that in order to grow
> significantly CAs will really have to "compete against
nonconsumption",
> and that entails finding new things that ordinary users want to do
for
> which SSL and certs are the answer, or at least a key component of
the
> answer.
I agree in part. I think CAs would love to see broader adoption of
certificates at a variety of assurance levels and that because the
software providers do not have a direct incentive to support this that
the system is taking the path it is - introduce lower cost lower
assurance certificates since they appear to provide the same value
(padlock) which I think will enable the backlash I suggested earlier.
>> Today most of the lower bar CAs have little adoption. There are a
>> handful of CA roots that are responsible for 95% of the market (I'm
>> guessing) - these CAs are likely to be willing to defend their
position
>> by providing at least best practices in terms of the base technology
>> like revocation.
> I actually don't expect that "lower bar" CAs will be able to take
> customers from "higher bar" CAs. I think the only possibility of
"lower
> bar" CAs is to compete against nonconsumption by finding new
customers
> that the "higher bar" CAs are not addressing and would not be likely
to
> pursue.
I don't know how many levels of bars there needs to be but I see a risk
to the user in presenting the less robust or lower auth offerings to
the user in such a way that they recognize it as a 'safe for banking.'
Nelson B
> [snip] Maybe I wasn't clear:
>
> Site-ID-verified-by-DNSSec: "site identity verified" indicator
> low-assurance cert: "site identity verified" indicator
> high-assurance cert: lock and "site identity verified" indicator
Thanks for that clarification, After reading it and rereading your
previous post, I see that is what you meant, but I didn't get that
the first time.
I do NOT think that DNSSec amounts to site identity verification.
It is rather only verification of the binding of DNSname to IP address.
I will start a new thread on this, since this thread has now gotten
too deep for Seamonkey to graphically show the thread referece tree.
--
Nelson B
Frank Hecker
> Hmm, posted a response earlier today - I'm trying again as it's been
> hours and hasn't shown up.
Actually, I did see your earlier post, reading it off of the
news.mozilla.org news server.
In general I think we agree more than we disagree, and in many cases are
aggressively in agreement, so I'll confine my followup comments to one
key point.
> I don't know how many levels of bars there needs to be but I see a risk
> to the user in presenting the less robust or lower auth offerings to
> the user in such a way that they recognize it as a 'safe for banking.'
This I think is the key question we need to look at: How to
differentiate different types of SSL/TLS applications (low assurance vs.
high, banking/e-commerce vs. "casual" use, etc.) while not either
violating user's existing expectations or overly confusing users.
One approach proposed is CA branding, so that the user makes
distinctions directly based on the CA-specific information presented to
them (logo, wordmark, whatever). See Ian G for details :-)
Another approach is to provide some sort of UI indicator that is a proxy
indicator for the level of assurance. For example, in an earlier message
to this forum Gerv proposed using a "site identity verified" message in
the status bar:
> Site-ID-verified-by-DNSSec: "site identity verified" indicator
> low-assurance cert: "site identity verified" indicator
> high-assurance cert: lock and "site identity verified" indicator
This proposal is actually quite radical, since it would abandon the
traditional use of the lock to indicate an SSL connection, and reserve
the lock for use only with certain types of SSL connections, i.e., those
made with "high assurance" certs (suitably defined). Other SSL
connections would *not* show a lock.
Radical though it might be, something like this might actually work.
However rather than using the phrase "site identity verified" (what does
this actually mean to users?) or some other textual message, why not use
a different graphic, like a check mark? Users would then be free to
build new expectations: Seeing a check mark is a good thing, but if
you're spending money you'll want to see a lock as well.
In this case to avoid confusing users I would reserve the check mark
only for SSL/TLS connections, since I think part of the user
expectations would be some level of confidentiality of communications.
That would also be part of the marketing message for CAs trying to sell
low-assurance certs to new customers not concerned with financial or
e-commerce applications.
Otherwise there'd be no distinction to the user between encrypted SSL
connections using low-assurance certs and unencrypted connections to
sites with domain names verified via DNSSec. I know some would argue
that SSL connections using low-assurance certs are indistinguishable
from non-SSL connections from a security point of view, but I don't
think treating them exactly the same from a UI perspective serves the
interests of anyone, least of all users.
Ian G
> Ram A M wrote:
>
>> Hmm, posted a response earlier today - I'm trying again as it's been
>> hours and hasn't shown up.
>
>
> Actually, I did see your earlier post, reading it off of the
> news.mozilla.org news server.
I saw it too, off the maillist.
> In general I think we agree more than we disagree, and in many cases are
> aggressively in agreement, so I'll confine my followup comments to one
> key point.
(Agreed!)
>> I don't know how many levels of bars there needs to be but I see a risk
>> to the user in presenting the less robust or lower auth offerings to
>> the user in such a way that they recognize it as a 'safe for banking.'
>
>
> This I think is the key question we need to look at: How to
> differentiate different types of SSL/TLS applications (low assurance vs.
> high, banking/e-commerce vs. "casual" use, etc.) while not either
> violating user's existing expectations or overly confusing users.
>
> One approach proposed is CA branding, so that the user makes
> distinctions directly based on the CA-specific information presented to
> them (logo, wordmark, whatever). See Ian G for details :-)
I stand ready to rant on command :)
> Another approach is to provide some sort of UI indicator that is a proxy
> indicator for the level of assurance. For example, in an earlier message
> to this forum Gerv proposed using a "site identity verified" message in
> the status bar:
>
> > Site-ID-verified-by-DNSSec: "site identity verified" indicator
> > low-assurance cert: "site identity verified" indicator
> > high-assurance cert: lock and "site identity verified" indicator
>
> This proposal is actually quite radical, since it would abandon the
> traditional use of the lock to indicate an SSL connection, and reserve
> the lock for use only with certain types of SSL connections, i.e., those
> made with "high assurance" certs (suitably defined). Other SSL
> connections would *not* show a lock.
>
> Radical though it might be, something like this might actually work.
> However rather than using the phrase "site identity verified" (what does
> this actually mean to users?) or some other textual message, why not use
> a different graphic, like a check mark? Users would then be free to
> build new expectations: Seeing a check mark is a good thing, but if
> you're spending money you'll want to see a lock as well.
>
> In this case to avoid confusing users I would reserve the check mark
> only for SSL/TLS connections, since I think part of the user
> expectations would be some level of confidentiality of communications.
> That would also be part of the marketing message for CAs trying to sell
> low-assurance certs to new customers not concerned with financial or
> e-commerce applications.
There are two approachs with the padlock, as you suggest:
the high road and the low road. The problem with the low
road is that nobody is happy with the perception of
lowered security. The problem with the high road is that
VeriSign aren't going to agree that Comodo's high-ass certs
are as good as the VeriSign ones. And, to a large extent
they have a point; there is no reasonable way to compare
certs at the high end, as a lot of care is taken to
decommoditise the product as more money is paid.
Of the two, I'd prefer the low road: padlock signifies
that a TLS connection is in place.
I think this matches the "pure view of TLS". The purpose
of the cert is to simply stop the MITM, so the domain needs
to be checked only. Hence Ram's "control-of-domain" term.
<rant>
The "expanded view of PKI" is that the identity information
in the cert is valid. That's a lot more problematic to
rely upon, as, in security business we have no great theory
of identity. Ellison&Schneier for example points out that
there is no great or strong reason to believe that a cert
signs on behalf of an individual - notwithstanding many laws
and products that rely on this concept. My own critique is
more software driven: Identity often drives the requirements,
but it can never be the application, so everything appears
backwards.
Yet Identity is what the assurance model promises. Given that,
pragmatically, anything that a browser can do to narrow down
the claims of identity and matching assurance statements will
help enourmously.
There is an even further step beyond, which might be called
"the trust view." That is, if the padlock is on, you can
trust... This is hopeful at best and will lose the client
money at worst, simply because trust is an undefined concept,
and thus is oversold. In the security community these days,
we tend to perceive the word 'trust' as snake oil; if you
can't describe your claims without using the word trust, it
is likely you don't know what your claims are, and you are
just hoping the listener doesn't notice.
</rant>
> Otherwise there'd be no distinction to the user between encrypted SSL
> connections using low-assurance certs and unencrypted connections to
> sites with domain names verified via DNSSec. I know some would argue
> that SSL connections using low-assurance certs are indistinguishable
> from non-SSL connections from a security point of view, but I don't
> think treating them exactly the same from a UI perspective serves the
> interests of anyone, least of all users.
Right. Which still leaves (sorry to bring this up) the
oddball meaning of a self-signed cert. Where this gets
interesting is that when it first appears, it signifies
a secure connection albeit with a minor risk of MITM.
But, if the user then accepts that connection, and if
she could record that acceptance, then follow-on connections
would potentially deserve the padlock. Still, let's ignore
that for now...
Frank Hecker
> There are two approachs with the padlock, as you suggest:
> the high road and the low road. The problem with the low
> road is that nobody is happy with the perception of
> lowered security. The problem with the high road is that
> VeriSign aren't going to agree that Comodo's high-ass certs
> are as good as the VeriSign ones.
Of course not, but that's their problem, not ours. We (the browser
vendors) could easily make a determination that a "high-assurance" cert
from CA Foo is equivalent to a "high-assurance" cert from CA Bar, at
least as far as typical users are concerned. See my next message for a
strawman proposal to do exactly that.
> Of the two, I'd prefer the low road: padlock signifies
> that a TLS connection is in place.
>
> I think this matches the "pure view of TLS". The purpose
> of the cert is to simply stop the MITM, so the domain needs
> to be checked only. Hence Ram's "control-of-domain" term.
But IMO your "pure view" of certs as an anti-MITM defense is just as
much an idealization as the "pure view" that certs prove identity. I
think the reality is rather that for typical users the padlock simply
means "it's OK to send my cherished personal information", no more and
no less.
> There is an even further step beyond, which might be called
> "the trust view." That is, if the padlock is on, you can
> trust... This is hopeful at best and will lose the client
> money at worst, simply because trust is an undefined concept,
> and thus is oversold. In the security community these days,
> we tend to perceive the word 'trust' as snake oil; if you
> can't describe your claims without using the word trust, it
> is likely you don't know what your claims are, and you are
> just hoping the listener doesn't notice.
Snake oil or not, I think the "trust view" is exactly what typical users
hold, for better or worse. (And I might add that just because a concept
is slippery and ill-defined doesn't mean it is wholly without validity
or use in real life.)
> Which still leaves (sorry to bring this up) the
> oddball meaning of a self-signed cert. Where this gets
> interesting is that when it first appears, it signifies
> a secure connection albeit with a minor risk of MITM.
> But, if the user then accepts that connection, and if
> she could record that acceptance, then follow-on connections
> would potentially deserve the padlock. Still, let's ignore
> that for now...
See my next message for how I'd propose to treat self-signed certs.
(Short answer: better than we do now, with all the alarming warning
dialogs, but not as you'd like them to be.)
Frank
P.S. Apropos of these discussions, there's an interesting post by Clay
Shirky (ostensibly on the subject of the "Wikipedia vs. Encyclopedia
Brittanica" debate) that posits two classes of people: "radialists" and
"Cartesians":
http://www.corante.com/many/archives/2005/03/09/one_world_two_maps_thoughts_on_the_wikipedia_debate.php
After reading it I realized that I am a "radialist" at heart, while I
suspect you are a "Cartesian" (as are certain others on this group as
well). I am interested in incrementally improving the situation in which
we (browser vendors, CAs, and end users) find ourselves, without
necessarily achieving ending up in some posited ideal end state. My next
message ("Strawman proposal for SSL UI changes") is an example of this
approach in action.
I think there is a place for the "Cartesian" approach, but I think in
practice it will prove to be outside the traditional SSL/TLS/PKI domain.
--
Frank Hecker
hec...@hecker.org
Ian G
> Ian G wrote:
>
>> There are two approachs with the padlock, as you suggest:
>> the high road and the low road. The problem with the low
>> road is that nobody is happy with the perception of
>> lowered security. The problem with the high road is that
>> VeriSign aren't going to agree that Comodo's high-ass certs
>> are as good as the VeriSign ones.
>
>
> Of course not, but that's their problem, not ours.
Actually, it's the user's problem, and therefore Mozilla's
problem (assuming an implicit goal, so that's debateable).
As Mozilla provides no way to show the user easily whether
the cert is a high assurance one from Verisign as opposed
to the Comodo alternate, we are again left with the lowest
common denominator - VeriSign is offered no incentive to
improve theirs beyond the minimum needed. So they'll all
be "just enough to clear the bar" and in some cases they
won't clear the bar, but nobody notices. The result will
be anything but high assurance.
> We (the browser
> vendors) could easily make a determination that a "high-assurance" cert
> from CA Foo is equivalent to a "high-assurance" cert from CA Bar, at
> least as far as typical users are concerned. See my next message for a
> strawman proposal to do exactly that.
Responded :)
>> Of the two, I'd prefer the low road: padlock signifies
>> that a TLS connection is in place.
>>
>> I think this matches the "pure view of TLS". The purpose
>> of the cert is to simply stop the MITM, so the domain needs
>> to be checked only. Hence Ram's "control-of-domain" term.
>
>
> But IMO your "pure view" of certs as an anti-MITM defense is just as
> much an idealization as the "pure view" that certs prove identity. I
Well, maybe pure is the wrong word - how about "minimalist view" ?
> think the reality is rather that for typical users the padlock simply
> means "it's OK to send my cherished personal information", no more and
> no less.
Ah. That I don't see. See my #1.
>> There is an even further step beyond, which might be called
>> "the trust view." That is, if the padlock is on, you can
>> trust... This is hopeful at best and will lose the client
>> money at worst, simply because trust is an undefined concept,
>> and thus is oversold. In the security community these days,
>> we tend to perceive the word 'trust' as snake oil; if you
>> can't describe your claims without using the word trust, it
>> is likely you don't know what your claims are, and you are
>> just hoping the listener doesn't notice.
>
>
> Snake oil or not, I think the "trust view" is exactly what typical users
> hold, for better or worse. (And I might add that just because a concept
> is slippery and ill-defined doesn't mean it is wholly without validity
> or use in real life.)
Certainly what you say as to validity is true. But, when
we cannot define it and it slips through our fingers, by
what theory are we to change it?
>> Which still leaves (sorry to bring this up) the
>> oddball meaning of a self-signed cert. Where this gets
>> interesting is that when it first appears, it signifies
>> a secure connection albeit with a minor risk of MITM.
>> But, if the user then accepts that connection, and if
>> she could record that acceptance, then follow-on connections
>> would potentially deserve the padlock. Still, let's ignore
>> that for now...
>
>
> See my next message for how I'd propose to treat self-signed certs.
> (Short answer: better than we do now, with all the alarming warning
> dialogs, but not as you'd like them to be.)
Sure. Just to clarify, in the scheme of things, there
are bigger phish to fry than self-signed certs, IMO. I
think they do make a rather interesting edge case by
which to test any proposal though.
> Frank
>
> P.S. Apropos of these discussions, there's an interesting post by Clay
> Shirky (ostensibly on the subject of the "Wikipedia vs. Encyclopedia
> Brittanica" debate) that posits two classes of people: "radialists" and
> "Cartesians":
>
> http://www.corante.com/many/archives/2005/03/09/one_world_two_maps_thoughts_on_the_wikipedia_debate.php
I read this initially as you accusing me of not being a radicalist :)
> After reading it I realized that I am a "radialist" at heart, while I
> suspect you are a "Cartesian" (as are certain others on this group as
> well). I am interested in incrementally improving the situation in which
> we (browser vendors, CAs, and end users) find ourselves, without
> necessarily achieving ending up in some posited ideal end state. My next
> message ("Strawman proposal for SSL UI changes") is an example of this
> approach in action.
>
> I think there is a place for the "Cartesian" approach, but I think in
> practice it will prove to be outside the traditional SSL/TLS/PKI domain.
OK, here's what I see. My proposal is cartesian, definately.
In that this whole thing has been bounced around some of the
best minds in the security business, and we've definately got
a view as to where we want to end up. We've got some experimental
research backing it up, and we now have a collected set of works
addressing each of the points. We've also worn down the opponents
and noticed that they are now pushing the vision :)
How we get there - the radial view - is beyond our scope. We,
the crypto / security community in general, cannot definately
say how to get there because we don't know where here is; we
are actually outside the framework of any given actual security
system.
To put it in product terms, the model that is espoused (user
engagement, petnames, branding, caching, logos, etc) is valid
for all browsing systems based on the CA/PKI model. The
model is applicable for Microsoft, Konqueror, Opera, and of
course Firefox.
How to implement it in the Firefox world is beyond my reach,
though. I'm not inside the Firefox world, nor inside the
security team, nor even inside Mozilla. The job of radiating
from here to there is something those on the inside have to
work out, if the so choose to go that path.
The best we can do on the outside is present that end point,
and describe why we think that's the place to head for. As
I often write, the little incremental steps there - the yellow
bar and status domain are exactly those - are very welcome.
"That's great, more please!"
iang
PS: another big distinction is that it's not about people,
but about interests - when I run my teams, I am a radialist,
in the terms above, because I'm paying for the changes.
Cartesian shifts are incredibly expensive, and I would
generally treat such as a sacking offence. But that's
when I am responsible for the deliverables.
Gervase Markham
> I can think of 3 other ways that the above page is
> "not true."
>
> 1. paypal's CA issues a false cert
> 2. any other CA issues a false cert
These things have happened a handful of times in the history of the web,
and no-one has lost any money to my knowledge. It's not comparable.
> 3. any CA issues a cert to paypa1.com,
> or anything that looks the same in the font,
> like wwwpaypal.com
paypa1.com doesn't look the same in the font we use as paypal.com. That
said, we should be open to font improvements. But in non-shmoo cases,
there is a distinction if you look. In the shmoo case, there isn't.
> 4. user doesn't notice the change
That page I described is a spec, as in "this is the minimum work a user
needs to do to be safe". That minimum work is checking that indicator is
correct. Suggestions to further reduce the work are welcome. :-)
Gerv
Gervase Markham
> Radical though it might be, something like this might actually work.
> However rather than using the phrase "site identity verified" (what does
> this actually mean to users?)
Just to clarify - my proposal wasn't supposed to suggest any UI at all,
and particularly not that :-)
My current UI idea is perhaps to make the domain name bold, but I'm very
open to ideas here.
> Otherwise there'd be no distinction to the user between encrypted SSL
> connections using low-assurance certs and unencrypted connections to
> sites with domain names verified via DNSSec. I know some would argue
> that SSL connections using low-assurance certs are indistinguishable
> from non-SSL connections from a security point of view, but I don't
> think treating them exactly the same from a UI perspective serves the
> interests of anyone, least of all users.
Fair point.
If we are going to do this, we need to:
- Collaborate with other browser manufacturers. Having divergent UI on
this would be a disaster, and banks wouldn't know how to educate their
customers.
- Work out with them exactly what states we want to indicate, and the UI
to choose. We should choose as few states and variables as we can
possibly get away with, rather than looking at it from a "what would it
be nice to differentiate?" point of view.
Gerv
Nelson Bolyard
>
> Right. Which still leaves (sorry to bring this up) the
> oddball meaning of a self-signed cert. Where this gets
> interesting is that when it first appears, it signifies
> a secure connection albeit with a minor risk of MITM.
Not "secure", merely encrypted.
> But, if the user then accepts that connection, and if
> she could record that acceptance, then follow-on connections
> would potentially deserve the padlock. Still, let's ignore
> that for now...
Yes, Let's!
Ram A M
> Ram A M wrote:
> > Ultimately my point was that a CA cannot reasonably leverage mass
> > market registrars for authentication to provide high assurance
services
> > since registrars cannot be expected to operate only high assurance
> > registration services - the price points don't allow it.
>
>
> I would agree with that basic point; although there
> have been many proposals to ask the registrars to
> control things like IDNs.
Yep and to the extent that it can be automated I expect to see
approaches that widdle away at the problem. To the extent that it's
manual you will see prices go up - given the nature of that market I
doubt this is coming without forcing a change in market behavior
through authority of some sort. Personally I don't need authentication
for most of the websites I visit so I don't really want to bear the
cost of authentication for every domain name I buy (rent? lease?
license?).
> > I agree in part. I think CAs would love to see broader adoption of
> > certificates at a variety of assurance levels and that because the
> > software providers do not have a direct incentive to support this
that
> > the system is taking the path it is - introduce lower cost lower
> > assurance certificates since they appear to provide the same value
> > (padlock) which I think will enable the backlash I suggested
earlier.
>
>
> Right. Again, check that rant. I think certain architects
> who were involved in the early construction of the PKI got
> it backwards and now we are all paying the price.
Eh. I think a reasonable job was done It was understood that bringing
trust to a defacto anonymous communication channel was most
practically achieved by leveraging the existing trust infrastructure -
the legal system. It would be tough to imagine that the goal was a
perfect security system that would never need change.
Ram A M
> Ram A M wrote:
> > I don't know how many levels of bars there needs to be but I see a
risk
> > to the user in presenting the less robust or lower auth offerings
to
> > the user in such a way that they recognize it as a 'safe for
banking.'
>
> This I think is the key question we need to look at: How to
> differentiate different types of SSL/TLS applications (low assurance
vs.
> high, banking/e-commerce vs. "casual" use, etc.) while not either
> violating user's existing expectations or overly confusing users.
>
> One approach proposed is CA branding,
...
> Another approach is to provide some sort of UI indicator
I agree in principle with your proposal - bucketizing trust indications
for the users. The big questions I see are the evaluation criteria, the
UI mechanics, and the migration strategy from current to proposed.
Looks like you started a thread on the topic -> I'll move there though
not right now... back to work
Frank Hecker
<snip>
While everyone else has been off having fun conversations (like in bug
286107) I've been distracted by work and family stuff, and (among other
things) forgot to respond in more depth to your reply addressing my
detailed set of questions to you re your concerns (or potential concerns
about the proposed CA cert policy). My apologies, I'll try to remedy
that (at least partially) now. (And BTW, thanks for answering the
questions!)
> I consider a duff cert to be any of the kinds of certs that have caused
> me (and the NSS group) trouble over the years, including (but not limited
> to) these:
>
> 1. certs with technical flaws, e.g.
> - duplicate issuer names and serial numbers.
> - invalid public keys (e.g. DSA cert with 2kbit primes,
> RSA certs with public exponent == 1).
> - incorrect extensions (e.g. SSL certs that exclude SSL usage, or
> authority key IDs that include BOTH the key ID *AND* the
> issuer's issuer name and serial number.
> - invalid dates
> - ASN.1 DER encoding errors.
CAs issuing technically incorrect certs could be addressed by the
proposed clause 4 of the policy, allowing rejection/removal of CAs in
cases where including their certs would "cause technical problems with
the operation of our software." I could even include a list like the
above as examples of such problems, although such a list might be more
appropriate for an accompanying FAQ.
However "technical correctness" can be a bit of a slippery concept at
times; more on this below.
> 2. Certs with false (and therefore inadequately verified) information
> about the identify of the party to whom the cert is issued, info
> that was verifiably false at the time of issuance.
First, determining whether information was "verifiably false", in the
sense that a CA should have known better than to issue the cert, is IMO
potentially a subjective determination. It's always easier in hindsight
to say something was "verifiably false", because we typically have more
information now than the CA would have had at the time, or we might be
evaluating the truth or falsity of information using means that go
beyond what the CA's policy actually calls for.
(To use a contrived example, the CA's policy might determine the name of
an applicant based on presentation of a driver's license, but that
information was verifiably false, as the CA could have determined if it
had bothered to take fingerprints and a DNA sample and match that
against a central government-maintained database.)
So I think your test in practice would at least have to be modified to
read something like "info that was verifiably false at the time of
issuance, based on the means of identification called for in the CA's
policies."
Another issue (at least as far as the policy is concerned) is that we
can't know in advance whether a CA is going to issue "verifiably false"
certs or not, so it's hard to use this as a criteria for evaluating CAs
unless the CA has a public track record of problems in that regard. In
that case we could use such a history of problems as grounds for denying
a CA's application based on clause 4 of the proposed policy, "where we
believe that including a CA certificate ... would cause undue risks to
users' security". If we happen to approve a CA for inclusion and then
they later start having problems, we can use the same clause 4 language
was grounds for removing the CA's cert.
> 3. Certs with NO INFORMATION about the party to whom the cert is
> issued, except an email address or a domain name, or other
> info that doesn't identify the party.
> [see "binary UI security model" below for more on this.]
See my comments below about this case.
> 4. (recent addition) certs used with phishing, including:
> - certs with names confusingly similar to other domains, e.g.
> paypal-security.com
> - certs with IDN/punycode names that look like well known names
> but aren't exactly.
Someone correct me if I'm wrong, but I think we've determined based on
prior discussions that CAs are not currently called upon to police
instances of misleading names, and cannot necessarily be expected to
enforce such rules in the future.
(Among other things, it's perfectly possible that different corporations
in different countries might have similar names, e.g., "First National
Bank", so, for example, we might have a "firstnationalbank.com" vs. a
"firstnationalbank.co.uk" or "firstnationalbank.co.au", with all of
these being different entities even though a naive user might take them
to be the same entity. In the US we might even have "firstbankofmd.com"
vs. "firstbankofca.com" -- not to mention "firstbank.com", which is a
real bank with branches in Virginia.)
As a result I am reluctant to have language in the policy calling for
rejection or removal of CAs based on this "misleading names" criterion,
until/unless the present situation changes.
> All these problems were present in the certs at the time they were
> issued. A CA who does adequate technical validity checking and
> adequate due diligence about the requestor's credentials will
> pass all these tests.
I disagree with your point here. Some of these tests are arguably out of
scope for CAs, like policing misleading names. Others of your tests
lead to possible inconsistencies. For example, let's take the case of a
CA issuing "control of domain" certs or "domain-validated certs" (what I
called them in my original message), i.e., SSL certs where the CA simply
verifies that the cert subscriber controls the domain for which the cert
is issued, and does *not* do detailed vetting of subscriber identity.
(For example, they don't require that you fax in your driver's license,
or your business license, or whatever.)
Should such a CA include information in a "control of domain" cert
beyond the domain name itself? If they don't include such information
then they fail your test 3 ("duff certs" include "Certs with NO
INFORMATION about the party to whom the cert is issued, except an email
address or a domain name"). But if the CA does include such information
in the cert, then they potentially could fail your test 2 ("duff certs"
include "Certs with false (and therefore inadequately verified)
information"), since they would be including information (e.g., a
contact name from the whois database) that is not explicitly checked as
part of the certificate issuance process, and therefore might be
"verifiably false".
Similar issues arise with email certs that are issued based on control
of the corresponding email account and for which the CA does not require
presentation of identity documents. I'll leave as an exercise for
readers coming up with "verifiably false" names that cert subscribers
might submit as input for the CN in this case.
> History: The model has not always been binary. In Netscape Navigator 3,
> the browser used a key icon that had 3 states:
> - broken
> - short, with one tooth
> - long, with two teeth.
> Two teeth meant "good enough for banking", and one tooth meant
> "better than nothing, but not good enough for banking".
A minor correction, but IMO a pertinent one: one tooth actually meant
"encrypted using a 40-bit symmetric key" and two teeth meant "encrypted
using a 128-bit key". Equating that distinction to "not good enough for
banking" vs. "good enough for banking" was an after-the-fact
interpretation, an interpretation that was to some extent subjective.
And in any case the question of key length was orthogonal to the
question of "high assurance" certs vs. "low assurance" certs.
> There are a variety of ways that this problem could be solved in the UI.
> The UI could:
>
> a) go back to a iconic model that has clearly 3 or more states, which
> are OBVIOUS to users in the chrome of the MAIN WINDOW, without the user
> needing to click or move the mouse to see the info,
This is the model I proposed in my middle-of-the-night strawman proposal
for SSL UI changes. I think the pros and cons of that proposal have been
adequately discussed in the relevant thread, so I won't comment further
here.
> b) go to a model that identifies the CA, and allow the user to decide
> for him/her self whether the CA is high or low assurance. The CA could
> be identified by text (a name) and/or a "FavIcon" as web sites are now.
> The browser could help the user remember his decision, and allow him to
> change it.
This is the "CA branding" model as proposed by Ian G and others and
implemented by Amir Herzberg and Ahmad Gbara in their TrustBar extension
(to name but one example). The pros and cons of this have also been
discussed elsewhere, so I won't comment further here.
> The second method requires the users to grow their awareness of CAs
> (of which they know nothing today). It also requires more window
> real-estate. But it keeps MF out of the judgment business, which is
> a business that MF seems particularly loath to do.
I think you're mischaracterizing the MF position (which is really not
the MF's position, at least not yet, but rather mine). I am not averse
at all to having the MF make judgements. My position is rather that the
judgements have to be based on some reasonable set of criteria that a)
can be justified in terms of reducing security risks to users; and b)
reflect the reality of how CAs operate today and are likely to operate
in the future.
> Most of the problems with technically erroneous certs have come from
> the CAs that are free, mostly users of OpenSSL, many from universities.
> The CAs with money don't have these problems, not very often.
As I stated above, we're perfectly free to reject/remove CAs that issue
"technically erroneous" certs, and I'm happy to have the policy say that
more clearly than it already does. I only ask that we have some clear
criteria on what sort of things we consider to be "technical errors",
and why. In particular, there are possibly certain things which might be
invalid according to RFC XYZ but are in practice commonly done, and not
just by "OpenSSL CAs"; if so, we'd want to take this into account.
(As one example, do we really want to disallow CAs that use CN for
domain name instead of subjectAltName in SSL certs? Would this break
existing CAs already in our list?)
> In the last month, I have seen certs from one free CA that:
> - had an invalid key
> - had NO name but the DNSName, which technically belongs not in
> the cert subject name, but in the "subject alt name". Had that
> DNSName been where it belonged, the cert's subject name would have
> been empty!
As a point of interest, for a "control of domain" cert (as defined
above) with the domain name in subjectAltName, what would you want to
see in the subject name? Information from the whois entry for the
domain? What if that information were "verifiably false" (e.g., the
domain was listed as registered to "Mickey Mouse", to use an example
from Ram A M)?
> Now, I want to summarize this. IMO, it turns out that COST has been the
> only factor responsible for the apparent success of PKI, having kept the
> issuers of duff certs out, and having allowed the issuers of good certs
> in. It wasn't the WebTrust criteria that kept them out, it wasn't the
> ETSI TS 101, it wasn't nosy auditors, it was cost.
This is a perfectly legitimate argument IMO: Costs artificially imposed
by browser vendors (e.g., requiring payments for inclusion, or requiring
costly audits) have been barriers of entry to the CA market that had the
effect of keeping out potential entrants who were judged inferior in
some way (did't know how to issue technically correct certs, didn't
follow good practices, etc.).
I think the one hole in the argument is that incumbents in the market
are now motivated to offer products like "control of domain" certs that
are issued according to less stringent policies. (Because after all
commercial CAs are businesses, not charities, and they have to grow the
business in order to satisfy shareholders and continue to pay for all
those experienced professionals, CA audits, etc.) And this in turn
reduces the perceived gap between such incumbents and the other CAs.
> Perhaps cost has also kept out some potential issuers of good certs.
> That is unfortunate. But in the security business, I think we have to
> err on the side of caution, on the side of security. This isn't
> "innocent until proven guilty". This is "untrusted until established
> as trustworthy". The only value that PKI/crypto offers is trustworthiness.
> If we lose that, we've lost the war.
Existing CAs already issue "control of domain" certificates that don't
involve strong identity checking, and IE, Firefox, etc., already "trust"
those CAs and certs. So is the war lost, or not?
> If you eliminate cost as a barrier, you MUST erect another barrier that
> will be as good as cost in keeping the duff issuers out (while the
> binary model remains).
> Will Draft 11 keep out an issuer of certs with names empty except for
> DNS names? Will draft 11 keep out issuers of certs with invalid keys?
If you define "certs with invalid keys" as technical errors then, yes,
clause 4 of draft 11 would keep them out.
As for certs with names empty except for DNS names, you have to provide
some clarification: Are SSL certs using CN for the domain name a
"technical error" for which we should invoke clause 4 to reject the CA?
What about SSL certs using subjectAltName for the domain name where the
CN value is not separately verified (e.g., it's taken directly from
whois data, or as submitted by the subscriber)? Is this a "technical
error", or rather a case where for non-technical reasons you believe CAs
should not operate using such a policy?
> > 1. I suspect that adding the other criteria (X9.79 and ETSI TS 101 456
> > and 102 042) is not at issue,
>
> Certainly those criteria are no weaker than WebTrust. Maybe even
> stronger. But will they keep out issuers of certs with invalid keys,
> with empty names? with invalid combinations of cert extensions?
Does WebTrust do this? I suspect not. So the bottom line is that the
specific set of criteria listed in the proposed policy is not an issue,
your issues are with other parts of the policy.
> > 2. Permitting "non-traditional" evaluation of CAs is certainly something
> > that one could imagine increasing risks, if the people doing the
> > evaluation don't do a good job.
>
> Doing a "good job" has to be defined in such a way that a good job
> keeps out duff issuers. I'm less worried that a non-traditional
> evaluator will be dishonest than that he will not know what to look
> for to keep out the duff. Certainly no financial auditor would.
A minor point, but: Is a "financial auditor" going to be able to discern
technical correctness of issued certs, e.g., that subjectAltName should
be used in preference to CN, or that certs should not have "authority
key IDs that include BOTH the key ID *AND* the issuer's issuer name and
serial number"? I think we can rely on CA auditors (e.g., as in the
WebTrust for CAs program) to verify that CAs operate in accordance with
their policies, and that those policies are in accordance with the
relevant criteria, no more and no less.
> > If you do believe that permitting non-traditional evaluations would
> > increase the risk of "duff certs" being issued, what would you recommend
> > we do? Tighten the requirements on when we'd allow such evaluations? Or
> > drop the idea entirely, and require that all evaluations be done by
> > authorized auditors and test labs?
>
> Well, my first goal is: keep duff cert issuers out.
>
> Now, if we can accomplish that by tighter requirements (and I think
> that is possible), then that seems very desirable. That would be
> my first choice.
It would be my first choice as well. But I think the key is separating
out cases where you might object to a CA on "technical correctness"
grounds vs. cases where you might object to a CA based on their
policies. I think criteria for "technical correctness" can be
well-specified and applied in a (relatively) non-controversial way, but
policy-related criteria are more difficult.
In some of your discussion of "duff certs" I think you are conflating
technical correctness issues with policy issues. For example: whether
CAs should stuff the domain name into CN vs. subjectAltName is a
technical issue. On the other hand, whether CAs should issue "control of
domain" certs or not is a policy issue. (And if CAs with such policies
are acceptable, and if technical correctness dictates that such CAs put
something into CN other than the domain name, then we have the
possibility of the resulting cert containing unverified and hence
potentially false information.)
> If we cannot or are unwilling to take that approach, then yes, I'd
> advocate continuing to require that all evaluations be done by
> authorized auditors and test labs. We'd be falling back on the old
> tried and true method of keeping duff issuers out. But that's not my
> first choice.
Nor would it be mine either, so let's forget the second choise for now
and continue to see if we can make the first choice work.
> > 3. Regarding requirements on CA validation of their customers, I
> > certainly don't have any such requirements in my current "WebTrust or
> > equivalent" policy, so in that sense the proposed new policy is more
> > stringent than the old policy.
>
> Somewhat, yes.
>
> > Did Netscape have such requirements?
>
> No, they required $$$$. Ever notice how the supply of PSM developers
> ended at about the same time as the trusted CA money stopped? Hmmm.
Are you suggesting that the MF charge CAs money and use it to hire PSM
developers? :-)
And on that (somewhat discordant) note I have to conclude this reply and
go get ready for work. But I hope I've at least addressed the key points
in your message.
Ian G
...
>> The second method requires the users to grow their awareness of CAs
>> (of which they know nothing today). It also requires more window
>> real-estate. But it keeps MF out of the judgment business, which is
>> a business that MF seems particularly loath to do.
>
>
> I think you're mischaracterizing the MF position (which is really not
> the MF's position, at least not yet, but rather mine). I am not averse
> at all to having the MF make judgements. My position is rather that the
> judgements have to be based on some reasonable set of criteria that a)
> can be justified in terms of reducing security risks to users; and b)
> reflect the reality of how CAs operate today and are likely to operate
> in the future.
I'd add to that c) can be justified in terms of the risks
that MF takes on by making those judgements.
>> Now, I want to summarize this. IMO, it turns out that COST has been the
>> only factor responsible for the apparent success of PKI, having kept the
>> issuers of duff certs out, and having allowed the issuers of good certs
>> in. It wasn't the WebTrust criteria that kept them out, it wasn't the
>> ETSI TS 101, it wasn't nosy auditors, it was cost.
>
>
> This is a perfectly legitimate argument IMO: Costs artificially imposed
> by browser vendors (e.g., requiring payments for inclusion, or requiring
> costly audits) have been barriers of entry to the CA market that had the
> effect of keeping out potential entrants who were judged inferior in
> some way (did't know how to issue technically correct certs, didn't
> follow good practices, etc.).
>
> I think the one hole in the argument is that incumbents in the market
> are now motivated to offer products like "control of domain" certs that
> are issued according to less stringent policies. (Because after all
> commercial CAs are businesses, not charities, and they have to grow the
> business in order to satisfy shareholders and continue to pay for all
> those experienced professionals, CA audits, etc.) And this in turn
> reduces the perceived gap between such incumbents and the other CAs.
I'm not sure it is fair to characterise CAs
as only commercial. CACert is not, and as I
wrote earlier, I found the process of being
"inducted" by them a far more daunting one
than the systems used by commercial CAs.
Also, some CAs are quangos. This tends to
occur when a "banking" style pervades in a
given country. Then, a CA tends to be operated
as a single operation wholly owned by big
organisations that are regulated and thus the
CA tends to be regulated. This removes their
profit motive, even if they are constituted as
a for-profit company.
Now, in such a scenario, it is somewhat restrictive
to think in terms of money as the barrier. It's
certainly an observation that money can be a barrier,
but it can also be a destroyer. (I used to live
next door to a TLD that was run for free and well
governed. Money came along and destroyed it....)
>> Perhaps cost has also kept out some potential issuers of good certs.
>> That is unfortunate. But in the security business, I think we have to
>> err on the side of caution, on the side of security. This isn't
>> "innocent until proven guilty". This is "untrusted until established
>> as trustworthy". The only value that PKI/crypto offers is
>> trustworthiness.
>> If we lose that, we've lost the war.
>
>
> Existing CAs already issue "control of domain" certificates that don't
> involve strong identity checking, and IE, Firefox, etc., already "trust"
> those CAs and certs. So is the war lost, or not?
This is the bit I don't get. We are in a situation
of being able to acquire practically any cert we
want whenever we want. (With a bit of skulduggery
of course, but polite thieves don't talk about that.)
So surely the pressing need is to *improve* that
situation ... by preparing the browser with additional
defences? No?
>> > Did Netscape have such requirements?
>>
>> No, they required $$$$. Ever notice how the supply of PSM developers
>> ended at about the same time as the trusted CA money stopped? Hmmm.
>
>
> Are you suggesting that the MF charge CAs money and use it to hire PSM
> developers? :-)
If MF is in the judgement business, I would say that
MF should definately charge money. As MF is now
implicitly in the judgement business by dint of
inheritance from Netscape, the current set of CAs may
have a backdated invoice coming .... unless the policy
changes along the lines of an objective, no-judgement
basis.
Netscape were able to get away with not explicitly
accounting for the risks they were taking on by being
a big company with a big balance sheet. It isn't
necessary to account for all risks, as long as the
balance sheet covers it. MF has no such easy ride.
It might well be a good idea to go back to the early
emails and internal memoranda to determine what
Netscape actually said about the risk of accepting
a CA into the root list. I gather the $$$$ was quite
large, so maybe they simply said "that should cover it."
iang
Ian G
...
(mild distraction into the arcania of history)
>> History: The model has not always been binary. In Netscape Navigator 3,
>> the browser used a key icon that had 3 states:
>> - broken
>> - short, with one tooth
>> - long, with two teeth.
>> Two teeth meant "good enough for banking", and one tooth meant
>> "better than nothing, but not good enough for banking".
>
>
> A minor correction, but IMO a pertinent one: one tooth actually meant
> "encrypted using a 40-bit symmetric key" and two teeth meant "encrypted
> using a 128-bit key". Equating that distinction to "not good enough for
> banking" vs. "good enough for banking" was an after-the-fact
> interpretation, an interpretation that was to some extent subjective.
> And in any case the question of key length was orthogonal to the
> question of "high assurance" certs vs. "low assurance" certs.
Ah... the Cryptowars, the good old days :-D In my dreams
I think of ways to restart the crypto wars, when crypto
meant something and people worked on crypto for the spirit
of security.
Coming back to reality, that whole 40-bit key thing was
nothing to do with banking. It was all to do with the
crypto export restrictions, and banking was seized upon
as a convenient and hard-to-refute excuse that tongue-
tied the average White House bureaurat.
40-bit crypto was fine for banking and probably still is,
as we lack any viable threat model for eavesdropping, and
the costs and risks associated with crunching one session
don't equate with the profit. (Peter Gutmann reports
that the cost of stolen credit card information is down
less than a buck, so to make crypto-crunching viable, you
have to crunch at substantially less than a buck, including
all risks **.)
Also note that, as has been exhaustively discussed, there
is way less strength in the certificates arm of the HTTPS
secure browsing model, with a $30 cert being easy to obtain,
and being amortised over thousands of phishes, so while
there is potentially a Pareto-secure improvement in going
from 40 bits to 128 bits, it isn't worth paying any dosh
for.
Still, both points to some extent are valid: we can have a
ternery security model again if we want to (Nelson's point)
and we just have to decide what those 3 points are (Frank's
point).
iang
** Sorry about the PDF...
http://www.cs.auckland.ac.nz/~pgut001/pubs/dammit.pdf
Gervase Markham
> (Among other things, it's perfectly possible that different corporations
> in different countries might have similar names, e.g., "First National
> Bank", so, for example, we might have a "firstnationalbank.com" vs. a
> "firstnationalbank.co.uk"
... and, in passing, I should mention that anyone who suggests
displaying the real name from the certificate to the user in the UI
needs to find a solution to this problem. :-)
Gerv
Ian G
As long as the solution is not hiding it from the user,
that doesn't sound like a problem to me. Show the name
to the user, and let the banks sort it out. That's what
happens in the real world.
iang
Ram A M
most users than having the full address listed. A lot of trickery is
enabled by clever (mis) use of the address bar. For most people the
address bar is the place they type a domain name and sometimes look to
confirm the domain name - having all the extra stuff shown makes the
users job harder. To be clear, do show "http://foobar.com" but leave
out the "user@" and the "/index.html" parts. I would of course like the
(non-default) option of seeing the full address bar because I am a
sophisiticated user.
Nelson B
>>> History: The model has not always been binary. In Netscape
>>> Navigator 3,
>>> the browser used a key icon that had 3 states:
>>> - broken
>>> - short, with one tooth
>>> - long, with two teeth.
>>> Two teeth meant "good enough for banking", and one tooth meant
>>> "better than nothing, but not good enough for banking".
Frank Hecker replied:
>> A minor correction, but IMO a pertinent one: one tooth actually meant
>> "encrypted using a 40-bit symmetric key" and two teeth meant
>> "encrypted using a 128-bit key". Equating that distinction to "not
>> good enough for banking" vs. "good enough for banking" was an
>> after-the-fact interpretation, an interpretation that was to some
>> extent subjective. And in any case the question of key length was
>> orthogonal to the question of "high assurance" certs vs. "low
>> assurance" certs.
Ian G wrote:
> [...] that whole 40-bit key thing was nothing to do with banking.
> It was all to do with the crypto export restrictions,
Banks told their users "40 bits isn't good enough", and "we won't
let you do online banking with us with a browser that can only do
40 bit crypto". The users didn't know 40-bit crypto from Limburger,
but they got the message that it their browser could only show one
tooth, it wasn't good enough for banking. They wanted browsers
good enough for banking. They understood that good enough for
banking also meant good for security in lots of other areas too.
Being good enough for banking was the driving force of much that
happened in the development of SSL.
> 40-bit crypto was fine for banking and probably still is,
> as we lack any viable threat model for eavesdropping, and
That's not true.
Transparent proxies abound. All the residents of the nation of
china have 100% of their international traffic eavesdropped.
The world's largest ISP still uses transparent proxies for all
non-SSL traffic. Many other ISPs do also.
And there are proxies operating now that do real MITM attacks
against SSL that passes through them. To use these proxies,
you must agree to an end user agreement and download their
software that installs their root CA cert. The end user agreement
prevents the user from taking any action against them for their
snooping. The user even agrees to "hold them harmless" against
any legal action that might come against them as a result of the
user blowing the whistle. Recent reports say there are tens of
thousands of users of it.
--
Nelson B
Ian G
> Ian G wrote:
>
>> [...] that whole 40-bit key thing was nothing to do with banking. It
>> was all to do with the crypto export restrictions,
>
>
> Banks told their users "40 bits isn't good enough", and "we won't
> let you do online banking with us with a browser that can only do
> 40 bit crypto"....
:-) OK, so Banks told the Users. Who told the Banks
that 40 bits wasn't good enough for them?
>> 40-bit crypto was fine for banking and probably still is,
>> as we lack any viable threat model for eavesdropping, and
>
>
> That's not true.
>
> Transparent proxies abound. All the residents of the nation of
> china have 100% of their international traffic eavesdropped.
> The world's largest ISP still uses transparent proxies for all
> non-SSL traffic. Many other ISPs do also.
Good point. So all ISPs can sniff on traffic. Now,
the question is, why have ISPs had a very low incidence
of snooping and eavesdropping? You'd think that by now
there would have been dozens even hundreds of cases of
such? After all, we know there is a non-trivial amount
of credit card traffic going over HTTP, and ISPs are
ideally placed to do perfect DNS attacks.
I've heard of about one, maybe two if we push it. I
think the reason is that your average ISP is staffed
with the wrong sort of person to do insider attacks,
whereas banks, telcos, and other places have no such
good luck.
(By viable threat model - I didn't mean it was possible,
but that it was economically attractive.)
> And there are proxies operating now that do real MITM attacks
> against SSL that passes through them. To use these proxies,
> you must agree to an end user agreement and download their
> software that installs their root CA cert. The end user agreement
> prevents the user from taking any action against them for their
> snooping. The user even agrees to "hold them harmless" against
> any legal action that might come against them as a result of the
> user blowing the whistle. Recent reports say there are tens of
> thousands of users of it.
Right, but we've excluded them, right? They could
set up 40 bit, 128 bit, 4096 bit for all we care,
and the proxy would still read A-OK. What this
means is that the user has been forced to accept
the ISP as an insider into their PC. Nothing SSL
can do about that except ... operate over HTTP :)
iang
Duane
> Right, but we've excluded them, right? They could
> set up 40 bit, 128 bit, 4096 bit for all we care,
> and the proxy would still read A-OK. What this
> means is that the user has been forced to accept
> the ISP as an insider into their PC. Nothing SSL
> can do about that except ... operate over HTTP :)
Geez no wonder people pull root certs out of their browser...
Nelson B
> :-) OK, so Banks told the Users. Who told the Banks
> that 40 bits wasn't good enough for them?
Well, I think many banks had a better clue than most Limburger
(er, 40-bit crypto) users. Then there was the incident where a
college student broke a 40-bit key using unused CPU cycles of
campus computers, and then proceeded to read old SSL traffic with
it.
> Good point. So all ISPs can sniff on traffic. Now,
> the question is, why have ISPs had a very low incidence
> of snooping and eavesdropping?
Why do you think that there has been a low incidence?
Perhaps you expect the ISPs to be dumb enough to go out and
use the CC numbers to buy TVs or drugs. Instead, some sell the
personal info they find to information brokers. Marketeers
really like to know who has big bank balances and who doesn't.
By keeping it inobvious to the victim, the eavesdroppers can keep
it up profitably for years. That's more valuable than a couple
of TVs. Many broadband users in the US have signed agreements
explicitly allowing this!
> You'd think that by now there would have been dozens even
> hundreds of cases of such?
There have been, but as I said ...
> I've heard of about one, maybe two if we push it. I
> think the reason is that your average ISP is staffed
> with the wrong sort of person to do insider attacks,
> whereas banks, telcos, and other places have no such
> good luck.
It's not the employee doing it against his boss's wishes.
It's the boss's wishes being carried out.
> (By viable threat model - I didn't mean it was possible,
> but that it was economically attractive.)
Very attractive to sell that data.
>> And there are proxies operating now that do real MITM attacks
>> against SSL that passes through them. To use these proxies,
>> you must agree to an end user agreement and download their
>> software that installs their root CA cert. The end user agreement
>> prevents the user from taking any action against them for their
>> snooping. The user even agrees to "hold them harmless" against
>> any legal action that might come against them as a result of the
>> user blowing the whistle. Recent reports say there are tens of
>> thousands of users of it.
> Right, but we've excluded them, right?
I don't think so. How have we excluded them?
One of them has a WebTrust seal. Although they have not yet
approached mozilla to be admitted as a CA (AFAIK), if they did so,
on what basis in the present policy draft would they be denied?
Hint: think policy floor.
--
Nelson B
Ian G
> Ian G wrote:
>
>> :-) OK, so Banks told the Users. Who told the Banks
>> that 40 bits wasn't good enough for them?
>
>
> Well, I think many banks had a better clue than most Limburger
> (er, 40-bit crypto) users. Then there was the incident where a
> college student broke a 40-bit key using unused CPU cycles of
> campus computers, and then proceeded to read old SSL traffic with
> it.
Yes, scary, but in the event a security threat of
much gravity. What's even more scary was that he
did it twice. Even his name is likely to make you
cringe ;-)
But, in security work, we make a distinction between
demonstrations of attacks and economics models of
viable attacks. What they/he did wasn't economic,
just scary.
>> Good point. So all ISPs can sniff on traffic. Now,
>> the question is, why have ISPs had a very low incidence
>> of snooping and eavesdropping?
>
>
> Why do you think that there has been a low incidence?
Literally, it's because - I hypothesize - that techies
make poor and unlikely crooks. Mostly the culture is
one where such opportunity would be frowned upon, and
the people concerned are rewarded relatively well for
activity that would mentally oppose the notion of theft.
Being a techie or programmer requires some element of
slavishness to the truth, as computers laugh if you
lie to them, and they give you all sorts of puzzles
that are based on fundamental but obscured truths.
One thing is that for any active attack, look for any
evidence of passive eavesdropping. (And there is very
little evidence that ISPs have people that do that.)
Techies have no time to sit their reading data looking
for the needle in a haystack.
Eavesdropping over open channels is a leading
indicator of any active attack, such as crunching easy
crypto or doing an MITM. The eavesdropping attack is
the only sensible one, as it leaves no traces. An MITM
is orders of magnitudes more risky as it involves sending
packets over the network, ones that can be traced and
tracked back to source.
Finally, there is this factor - for every attack, you get
a low likelihood of success, and a high work effort. You
have to scan many sessions to get one lousy credit card.
So you have a high workload, for low quality results.
> Perhaps you expect the ISPs to be dumb enough to go out and
> use the CC numbers to buy TVs or drugs. Instead, some sell the
> personal info they find to information brokers. Marketeers
> really like to know who has big bank balances and who doesn't.
> By keeping it inobvious to the victim, the eavesdroppers can keep
> it up profitably for years. That's more valuable than a couple
> of TVs. Many broadband users in the US have signed agreements
> explicitly allowing this!
>
>> You'd think that by now there would have been dozens even
>
> > hundreds of cases of such?
>
> There have been, but as I said ...
>
>> I've heard of about one, maybe two if we push it. I
>> think the reason is that your average ISP is staffed
>> with the wrong sort of person to do insider attacks,
>> whereas banks, telcos, and other places have no such
>> good luck.
>
>
> It's not the employee doing it against his boss's wishes.
> It's the boss's wishes being carried out.
Well, that's another thing, that's called marketing,
or as you mentioned in the other example, national
policy. Are you suggesting that Mozilla Foundation
take a stance on these things?
Where it is in the agreement, it is a thing that can
be accepted by the user or rejected. We should be
careful not to confuse our threat models with what's
written in the contract and doesn't appeal to our
sensibilities, and what's an aggressive and unexpected
attack.
(And, even more use of 40-bit crypto with certs will
stop that activity if that's what you don't like. No
marketeer is going to spend big bucks on crunching
hardware, he wants all stuff to be open at the cert
level, and to do that there will be the "chinese
agreement" in which case, our efforts here have been
overridden at layers 8 or 9 of the stack.)
>> (By viable threat model - I didn't mean it was possible,
>> but that it was economically attractive.)
>
>
> Very attractive to sell that data.
If it is risk free, yes. It isn't risk free if it is
uneconomic - that's my point. Security is about risks:
costs versus benefits must be calculated, and low risks
can be "absorbed" while high risks should be explicitly
addressed.
The distinctions are these:
* each CC is hard to get, a needle in a packet haystack
* techies aren't the type to do it
* crunching 40bits or doing MITMs is kind of obvious
over the long term.
In contrast, the people who work in the backoffice of
the merchants are often less well paid, less incentivised
to be honest, bored, and have an easy way to lift the entire
database with one SQL instruction. This is why almost
all theft of data happens at the backend, either as an
inside job, or as a crack from outside.
>>> And there are proxies operating now that do real MITM attacks
>>> against SSL that passes through them. To use these proxies,
>>> you must agree to an end user agreement and download their
>>> software that installs their root CA cert. The end user agreement
>>> prevents the user from taking any action against them for their
>>> snooping. The user even agrees to "hold them harmless" against
>>> any legal action that might come against them as a result of the
>>> user blowing the whistle. Recent reports say there are tens of
>>> thousands of users of it.
>
>
>> Right, but we've excluded them, right?
>
>
> I don't think so. How have we excluded them?
We have excluded them from the class of cert attackers
because they do it with the agreement of the users.
They are not attackers, they are participants, insiders.
The users install their root cert - that's what you said,
right?
Whatever Mozilla provides these users with, the ISP
says, we don't care, just let us read your encrypted
traffic. Right? They are excluded therefore from
our view of the threat model.
> One of them has a WebTrust seal. Although they have not yet
> approached mozilla to be admitted as a CA (AFAIK), if they did so,
> on what basis in the present policy draft would they be denied?
>
> Hint: think policy floor.
So, they are like another big CA that is in the root
list already - that has a stated objective that puts
it in conflict with the users of its certificates? I've
written elsewhere on who this might be.
Currently the view is tending towards:
a) MoFo should not be in the judgement business,
b) the CA process is clearly documented
c) some untested angle for kicking them out if they
do bad
so this hypothetical ISP/CA that has an agreement with
all users to listen to their traffic is no difficulty.
If it has the WebTrust it's in. If not, then it has to
follow the alternates that have been worked out by this
group.
Or, are you saying that MoFo should be in the judgement
business? And, who do you think gets to be the judge?
Judgement won't fly. We've clearly set our goals as the
average user, and if enough average users decide to take
up the kind offer of a benevolent ISP then ... the
average user has spoken! That's that!
( Go check out cryptorights.org.
But, just a slight upfront - even those guys are not in
the judgement business, they will supply their product
to the benevolent ISP as well as the user. It's just
that they've decided their target user is the one that
has something to hide and also has an aggressive attacker
who is trying to take it from them.
Unlike Mozilla. )
Gervase Markham
> Good point. So all ISPs can sniff on traffic. Now,
> the question is, why have ISPs had a very low incidence
> of snooping and eavesdropping? You'd think that by now
> there would have been dozens even hundreds of cases of
> such? After all, we know there is a non-trivial amount
> of credit card traffic going over HTTP, and ISPs are
> ideally placed to do perfect DNS attacks.
>
> I've heard of about one, maybe two if we push it. I
> think the reason is that your average ISP is staffed
> with the wrong sort of person to do insider attacks,
> whereas banks, telcos, and other places have no such
> good luck.
It's interesting to contrast this view of ISPs with your view of CAs,
which is almost entirely the opposite... :-)
Gerv
Gervase Markham
> I think that having a clean domain name listing is better by far for
> most users than having the full address listed.
Have you used Firefox 1.0?
Gerv
Ian G
LOL... I guess it may look that way, but the process is
the same: both are participants in the game of players,
and both should be modelled as economic agents with risks
and desires for dosh.
Statistically, we should have seen evidence of massive
fraud by now inside ISPs. Statistically, we should have
seen the same thing in CAs.
But in actual observable reality, we've only seen isolated
events that show a) it's easy to do and b) they aren't
doing it.
What that leads us to conclude (and I'm not the only one
that is thinking this) is that in neither case is there an
economic model for doing these things. Neither for the
CAs nor for the ISPs is there money in them breaking the
rules and futzing with the customers by spying, MITMing,
spoofing, identity theft, etc etc.
Now herein lies a key difference: CAs can issue false
certs which permit undetectable MITMs. ISPs are still
limited to crunching 40 bit crypto (rare, and not so
much of a danger but an interesting thought experiment
hence my claim of it being good enough for banking) or
by eavesdropping on sexchat on AIM or whatever takes
their fancy. Harder to make money there.... But ISPs
have got access to the traffic, which CAs don't really
have.
CAs combined with ISPs would be much more dangerous.
Having them separated means that any CA or ISP that
were to go rogue would still need a partner, and one of
our favourite anti-fraud techniques is to force frauds
into multi-player space. Once we have a conspiracy,
we know that it will unravel soon enough...
But what happens when a CA becomes an ISP? What happens
when a CA indicates it is in the business of helping
people to track, trace, spy, eavesdrop, spoof and MITM?
Now that's crossing a line called _conflict of interest_,
another one of our favourite anti-fraud techniques...
http://www.financialcryptography.com/mt/archives/000206.html
Frank Hecker
> Banks told their users "40 bits isn't good enough", and "we won't
> let you do online banking with us with a browser that can only do
> 40 bit crypto". The users didn't know 40-bit crypto from Limburger,
> but they got the message that it their browser could only show one
> tooth, it wasn't good enough for banking.
I'm actually not disagreeing with you, but there are some important
points here that I want to highlight because IMO they're relevant to the
present discussion. I'll warn you and others in advance that some of my
arguments may seem philosophical in nature, but I do think that the
philosophizing has a valid purpose.
First, we have to distinguish between differences in technical
mechanisms and the meaning that people attach to those differences. (By
"people" I mean typical users, but often others as well -- including us.)
To repeat: From a technical point of view the "one tooth"/"two teeth" UI
difference (one for 40-bit, two for 128-bit) was simply a distinction
regarding key length that arose from external factors (i.e., US
encryption export regulations). No one deliberately sat down and said
"We'll design SSL to have a 'good enough for banking' mode and a 'not
good enough for banking' mode, and we'll choose 128-bit encryption for
the one and 40-bit for the other."
On the other hand, once the technical distinction existed banks then
attached a particular meaning to the distinction: that secure on-line
banking required 128-bit keys, and could not be done with 40-bit keys.
And why should they not do so? Certainly all other things being equal,
using 128-bit encryption was at least as secure as using 40-bit and
possibly more so. (Or to put it in risk terms, using 128-bit certainly
did not increase risk vs. using 40-bit, and might possibly decrease it.)
And for US banks there was little or no cost in mandating use of 128-bit
encryption, so why not do so? (The only real impact would have been for
US banks with non-US customers, a fairly small group.)
(Note to Ian: Whether 40-bit encryption actually posed a real security
risk or not is IMO irrelevant to the banks' decision making. Arguably
not allowing use of 40-bit for online banking was irrational in some
sense, but I believe that in real-world security decisions irrationality
can't be removed from the equation, no more than it can in real-world
economic decisions -- e.g., behavioral economics -- and has to be
accounted for in any analysis.)
Once the banks attached meaning to 40-bit vs. 128-bit then clearly end
users picked up on that meaning (to the extent that they associated any
meaning at all to the 40-bit vs. 128-bit distinction). By the time the
liberalization of US export regulations ended the need for 40-bit, the
equation "(128-bit) SSL means 'secure for banking'" was firmly fixed in
people's minds, as it remains today.
Now, what does this have to do with the present discussion? Simply this:
we are again dealing with technical distinctions first and foremost, and
then running into trouble trying to attach firm fixed meanings to those
distinctions. More specifically: On the one hand we have certificates
(specifically SSL certs) that are issued after a particular type of CA
process, a process (typically automated) that verifies the suscriber's
control of the domain associated with the cert. On the other hand, we
have SSL certificates for which the CA's processes also include
additional checks (some automated, some not) through which the CA
purports to verify the claimed real-world identity of the subscriber.
At heart this is a technical distinction that IMO is ultimately driven
by the economics of the CA business: (commercial) CAs are motivated to
reach a new class of more price-sensitive customers (because their
traditional business has reached a plateau) and reaching those
price-sensitive customers requires achieving cost efficiencies, which in
turn can be done through the introduction of increased automation and
taking humans out of the loop.
It's tempting to attach a meaning to this technical distinction between
"control of domain" certs and "claimed identity" certs, and say that the
first is "low assurance" and the second is "high assurance"; the CAs
themselves encourage us to attach this meaning, just as the banks
encouraged us to think of 128-bit SSL as "good enough for banking" and
40-bit as "not good enough". And the organizations running e-commerce
and online financial sites have no reason to object to CAs attaching the
"low" / "high" labels; after all, from the point of view of those
organizations the difference in cost between "control of domain" and
"claimed identity" certs is negligible, and so they might as well choose
the (claimed) "high assurance" option. However I think we should resist
attaching the "low assurance/high assurance" meaning to this
distinction, at least temporarily -- while I finish my argument! -- and
maybe permanently, for the following reasons:
First, as with 40-bit vs. 128-bit I think the "control of domain" /
"claimed identity" distinction arises from external factors not
necessarily intrinsic to the actual security issues. Again, I doubt that
anyone did a thorough security analysis and concluded from that analysis
that we absolutely needed two (or more) types of certs and associated
cert issuance processes. IMO it's more that the distinction between
different types of certs *could* be made on technical grounds (having to
do with different cert issuance processes) and having done that it's
then tempting to attach fixed security-related meanings (e.g., "low/high
assurance") to the distinction.
Second: If we restrict our discussion to a given CA and don't care about
cost, it's certainly preferable to have a "claimed identity" cert than a
"control of domain" cert, since within a given CA a "claimed identity"
cert application involves all the checks done for a "control of domain"
cert plus some additional checks as well, and the manner in which the
checks common to both types of certs are done is the same. As a result
the "level of assurance" for a "claimed identity" cert is certainly not
less than that for a "control of domain" cert, and could possibly be
greater. However once we consider the domain of all CAs then we can't
necessarily assume a priori that this will remain true.
(Similarly in the 40-bit vs. 128-bit case the equation 'security of
128-bit' >= 'security of 40-bit' wasn't necessarily universally true
across all browsers and web servers; for example, the security of
128-bit encryption in Netscape Navigator 1.0 was less than the security
of 40-bit encryption in Netscape Navigator 2.0, due to SSL
implementation flaws in NN 1.0.)
Thus we can't necessarily throw all "control of domain" certs into a
"low assurance" category and all "claimed identity" certs into a "high
assurance" category, with any cert in the "high assurance" category
being associated with less risk than any cert in the "low assurance"
category. (This may have been one of the points Ian was trying to make
with his questions asking why one CA sold a "high-assurance" cert for
less than another CA sold a "low assurance" cert.)
Finally, it's not clear how big the "assurance gap" really is between
"control of domain" certs and "claimed identity" certs, and whether it's
large enough to justify using terms like "low" vs. "high" to describe
the two types. Clearly if it were trivially easy and cost nothing at all
(in terms of time, money, whatever) to "spoof" a CA's identity
verification process (i.e., to get a "claimed identity" cert under a
false identity) then there wouldn't be enough difference to justify a
"high/low" distinction. CAs will protest that it's not trivially easy to
spoof their procedures, and I'll gladly give them the benefit of the
doubt, but IMO using words like "low" and "high" in this context is
still something that can't simply be assumed a priori to be appropriate.
At this point you may be saying, "Enough philosophizing already, what's
your point?" My purpose in doing this is to try to think through my
strawman UI proposal earlier (to replace the binary "no SSL"/"SSL" UI
with a more multivalued model) and to try to improve it and address some
of the objections to it.
In particular, one of the main objections to the strawman proposal is to
the division of CA certs into "high assurance" certs (for which the
padlock is displayed) and "low assurance" certs (for which something
else is displayed), on the grounds that such a division isn't actually
valid or straightforward to do. I think those objections are worthy of a
serious response, and any realistic proposal has to take them into account.
As I mentioned in previous posts, the Mozilla Foundation could certainly
take on the task of deciding which CAs and certs were "high assurance"
and which were not. The problem is that IMO it's difficult to do this in
a way that is simultaneously easy, objective, and correct (i.e.,
reflecting the real risks -- not simply the hypothesized risks -- as
determined by a rigorous security analysis).
So what's the alternative? One alternative is to retain the division of
CAs and certs into two (or more) classes for purposes of the UI, but not
go overboard in presenting this as a "low" vs. "high" distinction. For
example, we could make a UI distinction between "control of domain" SSL
certs and "claimed identity" certs, but in presenting this to the user
(e.g., in informational messages and the like) we would simply present
the technical distinction and not editorialize about "trust", "high
assurance", "safe for online banking", and the like.
(So, for example, when a user is presented information about an
SSL-enabled site with a "control of domain" cert issued by the Foo Class
1 CA, Firefox might display something like "The site you connected to
has the domain name 'www.acmewidgets.com', as verified by the 'Foo Class
1 CA' independent service", while for "claimed identity" certs Firefox
might display something like "The site you connected to has the domain
name 'www.acmewidgets.com' and is operated by 'Acme Widgets, Inc.', as
verified by the 'Foo Class 1 CA' independent service.")
Now, would users and others insist on attaching meaning to the UI
differences, i.e., that seeing the padlock means "safe for
e-commerce/banking" and seeing the checkmark means "not safe enough"? Of
course they would; this is inevitable given that (at least some) users
already existing expectations, and that CAs and operators of major
e-commerce and financial sites have an interest in promoting and
reinforcing those expectations. But we as browser vendors don't have to
join them in doing this, and arguably it would be better if we didn't.
Ian G
> Nelson B wrote:
>
>> Banks told their users "40 bits isn't good enough", and "we won't
>> let you do online banking with us with a browser that can only do
>> 40 bit crypto". The users didn't know 40-bit crypto from Limburger,
>> but they got the message that it their browser could only show one
>> tooth, it wasn't good enough for banking.
>
>
> I'm actually not disagreeing with you, but there are some important
> points here that I want to highlight because IMO they're relevant to the
> present discussion. I'll warn you and others in advance that some of my
> arguments may seem philosophical in nature, but I do think that the
> philosophizing has a valid purpose.
It's definately a good thought experiment; the days
of 40-bit v. 128-bit are well behind us now, and the
notions and arguments of those times can be considered
history.
Of course, no bank would turn around and say "oh, well,
we'll save some bits and go 40-bits coz Iang said so..."
but it is instructive to try and work out in our own
minds why it is we think this, and whether it's a valid
model for technical and economics security reasons, as
opposed to the political, liability and marketing reasons
that also swirled around in the 'good old days' of the
crypto wars.
> First, we have to distinguish between differences in technical
> mechanisms and the meaning that people attach to those differences. (By
> "people" I mean typical users, but often others as well -- including us.)
>
> To repeat: From a technical point of view the "one tooth"/"two teeth" UI
> difference (one for 40-bit, two for 128-bit) was simply a distinction
> regarding key length that arose from external factors (i.e., US
> encryption export regulations). No one deliberately sat down and said
> "We'll design SSL to have a 'good enough for banking' mode and a 'not
> good enough for banking' mode, and we'll choose 128-bit encryption for
> the one and 40-bit for the other."
Right. Although, arguably, SSL was designed to be
"good enough for credit cards." What I would say
however is that when the 40 bit and 128 bit stuff
was put in there, it was totally driven by export
considerations, and only later did the alignment
along "banking strength" come up.
> On the other hand, once the technical distinction existed banks then
> attached a particular meaning to the distinction: that secure on-line
> banking required 128-bit keys, and could not be done with 40-bit keys.
> And why should they not do so? Certainly all other things being equal,
> using 128-bit encryption was at least as secure as using 40-bit and
> possibly more so. (Or to put it in risk terms, using 128-bit certainly
> did not increase risk vs. using 40-bit, and might possibly decrease it.)
> And for US banks there was little or no cost in mandating use of 128-bit
> encryption, so why not do so? (The only real impact would have been for
> US banks with non-US customers, a fairly small group.)
Right, Pareto-secure-improvements and all that ;-)
> (Note to Ian: Whether 40-bit encryption actually posed a real security
> risk or not is IMO irrelevant to the banks' decision making. Arguably
> not allowing use of 40-bit for online banking was irrational in some
> sense, but I believe that in real-world security decisions irrationality
> can't be removed from the equation, no more than it can in real-world
> economic decisions -- e.g., behavioral economics -- and has to be
> accounted for in any analysis.)
Let me add disagree mildly here: Banks make security decisions
according to rational processes. The problem is that those
processes are not based on security, so to the outside observer
they look irrational because they speak of security!
One of those processes
is an excessive sensitivity to criticism on security, which
relates to them as regulated players, and as listed players.
Both these forces push banks in the direction of doing
"everything they can" to secure their processes. Which
means that given the choice between 40-bit and 128-bit, it
would be very very unlikely that banks would choose 40-bit
knowingly.
Note that "cricitism to security" is not the same thing as
security.
The thing to look for with banks' security decisions
is the bunch of other factors involved. A simple decision
like 40-bit v. 128-bit was made clearly towards 128-bit
because there were almost no other factors (you indicated
one, being non-US customers; non-US banks had a much harder
time of it). A much more complex decision such as the use
of 2 factor authentication results in a much harder choice
for them. As a matter of history, banks in Europe have
chosen two-factor authentication without difficulty, whereas
only now, under influence from phishing, are US banks moving
to 2 factor devices. Which is a confusing story in itself,
until you remember that banks are not choosing 2 factor
authentication for security reasons ....
> Once the banks attached meaning to 40-bit vs. 128-bit then clearly end
> users picked up on that meaning (to the extent that they associated any
> meaning at all to the 40-bit vs. 128-bit distinction). By the time the
> liberalization of US export regulations ended the need for 40-bit, the
> equation "(128-bit) SSL means 'secure for banking'" was firmly fixed in
> people's minds, as it remains today.
> (Similarly in the 40-bit vs. 128-bit case the equation 'security of
> 128-bit' >= 'security of 40-bit' wasn't necessarily universally true
> across all browsers and web servers; for example, the security of
> 128-bit encryption in Netscape Navigator 1.0 was less than the security
> of 40-bit encryption in Netscape Navigator 2.0, due to SSL
> implementation flaws in NN 1.0.)
A good point.
(I've just limited this post to the "thought exercise"
of banks and 40 bits, for now.)
iang
Ian G
> Now, what does this have to do with the present discussion?...
>
> At heart this is a technical distinction that IMO is ultimately driven
> by the economics of the CA business: (commercial) CAs are motivated to
> reach a new class of more price-sensitive customers (because their
> traditional business has reached a plateau) and reaching those
> price-sensitive customers requires achieving cost efficiencies, which in
> turn can be done through the introduction of increased automation and
> taking humans out of the loop.
Right. It's important to bear in mind that the
entire cert sales industry is tiny, and is literally
too small to support the level of activity that we
see. There are only about order of 100k certs to
fight over in a year, so we are talking of order of
under $100m for revenues spread among 100 CAs.
> It's tempting to attach a meaning to this technical distinction between
> "control of domain" certs and "claimed identity" certs, and say that the
> first is "low assurance" and the second is "high assurance";...
The reason for separating out the certs into "high" and "low"
is almost guarunteed to be marketing. The marketing imperitive
is to create a ramped range of products. This is a well
studied phenomena in b-school and marketing school, as well
as (perhaps surprisingly) economics. The key phrases here are
'consumer surplus' and also 'price discrimination' if anyone
fancies researching more:
http://en.wikipedia.org/wiki/Consumer_surplus (not so good)
http://en.wikipedia.org/wiki/Price_discrimination (better)
Or, here's a quick description with grounding in the certs
market.
When a market only has one product, the pressure to create
two products, being an expensive one and a cheap one, is
*immense*. It would be utterly astounding if this were not
to happen, it would represent a challenge to our understanding
of the laws of economics. But we can ignore that as the market
for certs followed on spec.
Once two products are established and are *successful* there
arises pressure to create three, then four, then more, and in
each case there is one primary objective: create a range of
prices from very cheap to very expensive.
Now, the market for certs has followed here as well. Look
at godaddy's page, and you will see *four* difference certs
all with different prices.
The thing to keep firmly in mind is that this is *nothing*
to do with the technical issues of security or even cost.
It is solely a phenomenum of marketing and economics known
as price discrimination.
However - and this is where the security comes in - when
the user is presented with these different prices, they
need something to justify the difference. Security happens
to be a highly convenient issue. Automation is very
convenient for cheap, and human checking is good for
expensive. But you'll also note that wildcard domains
are in there as well, and they are priced differently on
different metrics.
How do we prove this? Easy: the existence of different
certs for different prices has to be primarily to create
a ramped price structure for the perception of the buyer
of the cert because the end-users - the browsing user and
the site operator - can't see the difference anyway.
QED.
> ...IMO it's more that the distinction between
> different types of certs *could* be made on technical grounds (having to
> do with different cert issuance processes) and having done that it's
> then tempting to attach fixed security-related meanings (e.g., "low/high
> assurance") to the distinction.
Precisely. Security and so forth comes along conveniently
to help the marketing. But we shouldn't make the mistake
that this is anything but a convenience.
(I'll go and read the non-econ part now...)
iang
Ian G
(Last one!)
> (So, for example, when a user is presented information about an
> SSL-enabled site with a "control of domain" cert issued by the Foo Class
> 1 CA, Firefox might display something like "The site you connected to
> has the domain name 'www.acmewidgets.com', as verified by the 'Foo Class
> 1 CA' independent service", while for "claimed identity" certs Firefox
> might display something like "The site you connected to has the domain
> name 'www.acmewidgets.com' and is operated by 'Acme Widgets, Inc.', as
> verified by the 'Foo Class 1 CA' independent service.")
The difficulty I see here is that a Cert has to
non-arbitrarily describe whether it is a control-
of-domain cert or whether it is a claimed-identity
cert. I don't see this as an easy thing to do.
Yes, there could be a bit in there. But, the
history of certs seems to indicate that relying
on bits for important statements has been
troublesome.
> Now, would users and others insist on attaching meaning to the UI
> differences, i.e., that seeing the padlock means "safe for
> e-commerce/banking" and seeing the checkmark means "not safe enough"? Of
> course they would; this is inevitable given that (at least some) users
> already existing expectations, and that CAs and operators of major
> e-commerce and financial sites have an interest in promoting and
> reinforcing those expectations. But we as browser vendors don't have to
> join them in doing this, and arguably it would be better if we didn't.
Right. Any one bit distinction is going to suffer
a need for widespread adoption (yeah, roight...)
and also a way of dealing with cheaters. We don't
have any power over a CA that decides to set the bit
in all certs, and then fob us off with excuses about
how their Nepalese call-centre operation did in fact
look at the png of a drivers licence.
It's for complex reasons like these that I like the
idea of putting the logo of the CA where all the other
stuff is. If the CA logo is one to one with the root
cert that signed, then it's up to the CA to brand his
logo for each root cert. If he wants 2 products, he
teaches his user base to look for the cheap green logo
and the expensive purple logo. If he wants 10 products
he pays more money and gets more 'brand' in which case
there is a natural limit on his use of the system.
And, there is no way a CA can cheat this system, as
if he cheats, it just causes a brand shift in the
user base. "Yeah, those purple ones aren't worth
it any more..."
iang
Ram A M
and Opera occasionally. This is in part hobby, in part a consequence of
my career path.
I assume you are leading to the domain-name in the status bar for TLS
sites. That is a solid step forward. (this is now redundant with the
same vein discussion on another thread so I'll stop here here).
Ram A M
Frank Hecker wrote:
> Nelson B wrote:
> > Banks told their users "40 bits isn't good enough", and "we won't
> > let you do online banking with us with a browser that can only do
> > 40 bit crypto". The users didn't know 40-bit crypto from
Limburger,
> > but they got the message that it their browser could only show one
> > tooth, it wasn't good enough for banking.
> To repeat: From a technical point of view the "one tooth"/"two teeth"
UI
> difference (one for 40-bit, two for 128-bit) was simply a distinction
> regarding key length that arose from external factors (i.e., US
> encryption export regulations). No one deliberately sat down and said
> "We'll design SSL to have a 'good enough for banking' mode and a 'not
> good enough for banking' mode, and we'll choose 128-bit encryption
for
> the one and 40-bit for the other."
I think folks learned that the US Government wouldn't allow
unrestricted use of 128-bit encryption but didn't care about
restricting 40-bit. Upon learning this they interpreted it to mean that
the US saw a practical cryptographic difference between the two such
that it didn't want to allow Netscape and Microsoft to enable trivial
impediment of US government access to data. By the way, you may recall
that exceptions were made for health and financial industries such that
a US bank could get a special certificate that temporarily enabled
"strong crypto" in "export grade" browsers during banking or medical
industry service access; interesting restrictions were put in place as
well such as no service to the 'bad countries' (known terrorist
countries) and 'bad companies' (those known to have 'sold out' US
national security interests in the past). The browser companies
probably felt obliged to enable the user to make the distinction even
though the service providers where enabled as well.
Can I correctly infer that you don't feel any safer submitting your
social security number to a site using a VeriSign Class 3 certificate
relative to a 'domain-control' only certificate?
> First, as with 40-bit vs. 128-bit I think the "control of domain" /
> "claimed identity" distinction arises from external factors not
> necessarily intrinsic to the actual security issues. Again, I doubt
that
> anyone did a thorough security analysis and concluded from that
analysis
> that we absolutely needed two (or more) types of certs and associated
> cert issuance processes. IMO it's more that the distinction between
> different types of certs *could* be made on technical grounds (having
to
> do with different cert issuance processes) and having done that it's
> then tempting to attach fixed security-related meanings (e.g.,
"low/high
> assurance") to the distinction.
I'd say that in the early days the US lawyers working in industry
(legal and CA believed that such a distinction was paramount for a
robust PKI. Some research will bare this out if you're really curious.
This is still true today; look at the discussions the American Bar
Association or the National Association of Notaries for current data;
OASIS carries technical forums that are active on this topic including
participation of ABA.
> Finally, it's not clear how big the "assurance gap" really is between
> "control of domain" certs and "claimed identity" certs, and whether
it's
> large enough to justify using terms like "low" vs. "high" to describe
> the two types. Clearly if it were trivially easy and cost nothing at
all
> (in terms of time, money, whatever) to "spoof" a CA's identity
> verification process (i.e., to get a "claimed identity" cert under a
> false identity) then there wouldn't be enough difference to justify a
> "high/low" distinction. CAs will protest that it's not trivially easy
to
> spoof their procedures, and I'll gladly give them the benefit of the
> doubt, but IMO using words like "low" and "high" in this context is
> still something that can't simply be assumed a priori to be
appropriate.
I'm sure some CAs work very hard to ensure that their process is hard
to spoof and further work at refining the process in response to
changes in the landscape, including testing the authentication staff by
regularly injecting fake enrollments to ensure they are paying
attention. This is similar to how a responsible software provider
improves their products and tests the code and UI that comes out of
development. Just as one distinguishes in quality between different
software providers, so it is possible to do for CA authentication
practices. Do you really believe that it is as easy to get an 'identity
cert' as it is to get a 'domain control' cert?
Ram A M
Ian G wrote:
> Frank Hecker wrote:
> > Nelson B wrote:
> > (Note to Ian: Whether 40-bit encryption actually posed a real
security
> > risk or not is IMO irrelevant to the banks' decision making.
Arguably
> > not allowing use of 40-bit for online banking was irrational in
some
> > sense, but I believe that in real-world security decisions
irrationality
> > can't be removed from the equation, no more than it can in
real-world
> > economic decisions -- e.g., behavioral economics -- and has to be
> > accounted for in any analysis.)
>
>
> Let me add disagree mildly here: Banks make security decisions
> according to rational processes. The problem is that those
> processes are not based on security, so to the outside observer
> they look irrational because they speak of security!
If phishing continues to gain in popularity I wouldn't be overly
surprised if we see banks start to require use of currently patched
OSes and browsers that make it harder to trick the user. This of course
assumes there is significant difference between the options a user has
which I expect will be the case with-in a few years time.
> One of those processes
> is an excessive sensitivity to criticism on security, which
> relates to them as regulated players, and as listed players.
> Both these forces push banks in the direction of doing
> "everything they can" to secure their processes. Which
> means that given the choice between 40-bit and 128-bit, it
> would be very very unlikely that banks would choose 40-bit
> knowingly.
>
> Note that "cricitism to security" is not the same thing as
> security.
Both fair points.
Ram A M
Ian G wrote:
> Frank Hecker wrote:
>
> > Now, what does this have to do with the present discussion?...
> >
> > At heart this is a technical distinction that IMO is ultimately
driven
> > by the economics of the CA business: (commercial) CAs are motivated
to
> > reach a new class of more price-sensitive customers (because their
> > traditional business has reached a plateau) and reaching those
> > price-sensitive customers requires achieving cost efficiencies,
which in
> > turn can be done through the introduction of increased automation
and
> > taking humans out of the loop.
>
>
> Right. It's important to bear in mind that the
> entire cert sales industry is tiny, and is literally
> too small to support the level of activity that we
> see. There are only about order of 100k certs to
> fight over in a year, so we are talking of order of
> under $100m for revenues spread among 100 CAs.
I think VeriSign claims over 400,000 active class 3 SSL subsribers.
> > It's tempting to attach a meaning to this technical distinction
between
> > "control of domain" certs and "claimed identity" certs, and say
that the
> > first is "low assurance" and the second is "high assurance";...
>
>
> The reason for separating out the certs into "high" and "low"
> is almost guarunteed to be marketing.
Disagree. There is certainly pressure to segment the market, especially
when there is a real difference in requirements. I think there is a
huge unserved markets for class 1 server certificates.
> > ...IMO it's more that the distinction between
> > different types of certs *could* be made on technical grounds
(having to
> > do with different cert issuance processes) and having done that
it's
> > then tempting to attach fixed security-related meanings (e.g.,
"low/high
> > assurance") to the distinction.
>
>
> Precisely. Security and so forth comes along conveniently
> to help the marketing. But we shouldn't make the mistake
> that this is anything but a convenience.
You would be shocked to learn the price of running revocation services
(CRL serving and OCSP responders). No immediatley value to the CA other
than providing a more robust service that is safer to rely on comes to
mind. The extra authentication costs associated with dual-controlled
authentication process with manual review doesn't add much marketing
value (yet?) but it does provide a more robust process that is less
susceptible to requiring revocation and in that way is a better
candidate for banking or other authentication sensitive applications
than a fully automated process. I think you'll appreciate the need to
manage margins as part of competing in a market and I asasume that
given a few hundred million US dollars on the line annually and a large
list of enabled competitors in the space (how many entries on the IE
and MoFo root lists for SSL) that the market is at least somewhat
competitive and that CAs doing expensive auth. and running expensive
services wouldn't do it if they didn't want to offer a best-of-breed
service, would they?
Ian G
>>Right. It's important to bear in mind that the
>>entire cert sales industry is tiny, and is literally
>>too small to support the level of activity that we
>>see. There are only about order of 100k certs to
>>fight over in a year, so we are talking of order of
>>under $100m for revenues spread among 100 CAs.
>
>
> I think VeriSign claims over 400,000 active class 3 SSL subsribers.
Ha. If they do, then they must be in non-browser
areas. Here's February's month's stats:
http://www.securityspace.com/s_survey/sdata/200502/certca.html
Which indicates 210k servers and Verisign with
less than 100k of those. I wonder what could
possibly make up 300k additional class 3s?
Perhaps email certs within companies? That
might give them the numbers, but why would a
company want high end user email certs?
Looking at the site, yes, you are right, they
claim 450,000 web servers, which is more than
securityspace.com can find!
Hmmm, hold on, later it says "450,000 Web sites,
intranets and extranets worldwide" which is
different. Maybe these are all individual
client certs that they are counting.
>>The reason for separating out the certs into "high" and "low"
>>is almost guarunteed to be marketing.
>
>
> Disagree. There is certainly pressure to segment the market, especially
> when there is a real difference in requirements. I think there is a
> huge unserved markets for class 1 server certificates.
:-) These are the sort of marketing questions
that keep people arguing for yonks. Let's
suffice to say that economists see the same
process in every market, and they also see it
occur over the silliest of discriminations.
> You would be shocked to learn the price of running revocation services
> (CRL serving and OCSP responders).
I would be shocked to hear a positive ROI, but I
wouldn't be shocked at the price of running it!
It really does look like very expensive stuff
when I see the chit chat on these lists.
Question: How many revocations does a CA do per
year?
> No immediatley value to the CA other
> than providing a more robust service that is safer to rely on comes to
> mind.
Which brings up a point that others have suggested
as something to hang the hat of low/high assurance
on.
In order to decide on CRL/OCSP (either, both) as
being a discriminatory metric for MoFo purposes,
we would want to show that this had meaning to the
users of the product (Firefox, not the cert).
So, when you say the above .. and the below, is
there anyway of showing that this might be worth
something to Firefox users?
> The extra authentication costs associated with dual-controlled
> authentication process with manual review doesn't add much marketing
> value (yet?) but it does provide a more robust process that is less
> susceptible to requiring revocation and in that way is a better
> candidate for banking or other authentication sensitive applications
> than a fully automated process. I think you'll appreciate the need to
> manage margins as part of competing in a market and I asasume that
> given a few hundred million US dollars on the line annually and a large
> list of enabled competitors in the space (how many entries on the IE
> and MoFo root lists for SSL) that the market is at least somewhat
> competitive and that CAs doing expensive auth. and running expensive
> services wouldn't do it if they didn't want to offer a best-of-breed
> service, would they?
My understanding was that the number of revocations
done is in the low hundreds per year. Has anyone
put a dollar value on how much that is worth?
Ram A M
I read it to say 450,000 Web sites [including those on] intranets and
extranets worldwide. I don't really know.
> >>The reason for separating out the certs into "high" and "low"
> >>is almost guarunteed to be marketing.
> >
> >
> > Disagree. There is certainly pressure to segment the market,
especially
> > when there is a real difference in requirements. I think there is a
> > huge unserved markets for class 1 server certificates.
>
>
> :-) These are the sort of marketing questions
> that keep people arguing for yonks. Let's
> suffice to say that economists see the same
> process in every market, and they also see it
> occur over the silliest of discriminations.
However I think you'll agree with me that economists would generally
not agree that every market segmentation and differentiation is around
silly differences.
> > You would be shocked to learn the price of running revocation
services
> > (CRL serving and OCSP responders).
>
>
> I would be shocked to hear a positive ROI, but I
> wouldn't be shocked at the price of running it!
> It really does look like very expensive stuff
> when I see the chit chat on these lists.
I guess it depends on the goal. If you consider brand equity and a
reputation for trying to do the right thing valuable then I'd argue
they think they're getting their money's worth.
> Question: How many revocations does a CA do per
> year?
I don't know, that information is by and large available by looking at
CRLs - at least for the public CAs.
> > No immediatley value to the CA other
> > than providing a more robust service that is safer to rely on comes
to
> > mind.
>
>
> Which brings up a point that others have suggested
> as something to hang the hat of low/high assurance
> on.
>
> In order to decide on CRL/OCSP (either, both) as
> being a discriminatory metric for MoFo purposes,
> we would want to show that this had meaning to the
> users of the product (Firefox, not the cert).
I don't think even the best practices can assure perfect
authentication, after all both computers and humans are used and both
are prone to errors. I'll take a swag at part of it; the value of
revocation probably correlates to the value of transactions being
protected and inverely to the likelyood of errors in issuance - these
is by no means exhaustive but only illustrative.
> > The extra authentication costs associated with dual-controlled
> > authentication process with manual review doesn't add much
marketing
> > value (yet?) but it does provide a more robust process that is less
> > susceptible to requiring revocation and in that way is a better
> > candidate for banking or other authentication sensitive
applications
> > than a fully automated process. I think you'll appreciate the need
to
> > manage margins as part of competing in a market and I asasume that
> > given a few hundred million US dollars on the line annually and a
large
> > list of enabled competitors in the space (how many entries on the
IE
> > and MoFo root lists for SSL) that the market is at least somewhat
> > competitive and that CAs doing expensive auth. and running
expensive
> > services wouldn't do it if they didn't want to offer a
best-of-breed
> > service, would they?
>
>
> My understanding was that the number of revocations
> done is in the low hundreds per year. Has anyone
> put a dollar value on how much that is worth?
Well one approach to valuing it is to ask how much it's worth to shut
down a phishing site after two hours instead of a day or three. I think
the lower the up-front authentication the more important revocation
becomes; this assumes the authentication is valued or leveraged.
Frank Hecker
> Can I correctly infer that you don't feel any safer submitting your
> social security number to a site using a VeriSign Class 3 certificate
> relative to a 'domain-control' only certificate?
No, you can't necessarily infer that :-) Subjectively I personally would
feel safer submitting sensitive information to a site using a "claimed
identity" certificate than I would if the same site had only a "control
of domain" certificate, assuming that the certs are from the same
overall CA provider and that the UI made me aware of the difference.
This is for two reasons:
First, per the argument in my prior message, for a given CA the risk
associated with the "claimed identity" certificate is certainly not
greater than with the "control of domain" cert, and could possibly be less.
Second, if the site were an e-commerce or financial services site or a
site run by a substantial organization then I would expect them to spend
the extra money to get the more expensive cert, given that the
incremental cost is probably negligible in comparison to the financial
resources available to them or potentially available to them, and I'd be
suspicious if they tried to save money by getting a less expensive cert.
In effect using the more expensive cert acts as a signalling mechanism:
This organization is willing to spend money on their site, and hence is
serious about doing business with me. It's not the only such signalling
mechanism: Having a clean and professional site design, not having typos
or confusing language on the site, having a "deep" site (in terms of
lots of content about the organization's products and services, and how
it does business), not having typos or ungrammatical sentences in the
site content -- all of these signal to me and others that the
organization has spent time and money on the site and hence is serious
about providing a quality service.
Now clearly most of this has nothing to do with security per se, and of
course phishing sites could simply rip off all the content of existing
sites and also get "claimed identity" certs of their own. But this does
raise the bar for phishers a little bit, and seeing these sorts of
signals does make me (and I suspect others) subjectively feel a little
better.
<digression>
As a side note, IMO there's a fascinating analogy here to the
hypothesized role of signalling mechanisms in the context of biological
evolution. The basic idea is that when evaluating potential mates
animals use physical attributes like physical size, the condition of
feathers and fur, etc., as signals of general health, freedom from
parasites, etc. -- all the things that might maximise reproductive
success. The animals being thus evaluated are "motivated" to present
false signals ("motivated" in the sense that genes improving an animal's
ability to present false signals would be selected for), which in turn
"motivates" (in the sense defined above) the animals doing the
evaluation to get better at deciding exactly which signals to look for.
The hypothesized conclusion from all of this is that the "best" signals
(i.e., the ones that would be selected for in the course of interactions
between many generations of evaluators and evaluatees) would be those
that are most difficult to fake. This is one evolutionary explanation
for why some animals have extreme physical attributes (large antlers,
long and showy feathers, etc.) that would otherwise seem detrimental to
them: it's exactly because such attributes require large amounts of
energy and time to maintain that they are good signals -- an unhealthy
animal would be unable to fake them.
I will leave the application of this theory to produce newer and more
effective anti-phishing strategies as a exercise for any interested
readers :-)
</digression>
Back to my subjective feeling of increased safety due to use of identity
certs: The problem is that subjectivity is not necessarily what people
want in a policy. If everyone involved were happy with me (or someone
else) saying "Yes, I subjectively feel that it's safe to include CA Foo
in the CA cert list" or "No, I feel queasy about having CA Bar in the
list, so I'll reject them", then we wouldn't need a policy at all.
That's certainly a legitimate approach; it's the approach taken in many
areas of Mozilla development, where module owners make subjective
decisions every day ("accept patch A, reject patch B") in the absence of
written policies. But when it comes to the question of which CAs are
included in Firefox/Thunderbird/etc. and which are not, people don't
seem to want to leave this to a subjective decision.
(Of course, that may just be because they don't trust me to make those
decisions. In that case anyone else is free to come forward and propose
themselves to the MF as the owner of these decisions, and if that's
acceptable to the MF I'll gladly stand aside -- it's not as if it's my
life goal to be the CA gatekeeper for the Mozilla project.)
[re justifications for "low assurance" / "high assurance" distinctions]
> I'd say that in the early days the US lawyers working in industry
> (legal and CA believed that such a distinction was paramount for a
> robust PKI.
I acknowledge your point here; I know that people spent lots of time
debating these issues. However I think the key word in your sentence is
"lawyers"; I suspect (and to some extent recall) that a lot of the
discussions and "research" work were around how PKI was going to
function from a legal sense, and in particular how things like digital
signatures were going to interact with existing laws and procedures
governing contracts, etc. In this context distinctions like "low
assurance" vs. "high assurance" make sense, in the same way that the
legal distinctions between verbal contracts and written contracts make
sense. However this legal analysis is not the same as an security
analysis dealing with actual threats, risks, cost/benefit tradeoffs, and
so on, and I'm not aware to what extent anyone did this sort of economic
analysis in addition to the legal analyses.
> Do you really believe that it is as easy to get an 'identity
> cert' as it is to get a 'domain control' cert?
No, I don't. That's why I wrote "if it were trivially easy" and not "it
is trivially easy".
Please understand that I'm not trying to discount CAs and the amount of
work they put into providing a quality service. My point was simply that
just because a CA provides two (or more) different cert offerings
doesn't mean that you can assume a priori (i.e., in the absence of other
evidence) that there is any significant improvement in security (i.e.,
significant reduction of risk) associated with the "higher assurance"
service. This is something that has to be demonstrated, and doing so is
not necessarily trivial.
Frank Hecker
> The reason for separating out the certs into "high" and "low"
> is almost guarunteed to be marketing.
Which is not necessarily a bad thing. Just because something is done for
"marketing" reasons doesn't mean that there's not actually value
provided to potential buyers, at least as they perceive it (and after
all, it's their money).
> The marketing imperitive
> is to create a ramped range of products. This is a well
> studied phenomena in b-school and marketing school, as well
> as (perhaps surprisingly) economics. The key phrases here are
> 'consumer surplus' and also 'price discrimination' if anyone
> fancies researching more:
>
> http://en.wikipedia.org/wiki/Consumer_surplus (not so good)
> http://en.wikipedia.org/wiki/Price_discrimination (better)
For a good discussion of price discrimination strategies as they relate
to information goods, I particularly recommend Varian and Shapiro's book
"Information Rules":
http://www.amazon.com/exec/obidos/ASIN/087584863X
> When a market only has one product, the pressure to create
> two products, being an expensive one and a cheap one, is
> *immense*.
<snip>
> Once two products are established and are *successful* there
> arises pressure to create three, then four, then more, and in
> each case there is one primary objective: create a range of
> prices from very cheap to very expensive.
As a point of interest Varian and Shapiro believe that offering products
at three price points (e.g., "silver", "gold", "platinum") is
an optimum strategy in many cases. The idea is that
extremely-price-sensitive buyers would buy the lowest price offering,
extremely-price-insensitive buyers would buy the high-price offering,
and everyone else (the majority of buyers) would buy the middle-priced
offering.
> The thing to keep firmly in mind is that this is *nothing*
> to do with the technical issues of security or even cost.
> It is solely a phenomenum of marketing and economics known
> as price discrimination.
Yes, but... It's not necessarily "just marketing", either in general or
for this specific case. In many cases -- and I would argue, in the cases
in which it works best -- price discrimination is associated with real
differences in value as perceived by customers, even if some would
question what that value actually is. (For example, some users of open
source software would question the value of paying for "certified"
versions of software, but others do perceive value in this.)
> How do we prove this? Easy: the existence of different
> certs for different prices has to be primarily to create
> a ramped price structure for the perception of the buyer
> of the cert because the end-users - the browsing user and
> the site operator - can't see the difference anyway.
Well, we're talking about introducing a difference (e.g., as in my
strawman SSL UI proposal), and that might in turn make a difference in
perceived values of the different offerings.
Ian G
> Ian G wrote:
>> [revocation...]
>>
>>I would be shocked to hear a positive ROI, but I
>>wouldn't be shocked at the price of running it!
>>It really does look like very expensive stuff
>>when I see the chit chat on these lists.
>
>
> I guess it depends on the goal. If you consider brand equity and a
> reputation for trying to do the right thing valuable then I'd argue
> they think they're getting their money's worth.
I consider brand to be valuable in its place, definatel!
I don't quite see how you can link these things that
you talk of - CRL/OCSP - to brand equity or reputation,
simply because a) CAs have no branding way to reach
the relying parties (users) and thus b) a very limited
way to convince purchasing parties (sites) of the need
to pay attention. This isn't the CAs' fault, and every
CA I have ever talked to understands that they are
powerless to develop their brand and thus their features
of quality of service until the browsers play their part.
But until that happens, any talk about CA brand is just
hypeware as far as I can see.
(This point comes out in the TrustBar paper where they
tested the brand recognition, and even Verisign flunked
the test.)
So, I'd suspect that brand and reputation are not useful
reasons behind CRL/OCSP work, as yet. It may have a
strategic future, but that's for the futuroligists.
> I don't know, that information is by and large available by looking at
> CRLs - at least for the public CAs.
Google found them in one hit :) Unfortunately, even
though there are some very big files there, they are
in binary, so not easy to count the number of entries,
nor skim them for applicability.
> I'll take a swag at part of it; the value of
> revocation probably correlates to the value of transactions being
> protected and inverely to the likelyood of errors in issuance - these
> is by no means exhaustive but only illustrative.
Well, what I'd be inclined to look for is something
that said:
1% of certs are revoced per annum.
0.5% of these reach clients in time to block fraud.
Therefore, estimated savings by reducing fraud to half.
Something like that ... that's a scratched out example.
Of course, we have fraud out there, that's what the
revocations are intended to stop. So it is a simple
matter of measuring how much fraud is out there, then
working backwards from that to work out how many fraud
transactions are blocked by the revocations that actually
get through to the relying parties.
Nothing's perfect, we will see a failure rate in there,
where something didn't work out and a fraud got through.
It's probably a benefit of it can reach 50% savings.
If it was only 10% savings I'd be skeptical of its value,
and if it was 90% it would be miraculous.
But somewhere between those numbers would be grand, this
would be a solid working number that said to Mozilla,
yes, we can hang a hat on this. We can say that the
attention paid to CRLs is definately something to bring
to our users in a positive discriminatory fashion.
> Well one approach to valuing it is to ask how much it's worth to shut
> down a phishing site after two hours instead of a day or three. I think
> the lower the up-front authentication the more important revocation
> becomes; this assumes the authentication is valued or leveraged.
Right, that's the sort of calculation we need. That
would be a perfect example for Mozilla to bring to its
users.
( But, until Firefox forces the phishers to use
certs, that is a hypothetical. I saw an SSL phish
once about 2 years back and followed it through for
the investigative experience ... but nobody else has
seen them to my knowledge. I would cheer the day we
say more of them, it would mean we would be making a
difference. )
So maybe the answer is that until SSL phishing starts
we cannot determine the value of CRLs and thus they
cannot be used as a way to determine "low"/"hi" assurance?
Ian G
> Ian G wrote:
>
>> The reason for separating out the certs into "high" and "low"
>> is almost guarunteed to be marketing.
>
>
> Which is not necessarily a bad thing. Just because something is done for
> "marketing" reasons doesn't mean that there's not actually value
> provided to potential buyers, at least as they perceive it (and after
> all, it's their money).
This is absolutely correct! There is nothing wrong
with this .. but see below.
>> http://en.wikipedia.org/wiki/Consumer_surplus (not so good)
>> http://en.wikipedia.org/wiki/Price_discrimination (better)
>
>
> For a good discussion of price discrimination strategies as they relate
> to information goods, I particularly recommend Varian and Shapiro's book
> "Information Rules":
>
> http://www.amazon.com/exec/obidos/ASIN/087584863X
I'd love to have the time to read that!
>> The thing to keep firmly in mind is that this is *nothing*
>> to do with the technical issues of security or even cost.
>> It is solely a phenomenum of marketing and economics known
>> as price discrimination.
>
>
> Yes, but... It's not necessarily "just marketing", either in general or
> for this specific case. In many cases -- and I would argue, in the cases
> in which it works best -- price discrimination is associated with real
> differences in value as perceived by customers, even if some would
> question what that value actually is. (For example, some users of open
> source software would question the value of paying for "certified"
> versions of software, but others do perceive value in this.)
Right. So here's the thing. The company's only
interest is economic discrimination. However the
user is uninterested in that, even offended. So
the user has to govern the company by either going
somewhere else or grumbling or causing trouble.
That is, the attention to user needs is a secondary
effect that drives the company away from its primary
desire of capturing the consumer surplus (as an
economist would say it).
So it's a feedback loop of two competing forces.
Really great for the world as it makes for improvement;
it's called competition.
Now, here's the clanger: in *some* markets, the user
does not play their part .. or plays it inadequately.
In those markets, the product mix moves towards pure
discrimination on arbitrary price points. Only when
the user governs the suppliers by bringing them back
to the needs of the user is the feedback loop then
engaged and the user's needs met.
Here's the conclusion: I claim, or hypothesize,
that the market for certs is such a market: that
the users cannot easily govern the suppliers for
their desired characteristics, so the market has
moved as much as it is able (size is the limit here)
to a mix of products based on arbitrary price points.
(When I say, arbitrary, I mean without obvious or
working feedback. If you say, the price point is
security, I would say, ok, show us some evidence
of consumers choosing on security.)
Now, if this is the case, what this means in the right
here and right now is that none of those arbitrary
points that we see out on the market place (c.f. the
post of the prices of certs for different suppliers)
will support a policy decision by Mozilla Foundation.
And that won't change until users start to govern
the market place based on criteria that are important
to the users.
(Hence, a lot of my writings are directed at getting
information to the users, so that they can start to
govern the marketplace and direct the suppliers to
provide product that matters to them. A lot of other
peoples' writings are directed at hiding that info
so that the current status quo can continue. Standard
ostrich economics.)
>> How do we prove this? Easy: the existence of different
>> certs for different prices has to be primarily to create
>> a ramped price structure for the perception of the buyer
>> of the cert because the end-users - the browsing user and
>> the site operator - can't see the difference anyway.
>
>
> Well, we're talking about introducing a difference (e.g., as in my
> strawman SSL UI proposal), and that might in turn make a difference in
> perceived values of the different offerings.
Right. So the question for that proposal is what to
hang the hat of the difference on. I argue above that
there is nothing that is there currently that will
support that.
OTOH, there is a pressing need to get the users - the
relying parties or the cert buyers - to make decisions
on security. Which needs more information, which is
currently withheld from them. Release the information
and the users will provide the signal needed to
separate "low" from "high" ...
Ram A M
> Ram A M wrote:
> > Can I correctly infer that you don't feel any safer submitting your
> > social security number to a site using a VeriSign Class 3
certificate
> > relative to a 'domain-control' only certificate?
>
> No, you can't necessarily infer that :-) Subjectively I personally
would
> feel safer submitting sensitive information to a site using a
"claimed
> identity" certificate than I would if the same site had only a
"control
> of domain" certificate,
I would've been very surprised otherwise.
> assuming that the certs are from the same
> overall CA provider and that the UI made me aware of the difference.
The UI in most browsers doesn't do a good job of showing it. Since some
CAs only issue identity (legal-name) certificates the need for a more
robust UI is not as critical as seeing the overall brand.
> This is for two reasons:
>
> First, per the argument in my prior message, for a given CA the risk
> associated with the "claimed identity" certificate is certainly not
> greater than with the "control of domain" cert, and could possibly be
less.
>
> Second, if the site were an e-commerce or financial services site or
a
> site run by a substantial organization then I would expect them to
spend
> the extra money to get the more expensive cert, given that the
> incremental cost is probably negligible in comparison to the
financial
> resources available to them or potentially available to them, and I'd
be
> suspicious if they tried to save money by getting a less expensive
cert.
For this position to hold up I think it would also have to be the case
that a phisherman would not find value in buying the more expensive
certificate. If an extra US$500 gets a larger return, perhaps $50,000
instead of $10,000, I think they'll spend the 500. Do you agree? Do you
still feel safer with the identity certificate?
> In effect using the more expensive cert acts as a signalling
mechanism:
> This organization is willing to spend money on their site, and hence
is
> serious about doing business with me.
There's something to do this, but remember that criminals work in
economic systems and will play the game just like anyone else; a larger
ROI for a different tact will make that different tact more appealing.
> It's not the only such signalling
> mechanism: Having a clean and professional site design, not having
typos
> or confusing language on the site, having a "deep" site (in terms of
> lots of content about the organization's products and services, and
how
> it does business), not having typos or ungrammatical sentences in the
> site content -- all of these signal to me and others that the
> organization has spent time and money on the site and hence is
serious
> about providing a quality service.
Agree. Certainly I would discount trust for a site that was lousy with
mistakes or thin on content, however I would not trust a site just
because they used a spell checker and a link verifier - at least not
for activity with real risk.
I think this favors my position - the identity cert is presumably
harder to get and therefor it is harder to fake identity that way.
Given a CA deteremined to protect it's repuation as a high quality
provider you will see good enrollment vetting and robust revocation
services.
> Back to my subjective feeling of increased safety due to use of
identity
> certs: The problem is that subjectivity is not necessarily what
people
> want in a policy. If everyone involved were happy with me (or someone
> else) saying "Yes, I subjectively feel that it's safe to include CA
Foo
> in the CA cert list" or "No, I feel queasy about having CA Bar in the
> list, so I'll reject them", then we wouldn't need a policy at all.
>
> That's certainly a legitimate approach; it's the approach taken in
many
> areas of Mozilla development, where module owners make subjective
> decisions every day ("accept patch A, reject patch B") in the absence
of
> written policies. But when it comes to the question of which CAs are
> included in Firefox/Thunderbird/etc. and which are not, people don't
> seem to want to leave this to a subjective decision.
If I didn't work for a CA I would be very interested in a branded
release of FF where I did exactly that, given my job I feel I can't do
that in good faith. The best I can do is participate in the debate with
the goal of reaching consensus in the right direction. My intent is as
selfish as noble - I hate clicking on the padlocks everytime I log-in
to my broker, bank, medical service provider site. TrustBar is a great
tool for me and there is some value to most users but I think that
changes in the treatment of 'trust' in the software stack is much more
valuable to the typical user and that, IMO, should be the priority
[which is why I think the software engineer oriented address-bar is so
wrong].
> (Of course, that may just be because they don't trust me to make
those
> decisions.
You're being silly here, I've been reading this list for a long time
and I see no reason to believe this. I do think it's better for many
reasons to have a well documented policy even if it does include
subjective components. Transparency is critical element of trust.
> In that case anyone else is free to come forward and propose
> themselves to the MF as the owner of these decisions, and if that's
> acceptable to the MF I'll gladly stand aside -- it's not as if it's
my
> life goal to be the CA gatekeeper for the Mozilla project.)
Somehow I don't expect to see many volunteers : )
> [re justifications for "low assurance" / "high assurance"
distinctions]
> > I'd say that in the early days the US lawyers working in industry
> > (legal and CA believed that such a distinction was paramount for a
> > robust PKI.
>
> I acknowledge your point here; I know that people spent lots of time
> debating these issues. However I think the key word in your sentence
is
> "lawyers"; I suspect (and to some extent recall) that a lot of the
> discussions and "research" work were around how PKI was going to
> function from a legal sense, and in particular how things like
digital
> signatures were going to interact with existing laws and procedures
> governing contracts, etc. In this context distinctions like "low
> assurance" vs. "high assurance" make sense, in the same way that the
> legal distinctions between verbal contracts and written contracts
make
> sense. However this legal analysis is not the same as an security
> analysis dealing with actual threats, risks, cost/benefit tradeoffs,
and
> so on, and I'm not aware to what extent anyone did this sort of
economic
> analysis in addition to the legal analyses.
A fair comment. I think that legal system (the ones I like) are the way
they are because they are incrementally refined over time and as such
at any given time they describe some representation of current values
of the society with a heavy bias to practical concerns. [No I do not
agree with much of the representation, but other parts of it protect my
ability to live in the society so a workable if not fair compromise is
struck.] If the PKI (or other technologies) are well aligned with the
legal constructs I'd say that's a solid foundation as it's the best
society has come up with. There is still crime in every country and the
legal system is not designed by security experts yet the legal system
seems to work ok but not perfectly.
> > Do you really believe that it is as easy to get an 'identity
> > cert' as it is to get a 'domain control' cert?
>
> No, I don't. That's why I wrote "if it were trivially easy" and not
"it
> is trivially easy".
>
> Please understand that I'm not trying to discount CAs and the amount
of
> work they put into providing a quality service. My point was simply
that
> just because a CA provides two (or more) different cert offerings
> doesn't mean that you can assume a priori (i.e., in the absence of
other
> evidence) that there is any significant improvement in security
(i.e.,
> significant reduction of risk) associated with the "higher assurance"
> service. This is something that has to be demonstrated, and doing so
is
> not necessarily trivial.
My belief is that you are relatively undogmatic and interested in
practical progress. My point as that if an expert like you feels better
with identity certs on the other end of the wire relative to
domain-certs or no certs then that must mean something. I think your
opinions generally support my claim that identity-certs are better
protection than domain-certs, and that the more rigorous the
authentication practices around an identity-cert and the more stringent
the revocation pracitices and the better the support for revocation
technology the safer you are as well.