Hmm, posted a response earlier today - I'm trying again as it's been
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.'
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
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
