Ian Grigg wrote:
Thanks!Amir,
here are comments, not particularly well reviewed.
http://www.cs.biu.ac.il/~herzbea//Papers/ecommerce/spoofing.htm
Mozilla people (2nd try),
Please provide more comments...
Here are some responses to your comments:
I didn't find the definition and didn't quite understand the distinction you made.
Right, that idea. A couple of things - it's called a petname which has a defined meaning, you can probably google for the defining paper. It is a name that is explicitly not shared with the rest of the world, so it is distinct by definition with the nickname, which is shared.
I think we use different terms here. When I say `confirm the public key` I simply mean `confirm that the site actually has the private key corresponding to this public key. Nothing to do with certificates, CA etc.... usually done using SSL.
SSL/TLS isn't used to confirm the public key.
...
...Existing web security mechanisms (SSL/TLS) may cause substantial overhead if applied to most web pages, as required for securing credentials (e.g. logo) of each page. ...
> Amir! This has to be the worst reason to present! It's 2004,Unfortunately, most web pages are not protected by SSL. This includes most corporate and government web pages, and other sensitive web pages. The reason is mainly performance; the SSL protocol, while fairly optimized, still consumes substantial resources at both server
...most everybody has cycles sitting there doing nothing on their web servers, even your PDA could do SSL without you noticing
There is still valid concern about the cost of SSL esp at the server (check your own numbers... and remember that 512 bits is definitely insecure and even 1024 bits is considered insecure).
All I'm saying is this is not a show stopper. If you think we don't need a lighter version, so much the better. But some may disagree (for them I'll show the light version).
[Not]
...Protecting pages with SSL is 99% due to the cost of the certificate process. No manager in his right mind wants to futz around with that process, simply because its costly,
I agree browsers should accept self-signed certificates etc... will clarify this further. But I'm not sure this could explain the situation where we have sites which are mostly unprotected with some protected parts.
...
Customization: the visual representation of the different credentials should be customizable by the user. Such customization may
So we now have a class of ideas where the USER tells the BROWSER something about the certificate in question. And then, this:
In addition, our extension generates, upon installation, a private signature key, which it uses later on to sign logo certificates, linking public keys and logos, if the user (manually) specifies the use of the logo for the public key.
So we now have a local signing key generated on install to record those decisions of all user trust metrics. Perfect.
Right!
Finally, popular browsers are pre-configured with a list of many certification authorities, and the liabilities of certificate authorities are not well defined;
Yup! Not only are all CAs different, about the only thing they concur on is that they all want to escape liability.
Quite.
A logo certificate is a signature over the (hash of the) logo and over the public key, binding them, and saying: "the owner of the private key corresponding to this public key is also the owner of the trademark logo.". IMHO, this is better defined than identity certificates...This is where I'm getting confused. The site has a logo. That much we are happy with as a consequence of (other) branding.
Now, the logo can be signed. Sure. We could call that a logo certificate. Is that what is meant?
The answer: somebody who can make the assertion (and have users trust it...).
Then, the question is, who signs the logo and thus creates the logo cert?
This doesn't make any sense to me. Have the site sign its own logo?? What's to prevent it from signing somebody's else logo?
It would seem obvious at one level that the site cert should do so. That way they can do a dozen or more, and have control over the site layout, etc. Kind of critical, really, for efficiency.
Bingo; which is why we definitely don't let the site sign the logo! I mean, Ok, the site can _suggest_ a logo, but this will require the user to manually approve it.
But, if a spoofer does acquire a cert validly signed by a CA, then it can also create its own logo set, just by copying the graphics.
Exactly. Or maybe USPTO will sign one format of the logo (or few), and VeriSign and company will sign other formats.
Hence the notion of a Logo Certificate Authority, I guess. An LCA signs a logo and then acts as a kind of extended-trademark-authority. (E.g., it could be Verisign signing the cococola logo, or it could be the USPTO signing the Bob's bookstore logo.)
Logos must be approved by a trusted authority (Logo certifying authority, or the user, or his trusted friends).
The question then is - which? Is it one, or the other or both?
No site-signed logo; site can only suggest a logo but the user- or other trusted entity - must approve/certify it. And we'll simply display also the logo of the certifying party (see paper...).Then the issue arises how to display a site-signed logo alongside the "better" LCA-signed logo?
Definitely, that's what we already use and it is very handy.
(Later I find there is a THIRD choice, the user signature. That's good, too... *that* presents a much better starting point.)
The LCA should be trusted by the user. LCAs can cross certify and a site can present multiple logo certs from different LCAs. Also users can approve additional LCAs. I'll try to explain this better.
Finally, for each trusted LCA, the browser extension also maintains its logo and name, to identify it to the user (as responsible for the matching between the site and the site’s logo).
Essential, yes.
We expect such predefined lists to contain a relatively small number of logo certifying authorities, known to many users and `almost universally trusted`, e.g. the USPTO. This is very different from the predefined (or, at least for Internet Explorer, remotely managed by the vendor) lists of certification authorities in browsers, which include typically over hundred entities, as discussed in Section ‎2.1.
I don't see how that logic differs from the logic
explaining the proliferation of CAs.
...
Users should select the LCA (or trademark office) they trust... we are not about enforcing laws here, we are about protecting the user.There are about 200 countries.... even most of the Caribbean deals with trademarks now, and they (each) require filing if you want protection. So I'm unclear how it is that LCAs will not be subject to proliferation?
CAs currently only need to specify a minimal requirement and be in the list trusted by browsers. So why should they cross certify? With LCAs that should be different - none (or very few) should be on the default list. So others CAs should either convince the users to add them or cross certify.
...One reason that the predefined lists of logo certifying authorities can be very short, is that we allow and expect sites to obtain multiple logo certificates, and logo certifying authorities could cross-certify each other,...
CAs don't cross-certify each other. Why should LCAs do so?
The ideal presentation is due additional research but we use some common sense for now.
For example, in Figure 6 (a), eforcity.com is certified by eBay, Square Trade and VISA, while in (b), Citibank™’s logo is certified by Verisign
Is it easy for the user to see which cert is being certified by which authority? Ah, yes, I see, there is a box there that encapsulates the authorities. Excellent!
I think we should allow the user to select that we do this automatically (this is how many security dialogs work - they pop up until the user selects not to see them again).
To `bootstrap` the process of adoption of the Trusted Credentials Area (TCA) and of logo certificates, we propose that TCA-enabled browsers would also allow user-certified logos....
Yup. This is critical.
The following list of 4 points is interesting. One thing - the whole environment of site access is about users not being bothered by popup questions and the browser making default security choices.
In this vein, I'd say that the 3rd choice is the one to go with: " Present the organization name and/or URL..."
I guess it'll be best you give more feedback on our choice of specific UI after you played with our current design.
Then, offer an easy button to do more, like adding a menu option for "authenticate logo" on the right click over graphics. Also, say the certificate has been seen 5 times, the browser could pop up and suggest that a selection of logos be chosen from amongst.
I still don't see why the same corporation needs multiple SSL certificates. Why??
Unfortunately, many sites use multiple different public/private key pairs (and certificates), usually with no special reason, which increases this risk and inconvenience the users; we became aware of this since the opportunistic identification pops-up whenever encountering an unknown public key, and this often happens several times in some sites (e.g. Citibank), while not at all in others.
This is to be expected. Trying to think in terms of "one good cert" is a dead end. Corporates should be able to establish certs on the fly, and they should ideally be able to tie them back to a central signing CA internally, but that might be pushing things.
...
Yes, but the user can share the logos she certifies on her laptop with her desktop and home browsers by adding the public key of the laptop as a `tiny trusted CA`... which means if you approve a logo at work you'll automatically see it at home and on mobile. We don't have this feature for the history records.Web of trust...Well, that's going further than I'd thought of, but
yes, it's an obvious extension.
Notice, however, that the history is limited to access via this particular browser and computer.
Notice that this criticism applies to all of the ideas in this class - the browser has its private key and its petnames and signed logos. It doesn't necessarily share all these with every other browser, or even the ones that can be predicted. Now, the user knows this. If it sees that in a different browser, all the logos change, and the numbers change and so forth, they can quickly get the feeling that it is because they are accessing from a different place - and factor that uncertainty in.
4 Efficient Authentication of Response Credentials using CLTLS
I feel that this proposal sits oddly here. Not only the objections to performance issues, as above, but also that few people will read both parts - beyond remit.
I agree; I'll remove all of this to separate publication (maybe).
I know, but it is very different. In fact, what you refer to is a way to extend SSL so it runs over UDP, while I propose a much simpler and more efficient protocol which is connection less by design... but this will be taken elsewhere.( Also, note that there is an RFC or ID on a way to use TLS in a lightweight hybrid connectionless protocol that sits between UDP and TCP. I think it was by Eric Rescorla, but I can't recall for sure. )
5 Conclusions and Recommendations
I think the most important thing to come out of this is the placing of the user as the pre-eminient authenticator of local browser-cached info. Whether it be LCAs, logos, petnames, CAs, SSCs, or "My bank" icons, the user is the one that sets up the primary trust record.
Agree!
It works against most phishers, i.e. ones that cannot intercept traffic (`spoofing` or `random client` adversary models, rather than `intercepting adversary` model). Quite useful, therefore.5.3 - 4. Use cookies to personalize the main web page of each customer, e.g. include personal greeting by name and/or by a personalized mark/picture (e.g. see [PM04]). Also, warn users against using the page if the personal greeting is absent. This will foil many of the phishing attacks, which will be unable to present personalized pages.
Curious ... does that work? Can a phisher get access to a cookie? I've never thought about it.
5.3 On the secure client requirement
Yes, this is inevitable. We've crossed that rubicon in the last few months. But I don't think we should stop work on securing the browser for that. It has to be treated as "not our problem" but an important limitation notwithstanding.
_______________________________________________ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
