Lock icon removed from 4.0b7
Steve Schultze
http://support.mozilla.com/en-US/questions/767559
I feel essentially the same as the users in that thread. Was this
discussed somewhere? Is this newsgroup the appropriate place to discuss it?
David E. Ross
See bug #574688 at
<https://bugzilla.mozilla.org/show_bug.cgi?id=574688>. I raised the
issue about removing the lock icon in comment #130. Subsequent comments
in the bug report also discussed this.
The bug report is now marked as Resolved and Fixed, which means the
change has been implemented and reversing that decision is unlikely.
This means that many government and financial Web site that advocate
looking for the lock symbol will now have to be changed.
I think this is another bug report reflecting the triumph of developer
desires over user needs. This was submitted as a "Normal" bug -- an
actual discrepancy -- and not as an RFE, which it clearly is. More and
more, Mozilla products are becoming playthings for developers instead of
serious applications for end-users.
--
David E. Ross
<http://www.rossde.com/>
On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.
Eddy Nigg
> Oh my:
> http://support.mozilla.com/en-US/questions/767559
>
> I feel essentially the same as the users in that thread. Was this
> discussed somewhere?
Yes, tons of it for years I think. Finally there is something more
meaningful than a binary yes/no UI. Isn't this exciting? :-)
> Is this newsgroup the appropriate place to discuss it?
This is a good place. Maybe also m.d.usability group as well.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Eddy Nigg
> I think this is another bug report reflecting the triumph of developer
> desires over user needs. This was submitted as a "Normal" bug -- an
> actual discrepancy -- and not as an RFE, which it clearly is. More and
> more, Mozilla products are becoming playthings for developers instead of
> serious applications for end-users.
Not so - when "Larry" was introduced in FF3 it was clear that the
padlock will disappear one day. I think that Jonathan also discussed it
at his blog, in bugs, mailing lists like this one (or it was probably
m.d.security and m.d.t.crypto at that time) and elsewhere. This doesn't
come as a surprise (at least for me) and is an attempt to provide a more
meaningful UI than the hated/loved binary padlock.
If you give it a little bit more thought you'll probably agree that the
padlock wasn't such a good indicator for site security and what it means.
Steve Schultze
> On 12/20/2010 09:14 PM, From David E. Ross:
>> I think this is another bug report reflecting the triumph of developer
>> desires over user needs. This was submitted as a "Normal" bug -- an
>> actual discrepancy -- and not as an RFE, which it clearly is. More and
>> more, Mozilla products are becoming playthings for developers instead of
>> serious applications for end-users.
>
> Not so - when "Larry" was introduced in FF3 it was clear that the
> padlock will disappear one day. I think that Jonathan also discussed it
> at his blog, in bugs, mailing lists like this one (or it was probably
> m.d.security and m.d.t.crypto at that time) and elsewhere. This doesn't
> come as a surprise (at least for me) and is an attempt to provide a more
> meaningful UI than the hated/loved binary padlock.
>
> If you give it a little bit more thought you'll probably agree that the
> padlock wasn't such a good indicator for site security and what it means.
Someone mentioned to me that they would assume I'd be in favor of
banishing the lock, given my past criticism of the actual strength of
the current trust system. Although I agree that many users assume that
the lock means more than it really does, the reality is that it's an
ingrained part of how we use the web. I noticed the change because I
was on a banking site, checked for the lock, and freaked. This is not good.
I am in favor of phasing out the lock for DV certs, but only when we
have a viable alternative in place (either cryptographically or from a
user interface perspective) that users are likely to understand. I
don't think that this is it.
Eddy Nigg
> Someone mentioned to me that they would assume I'd be in favor of
> banishing the lock, given my past criticism of the actual strength of
> the current trust system. Although I agree that many users assume
> that the lock means more than it really does, the reality is that it's
> an ingrained part of how we use the web. I noticed the change because
> I was on a banking site, checked for the lock, and freaked. This is
> not good.
>
> I am in favor of phasing out the lock for DV certs, but only when we
> have a viable alternative in place (either cryptographically or from a
> user interface perspective) that users are likely to understand. I
> don't think that this is it.
>
I don't think it has something to do with DV or not, rather with
providing more - and most important - more accurate information. What
does it matter if it's a pad lock or a cube or triangle or whatever? Of
course there is some re-education going on which started back with FF3
with the introduction of "Larry" and the new error pages instead of that
stupid click-away dialog from the Netscape era.
Why are you still looking for the padlock if you have such strong
indicators like the blue (or green) extended icon in the address bar,
conveniently next where you typed the URL (or you should see the URL)?
What would the padlock indicate to you compared to the UI in place since
FF3?
The meaning of "Larry" and the indicator mean the same thing as the
padlock, but in fact provide you with more and better information. I
personally have stopped looking for the padlock a long time ago and look
only at the address bar. If the blue or green extender is missing my
alarm bells go on, I haven't even noticed that the padlock is still
there :-)
PS. the issue with DV and OV is something I'd like to have addressed for
a long time, but this is a different discussion.
Steve Schultze
> On 12/20/2010 09:45 PM, From Steve Schultze:
>> Someone mentioned to me that they would assume I'd be in favor of
>> banishing the lock, given my past criticism of the actual strength of
>> the current trust system. Although I agree that many users assume that
>> the lock means more than it really does, the reality is that it's an
>> ingrained part of how we use the web. I noticed the change because I
>> was on a banking site, checked for the lock, and freaked. This is not
>> good.
>>
>> I am in favor of phasing out the lock for DV certs, but only when we
>> have a viable alternative in place (either cryptographically or from a
>> user interface perspective) that users are likely to understand. I
>> don't think that this is it.
>
> indicators like the blue (or green) extended icon in the address bar,
> conveniently next where you typed the URL (or you should see the URL)?
> What would the padlock indicate to you compared to the UI in place since
> FF3?
You are making a completely accurate logical argument. However,
usability also involves a significant degree of psychology and behavior.
People have had "look for the lock icon" shouted at them for so many
years that it's hard to know how to reverse this conditioning. Even as
a highly informed user, I wasn't immediately certain what was going on,
and I wasn't familiar with the "Larry" schema (does anybody know why
it's even called that?!). The folks in that thread I linked to were
likewise confused.
It would be interesting to know if there is any empirical data on what
people think in this scenario... actual user testing.
In any case, it looks like this was all discussed already, and that new
appeals to restore the lock won't likely work:
https://bugzilla.mozilla.org/show_bug.cgi?id=558551#c15
Eddy Nigg
> You are making a completely accurate logical argument. However,
> usability also involves a significant degree of psychology and
> behavior. People have had "look for the lock icon" shouted at them
> for so many years that it's hard to know how to reverse this conditioning.
Of course there is some pain involved, however we must break away from
it at some point despite all the shouting and that point has apparently
come close after the careful introduction of "Larry" quite a while ago...
> Even as a highly informed user, I wasn't immediately certain what
> was going on, and I wasn't familiar with the "Larry" schema (does
> anybody know why it's even called that?!).
Sure:
http://blog.johnath.com/2008/05/06/about-larry/
http://www.dria.org/wordpress/archives/2008/05/06/635/
> It would be interesting to know if there is any empirical data on what
> people think in this scenario... actual user testing.
Johnathan might have some clue about it...
> In any case, it looks like this was all discussed already, and that
> new appeals to restore the lock won't likely work:
Yup.
Eddy Nigg
> banishing the lock, given my past criticism of the actual strength of
> the current trust system.
PS. Some criticism is certainly justified and I share many of those with
you, but criticism alone doesn't lead to much (except perhaps inviting
thought and discussion in case it's done in the right way). In order to
improve the system, hard work is needed - for example by reviewing CA
inclusion requests right here at Mozilla.
I'm completely against the ranting and complaining without A) providing
a better alternative, B) lead by example, C) do the leg work required,
D) accept reality and address the needs of the masses (including legal).
By now you probably know what I'm hinting at....
....and if you've followed this mailing list you also know that work we
have done here (and elsewhere) are bearing fruits with the soon-to-come
Mozilla CA policy update and the basic guidelines for CAs from the CAB
forum. Many seriously problematic practices will be eliminated within a
reasonable time frame, for the good of the entire Internet community and
all parties involved. This is a great step forward and in my opinion
will be far more significant than the introduction of EV.
My goal was always to remove the flaws within the reasonable limits and
strengthen the framework on which we today rely for Internet traffic,
not weaken or seeking to abolish the system (CAs). However it must be
also recognized that CAs are working within a legal framework which
can't be ignored and survivability of a CA is probably in the interest
of all parties. In this respect I believe that most if not all CAs are
keeping way more than they actually promise - because the legal
establishment almost forces CAs into that - and otherwise you'd have no
one taking any responsibility whatsoever. The alternative would be no
trust system at all.
For example there are many things broken with banks, but probably
today's world can't simply functioning without it. So things will
improve, will be better controlled, regulations are introduced,
etc....but at the end of the day they are businesses most of the time
and by nature of their business can't give you 100% guaranties. Very
similar with CAs. I believe that today you can't do without them, which
doesn't mean that there is still a lot to be improved.
But as with the UI issue (pad lock) with which this thread started by
you, at some point things must be actually implemented. But one step at
the time. The same with CA trust model and framework, things are
improving and actually done. But it takes time.
[ For references:
http://www.freedom-to-tinker.com/blog/sroosa/flawed-legal-architecture-certificate-authority-trust-model
http://citpsite.s3.amazonaws.com/publications/Roosa_Schultze_CA_Trust_Model.pdf
]
Jean-Marc Desperrier
> See bug #574688 at
> <https://bugzilla.mozilla.org/show_bug.cgi?id=574688>. I raised the
> issue about removing the lock icon in comment #130.
bug #598973 is more appropriate :
https://bugzilla.mozilla.org/show_bug.cgi?id=598973
davemg...@gmail.com:
"Padlock icons to way too many people imply safety. They really just
were used to indicate a stable encryption link. You can be fully
encrypted to either your bank, or criminals pretending to be your bank
who wish to steal all your money.
It was decided quite a while ago to phase them out. [...]
Closing as INVALID by intended gradual phase out of this old
misunderstood feature."
Steve Schultze
> On 12/20/2010 09:45 PM, From Steve Schultze:
> you, but criticism alone doesn't lead to much (except perhaps inviting
> thought and discussion in case it's done in the right way). In order to
> improve the system, hard work is needed - for example by reviewing CA
> inclusion requests right here at Mozilla.
>
> I'm completely against the ranting and complaining without A) providing
> a better alternative, B) lead by example, C) do the leg work required,
> D) accept reality and address the needs of the masses (including legal).
I'm somewhat puzzled at your long missive about doing work in this area,
and I'm assuming you aren't directing this at me, given that with
respect to legal issues in "D" I wrote this reference you cited:
> http://www.freedom-to-tinker.com/blog/sroosa/flawed-legal-architecture-certificate-authority-trust-model
> http://citpsite.s3.amazonaws.com/publications/Roosa_Schultze_CA_Trust_Model.pdf
Or are you objecting that I didn't provide a solution in the first ever
introductory article written about the legal problems?
With respect to A, I believe that the trust model alternative will be
keys-in-DNSSEC, and I encourage others to participate (as I have been)
in the newly-formed DANE IETF Working Group:
http://www.ietf.org/mail-archive/web/keyassure/current/msg01091.html
http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html
Kaminsky has been blogging about his approach to the technical details
of keys-in-DNSSEC here (which vary slightly from the WG's draft):
http://dankaminsky.com/category/security/
And I think the superior UI alternative would be to maintain the lock
icon but to continue to further emphasize the color coding scheme.
With respect to B and C, I plan to continue to participate in root cert
reviews and the cert policy review, as I have in the past.
But in any case, criticism is the first step in understanding the
problem(s)... and finding a solution. Despite past discussions, I don't
think that this UI problem is well enough understood.
>> Even as a highly informed user, I wasn't immediately certain what
>> was going on, and I wasn't familiar with the "Larry" schema (does
>> anybody know why it's even called that?!).
> http://blog.johnath.com/2008/05/06/about-larry/
>
> http://www.dria.org/wordpress/archives/2008/05/06/635/
And after googling this issue earlier today I already found those pages,
but they didn't answer my question (wtf is "Larry"?). The fact that it
took me awhile to even find a page explaining why the lock was no longer
part of the UI is a problem... let alone finding out more about why the
decision was made (which involved getting in contact with people on this
list and/or posting to bugzilla and getting directed to an existing bug
that I was unable to find through searching... something that 99.999% of
users will not do).
On 12/20/10 8:30 PM, Eddy Nigg wrote:
> Of course there is some pain involved, however we must break away from
> it at some point despite all the shouting and that point has apparently
> come close after the careful introduction of "Larry" quite a while ago...
I still haven't seen a Mozilla document laying out the long-range plan
to phase out the lock icon, including policy considerations and user
testing. It might exist, but I haven't seen it nor does it seem that
users have been sufficiently put on notice.
Look, I'm not categorically opposed to the decision, and I can see both
sides of the argument. In my opinion it is, on balance, not a good
idea... but others have thought about it for longer than I have. I'm
also a bit surprised that the change was made in a supposedly
feature-frozen beta release without any discernible fanfare.
For reference, these are the types of usability studies I would have
liked to see:
http://usablesecurity.org/emperor/
http://lorrie.cranor.org/pubs/sslwarnings.pdf
Finally, a question. To the extent that the grey/blue/green standard is
indeed a standard, is there a formal effort to correlate the efforts
across all browsers?
Chrome: EV *and* DV sites show up with a green lock and green "https"
text, but only EV sites show the name of the entity in a green-shaded
box in the left-hand side of the navigation bar (evidently they have
rolled out this ill-advised change:
http://code.google.com/p/chromium/issues/detail?id=41481 -- note
mbeltzner suggesting they maintain the lock icon as recently as April of
this year).
Safari: no special color for DV certs, green text (no special
background) with the name of the company in the right-hand side of the
navigation bar.
Internet Explorer: (I'm not on my Windows box at the moment, but someone
else will know)
For the sake of users, it seems to make sense to pull together a
concerted effort to standardize these things. In the apparently waning
era of the padlock icon, at least there was some uniformity (albeit with
less clear distinctions)
Steve
David E. Ross
> On 12/20/10 11:02 AM, Steve Schultze wrote:
>> Oh my:
>> http://support.mozilla.com/en-US/questions/767559
>>
>> I feel essentially the same as the users in that thread. Was this
>> discussed somewhere? Is this newsgroup the appropriate place to discuss it?
>
> See bug #574688 at
> <https://bugzilla.mozilla.org/show_bug.cgi?id=574688>. I raised the
> issue about removing the lock icon in comment #130. Subsequent comments
> in the bug report also discussed this.
>
> The bug report is now marked as Resolved and Fixed, which means the
> change has been implemented and reversing that decision is unlikely.
> This means that many government and financial Web site that advocate
> looking for the lock symbol will now have to be changed.
>
> I think this is another bug report reflecting the triumph of developer
> desires over user needs. This was submitted as a "Normal" bug -- an
> actual discrepancy -- and not as an RFE, which it clearly is. More and
> more, Mozilla products are becoming playthings for developers instead of
> serious applications for end-users.
>
Firefox 4.0 has not yet been released as a completed product for
end-users. However, an extension to undo the implementation of bug
#574688 has already been downloaded 23,988 times from addons.mozilla.org.
Eddy Nigg
> With respect to A, I believe that the trust model alternative will be
> keys-in-DNSSEC
And which warranties and liability will you receive from DNSSEC if
something goes wrong? More than that, which policies and audits are
controlling DNSSEC? Besides some inherent issues (including technical),
I believe that DNSSEC isn't capable of replacing CAs and its current
trust model nor is it meant to be. But this would be a different
discussion and probably at a different forum.
> With respect to B and C, I plan to continue to participate in root
> cert reviews and the cert policy review, as I have in the past.
Excellent, I'm glad to hear!
> Finally, a question. To the extent that the grey/blue/green standard
> is indeed a standard, is there a formal effort to correlate the
> efforts across all browsers?
If you think CAs can't agree to anything than you haven't tried to get
anything similar achieved with the software vendors. On the one hand
some freedom is good, but on the other hand there were and are efforts
to align at least a certain UI behavior throughout all major browsers.
And that's easier said than done and so far any such efforts were
fruitless. At least at the moment since it's an ongoing thing.
> For the sake of users, it seems to make sense to pull together a
> concerted effort to standardize these things.
Agreed and there are efforts specially by CAs to achieve it. I'll keep
you posted if anything should happen into this direction.
Stephen Schultze
> On 12/21/2010 06:45 AM, From Steve Schultze:
>> With respect to A, I believe that the trust model alternative will be
>> keys-in-DNSSEC
>
> And which warranties and liability will you receive from DNSSEC if
> something goes wrong? More than that, which policies and audits are
> controlling DNSSEC? Besides some inherent issues (including technical),
> I believe that DNSSEC isn't capable of replacing CAs and its current
> trust model nor is it meant to be. But this would be a different
> discussion and probably at a different forum.
The group of leading security developers involved in the effort have
answers to these questions, but you seem to not want to not talk about
it here (you were the one who asked about alternatives).
> If you think CAs can't agree to anything than you haven't tried to get
> anything similar achieved with the software vendors. On the one hand
> some freedom is good, but on the other hand there were and are efforts
> to align at least a certain UI behavior throughout all major browsers.
> And that's easier said than done and so far any such efforts were
> fruitless. At least at the moment since it's an ongoing thing.
>
>> For the sake of users, it seems to make sense to pull together a
>> concerted effort to standardize these things.
>
> Agreed and there are efforts specially by CAs to achieve it. I'll keep
> you posted if anything should happen into this direction.
Would you care to share any detail at all? All of these things are best
done openly in the view of users (not to mention experts that can help
advise). It is clear that any efforts have not succeeded to date, given
that the browsers continue in their divergent paths.
Eddy Nigg
> The group of leading security developers involved in the effort have
> answers to these questions, but you seem to not want to not talk about
> it here (you were the one who asked about alternatives).
Right, this is the policy group for CAs, so it's not the appropriate
forum I think. And correct, I asked for it and I'm not surprised by your
answer. :-)
> Would you care to share any detail at all? All of these things are
> best done openly in the view of users (not to mention experts that can
> help advise). It is clear that any efforts have not succeeded to
> date, given that the browsers continue in their divergent paths.
Some (most?) CAs believe that a unifying UI or agreed patters are
beneficial for relying parties (users of the browsers). The major
browser vendors still have to show some willingness to even consider
anything of that. That's not much I'm afraid :S
Stephen Schultze
> On 12/22/2010 12:06 AM, From Stephen Schultze:
>> The group of leading security developers involved in the effort have
>> answers to these questions, but you seem to not want to not talk about
>> it here (you were the one who asked about alternatives).
>
> Right, this is the policy group for CAs, so it's not the appropriate
> forum I think. And correct, I asked for it and I'm not surprised by your
> answer. :-)
This is the policy group for Mozilla Security, and if you're going to
write off the answer to a question you asked then I think it's at least
reasonable to hear the response.
In any case, Keys-in-DNSSEC will enhance the role of clueful CAs
(helping them to do their job better and make more money) while solving
several fundamental problems with the current CA/PKIX model. If you
don't want to talk about it here, I'd invite you to at least participate
in the DANE WG mailing list to learn why.
>> Would you care to share any detail at all? All of these things are
>> best done openly in the view of users (not to mention experts that can
>> help advise). It is clear that any efforts have not succeeded to date,
>> given that the browsers continue in their divergent paths.
>
> Some (most?) CAs believe that a unifying UI or agreed patters are
> beneficial for relying parties (users of the browsers). The major
> browser vendors still have to show some willingness to even consider
> anything of that. That's not much I'm afraid :S
Right, so if the "efforts specifically by CAs to achieve it" aren't
working then perhaps it's time for renewed attention to the problem...
perhaps catalyzed by some discussion in the Mozilla security policy
newsgroup.
David E. Ross
>> Oh my:
>> http://support.mozilla.com/en-US/questions/767559
>>
>> I feel essentially the same as the users in that thread. Was this
>> discussed somewhere? Is this newsgroup the appropriate place to discuss it?
>
> See bug #574688 at
> <https://bugzilla.mozilla.org/show_bug.cgi?id=574688>. I raised the
> issue about removing the lock icon in comment #130. Subsequent comments
> in the bug report also discussed this.
>
> The bug report is now marked as Resolved and Fixed, which means the
> change has been implemented and reversing that decision is unlikely.
> This means that many government and financial Web site that advocate
> looking for the lock symbol will now have to be changed.
>
> I think this is another bug report reflecting the triumph of developer
> desires over user needs. This was submitted as a "Normal" bug -- an
> actual discrepancy -- and not as an RFE, which it clearly is. More and
> more, Mozilla products are becoming playthings for developers instead of
> serious applications for end-users.
>
It turns out that bug #574688 is implemented only in Firefox 4. It is
not planned for implementation in SeaMonkey 2.1.
Eddy Nigg
>
> This is the policy group for Mozilla Security, and if you're going to
> write off the answer to a question you asked then I think it's at
> least reasonable to hear the response.
Perhaps m.d.security would be better (I'm subscribed there too), even
though it's probably a broader discussion for now beyond Mozilla
specifically. But you are right and I apologize that currently I don't
want to / or can't engage in a full blown discussion about DNSSEC. If
your answer would have been a different one, I might have had a faster
and more thorough response.
>
> In any case, Keys-in-DNSSEC will enhance the role of clueful CAs
> (helping them to do their job better and make more money) while
> solving several fundamental problems with the current CA/PKIX model.
There is certainly a benefit which can be derived from signed DNS
responses amongst other things and nobody denies it. However it's not a
trust system in the sense and capabilities CAs are doing now, so it's
IMO really on top (or rather on bottom) of that. DNSSEC can not and will
not replace CAs - and in this respect I believe in improving the current
trust model and framework of SSL/PKI/CAs first of all. That's what I
meant a few posts back.
> If you don't want to talk about it here, I'd invite you to at least
> participate in the DANE WG mailing list to learn why.
Hopefully I will find the time for it.
> Right, so if the "efforts specifically by CAs to achieve it" aren't
> working then perhaps it's time for renewed attention to the problem...
> perhaps catalyzed by some discussion in the Mozilla security policy
> newsgroup.
Probably m.d.usability is where the UI folks sit around I think. I know
that Johnathan is reading this list from time to time, but discussions
must be held with him and some others. I believe we are here a bit
powerless in this forum regarding UI issues.
Steve Schultze
EN = Eddy Nigg
With respect to the user interface:
[Firefox, Chrome, Safari, and IE are all diverging in their SSL UI]
SS: For the sake of users, it seems to make sense to pull together a SS:
concerted effort to standardize these things.
EN: Agreed and there are efforts specially by CAs to achieve it. I'll
EN: keep you posted if anything should happen into this direction.
SS: Would you care to share any detail at all?
EN: Some (most?) CAs believe that a unifying UI or agreed patters are
EN: beneficial for relying parties (users of the browsers). The major
EN: browser vendors still have to show some willingness to even consider
EN: anything of that. That's not much I'm afraid
SS: Right, so if the "efforts specifically by CAs to achieve it" aren't
SS: working then perhaps it's time for renewed attention to the
SS: problem... perhaps catalyzed by some discussion in the Mozilla
SS: security policy newsgroup.
EN: Probably m.d.usability is where the UI folks sit around I think. I
EN: know that Johnathan is reading this list from time to time, but
EN: discussions must be held with him and some others. I believe we are
EN: here a bit powerless in this forum regarding UI issues.
I already gave beltzner and faaborg a heads-up about this thread, so I
wouldn't assume that discussions here won't be heard. Perhaps there's
something I can do in my role here at Princeton to encourage
inter-browser cooperation on this issue. Hmm.
With respect to Keys-in-DNSSEC (off-topic of the thread's subject, but
still important):
[http://www.ietf.org/mail-archive/web/keyassure/current/msg01091.html]
EN: it's probably a broader discussion for now beyond Mozilla
specifically
Yes, at this point there is not yet a finalized standard to be
considered. However, I'd like to see more participation from some
members of the Mozilla community, similar to how the Chrome guys are
very involved.
SS: In any case, Keys-in-DNSSEC will enhance the role of clueful CAs
SS: (helping them to do their job better and make more money) while
SS: solving several fundamental problems with the current CA/PKIX model.
EN: There is certainly a benefit which can be derived from signed DNS
EN: responses amongst other things and nobody denies it. However it's
EN: not a trust system in the sense and capabilities CAs are doing now,
EN: so it's IMO really on top (or rather on bottom) of that.
Keys-in-DNSSEC could replace the DV function of CAs because it does what
the current DV regime does, but better. It introduces true domain
constraints, excludability of certifiers, and a single knowable trust
path. When combined with EV certs, these also make the EV regime
stronger. Call it a trust model or not, it is a better system.
EN: DNSSEC can not and will not replace CAs
Keys-in-DNSSEC can and should replace the current DV function of CAs,
freeing up CAs to do more important things.
EN: and in this respect I believe in improving the current trust
EN: model and framework of SSL/PKI/CAs first of all. That's what I
EN: meant a few posts back.
It is not an either/or decision. Working on both at the same time is
prudent. That's why in addition to working on Keys-in-DNSSEC, encourage
folks to join me here and elsewhere to: 1) improve the current
approval/audit regime 2) close loopholes like sub-CAs 3) highlight
problems with the current legal regime, and 4) make sure the user
interface is optimal and uniform across browsers.
Eddy Nigg
> Keys-in-DNSSEC could replace the DV function of CAs because it does what
> the current DV regime does, but better. It introduces true domain
> constraints, excludability of certifiers, and a single knowable trust
> path. When combined with EV certs, these also make the EV regime
> stronger. Call it a trust model or not, it is a better system.
Just a final note here (for the time-being, I'm sure there will be more
at some point). DNSSEC might be able to help CAs perform better domain
control validation - or any domain validation, not only DV. It might
help systems to get more accurate DNS data (maybe, at some point).
However DNSSEC is not a point to point encryption layer and not even
part of that. And DNSSEC isn't many things currently SSL/X.509 PKI and
CAs provide and stand for.
I know what Dan and some others are up to (more or less) and including
keys into the DNS is one of their ideas. Nothing overly exciting at the
moment and I believe that they haven't thought all of it through. They
are geeks, which is perfectly fine, but the effects will be perhaps
similar to PGP - mostly irrelevant to what web sites need.
Claiming that DNSSEC is about replacing DV certs is a lie and the
disappointment will be accordingly for those holding out for the
diminishing of the CAs to a little corner reserved for some sites that
need EV. Sorry about that, it will not happen as far as I can see it.
Neither within any time-frame I consider useful at the moment (IPv6
anybody)?
Anyway, I better shut up now...
Steve Schultze
Yes, you have expressed general skepticism about the proposal for some
time now but never explained your specific critique(s).
Several of your comments indicate that you really do not know much about
the proposal, including:
* "DNSSEC is not a point to point encryption layer" (irrelevant because
it works in conjunction with TLS and other p2p encryption layers)
* "Claiming that DNSSEC is about replacing DV certs is a lie" (actually,
that is exactly what it's about)
* "DNSSEC isn't [...] X.509" (yes, this is the point)
* "Nothing overly exciting" (open to debate I suppose, but entirely
unsubstantiated)
Finally, you seem to be concerned that when relieved from DV duties, CAs
will be relegated to "a little corner reserved for some sites that need
EV," which fails to appreciate the enhanced value of real CA
certification once domain validation is implicit in the DNS. Some of
your competitors are already active and supportive participants in the
working group because they get it (as are other browser vendors and
major sites like PayPal).
Eddy Nigg
> Yes, you have expressed general skepticism about the proposal for some
> time now but never explained your specific critique(s).
I haven't done that yet either, it's not my intention to criticize
DNSSEC itself, just noted some obvious points what it isn't and what I
believe it will never become or do. It's neither my intention to provide
any prove for that today.
>
> Finally, you seem to be concerned that when relieved from DV duties,
> CAs will be relegated to "a little corner reserved for some sites that
> need EV," which fails to appreciate the enhanced value of real CA
> certification once domain validation is implicit in the DNS.
DV certs will die when the group of the most important CAs issuing them
and/or the browser vendors will agree to kill them, not before. I'm not
worried at all, our revenues aren't based on DV certs as you probably
might know. So my concern is....hmmm....very small if this is what you
are hinting at. :-)
> Some of your competitors are already active and supportive
> participants in the working group because they get it (as are other
> browser vendors and major sites like PayPal).
You may freely assume that I probably know more about that and the
relevance might be about the same as the 2 % market share of EV to this
day. It's also mostly the same group plus Google, for the better or
worse. And Paypal is just only one online business and as significant as
they are, the Internet is a bit larger than that. Nor is Paypal the
typical subscriber I care about. Hence I'm not overly impressed by that
either. And neither the fact that those very competitors are listening
here...
.....so, this isn't a good forum anyway to discuss DNSSEC and whatever
that means. I'm sure there will be time and place to do that. In the
meantime let us tend to the reviews and inclusions of some CAs here that
need urgent attention.
Steve Schultze
> On 12/22/2010 06:23 AM, From Steve Schultze:
>> Yes, you have expressed general skepticism about the proposal for some
>> time now but never explained your specific critique(s).
>
> I haven't done that yet either, it's not my intention to criticize
> DNSSEC itself, just noted some obvious points what it isn't and what I
> believe it will never become or do. It's neither my intention to provide
> any prove for that today.
As I explained, your "obvious points" were clearly incorrect. If you
don't want to provide justification for them, I suppose we can safely
ignore both them and your more general opinions on the matter. I'd
rather have a productive dialogue.
As an aside, it's Keys-in-DNSSEC, not just DNSSEC (important distinction).
>> Finally, you seem to be concerned that when relieved from DV duties,
>> CAs will be relegated to "a little corner reserved for some sites that
>> need EV," which fails to appreciate the enhanced value of real CA
>> certification once domain validation is implicit in the DNS.
>
> DV certs will die when the group of the most important CAs issuing them
> and/or the browser vendors will agree to kill them, not before. I'm not
> worried at all, our revenues aren't based on DV certs as you probably
> might know. So my concern is....hmmm....very small if this is what you
> are hinting at. :-)
DV certs will die when there is a better alternative that browsers and
users adopt. CAs can either try to understand possible upcoming
alternatives and figure out how to capitalize on them or not.
> .....so, this isn't a good forum anyway to discuss DNSSEC and whatever
> that means. I'm sure there will be time and place to do that. In the
> meantime let us tend to the reviews and inclusions of some CAs here that
> need urgent attention.
You're the one that started the conversation, but I do think it's
relevant to this list's general mandate as a place where members of the
community talk about security-relevant policy (in addition to the work
of CA root review and inclusion).
Steve
Jean-Marc Desperrier
> it will not happen as far as I can see it. Neither within any time-frame
> I consider useful at the moment (IPv6 anybody)?
When the IPv4 exhaustion shit will hit the fan in a pair of months, I
feel a lot of people will be very vocal when asking why IPv6 hasn't been
deployed a lot faster and a lot earlier, and how the hell could
everybody just continue to act just like nothing would happen and paint
themselves in a corner like that.
I believe to ordinary people IT guys will look as stupid as the finance
guys who went headfirst foreseeing nothing into the mortgage crisis.
Part of this is I don't believe IANA has been handling the situation
very well. One possible solution could have been to make everybody feel
the exhaustion pain progressively, by slowing more and more the
allocation speed.
Eddy Nigg
> As I explained, your "obvious points" were clearly incorrect. If you
> don't want to provide justification for them, I suppose we can safely
> ignore both them and your more general opinions on the matter.
Please ignore it.
> DV certs will die when there is a better alternative that browsers and
> users adopt. CAs can either try to understand possible upcoming
> alternatives and figure out how to capitalize on them or not.
Thanks for your advise.
> You're the one that started the conversation,
Not really. You had a problem with the lock icon and you shared with us
your past criticism of the current trust system. And you proposed
alternative is DNSSEC which I think will not become one. But it wasn't
my intention to talk about DNSSEC and I didn't start either discussions
(Lock icon nor DNSSEC).
> but I do think it's relevant to this list's general mandate as a place
> where members of the community talk about security-relevant policy .
Sure. Feel free to continue the discussion.
Steve Schultze
>> You're the one that started the conversation,
>
> Not really. You had a problem with the lock icon and you shared with us
> your past criticism of the current trust system. And you proposed
> alternative is DNSSEC which I think will not become one. But it wasn't
> my intention to talk about DNSSEC and I didn't start either discussions
> (Lock icon nor DNSSEC).
Right, you asked me to talk about alternatives and then said you didn't
actually want to talk about them. This would all be a pointless
exercise in egotism (which I would have eagerly avoided) if it weren't
for the fact that through your ignorance of the issue you began to
spread FUD and falsehoods. It's important for this list to not
misunderstand the facts about this topic, because it will likely be
relevant to our work in the not-too-distant future. It also happens to
relate to the security UI, because Mozilla may have to determine how
Keys-in-DNSSEC fits into the so-called "Larry" site ID system.
In summary, I encourage folks who want to know more to read the draft
and participate in the list:
http://www.ietf.org/mail-archive/web/keyassure/current/msg01091.html
http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html
Eddy Nigg
>
> Right, you asked me to talk about alternatives and then said you
> didn't actually want to talk about them.
Steven, asking you about them isn't automatically an agreement to hold a
discussion on that topic no matter what your answer will be, right? Your
answer was something I prefer not to talk about more extensively here at
this forum at this time. And I guess I have the freedom to do that :-)
> This would all be a pointless exercise in egotism (which I would have
> eagerly avoided) if it weren't for the fact that through your
> ignorance of the issue you began to spread FUD and falsehoods.
Well, the FUD started with
http://citpsite.s3.amazonaws.com/publications/Roosa_Schultze_CA_Trust_Model.pdf
without providing a better alternative on this particular subject.
Or can you point me to the liabilities, warranties and responsibility
commitments that DNSSEC provides that are better than those of the
"worst" CAs? If any?
Which guaranties do I get that the keys are handled at least equal the
standards to those of the CAs?
Who is auditing those signing the keys?
What happens in case of wrongful issuance and damage is caused to third
parties?
Do you believe that that any reliance agreement or other legal
disclaimers by the domain name registrars will be any different from
those of the CAs?
Lets stay focused on this particular subject which is apparently of
interest to both of us (without getting into the technical
advantages/disadvantages one might have above the other).
Steve Schultze
>> This would all be a pointless exercise in egotism (which I would have
>> eagerly avoided) if it weren't for the fact that through your
>> ignorance of the issue you began to spread FUD and falsehoods.
>
> Well, the FUD started with
> http://citpsite.s3.amazonaws.com/publications/Roosa_Schultze_CA_Trust_Model.pdf
> without providing a better alternative on this particular subject.
So, to be clear, you aren't actually disputing anything in the article.
You're just upset that an article targeted at legal professionals laid
out potential exposure for their clients and suggested ways of
mitigating that. This is what these types of articles do.
The article isn't supposed to be a comprehensive treatment of the CA
liability regime and its alternatives. That's coming as a law review
article later.
It sounds to me that you got worked up about that article and used my
question about the user interface to bring it up.
> Or can you point me to the liabilities, warranties and responsibility
> commitments that DNSSEC provides that are better than those of the
> "worst" CAs? If any?
>
> Which guaranties do I get that the keys are handled at least equal the
> standards to those of the CAs?
>
> Who is auditing those signing the keys?
>
> What happens in case of wrongful issuance and damage is caused to third
> parties?
>
> Do you believe that that any reliance agreement or other legal
> disclaimers by the domain name registrars will be any different from
> those of the CAs?
The potential strength of putting Keys-in-DNSSEC is that it locates
control of domain validation in the most logical place for it... in DNS.
The proposal starts with the observation that CA DV *already
inherently* relies on the DNS for validation (emails to the domain, etc).
Why is it likely to be more secure than CA DV? First of all, it
subtracts hundreds of otherwise-unrelated entities from the process and
provides a single clear and public trust path that the Subscriber gets
to choose. Indeed, this generates in the market a virtuous race to the
top rather than the current race to the bottom.
Thus, the Keys-in-DNSSEC model starts without several of the
shortcomings that the existing CA legal architecture seeks to remedy
(primarily by disclaiming all liability on the part of CAs). Indeed, as
noted by the article and in our followup comments on the blog post, "the
CA Trust Model's legal architecture inures to the benefit of no one"
(including the CAs). With respect to at least some elements, no
explicit legal infrastructure is better than what we have now (eg:
Relying Party Agreement). I'll soon be posting a talk by my co-author
in which he describes the false sense of security generated by the EV
warranty model as well (I'm just waiting for the audio to be edited).
To the extent that Keys-in-DNSSEC needs supplementary legal support
(beyond inherent torts), the chain of relationships is clearer and more
direct. Should we push for more explicit warranties on the part of the
DNS root and the registrars? Perhaps, but the behavior of the actors so
far (witness the rigorous root-signing procedures), and the inherent
market dynamics might make explicit warranties unnecessary.
Steve
Eddy Nigg
> So, to be clear, you aren't actually disputing anything in the
> article. You're just upset that an article targeted at legal
> professionals laid out potential exposure for their clients and
> suggested ways of mitigating that. This is what these types of
> articles do.
I suggest to scroll back a bunch of posts and re-read what I exactly
wrote there.
>
> The article isn't supposed to be a comprehensive treatment of the CA
> liability regime and its alternatives.
But the article doesn't say that it isn't supposed to be a comprehensive
treatment of the CA liability regime. Unfortunately. No disclaimer
either, instead advise about potential exposure and a conclusion.
Your article is used for bashing and pulling the entire system (all CAs
for that matter, browsers, everything we rely on today) once more
through the mud - *without* providing a better alternative and *without*
recognizing the legal restrictions (or even a basic understanding on
legal matters) and constraints almost any if not all entities
(commercial and non-commercial) are subject to. It makes a nice article
to smear once again the CAs (all of them) and probably for the only
reason to advance other interests and a different agendas of the author.
And the irony of all that? The very same author is looking for the
padlock in the browser :-)
>
> It sounds to me that you got worked up about that article and used my
> question about the user interface to bring it up.
To be more correct, not the question about the padlock and UI decisions
but, I'm quoting: "given my past criticism of the actual strength of the
current trust system."
> The potential strength of putting Keys-in-DNSSEC is that it locates
> control of domain validation in the most logical place for it... in
> DNS. The proposal starts with the observation that CA DV *already
> inherently* relies on the DNS for validation (emails to the domain, etc).
Nothing new and surprising indeed. But you talk about two different
things above, one is DNSSEC and the other is using it for something
else). As I said previously, plain DNSSEC might help CAs to perform a
more robust domain control validation - up to a certain point and with
the usual due diligence involved. If combined with current practices I
believe there is an obvious advantage and another indicator for CAs to use.
> To the extent that Keys-in-DNSSEC needs supplementary legal support
> (beyond inherent torts), the chain of relationships is clearer and
> more direct. Should we push for more explicit warranties on the part
> of the DNS root and the registrars? Perhaps, but the behavior of the
> actors so far (witness the rigorous root-signing procedures), and the
> inherent market dynamics might make explicit warranties unnecessary.
>
Oh really? In fact I just was waiting for an answer like that the
superior technology will relief from liability, responsibility and
warranties - of course! Now, you can sell that to whomever you want, but
I'm not buying it. And most likely neither some others that have a stake
in it.
This is only one of the issues *I will* address in due time. Not
speaking about putting some keys into DNS which has yet other
implications. This is something for later (if you allow to excuse me on
this specific topic for now).
Steve Schultze
accusations. I've tried very hard to be patient and to give specific
concrete answers to your critiques when they are discernible. It's fine
if you disagree, and if you explain what specifically you think is
incorrect, but the current path is not constructive. My work seeks to
help CAs and the entire ecosystem, but you seem to regard any effort to
discuss weaknesses as a personal affront. I could reply line-by-line
below, but I won't subject the list to that (or to any more replies
unless they deal with actual concrete policy, technical, or legal issues).
I hope this thread has at least served as a starting point for
constructive future discussion of the UI questions at hand (I will
cross-post a related blog post here and at m.d.usability after the
holidays), and a friendly invitation to participate in the burgeoning
Keys-in-DNSSEC community despite the abrasive context.
Eddy Nigg
> Eddy, it's disheartening that you're devolving to ad hominems and
> vague accusations. I've tried very hard to be patient and to give
> specific concrete answers to your critiques when they are
> discernible. It's fine if you disagree, and if you explain what
> specifically you think is incorrect, but the current path is not
> constructive.
Do you think that releasing such articles is any better? I believe a
serious engagement starts differently which would allow to discuss and
perhaps clarify some what you haven't thought about. I told you freely
what I think about it - it's another attempt to smear the CAs through
the mud withoutproviding a better alternative and withoutrecognizing the
legal restrictions of the real world.
Did you ever look at the contracts and end-user agreements of your
software upon which you rely BEFORE you can rely on a certificate from a
CA? And for that matter your bank, credit card vendor and your Internet
provider, BEFORE any CA comes into play? Not that I'm happy with
everything there is in this respect, but those are realities.
Just as an interesting exercise I suggest to produce a piece of software
with some millions $ investment which will be used by millions upon
millions of users, then speak to your lawyer about the liability and
warranty you want to attach to your software. Then let us talk again.
> My work seeks to help CAs and the entire ecosystem, but you seem to
> regard any effort to discuss weaknesses as a personal affront.
If you want to help, I believe there are smarter, more effective and
less offensive ways doing that. Certainly not with advices to the public
which basically say - don't trust them. That's of course only my
opinion. Additionally without having a viable alternative or ways of
doing anything you criticize any better, I would consider again if the
critic is in place and even justified. At least until you have.
CAs get criticized a lot - from outside and from within. Those that are
able to show the weakness and provide a realistic solution are most of
the time more successful in achieving their goals for improvement. Even
if it takes time - but you should try that.
Jeremy Rowley
http://support.mozilla.com/en-US/kb/Site%20Identity%20Button#w_blue-basic-id
entity-information.
"When a domain has been verified, it means that the people who are running
the site have bought a certificate proving that they own the domain and it
is not being spoofed."
This is inaccurate. A verified domain does not prove who owns the domain or
that the domain is not being spoofed. Accurate language would be "A
verified domain means that the certificate holder owns or controls the
secured domain."
Jeremy
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Eddy Nigg
Sent: Tuesday, December 21, 2010 9:01 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Lock icon removed from 4.0b7
On 12/22/2010 05:00 AM, From Steve Schultze:
> Keys-in-DNSSEC could replace the DV function of CAs because it does what
> the current DV regime does, but better. It introduces true domain
> constraints, excludability of certifiers, and a single knowable trust
> path. When combined with EV certs, these also make the EV regime
> stronger. Call it a trust model or not, it is a better system.
Just a final note here (for the time-being, I'm sure there will be more
at some point). DNSSEC might be able to help CAs perform better domain
control validation - or any domain validation, not only DV. It might
help systems to get more accurate DNS data (maybe, at some point).
However DNSSEC is not a point to point encryption layer and not even
part of that. And DNSSEC isn't many things currently SSL/X.509 PKI and
CAs provide and stand for.
I know what Dan and some others are up to (more or less) and including
keys into the DNS is one of their ideas. Nothing overly exciting at the
moment and I believe that they haven't thought all of it through. They
are geeks, which is perfectly fine, but the effects will be perhaps
similar to PGP - mostly irrelevant to what web sites need.
Claiming that DNSSEC is about replacing DV certs is a lie and the
disappointment will be accordingly for those holding out for the
diminishing of the CAs to a little corner reserved for some sites that
need EV. Sorry about that, it will not happen as far as I can see it.
Neither within any time-frame I consider useful at the moment (IPv6
anybody)?
Anyway, I better shut up now...
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Eddy Nigg
> This is inaccurate. A verified domain does not prove who owns the domain or
> that the domain is not being spoofed. Accurate language would be "A
> verified domain means that the certificate holder owns or controls the
> secured domain."
Or perhaps even better: the holder either owns the domain or can
demostrate control over the domain space or has been authorized to use
the secured domain.
aero...@gmail.com
As it does, the security UI hasn't improved, and it takes away the only bastion of security theater that people have.
Frankly, I'm pretty much done with Mozilla.
-Kyle H
On Mon, Dec 20, 2010 at 5:30 PM, Eddy Nigg <eddy...@startcom.org> wrote:
> On 12/21/2010 03:16 AM, From Steve Schultze:
>>
>> You are making a completely accurate logical argument. However, usability
>> also involves a significant degree of psychology and behavior. People have
>> had "look for the lock icon" shouted at them for so many years that it's
>> hard to know how to reverse this conditioning.
> Of course there is some pain involved, however we must break away from it at
> some point despite all the shouting and that point has apparently come close
>> Even as a highly informed user, I wasn't immediately certain what was
>> going on, and I wasn't familiar with the "Larry" schema (does anybody know
>> why it's even called that?!).
>
>
> http://blog.johnath.com/2008/05/06/about-larry/
>
> http://www.dria.org/wordpress/archives/2008/05/06/635/
>
>> It would be interesting to know if there is any empirical data on what
>> people think in this scenario... actual user testing.
>
> Johnathan might have some clue about it...
>
>> In any case, it looks like this was all discussed already, and that new
>> appeals to restore the lock won't likely work:
>
> Yup.
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> XMPP: star...@startcom.org
> Blog: http://blog.startcom.org/
> Twitter: http://twitter.com/eddy_nigg
>
aero...@gmail.com
On Mon, Dec 20, 2010 at 8:45 PM, Steve Schultze <sjschult...@gmail.com> wrote:
>
> And after googling this issue earlier today I already found those pages, but
> they didn't answer my question (wtf is "Larry"?). The fact that it took me
> awhile to even find a page explaining why the lock was no longer part of the
> UI is a problem... let alone finding out more about why the decision was
> made (which involved getting in contact with people on this list and/or
> posting to bugzilla and getting directed to an existing bug that I was
> unable to find through searching... something that 99.999% of users will not
> do).
Becoming part of a community is different from running a piece of software.
And while (many) technical people are willing to give the benefit of the doubt, most non-technical people are too busy elsewhere.
-Kyle H
Nelson Bolyard
> Firefox 4.0 has not yet been released as a completed product for
> end-users. However, an extension to undo the implementation of bug
> #574688 has already been downloaded 23,988 times from addons.mozilla.org.
Thank goodness that it's available!!
--
/Nelson Bolyard
Eddy Nigg
> Thank goodness that it's available!!
:-)
Matt McCutchen
On Dec 22 2010, 6:14 pm, Eddy Nigg <eddy_n...@startcom.org> wrote:
> Which guaranties do I get that the keys are handled at least equal the
> standards to those of the CAs?
>
> Who is auditing those signing the keys?
There are DNSSEC practice statements that cover these issues, for
example:
https://www.iana.org/dnssec/icann-dps.txt
https://verisigninc.com/en_US/repository/index.xhtml
> Or can you point me to the liabilities, warranties and responsibility
> commitments that DNSSEC provides that are better than those of the
> "worst" CAs? If any?
>
> What happens in case of wrongful issuance and damage is caused to third
> parties?
Warranties do not seem to be in place at this time. Hopefully they
will come as the system matures.
> Do you believe that that any reliance agreement or other legal
> disclaimers by the domain name registrars will be any different from
> those of the CAs?
They may well be the same. The advantage is that access to a given
domain name is only exposed to a few registries/registrars which
(depending on the domain name) may be in jurisdictions generally
considered more trustworthy, compared to hundreds of CAs in
jurisdictions around the world against whom it may be difficult to
enforce any assurances in the agreements.
--
Matt
S Davidson
> domain name is only exposed to a few registries/registrars which
> (depending on the domain name) may be in jurisdictions generally
> considered more trustworthy, compared to hundreds of CAs in
> jurisdictions around the world against whom it may be difficult to
> enforce any assurances in the agreements.
Based on the Netcraft data, 95% of public SSL are issued by the top 6 CAs, all of whom are either US-based or have significant US operations.
S Davidson
> domain name is only exposed to a few registries/registrars which
> (depending on the domain name) may be in jurisdictions generally
> considered more trustworthy, compared to hundreds of CAs in
> jurisdictions around the world against whom it may be difficult to
> enforce any assurances in the agreements.
Based on the Netcraft data, 95% of public SSL are issued by the top 6 CAs, all of whom are either US-based or have significant US operations.
Eddy Nigg
> https://www.iana.org/dnssec/icann-dps.txt
> https://verisigninc.com/en_US/repository/index.xhtml
So far nobody is auditing it I guess...
> Warranties do not seem to be in place at this time. Hopefully they
> will come as the system matures.
OK, let us know about it.
> They may well be the same. The advantage is that access to a given
> domain name is only exposed to a few registries/registrars which
> (depending on the domain name) may be in jurisdictions generally
> considered more trustworthy, compared to hundreds of CAs in
> jurisdictions around the world against whom it may be difficult to
> enforce any assurances in the agreements.
>
There are provably way more domain name registrars than CAs, for some
sole TLDs as many. I can't follow your argument considering that in
Firefox there are currently 160 or so CA roots (not CAs).
Ben Wilson
the EFF SSL Observatory map that doesn't include all of the CAs linked to
DFN-Verein. Or as a follow up to Stephen Davidson's post, a map of the
95%-99%.
-----Original Message-----
From: dev-security-policy-bounces+ben=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
Behalf Of Eddy Nigg
Sent: Tuesday, January 18, 2011 12:28 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Keys-in-DNSSEC
On 01/18/2011 07:47 PM, From Matt McCutchen:
> https://www.iana.org/dnssec/icann-dps.txt
> https://verisigninc.com/en_US/repository/index.xhtml
So far nobody is auditing it I guess...
> Warranties do not seem to be in place at this time. Hopefully they
> will come as the system matures.
OK, let us know about it.
> They may well be the same. The advantage is that access to a given
> domain name is only exposed to a few registries/registrars which
> (depending on the domain name) may be in jurisdictions generally
> considered more trustworthy, compared to hundreds of CAs in
> jurisdictions around the world against whom it may be difficult to
> enforce any assurances in the agreements.
>
There are provably way more domain name registrars than CAs, for some
sole TLDs as many. I can't follow your argument considering that in
Firefox there are currently 160 or so CA roots (not CAs).
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
_______________________________________________
S Davidson
S Davidson
Stephen Schultze
> There are provably way more domain name registrars than CAs, for some
> sole TLDs as many. I can't follow your argument considering that in
> Firefox there are currently 160 or so CA roots (not CAs).
The way DNSSEC works, there is a single path of trust for any given
domain that contains a number DS records (representing trusted entities)
equal to the number of components of the domain (hierarchical
delegation). So, the number of entities that make assertions in DNS
about the delegated validity of DNS records for mozilla.org is 2: the
registry for .org and the root. The other party involved is the
registrar that Mozilla chooses. Other registrars do not matter, because
the registries only permit _exclusive_ access to their database (ie:
only one registry can control a given domain at a time). Once someone
chooses their registrar, that choice gets "locked in" so to speak, and
there's nothing that any other registrar can do about it. This
generates a race-to-the-top toward trustworthy registrars (and
registries via choosing a TLD), as opposed to the PKIX race-to-the bottom.
Incidentally, this is also why S Davidson's point that "of public SSL
are issued by the top 6 CAs, all of whom are either US-based or have
significant US operations" is not particularly comforting. In today's
model, bad guys will go to the jurisdictions / CA's that are less
scrupulous regardless of what the majority of the population does.
Keys-in-DNSSEC has valuable characteristics of delegation and
excludability that the current PKIX CA model does not. I discuss some
aspects of this here:
http://www.freedom-to-tinker.com/blog/sjs/web-security-trust-models
Steve
S Davidson
wrote:
> Once someone chooses their registrar, that choice gets "locked in" so to speak, and
> there's nothing that any other registrar can do about it. This
> generates a race-to-the-top toward trustworthy registrars (and
> registries via choosing a TLD), as opposed to the PKIX race-to-the bottom.
>
> Incidentally, this is also why S Davidson's point that "of public SSL
> are issued by the top 6 CAs, all of whom are either US-based or have
> significant US operations" is not particularly comforting. In today's
> model, bad guys will go to the jurisdictions / CA's that are less
> scrupulous regardless of what the majority of the population does.
I disagree that there is a race to the top for registrars but a race
to the bottom for CAs.
Many ccTLDs only have one registrar ... that is operated or controlled
by the Government. Choice is limited or non-existent.
Public SSL is very concentrated. 6 CAs issue 95% of public SSL ...
but that number climbs to more than 99% if you add just a handful of
CAs more from the list. What remains are a variety of CAs that issue
SSL to target markets and are not really set up for "international
retail."
Is there any evidence of bad guys buying SSL from commercial CAs,
never mind jurisdiction shopping?
Stephen Schultze
> On Jan 18, 4:44 pm, Stephen Schultze<sjschultze.use...@gmail.com>
> wrote:
>
>> Once someone chooses their registrar, that choice gets "locked in" so to speak, and
>> there's nothing that any other registrar can do about it. This
>> generates a race-to-the-top toward trustworthy registrars (and
>> registries via choosing a TLD), as opposed to the PKIX race-to-the bottom.
>>
>> Incidentally, this is also why S Davidson's point that "of public SSL
>> are issued by the top 6 CAs, all of whom are either US-based or have
>> significant US operations" is not particularly comforting. In today's
>> model, bad guys will go to the jurisdictions / CA's that are less
>> scrupulous regardless of what the majority of the population does.
>
> I disagree that there is a race to the top for registrars but a race
> to the bottom for CAs.
>
> Many ccTLDs only have one registrar ... that is operated or controlled
> by the Government. Choice is limited or non-existent.
Sure, if you want a given ccTLD then you sometimes only have one choice.
However, if you really care about the trustworthiness of your trust
chain, you might very well be persuaded to move to another domain... or
even if you aren't persuaded, others might be, thus exerting pressure on
that ccTLD. In any case, even if the race-to-the-top effects do not
apply, the system is still far more delegated and excludable than
current PKIX, which has major benefits.
> Public SSL is very concentrated. 6 CAs issue 95% of public SSL ...
> but that number climbs to more than 99% if you add just a handful of
> CAs more from the list. What remains are a variety of CAs that issue
> SSL to target markets and are not really set up for "international
> retail."
Again, the percentage of public use of CAs is largely irrelevant... even
the percentage of CAs set up for "international retail" is largely
irrelevant. The trust model must incorporate the likelihood that any
given CA may be under pressure/attack from non-commercial entities its
jurisdiction (including its government) to do bad stuff.
What matters is the surface area of validation authority for any given
domain. In today's PKIX it's somewhere between hundreds and thousands
of entities. With keys-in-DNSSEC it's the handful of entities involved
in the trust path chosen by the domain owner.
> Is there any evidence of bad guys buying SSL from commercial CAs,
> never mind jurisdiction shopping?
Again, "commercial" CAs are only one portion of the set of CAs that
contribute to the threat.
And in answer to your question, no... but we have poor means for
measuring this. The point is that to the extent that there are any
race-to-the-* effects at all, the incentives point in one direction for
CA-based PKIX and the other for Keys-in-DNSSEC.
S Davidson
> However, if you really care about the trustworthiness of your trust
> chain, you might very well be persuaded to move to another domain... or
> even if you aren't persuaded, others might be, thus exerting pressure on
> that ccTLD.
And if I were a bad guy I might also jurisdiction shop for lax ccTLDs.
If I cared about the trustworthiness of my trust chain I'd probably be interested in EV SSL.
I speculate that the "map" of registries and registrars is more complicated than that of the CAs.
S Davidson
> However, if you really care about the trustworthiness of your trust
> chain, you might very well be persuaded to move to another domain... or
> even if you aren't persuaded, others might be, thus exerting pressure on
> that ccTLD.
And if I were a bad guy I might also jurisdiction shop for lax ccTLDs.
Stephen Schultze
>> Sure, if you want a given ccTLD then you sometimes only have one choice.
>> However, if you really care about the trustworthiness of your trust
>> chain, you might very well be persuaded to move to another domain... or
>> even if you aren't persuaded, others might be, thus exerting pressure on
>> that ccTLD.
>
> And if I were a bad guy I might also jurisdiction shop for lax ccTLDs.
Ok, but you continue to miss the point that the level of security is up
to the person registering the domain.
And from the perspective of end users it is far more self-evident who is
involved in the trust chain for sites they choose (enabling, for
example, citizens in a particular country that surveils it's citizens to
avoid that country's ccTLD or TLDs with a bad reputation).
Relative to today's DV CA PKIX market, the overall system risk is far
lower with Keys-in-DNSSEC (presuming the system operates as it is being
described/theorized/implemented).
> If I cared about the trustworthiness of my trust chain I'd probably be interested in EV SSL.
Actually, your best bet would be to get an EV cert and place that in
DNSSEC-secured DNS. That would give you both the real-world-entity
identity validation of EV (and the CAB Forum's higher standards) and the
benefits of exclusivity and delegation from DNS. Indeed, this precise
scenario is why many of us are excited about Keys-in-DNSSEC, and we see
it as a value-add to EV.
> I speculate that the "map" of registries and registrars is more complicated than that of the CAs.
I'm not sure what you could mean here, but regardless of your
speculation on "complexity," the structure and rules for DNS delegation
are far more well defined.
=JeffH
...
The trust model must incorporate the likelihood that any
given CA may be under pressure/attack from non-commercial entities its
jurisdiction (including its government) to do bad stuff.
indeed. E.g. see..
Soghoian, Christopher, and Sid Stamm. "Certified
Lies: Detecting and Defeating Government Interception
Attacks Against SSL" (2010)
http://www.cs.indiana.edu/ftp/techreports/TR684.pdf
=JeffH
Eddy Nigg
>
> indeed. E.g. see..
>
> http://www.cs.indiana.edu/ftp/techreports/TR684.pdf
>
Show me the certificates, not speculations.
Peter Gutmann
>Is there any evidence of bad guys buying SSL from commercial CAs, never mind
>jurisdiction shopping?
If "bad guys" you mean malware hosting, pay-per-install, carding, etc, then
yes, there's plenty of that going on (one that immediately springs to mind is
https://www.pay-per-install.org/). After all, the Russian mafia are entitled
to SSL just as much as the rest of us.
Peter.
Eddy Nigg
> If "bad guys" you mean malware hosting, pay-per-install, carding, etc, then
> yes, there's plenty of that going on (one that immediately springs to mind is
> https://www.pay-per-install.org/).
But DNSSEC (and key's therein) will not change it, quite the opposite.
It will make it worse because nobody will revoke it - specially
considering that this site uses a valid domain name as of this writing.
Registrars certainly will not kill the domain either.
Peter Gutmann
>Once someone chooses their registrar, that choice gets "locked in" so to
>speak
You probably need to qualify this somewhat by mentioning that signed domain
transfers in DNSSEC are so difficult (I've heard them characterised as "too
painful to do" and "effectively impossible in practice") that you get locked
in whether you want to or not.
>This generates a race-to-the-top toward trustworthy registrars (and
>registries via choosing a TLD), as opposed to the PKIX race-to-the bottom.
Again, the observation I've heard is that once you've chosen a registrar for
DNSSEC use, you're stuck with them forever (that was from a registrar, said in
a somewhat gleeful tone. I got the impression that if there'd been a sound
effect to go with the statement it would have been the ka-ching of a cash
register :-).
Peter.
Steve Schultze
> On 01/19/2011 02:09 AM, From Peter Gutmann:
>> If "bad guys" you mean malware hosting, pay-per-install, carding, etc,
>> then
>> yes, there's plenty of that going on (one that immediately springs to
>> mind is
>> https://www.pay-per-install.org/).
>
> But DNSSEC (and key's therein) will not change it, quite the opposite.
> It will make it worse because nobody will revoke it - specially
> considering that this site uses a valid domain name as of this writing.
> Registrars certainly will not kill the domain either.
This issue is irrelevant to the Keys-in-DNSSEC question (and the PKIX CA
model). The question of whether or not domain owners are doing "bad"
things with their domain names has nothing to do with validating domain
ownership or real-world identity. Indeed, the registries that have
shown the most willingness to revoke domain ownership based on owner
practices are in jurisdictions that are most frequently accused of
censorship.
Of course, the US could become one of these if COICA goes through:
http://en.wikipedia.org/wiki/Combating_Online_Infringement_and_Counterfeits_Act
But that is way off-topic.
Eddy Nigg
> This issue is irrelevant to the Keys-in-DNSSEC question (and the PKIX
> CA model). The question of whether or not domain owners are doing
> "bad" things with their domain names has nothing to do with validating
> domain ownership or real-world identity.
I don't think so - just read a few CA policies (sections "Subscriber
Obligations" and similar are suggested readings).
And what would you expect from a CA that issued an EV certificate for a
site that openly distributes mal-ware and phishes PayPal?
There might be some benefits and values conventional CAs provide - I
don't expect you agreeing with that, but there still might be something...
Steve Schultze
> On 01/19/2011 03:29 AM, From Steve Schultze:
>> This issue is irrelevant to the Keys-in-DNSSEC question (and the PKIX
>> CA model). The question of whether or not domain owners are doing
>> "bad" things with their domain names has nothing to do with validating
>> domain ownership or real-world identity.
>
> I don't think so - just read a few CA policies (sections "Subscriber
> Obligations" and similar are suggested readings).
Oh, I don't dispute that many CAs claim to prohibit certain activities.
Many registrars do too. Check out GoDaddy's restriction of, among
other things, "morally objectionable activities":
http://www.godaddy.com/agreements/ShowDoc.aspx?pageid=REG_SA
But this is the area of purportedly reserved legal rights, and not
necessarily actual practice. It also has nothing to do with validating
domain ownership or real-world identity... as I said.
My contention is that the willingness of CAs or registrars to revoke
certs or domain ownership because of "unlawful" or otherwise
"objectionable" behavior of the customers is not good policy... as we
see in COICA and other examples. But, as I said, this is rather off-topic.
> And what would you expect from a CA that issued an EV certificate for a
> site that openly distributes mal-ware and phishes PayPal?
Do you have any examples of CAs doing something in this case? I know of
examples where CNNIC did this, but not others (although it certainly
could be true). In any case, my policy position is that it's a bad idea
because we don't have good judicial oversight globally, which leads to
likely abuse.
> There might be some benefits and values conventional CAs provide - I
> don't expect you agreeing with that, but there still might be something...
I absolutely agree. That's why I said that EV-plus-Keys-in-DNSSEC is
very valuable indeed.
Steve Schultze
I confess that I don't know much about the details of registrar
interactions during the domain transfer process, but I don't see how
asking your registrar to put a DS record in the parent zone could be
relevant to transfer. Can you explain, or point to any public
explanation of this?
Eddy Nigg
>> And what would you expect from a CA that issued an EV certificate for a
>> site that openly distributes mal-ware and phishes PayPal?
>
> Do you have any examples of CAs doing something in this case?
Let me insist on an answer to my previous question first, what would you
expect from a CA in such a case?
Steve Schultze
> On 01/19/2011 04:36 AM, From Steve Schultze:
>>> And what would you expect from a CA that issued an EV certificate for a
>>> site that openly distributes mal-ware and phishes PayPal?
>>
>> Do you have any examples of CAs doing something in this case?
>
> Let me insist on an answer to my previous question first, what would you
> expect from a CA in such a case?
Eddy, you are such an expert on these matters that I rely on your
insight to know what to expect.
As to what I think the right behavior is from a policy perspective, I
don't think that CAs should be in the business of making these judgment
calls... which should be evident from my earlier comments.
Eddy Nigg
From the EV guidelines:
The primary purposes of Extended Validation Certificates are to: 1)
identify the legal entity that controls a Web or service site, and 2)
enable encrypted communications with that site. The secondary purposes
include significantly enhancing cybersecurity by helping establish the
legitimacy of an organization claiming to operate a Web site, and
providing a vehicle that can be used to assist in addressing problems
related to distributing malware, phishing, identity theft, and diverse
forms of online fraud.
6.1.2 Secondary Purposes
The secondary purposes of an EV Certificate are to help establish the
legitimacy of a business claiming to operate a Web site or distribute
executable code, and to provide a vehicle that can be used to assist in
addressing problems related to phishing, malware, and other forms of
online identity fraud. By providing more reliable third-party verified
identity and address information regarding the business, EV Certificates
may help to: Make it more difficult to mount phishing and other online
identity fraud attacks using Certificates; Assist companies that may be
the target of phishing attacks or online identity fraud by providing
them with a tool to better identify themselves to users; and Assist law
enforcement organizations in their investigations of phishing and other
online identity fraud, including where appropriate, contacting,
investigating, or taking legal action against the Subject.
(2) Acceptable Methods of Verification: The CA MAY identify High Risk
Applicants by checking appropriate lists of organization names that are
most commonly targeted in phishing and other fraudulent schemes, and
automatically flagging EV Certificate Requests from Applicants named on
these lists for further scrutiny before issuance. Examples of such lists
include:
(A) Lists of phishing targets published by the Anti-Phishing Work Group
(APWG); and
(B) Internal databases maintained by the CA that include previously
revoked EV Certificates and previously rejected EV Certificate Requests
due to suspected phishing or other fraudulent usage.
The information MUST then be used to flag suspicious new EV Certificate
Requests. If an Applicant is flagged as a High Risk Applicant, the CA
MUST perform reasonably appropriate additional authentication and
verification to be certain beyond reasonable doubt that the Applicant
and the target in question are the same organization.
(We can't discuss the basic guidelines yet, but you may expect something
similar which is one of the many reasons why (self-signed)
keys-in-DNSSEC isn't the same as CA issued certificates (which may be
included in DNS if such a scheme should materialize).
Steve Schultze
Let's review. You said that the CA model can deal with malware hosting,
but a Keys-in-DNSSEC model will not. I said that if this were true, it
would be a bad policy outcome because CAs should be in the business of
validating identity, not judging use. I also explained that in any
event, registrars have similar clauses in their legal documentation. I
explained that with both CA-issued certs and domain names, the
enforcement of these policies is spotty at best. You haven't explained
why you disagree with any of this, if you do.
We now seem to have gone down some rathole about the details of the EV
guidelines. You seem to think that the guidelines compel CAs to deal
with problems like malware. It's all rather beside the point for the
reasons stated above, but I'll respond to this because I think it's an
interesting topic. As I read the text you quoted, all of the language
about deterring "bad" behavior is in the section about secondary
purposes. This section assumes that such benefits flow out of the
actual sole job of CAs... to validate real-world identity. As you can
see, all of these benefits are explained after noting, "By providing
more reliable third-party verified identity and address information
regarding the business, EV Certificates may help to..." It's just a
descriptive section about what people *could* do once a well-validated
cert exists. This is, in fact, the right policy outcome from my
perspective.
Eddy Nigg
> Let's review.
Thanks for flowing along with me....
> As you can see, all of these benefits are explained after noting, "By
> providing more reliable third-party verified identity and address
> information regarding the business, EV Certificates may help to..."
> It's just a descriptive section about what people *could* do once a
> well-validated cert exists. This is, in fact, the right policy
> outcome from my perspective.
It's one of them (and certainly a stronger foundation than not
validating the real-world identity. But there is also for example:
(A) Lists of phishing targets published by the Anti-Phishing Work Group
(APWG); and
(B) Internal databases maintained by the CA that include previously
revoked EV Certificates and previously rejected EV Certificate Requests
due to suspected phishing or other fraudulent usage.
And there are yet other things CAs do on all validation levels that are
currently neither required nor always disclosed besides general
references. That's in order to protect themselves and the relying
parties. Hence I believe (amongst other things like revocation,
warranties, etc.) that a self-signed certificate will never be the same
like a CA issued certificate. At least not until registrars would
perform these functions, which they probably never will because those
very domains which distribute mal-ware and are involved in phishing etc.
are very much alive and remain valid. Otherwise there would be no reason
to have CAs involved with preventing (or revoking) certificates for such
applicants. Basically a secure connecting to the mal-ware distributor
and phisher isn't such a cool thing.
Matt McCutchen
wrote:
> On 1/18/11 8:03 PM, Peter Gutmann wrote:
> > You probably need to qualify this somewhat by mentioning that signed domain
> > painful to do" and "effectively impossible in practice") that you get locked
> > in whether you want to or not.
> > Again, the observation I've heard is that once you've chosen a registrar for
> >DNSSECuse, you're stuck with them forever (that was from a registrar, said in
> > a somewhat gleeful tone. I got the impression that if there'd been a sound
> > effect to go with the statement it would have been the ka-ching of a cash
> > register :-).
>
> I confess that I don't know much about the details of registrar
> interactions during the domain transfer process, but I don't see how
> asking your registrar to put a DS record in the parent zone could be
> relevant to transfer. Can you explain, or point to any public
> explanation of this?
GoDaddy claims that a signed domain can be transferred, provided that
the gaining registrar supports DNSSEC. Presumably the DS records are
transferred without the user having to do anything special. I have
not tried it.
http://help.godaddy.com/topic/809/article/6151
Peter, maybe you are confusing a transfer among registrars with a KSK
change (which might be incident to a transfer to a new /registrant/).
The latter requires careful planning and execution to make sure the
domain continues to validate during the process, but there's plenty of
documentation online about how to do it. To the extent that a KSK
change is difficult, it is not for anticompetitive reasons.
--
Matt
Steve Schultze
> It's one of them (and certainly a stronger foundation than not
> validating the real-world identity. But there is also for example:
>
> (A) Lists of phishing targets published by the Anti-Phishing Work Group
> (APWG); and
> (B) Internal databases maintained by the CA that include previously
> revoked EV Certificates and previously rejected EV Certificate Requests
> due to suspected phishing or other fraudulent usage.
You are again trying to selectively read. That section is immediately
preceded by, "The CA MAY identify High Risk Applicants by checking
appropriate lists of organization names that are most commonly targeted
in phishing and other fraudulent schemes, and automatically flagging EV
Certificate Requests from Applicants named on these lists for further
scrutiny before issuance." It seems to on its face describe an
acceptable mechanism for further scrutiny of actual identity, *not* that
such flags by their nature are justification for denial. This is
consistent with my description.
> And there are yet other things CAs do on all validation levels that are
> currently neither required nor always disclosed besides general
> references. That's in order to protect themselves and the relying
> parties. Hence I believe (amongst other things like revocation,
> warranties, etc.) that a self-signed certificate will never be the same
> like a CA issued certificate. At least not until registrars would
> perform these functions, which they probably never will because those
> very domains which distribute mal-ware and are involved in phishing etc.
> are very much alive and remain valid. Otherwise there would be no reason
> to have CAs involved with preventing (or revoking) certificates for such
> applicants. Basically a secure connecting to the mal-ware distributor
> and phisher isn't such a cool thing.
And I disagree from a policy perspective because I think that
introducing more arbitrary intermediary control over internet
communications isn't such a cool thing.
In any case, people can point to "bad" guys who still have certificates
(as Peter Gutman did initially) or domains, so obviously the theoretical
policing in either area is non-existent or not working.
Steve Schultze
> On Jan 18, 9:37 pm, Steve Schultze<sjschultze.use...@gmail.com>
> wrote:
>> > On 1/18/11 8:03 PM, Peter Gutmann wrote:
>>> > > You probably need to qualify this somewhat by mentioning that signed domain
>>> > > transfers inDNSSECare so difficult (I've heard them characterised as "too
>>> > > painful to do" and "effectively impossible in practice") that you get locked
>>> > > in whether you want to or not.
>>> > > Again, the observation I've heard is that once you've chosen a registrar for
>>> > >DNSSECuse, you're stuck with them forever (that was from a registrar, said in
>>> > > a somewhat gleeful tone. I got the impression that if there'd been a sound
>>> > > effect to go with the statement it would have been the ka-ching of a cash
>>> > > register:-).
>> >
>> > I confess that I don't know much about the details of registrar
>> > interactions during the domain transfer process, but I don't see how
>> > asking your registrar to put a DS record in the parent zone could be
>> > relevant to transfer. Can you explain, or point to any public
>> > explanation of this?
> GoDaddy claims that a signed domain can be transferred, provided that
> the gaining registrar supports DNSSEC. Presumably the DS records are
> transferred without the user having to do anything special. I have
> not tried it.
>
> http://help.godaddy.com/topic/809/article/6151
I don't even see why the DS records would have to be "transferred."
They sit in the parent zone, so there's nowhere they need to be
transferred to.
Eddy Nigg
> And I disagree from a policy perspective because I think that
> introducing more arbitrary intermediary control over internet
> communications isn't such a cool thing.
But it's necessary. And with that we both are free to disagree.
Steve Schultze
> On 01/19/2011 07:11 PM, From Steve Schultze:
>> And I disagree from a policy perspective because I think that
>> introducing more arbitrary intermediary control over internet
>> communications isn't such a cool thing.
>
> But it's necessary. And with that we both are free to disagree.
Indeed, I suppose we will have to. I do think that EFF's work on COICA
here in the US is instructive:
Matt McCutchen
The relevant question is not whether keys-in-DNSSEC is the same as the
DV CA system, but whether it meets Mozilla's needs for a server
authentication mechanism to back the SSL/TLS features of its
products. The primary need is to authenticate a server as designated
by the registrant of a DNS name, and keys-in-DNSSEC does that. We
also have the malware protector and phishing protector.
--
Matt
Eddy Nigg
> The relevant question is not whether keys-in-DNSSEC is the same as the
> DV CA system, but whether it meets Mozilla's needs for a server
> authentication mechanism to back the SSL/TLS features of its
> products. The primary need is to authenticate a server as designated
> by the registrant of a DNS name, and keys-in-DNSSEC does that. We
> also have the malware protector and phishing protector.
>
Right. My point was that DV is probably more than authentication of the
host name - it is however the primary purpose. Another one is that they
are revocable for whatever reason. And all the other stuff we already
have been through.
Matt McCutchen
> On 01/19/2011 08:07 PM, From Matt McCutchen:
>
> > DV CA system, but whether it meets Mozilla's needs for a server
> > authentication mechanism to back the SSL/TLS features of its
> > products. The primary need is to authenticate a server as designated
> > also have the malware protector and phishing protector.
>
> Right. My point was that DV is probably more than authentication of the
> host name - it is however the primary purpose. Another one is that they
> are revocable for whatever reason. And all the other stuff we already
> have been through.
Please be specific so we can try to resolve the question.
- Revocation: In keys-in-DNSSEC, a domain registrant can revoke
endorsement of a server certificate by removing the TLSA record, and a
registry can revoke an organization's control of a domain by removing
the DS record. (There is no reasonable way for a registrar to revoke
an individual server certificate.) The RRSIG expiration time is
analogous to the expiration time of an OCSP response.
- Malware/phishing sites: You say the DV CAs work to avoid issuing
them certificates (or revoke already issued certificates), though
Stephen questions the effectiveness of those controls. For keys-in-
DNSSEC, it's not clear if the registries/registrars do the same. In
any case, Firefox has the malware and phishing protectors.
- Anything else?
--
Matt
Eddy Nigg
> Please be specific so we can try to resolve the question.
>
> - Revocation: In keys-in-DNSSEC, a domain registrant can revoke
> endorsement of a server certificate by removing the TLSA record, and a
> registry can revoke an organization's control of a domain by removing
> the DS record.
Extremely unlikely considering the current state of things - which is
that registrars keep domains alive that are currently used for any of
the purposes we would like to protect users. Otherwise we wouldn't have
to worry about phishing filters and such. This is a fact, it would be
very easy draw up a list of an enormous list of such known domains.
> - Malware/phishing sites: You say the DV CAs work to avoid issuing
> them certificates (or revoke already issued certificates), though
> Stephen questions the effectiveness of those controls.
Depending on the CA quite effective, perhaps we have to bring the others
onto the same level.
> For keys-in-
> DNSSEC, it's not clear if the registries/registrars do the same. In
> any case, Firefox has the malware and phishing protectors.
For current active mal-ware spewing and phishing sites only. There is
more into it and high risk applicants for certificates are not something
Firefox has an answer. What makes a high-risk applicant may differ,
including the network the site is hosted, domain space, naming
convention, locality and so forth.
> - Anything else?
Oh yes, loads of it - but not at the moment.
Peter Gutmann
>GoDaddy claims that a signed domain can be transferred, provided that the
>gaining registrar supports DNSSEC.
Hmm, I think their answer (or at least the question) is somewhat disingenious,
asking "Can I transfer a domain name that is DNSSEC-enabled?" is the same as
asking "Can I go to the moon?", the answer to both questions is yes but
there's a nontrivial amount of effort involved.
>Peter, maybe you are confusing a transfer among registrars with a KSK change
>(which might be incident to a transfer to a new /registrant/).
I was hoping that someone from a DNSSEC-using registrar would chime in at some
point, I was listening in on the discussion among people who worked for
registrars but wasn't sitting there taking notes to ensure technical accuracy.
It was definitely a transfer of a signed domain from one registrar to another,
with the accompanying problems of unsigning during the transfer, but as I said
I wasn't taking detailed notes.
Peter.