Re: Client Certificate UI for Chrome?

2009-09-09 Thread James A. Donald

Steven Bellovin wrote:
Several other people made similar suggestions.  They all boil down to 
the same thing, IMO -- assume that the user will recognize something 
distinctive or know to do something special for special sites like 
banks. 


Not if he only does it for special sites like banks, but if something 
special is pretty widely used, he will notice when things are different.


Peter, I'm not sure what you mean by good enough to satisfy security 
geeks vs. good enough for most purposes.  I'm not looking for 
theoretically good enough, for any value of theory; my metric -- as a 
card-carrying security geek -- is precisely good enough for most 
purposes.  A review of user studies of many different distinctive 
markers, from yellow URL bars to green partial-URL bars to special 
pictures to you-name-it shows that users either never notice the 
*absence* of the distinctive feature


I never thought that funny colored url bars for banks would help, and 
ridiculed that suggestion when it was first made, and said it was merely 
an effort to get more money for CAs, and not a serious security proposal


The fact that obviously stupid and ineffectual methods have failed is 
not evidence that better methods would also fail.


Seems to me that you are making the argument We have tried everything 
that might increase CA revenues, and none of it has improved user 
security, so obviously user security cannot be improved.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-09-09 Thread Steven M. Bellovin
On Wed, 09 Sep 2009 15:42:34 +1000
James A. Donald jam...@echeque.com wrote:

 Steven Bellovin wrote:
  Several other people made similar suggestions.  They all boil down
  to the same thing, IMO -- assume that the user will recognize
  something distinctive or know to do something special for special
  sites like banks. 
 
 Not if he only does it for special sites like banks, but if
 something special is pretty widely used, he will notice when things
 are different.

We conducted a small-scale controlled user study -- it didn't work.
 
  Peter, I'm not sure what you mean by good enough to satisfy
  security geeks vs. good enough for most purposes.  I'm not
  looking for theoretically good enough, for any value of theory;
  my metric -- as a card-carrying security geek -- is precisely good
  enough for most purposes.  A review of user studies of many
  different distinctive markers, from yellow URL bars to green
  partial-URL bars to special pictures to you-name-it shows that
  users either never notice the *absence* of the distinctive feature
 
 I never thought that funny colored url bars for banks would help, and 
 ridiculed that suggestion when it was first made, and said it was
 merely an effort to get more money for CAs, and not a serious
 security proposal
 
 The fact that obviously stupid and ineffectual methods have failed is 
 not evidence that better methods would also fail.
 
 Seems to me that you are making the argument We have tried
 everything that might increase CA revenues, and none of it has
 improved user security, so obviously user security cannot be
 improved.
 
Not quite.  I'm not saying it cannot be improved.  I'm saying that
controlled studies thus far have demonstrated none of the proposed
methods have worked, against fairly straight-forward new attacks.  And
if we've learned one thing over the last ten years, it's that the
attackers are as good as we are at what they do.  There's money to be
made and the market has worked its wonders: there is a demand for
capable hackers, and they're making enough money to attract good people.

What I am saying is twofold.  First -- when you invent a new scheme,
do a scientific test: does it actually help?  Don't assume that because
pure reason tells you it's a good idea, it actually is in the real
world.  Second -- you may very well be right that tinkering with the
password entry mechanisms cannot succeed, because users are habituated
to many different mechanisms and to login screens that regularly change
because some VP in charge of publicity has decided that the site's web
presence looks old-fashioned and needs to be freshened.  In that case,
we have to look at entirely different approaches.  (How many different
experiments will it take to convince people that you can't make gold by
mixing chemicals together?)


--Steve Bellovin, http://www.cs.columbia.edu/~smb

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-09-08 Thread Nicolas Williams
On Thu, Sep 03, 2009 at 04:26:30PM +1200, Peter Gutmann wrote:
 Steven Bellovin s...@cs.columbia.edu writes:
 This returns us to the previously-unsolved UI problem: how -- with today's
 users, and with something more or less like today's browsers since that's
 what today's users know -- can a spoof-proof password prompt be presented?
 
 Good enough to satisfy security geeks, no, because no measure you take will
 ever be good enough.  [...]

Well, if you're willing to reserve screen real estate, keyboard key
combinations, and so on, with said reserved screen space used to
indicate unambiguously the nature of other things displayed, and
reserved input combinations used to trigger trusted software paths, then
yes, you can solve that problem.  That's the premise of trusted
desktops, at any rate.  There are caveats, like just how large the TCB
becomes (including parts of the browser), the complexity of the trusted
information to be presented to users versus the limited amount of screen
real estate available to convey it, the need to train users to
understand the concept of trusted desktops, no fullscreen apps can be
allowed, accessibility issues, it all falls apart if the TCB is
compromised, ...

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-09-08 Thread Peter Gutmann
Ian G i...@systemics.com writes:

If one is trying to solve the whole thing, then using the much-commented
secure-bookmarks model would do this.  Within the secure bookmark, record the
user's certificate and cache enough info on the server's cert to deal with
replacements (like, cert, name, CA).

There's a variant of this, the site-specific browser (SSB), that takes you to
(for example) your bank in a strongly sandboxed, hardened environment.  This
reduces the cognitive load on the user from a more or less impossible-to-
follow set of instructions to only ever do your banking by clicking on this
desktop icon.  This isn't by any means a general solution, but by solving for
the most common cases (your bank, Paypal, eBay, Amazon) you'd address a fairly
large chunk of the problem.  See Breaking out of the Browser to Defend
Against Phishing Attacks by Smetters and Stewart for more details on this.

Others have suggested some ideas, so I'll just add:  the problem isn't IMO
how to do it.  There are lots of good ideas.

Actually that does point out one problem, which I alluded to in my previous 
post: we have lots and lots of good ideas, but little hard data to indicate 
which ones will work and which won't, or which ones work better than others 
(although the cynical response to this might be that almost anything would 
work better than what we've got now).  Specifically, there are a pile of 
papers along the lines of here's an experiment showing that what we're doing 
now doesn't work, here's a completely new security mechanism we've invented 
that involves redesigning the browser and server authentication back-end, and 
as a side-effect here are some UI ideas to go with it.  What we don't have 
however is here's a real-world evaluation of various ideas that have been 
proposed for fixing what we already have built into browsers and servers. 
Unfortunately without this data we (including myself) are to some extent just 
people wanking around with their opinions [0].

It's also not certain how such data would be published.  Which journal or
conference would accept a paper with no new ideas in it, just a
straightforward evaluation of existing material?

Peter.

[0] A Linus quote, brought about by a discussion on the difference between OS
secheduler design and security design: the *discussion* on security seems to
never get down to real numbers. So the difference between them is simple: one
is 'hard science'. The other one is 'people wanking around with their
opinions'.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-09-08 Thread Steven Bellovin


On Sep 3, 2009, at 12:26 AM, Peter Gutmann wrote:


Steven Bellovin s...@cs.columbia.edu writes:

This returns us to the previously-unsolved UI problem: how -- with  
today's
users, and with something more or less like today's browsers since  
that's
what today's users know -- can a spoof-proof password prompt be  
presented?


Good enough to satisfy security geeks, no, because no measure you  
take will
ever be good enough.  However if you want something that's good  
enough for
most purposes then Camino has been doing something pretty close to  
this since
it was first released (I'm not aware of any other browser that's  
even tried).
When you're asked for credentials, the dialog rolls down out of the  
browser
title bar in a hard-to-describe scrolling motion a bit like a  
supermarket till
printout.  In other words instead of a random popup appearing in  
front of you
from who knows what source and asking for a password, you've got a  
direct
visual link to the thing that the credentials are being requested  
for.  You
can obviously pepper and salt this as required (and I wouldn't dream  
of
deploying something like this without getting UI folks to comment  
and test it
on real users first), but doing this is a tractable UI design issue  
and not an

intractable business-model/political/social/etc problem.



Several other people made similar suggestions.  They all boil down to  
the same thing, IMO -- assume that the user will recognize something  
distinctive or know to do something special for special sites like  
banks.  Both, to me, are unproven assumptions.  Worse yet, both the  
security literature and what I've seen of user behavior strongly  
suggest to me that neither scenario is true.


Peter, I'm not sure what you mean by good enough to satisfy security  
geeks vs. good enough for most purposes.  I'm not looking for  
theoretically good enough, for any value of theory; my metric -- as  
a card-carrying security geek -- is precisely good enough for most  
purposes.  A review of user studies of many different distinctive  
markers, from yellow URL bars to green partial-URL bars to special  
pictures to you-name-it shows that users either never notice the  
*absence* of the distinctive feature or are fooled by a tailored  
attack (see, e.g., the paper on picture-in-picture attacks).  Maybe  
Camino is really better -- or maybe it just hasn't been properly  
attacked yet, say by a clever flash animation or some AJAX weirdness.   
Given the failure of all previous attempts -- who, amongst the  
proponents of EV certificates, realized that attackers could and would  
use all-green favicon.ico files to fool users -- I think the burden of  
proof is on the proponents.


--Steve Bellovin, http://www.cs.columbia.edu/~smb





-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-09-08 Thread Peter Gutmann
Steven Bellovin s...@cs.columbia.edu writes:

Peter, I'm not sure what you mean by good enough to satisfy security geeks
vs. good enough for most purposes.  I'm not looking for theoretically good
enough, for any value of theory; my metric -- as a card-carrying security
geek -- is precisely good enough for most purposes.

Here's a real-world example of the problem I was referring to, from a
discussion with some browser developers.  We were going over the above issue -
how to use the results of usability studies to improve the browser security UI
- and I asked why, if they were aware of this work, no-one had done anything
with it.  The response was that if we implement this then attackers will use
XUL to spoof it, and because of that it's not even worth trying.  In other
words because a hypoethetical weakness existed, it wasn't even worth
attempting to improve anything.  Instead of trying to help at least some of
the people some of the time, it was better to leave everyone unprotected all
of the time.

Given the failure of all previous attempts -- who, amongst the proponents of
EV certificates, realized that attackers could and would use all-green
favicon.ico files to fool users -- I think the burden of proof is on the
proponents.

But the problem with these approaches is that they're pretty much all just
random tweaking of the same thing, aimlessly rearranging the UI elements in
the hope that eventually something will work after (as you point out) the
twenty more or less identical previous attempts have failed.  For example the
Firefox password-entry mechanism (a generic popup dialog with a gibberish
title) hasn't changed in at least ten years (possibly even longer, I can't
remember what the Netscape 2.0 one looked like any more), all that's changed
is that every major release a few new bits of flair get added to the browser
chrome.  The previous attempts aren't lots of different approaches, it's the
same failed approach tried over and over and over again, with slight
variations over time in the hope that one of them might work.

What I was advocating was trying new approaches based on ideas from UI
research, not just fiddling with the chrome in the hope that this time it'll
finally start working.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-09-08 Thread Jerry Leichter

On Sep 3, 2009, at 12:26 AM, Peter Gutmann wrote:
This returns us to the previously-unsolved UI problem: how -- with  
today's
users, and with something more or less like today's browsers since  
that's
what today's users know -- can a spoof-proof password prompt be  
presented?


Good enough to satisfy security geeks, no, because no measure you  
take will
ever be good enough.  However if you want something that's good  
enough for
most purposes then Camino has been doing something pretty close to  
this since
it was first released (I'm not aware of any other browser that's  
even tried).
When you're asked for credentials, the dialog rolls down out of the  
browser
title bar in a hard-to-describe scrolling motion a bit like a  
supermarket till printout
I'm not sure what version of Camino you're running.  The most recent  
versions use a standard Mac OS GUI element to prompt for passwords -  
it's indistinguishable from what you get from Safari.  In both cases,  
a special prompt window scrolls down out of the chrome, covering some  
of the main body of the window.  It has a distinctive look:  After  
it's scrolled down, it appears to be under the chrome but over the  
top of the body.  In Safari - I didn't experiment with Camino - it's  
physically tied to the browser window, moving and iconifying with it,  
and is fully modal at the window level - you can't switch to another  
tab in the same window.  (Curiously, you *can* switch to a different  
window.)  The loading indicator in the address bar remains active  
while you're being prompted.  The *intent* is clearly to create  
something hard to spoof, but I don't know enough Flash to say if one  
could produce an accurate, or even plausible, fake.  (Of course,  
*most* passwords on the Web are entered into some random web page.  A  
distinctive secure prompt that only appears in a minority of cases  
doesn't help much.)


The most common MacOS password prompts are from the keychain program,  
since you typically store your passwords there.  (There are  
configurations in which it just asks for permission, not for a  
password; and configurations in which it just sends the password.  But  
if you want to be careful, you only want keychains unlocked when you  
intend to use them.)  Since *any* program - including programs with no  
visible GUI - can use keychains, these prompts are necessarily stand- 
alone windows at least sometimes (and for uniformity, they are so all  
the time).  Those could be spoofed more easily (though if you're  
really cautious, you can unlock the necessary keychain by hand ahead  
of time and arrange to just give permission to use the entry later, so  
you're never entering your password into a window that just pops up on  
its own).


-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-09-08 Thread Jerry Leichter

On Sep 7, 2009, at 8:58 AM, Jerry Leichter wrote:

...standard Mac OS GUI element to prompt for passwords ...
I should expand on that a bit:  This GUI element is used for all kinds  
of things tied to a window, not just passwords.  For example, if you  
try to close a window that contains stuff you haven't saved, the same  
element is used to ask you to confirm, save now, or cancel.  So it's a  
pretty familiar thing to Mac users

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-09-04 Thread Steven Bellovin


On Aug 26, 2009, at 6:26 AM, Ben Laurie wrote:

On Mon, Aug 10, 2009 at 6:35 PM, Peter Gutmannpgut...@cs.auckland.ac.nz 
 wrote:
More generally, I can't see that implementing client-side certs  
gives you much
of anything in return for the massive amount of effort required  
because the
problem is a lack of server auth, not of client auth.  If I'm a  
phisher then I
set up my bogus web site, get the user's certificate-based client  
auth
message, throw it away, and report successful auth to the client.   
The browser
then displays some sort of indicator that the high-security  
certificate auth
was successful, and the user can feel more confident than usual in  
entering
their credit card details.  All you're doing is building even more  
substrate

for phishing attacks.

Without simultaneous mutual auth, which -SRP/-PSK provide but PKI  
doesn't,
you're not getting any improvement, and potentially just making  
things worse

by giving users a false sense of security.


I certainly agree that if the problem you are trying to solve is
server authentication, then client certs don't get you very far. I
find it hard to feel very surprised by this conclusion.

If the problem you are trying to solve is client authentication then
client certs have some obvious value.

That said, I do tend to agree that mutual auth is also a good avenue
to pursue, and the UI you describe fits right in with Chrome's UI in
other areas. Perhaps I'll give it a try.



This returns us to the previously-unsolved UI problem: how -- with  
today's users, and with something more or less like today's browsers  
since that's what today's users know -- can a spoof-proof password  
prompt be presented?


--Steve Bellovin, http://www.cs.columbia.edu/~smb





-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-09-04 Thread James A. Donald

Steven Bellovin wrote:
This returns us to the previously-unsolved UI problem: how -- with 
today's users, and with something more or less like today's browsers 
since that's what today's users know -- can a spoof-proof password 
prompt be presented?


When the user clicks on a button generated by a particular special kind 
of html tag, perhaps
loginbutton logintype=SRP 
loginurl=/customers/loginpage.scriptlogin/loginbutton


A not quite rectangular login form which is not an html page rolls out 
of the url, with a motion like a blind or toilet paper unrolling, and 
partially covers the browser chrome, thus associating the form  with the 
browser and the url, rather than the web page.


The form will be decorated and prominently watermarked in manner that is 
customizable by the end user, and if the end user does not customize it, 
which he probably will not, a customization was randomly selected at 
install time.


A phisher could do a flash animation that looks almost like the form 
rolling out, but the flash animation will not roll out of the url, and 
will not partially cover the browser chrome, and is unlikely to match 
the customization.


If the url is http://exampledomain.com/somedirectory/somepage.html

Then the content of the login form is controlled by script at 
login://exampledomain.com//customers/loginpage.script


The login form will be associated with a public key.  If the user has 
logged in before using this browser, there will be an entry in his 
bookmarks list for the url *and* public key


If the login form is the browser's bookmark list, the title on the login 
form will be the petname, that is to say, the name under which it 
appears in the bookmark list.


If the login form is *not* in the browser's bookmark list, the title on 
the login form will be No Previous Login at this site using this 
browser by this user, with script supplied title and or certificate 
supplied title somewhere else in smaller print.


The loginpage.script will tell the browser what fields and fieldnames to 
request from the user - typically username and password, but this needs 
to be scriptable - for example it could be credit card number, etc.  The 
script will tell the server what database table and what database fields 
to associate these user supplied fields with when the client responds.


Peter Gutmann has, he believes, a much simpler solution.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-09-04 Thread Peter Gutmann
Steven Bellovin s...@cs.columbia.edu writes:

This returns us to the previously-unsolved UI problem: how -- with today's
users, and with something more or less like today's browsers since that's
what today's users know -- can a spoof-proof password prompt be presented?

Good enough to satisfy security geeks, no, because no measure you take will
ever be good enough.  However if you want something that's good enough for
most purposes then Camino has been doing something pretty close to this since
it was first released (I'm not aware of any other browser that's even tried).
When you're asked for credentials, the dialog rolls down out of the browser
title bar in a hard-to-describe scrolling motion a bit like a supermarket till
printout.  In other words instead of a random popup appearing in front of you
from who knows what source and asking for a password, you've got a direct
visual link to the thing that the credentials are being requested for.  You
can obviously pepper and salt this as required (and I wouldn't dream of
deploying something like this without getting UI folks to comment and test it
on real users first), but doing this is a tractable UI design issue and not an
intractable business-model/political/social/etc problem.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-26 Thread Ben Laurie
On Mon, Aug 10, 2009 at 6:35 PM, Peter Gutmannpgut...@cs.auckland.ac.nz wrote:
 More generally, I can't see that implementing client-side certs gives you much
 of anything in return for the massive amount of effort required because the
 problem is a lack of server auth, not of client auth.  If I'm a phisher then I
 set up my bogus web site, get the user's certificate-based client auth
 message, throw it away, and report successful auth to the client.  The browser
 then displays some sort of indicator that the high-security certificate auth
 was successful, and the user can feel more confident than usual in entering
 their credit card details.  All you're doing is building even more substrate
 for phishing attacks.

 Without simultaneous mutual auth, which -SRP/-PSK provide but PKI doesn't,
 you're not getting any improvement, and potentially just making things worse
 by giving users a false sense of security.

I certainly agree that if the problem you are trying to solve is
server authentication, then client certs don't get you very far. I
find it hard to feel very surprised by this conclusion.

If the problem you are trying to solve is client authentication then
client certs have some obvious value.

That said, I do tend to agree that mutual auth is also a good avenue
to pursue, and the UI you describe fits right in with Chrome's UI in
other areas. Perhaps I'll give it a try.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome? [OT anonymous-transaction bull***t]

2009-08-21 Thread Ray Dillinger
[Moderator's note: this is getting a bit off topic, and I'd prefer to
limit followups. --Perry]

On Wed, 2009-08-19 at 06:23 +1000, James A. Donald wrote:
 Ray Dillinger wrote:

  If there is not an existing relationship (first time someone 
  uses an e-tailer) then there has to be a key depository that 
  both can authenticate to, with a token authorizing their 
  authentication to authenticate them to the other, which then 
  vouches to each for the identity of the other.  
 
 Actually not.
 
 What the seller wants to know is that the buyer's money is good, not 
 what the true name of the buyer is - a service provided by Visa, or 
 Web-money, or some such.

No.  This juvenile fantasy is complete and utter nonsense, and 
I've heard people repeating it to each other far too often.  If 
you repeat it to each other too often you run the risk of starting
to believe it, and it will only get you in trouble.  This is a 
world that has not just cryptographic protocols but also laws 
and rules and a society into which those protocols must fit.  That 
stuff doesn't all go away just because some fantasy-world 
conception of the future of commerce as unlinkable anonymous
transactions says it should.  

In any transaction involving physical goods, the seller also wants 
to know to whom to ship the product.  Since the laws in most nations 
do not require the recipient of an erroneous shipment to return 
the goods and *do* require the seller to give back the buyer's money
if the shipment doesn't go where the buyer wants it, sellers really 
care that the correct recipient will receive the package and really 
need some way to contact the buyer in case there's a mistake about 
the recipient address or identity.  Otherwise you'd get people 
playing silly buggers with the shipping address to get out of paying 
for million-dollar equipment.

The law usually requires that the recipient of defective goods 
or services has the ability to return those goods for a refund 
or obtain a refund in the event of seller nonperformance of 
services or nonshipment of goods.  Since such returns can be 
used to launder money from illegal enterprises, laws usually 
restrict anonymous returns. Therefore the seller needs the 
buyer's (or client's) identity in order to comply with the law.

In information-based transactions involving IP that's subject 
to copyright or trade secret protection (which is effectively 
all of them since other IP can be had for free) the seller also 
wants to know who is the licensee that's bound by the terms 
of the license and who now poses a risk of copyright breakage.  
In both cases this is a liability taken on by the buyer, and 
not something that his money being good for just the 
transaction price can ameliorate.

In financial transactions The seller also wants to know that s/he 
can comply with, eg, know your customer laws and avoid liability
for gross negligence in, eg, money laundering cases.  

In many transactions the seller wants the buyer's identity and a 
liability waiver signed by the buyer so as to keep track of or 
avoid liability for what the customer is going to do with his/her
products.  

Most sellers want the ability to offer the buyer credit terms,
especially when large sums are involved.  And even where money 
is supposedly firm (like the money Bernie Madoff's clients had 
in their accounts) it is subject to catastrophic vanishment in
extraordinary circumstances.  The seller needs to know whom to 
sue or at least whose name to put on the forms for their insurance 
claim if contrary to expectations the buyer's money turns out not 
to be good.

If the cert authority does not provide the identity of the buyer 
but asserts that the buyer's money is good, and this turns out not 
to be true (as in the case of Madoff's clients), then in most 
legal systems the cert authority is either liable, or can expect 
to be sued in a very expensive empirical test of liability.  So 
the cert authority doesn't want to be in the business of vouching 
for the ability of anonymous people to pay.  

The only way for the money to be truly firm for these purposes 
is that the cert authority has it in escrow.  This makes the 
cert authority a financial institution and therefore subject to 
know your customer mandatory reporting, data retention laws,
subpeonas, and so on.  Also, it introduces a needless delay 
and complication to the transaction that legitimate buyers and 
sellers would mostly rather not have. 

Also, in any large transaction the seller or cert authority or both 
must retain buyer identity information in order to be able to 
comply with subpeonas, inquests, or equivalent writs, for 
periods ranging from zero in a few undeveloped african nations to 
five years in much of the rest of the world. 

In most of the nations on earth, there is such a thing as sales 
tax or use tax on goods or services, and any transaction involving
more than a tiny sum must be reported (with the names of buyer and
seller) to 

Re: Client Certificate UI for Chrome? -- OT anonymous-transaction

2009-08-21 Thread Anne Lynn Wheeler

On 08/20/09 00:11, Ray Dillinger wrote:

No.  This juvenile fantasy is complete and utter nonsense, and
I've heard people repeating it to each other far too often.  If
you repeat it to each other too often you run the risk of starting
to believe it, and it will only get you in trouble.  This is a
world that has not just cryptographic protocols but also laws
and rules and a society into which those protocols must fit.  That
stuff doesn't all go away just because some fantasy-world
conception of the future of commerce as unlinkable anonymous
transactions says it should.


most of the financial industry digital certificate specifications
were relying party only digital  certificates ... effectively only
containing an account number ... because of privacy (both in us and
europe) and liability issues. some of this was also about the time
that EU-DPD made statements that electronic retail transactions
should be w/o names (i.e. remove person names from payment cards
... also a form of relying party only instrument).

this somewhat side-stepped whether it was linkable or not ...
since it then was back at the financial institution whether
the account number was linked to a person or anonymous ... but
did meet privacy requirements for retail payments  depending
on gov.  financial institution with regard to any possible
know your customer mandates ... a court order to the
financial institution  had the potential of revealing any linkage

There were a couple issues:

1) even as a relying-party-only digital certificate ... the digital
certificate gorp resulted on the order of 100 times payload bloat for typical
payment transaction payload size. there were two approaches a) strip the
digital certificate off the payment transaction as early as possible
to minimize the onerous payload penalty; b) financial standards looked
at doing compressed relying-party-only digital certificates ... possibly
getting the payload bloat down to only a factor of ten times (instead of
one hundred times).

2) it was trivial to show that the issuing financial institution
already had a superset of information carried in the relying-party-only
digital certificate ... so it was redundant and superfluous to repeatedly
send such a digital certificate back to the issuing financial institution
appended to every payment transactions (completely redundant and superfluous
was separate issue from representing factor of 100 times payload bloat).

so there were two possible solutions to the enormous payload bloat

a) just digital sign the transaction and not bother to append
the redundant and superfluous relying party only certificate

b) the standards work on compression included eliminating fields
that the issuing financial institution already possessed ... since
it was possible to demonstrate that the issuing financial institution
had a superset of all information in a relying-party-only digital
certificate ... it was possible to compress the size of the
digital certificate to zero bytes. then it was possible to mandate
that zero byte digital certificates be appended to every payment
transaction (also addressing the enormous payload bloat problem).

the x9.59 financial transaction standard ... some refs
http://www.garlic.com/~lynn/x959.html#x959

just specified requirement for every payment transaction
to be authenticated ... and didn't really care whether there was
no digital certificate appended ... or whether it was
mandated that zero-byte digital certificates were appended.

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-18 Thread James A. Donald

James A. Donald jam...@echeque.com writes:

[Incredibly complicated description of web scripting plumbing deleted]


Peter Gutmann wrote:

We seem to be talking about competely different things here.  For a typical
application, say online banking, I connect to my bank at www.bank.com or
whatever, the browser requests my credential information, and the TLS-SRP or
TLS-PSK channel is established. That's all.  There's no web application
framework and PHP and scripting and other stuff at all, in fact I can't even
see how you'd inject this into the process.


I cannot see how you could create a bank web page without a web 
application framework (counting mod-php as a very primitive web 
application framework) and scripting and a database, which scripting and 
database has to know who it is is that logged in - which is indeed a 
great deal of complicated plumbing to ensure that the script knows at 
script execution time, *after* the connection has been made, which user, 
which database primary key, is connected.  The information about which 
user, which database primary key is logged in, has to be passed up 
through one layer after another and from one process to another.  The 
toe bone is connected to foot bone, the foot bone is connected to the 
ankle bone, the ankle bone is connected ... The plumbing really is that 
complicated.



Further, if we do the SRP dance every single page, it is a huge performance
hit, with many additional round trips. One loses about 20 percent of one's
market share for each additional round trip.



You only do it once when the TLS session is set up, it's exactly as for
standard TLS except that instead of PKI-based non-authentication you use
cryptographic mutual authentication.  How do you get an SRP exchange for every
web page?


Because keep-alive usually fails for plumbing reasons, standard TLS 
usually does the PKI-based non-authentication dance every page, 
resulting in additional round trips, resulting in painfully bad 
performance for SSL web sites such as 
https://www.cia.gov/library/publications/the-world-factbook/



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-18 Thread Peter Gutmann
James A. Donald jam...@echeque.com writes:

I cannot see how you could create a bank web page without a web application
framework (counting mod-php as a very primitive web application framework)
and scripting and a database, which scripting and database has to know who it
is is that logged in

We really are talking about completely different things here.  The scripting
and whatnot has nothing to do with TLS or TLS auth mechanisms.  The only thing
you need to care about (if you really want to go this way) is channel binding.

The information about which user, which database primary key is logged in,
has to be passed up through one layer after another and from one process to
another.

Yeah, and that's what channel binding is for.

The plumbing really is that complicated.

Only if you deliberately choose to make it so.  Read the RFCs I mentioned
earlier.

Because keep-alive usually fails for plumbing reasons, standard TLS usually
does the PKI-based non-authentication dance every page, resulting in
additional round trips, resulting in painfully bad performance for SSL web
sites

But TLS doesn't work like that.  If it did, you'd get a cert popup every time
you clicked on a link on a TLS-protected web site.  Unless you somehow manage
to flush the TLS session cache on the server (which seems unlikely unless
you're DoS'ing it) there's no additional round-trip(s), or additional anything
for that matter.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-16 Thread Peter Gutmann
James A. Donald jam...@echeque.com writes:

[Incredibly complicated description of web scripting plumbing deleted]

We seem to be talking about competely different things here.  For a typical
application, say online banking, I connect to my bank at www.bank.com or
whatever, the browser requests my credential information, and the TLS-SRP or
TLS-PSK channel is established. That's all.  There's no web application
framework and PHP and scripting and other stuff at all, in fact I can't even
see how you'd inject this into the process.

Further, if we do the SRP dance every single page, it is a huge performance
hit, with many additional round trips. One loses about 20 percent of one's
market share for each additional round trip.

You only do it once when the TLS session is set up, it's exactly as for
standard TLS except that instead of PKI-based non-authentication you use
cryptographic mutual authentication.  How do you get an SRP exchange for every
web page?

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-13 Thread Wes Felter

James A. Donald wrote:


For password-authenticated key agreement such as TLS-SRP
or TLS-PSK to work, login has to be in the chrome.


Regrettably, login in the (non-customizable) chrome is unusable; this is 
why *everyone* now uses cookies instead of HTTP authentication. Just 
asking the user for a username instead of an email address can trip them up.


SSL has a worse problem AFAIK, which is that the server either always 
asks for a client cert (before the login page) or never asks, but I 
think we want to show a login page over SSL, *then* ask the user for 
their cert or password.


Despite its complexity, I'm thinking that something like infocards -- 
where some HTML tag or JS API can trigger the browser to perform secure 
authentication with an unspoofable UI -- is the way to go.


Wes Felter

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


RE: Client Certificate UI for Chrome?

2009-08-12 Thread Thomas Hardjono



 
 From: James A. Donald [jam...@echeque.com]
 Sent: Sunday, August 09, 2009 1:21 AM
 To: Thomas Hardjono
 Cc: Ben Laurie; Cryptography
 Subject: Re: Client Certificate UI for Chrome?

 Thomas Hardjono wrote:
   In this UI discussion, I think its less relevant
   whether trust is hierarchical or flat/p2p.

 The hard part is always certificate management, which
 has to be launched off existing trust and connections.

 So the question is, do we have certificate management
 that assumes that everyone has boundless trust in
 Verisign, and no trust in existing connections and
 existing shared knowledge, or do we have certificate
 management designed make use of any existing
 connections, trust, and shared knowledge, wherever it is
 to be found?

[bottom-posted]

Agree. Unfortunately (or fortunately) some browsers have
shipped with root CA certs for a number of years
 now, which does force the end-user to trust the CA.
This has been great for sales of SSL certs for VeriSign
and other CAs but there is still that fundamental problem
of educating the average user (Mom/Dad) about equating
trust with certs (or root CA certs).=20

I'm not sure if the Chrome folks would be prepared
to ship their browser without any CA certs loaded,
but that would be an interesting and perhaps even revolutionary idea.
Assuming the Chrome UI had a nice and easy way for users
to download and install certs (trust anchors), this
approach could level the playing field and allows
other modes of trust to be played-out.
Both LinkedIn and FaceBook could in fact be CAs
that issue certs based on the number of verified
connections that a person had.

/thomas/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-12 Thread James A. Donald

Thomas Hardjono wrote:
 I'm not sure if the Chrome folks would be prepared to
 ship their browser without any CA certs loaded,

Excessive distrust is inconvenient, excessive trust is
vulnerable.  It is better to remedy flaws by expanding
functionality rather than restricting it.

On the one hand, something like Verisign is very useful
to signify that an entity that calls itself a bank is in
fact regarded as a bank by governments and other major
banks, on the other hand, it is pretty useless for
designating membership of a group to other members of
the group, which is the major function of client side
certificates.

The number of globally important entities is necessarily
small, therefore a global namespace of globally unique
human memorable names, (such as Bank Of America) works
well for them.   The number of entities that have or
need keys is quite large, therefore Zooko's triangle
applies - globally unique human memorable names work
very badly for the vast majority of keyholders,
therefore a business whose job is enforcing global
uniqueness of human memorable names (such as Verisign)
is going to be a pain to deal with, for it is trying to
do something that really cannot be done, therefore in
practice will merely make it sufficiently difficult for
clients that scammers do not bother.

Even for banks, globally unique names are problematic.
A remarkably large number of banks are called something
National Bank, or First National Bank of something.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-12 Thread James A. Donald

James A. Donald jam...@echeque.com writes:
  [In order to implement strong password based
  encryption and authentication] on the server side,
  we need a request object in the script language that
  tells the script that this request comes from an
  entity that established a secure connection using
  shared secrets associated with such and such a
  database record entered in response to such and such
  a web page

Peter Gutmann wrote:
 Ah, that is a good point, you now need the credential
 information present at the TLS level rather than the
 tunneled-protocol level (and a variation of this,
 although I think one that way overcomplicates things
 because it starts diverting into protocol redesign, is
 the channel binding problem (see RFC 5056 and,
 specific to TLS,
 draft-altman-tls-channel-bindings-05.txt)).  On the
 other hand is this really such an insurmountable
 obstable?

Consider what would be involved in building the UI into
the Google browser, and also building the necessary
scripting support into Web2Py on Google App Engine.  It
is not a small job.

 I don't really see why you'd need complex scripting
 interfaces though, just return the shared-secret
 value associated with this ID in response to a
 request from the TLS layer.

This request is issued when the connection is being
established, before the URL is specified.  So it is
impossible to service that request from the script that
generates the web page.   So where are we servicing that
request?  Presumably, need to service it somewhere
within the Web Application Framework, for example within
Mod PHP or Web2Py.

Further, some applications, for example banks and share
registries, typically have several different ID tables
at a single domain, and several different kinds of
shared human memorable secret information associated
with each ID.

And, having established that association, then when the
URL is specified, and the script associated that URL is
finally invoked by the Web Application Framework, then
that script needs to be invoked with the relevant ID, or
better, the script then needs to be provided with a
database cursor pointing at the relevant ID.

Further, if we do the SRP dance every single page, it is
a huge performance hit, with many additional round
trips. One loses about 20 percent of one's market share
for each additional round trip.

So we only want to do the SRP dance on session
establishment, only want to do it once per human
session, once per logon, not once per TLS session.

Which means that the TLS layer has to cache the the
transient strong shared secret constructed from the weak
durable human memorable secret for the duration of the
Web Application Framework's logon and logoff and provide
the cached database cursor to the web page script at
every page request during a single logon session, which
requires a higher level of integration between TLS and
the Web Application Framework than either one was
originally designed for.

Which means a significant amount of work integrating
this stuff with any given web application framework.

Further, suppose, as is typical with banks, a given
domain name hosts multiple ID tables each with different
kinds of shared secret information.  In that case, we
can obtain multiple different kinds of SRP logons, each
relevant to certain web pages but not others, each with
different privilege levels, and the framework has to
enforce that, has to provide to each web page
information about the logon type, and ensure that
inappropriate web pages are never invoked at all, but
are 403ed when the user attempts to access a url through
a logon of inappropriate type.

We cannot rely on the server side web page script to 403
itself in response to inappropriate logon type, since
when a new kind of logon was introduced, no one would
ever go back and make sure that all the old web pages
correctly checked the logon type.  If the web page
script contains a line of code that says If such and
such, then do a 403,

then sooner or later someone will delete that code and
say Hey, it still works just fine..

This is starting to sound depressingly like a great deal
of work rewriting lots of complex, bugridden stuff in
web application frameworks that are already designed to
handle logons in a quite different way.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-11 Thread Peter Gutmann
James A. Donald jam...@echeque.com writes:

For password-authenticated key agreement such as TLS-SRP or TLS-PSK to work, 
login has to be in the chrome.

Sure, but that's a relatively tractable UI problem (and see the comment below 
on Camino).  Certificates on the other hand are an apparently intractable 
business, commercial, user education, programming, social, and technical 
problem.  I'd much rather try and solve the former than the latter.

The problem with password auth is that no browser (with the exception of 
Camino) has made even the most basic attempt to do the UI for this properly.  
In all cases the browser pops up a dialog box, unconnected to the underlying 
operation or web page, that says Gimme your password in one way or another. 
This could be coming from anywhere, the browser, Javascript on the web page, 
another web page, who knows where, but since everyone knows that passwords are 
insecure there's no point in expending any effort to try and make them 
secure, and that's been the status quo for fifteen years.

What Camino does (and it's been awhile since I played with it, so I'll qualify 
that with what I hope it still does) is roll the password-entry box down out 
of the browser menu bar in a circular motion that's both hard to spoof and 
that unmistakably ties the credential-entry request both to the web page that 
it's associated with and to the browser rather than being some floating popup 
coming from who knows where or what.  This can no doubt be nitpicked, but it's 
better than any other browser (that I've seen) does.

More generally, I can't see that implementing client-side certs gives you much 
of anything in return for the massive amount of effort required because the 
problem is a lack of server auth, not of client auth.  If I'm a phisher then I 
set up my bogus web site, get the user's certificate-based client auth 
message, throw it away, and report successful auth to the client.  The browser 
then displays some sort of indicator that the high-security certificate auth 
was successful, and the user can feel more confident than usual in entering 
their credit card details.  All you're doing is building even more substrate 
for phishing attacks.

Without simultaneous mutual auth, which -SRP/-PSK provide but PKI doesn't, 
you're not getting any improvement, and potentially just making things worse 
by giving users a false sense of security.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-11 Thread James A. Donald

--
 James A. Donald jam...@echeque.com writes:
 For password-authenticated key agreement such as
 TLS-SRP or TLS-PSK to work, login has to be in the
 chrome.

Peter Gutmann wrote:
 Sure, but that's a relatively tractable UI problem

Indeed.  You know how to solve it, and I know how to
solve it, yet the solution is not out there.

As you say, shared secrets should be entered a form that
implements password-authenticated key agreement such as
TLS-SRP or TLS-PSK, that cannot easily be spoofed, that
is clearly associated with the browser and with a
particular url and web page (you suggest that the form
should roll out of the browser bar with an eye catching
motion and land on top of the web page) and an encrypted
connection should be established by that shared
knowledge, which cannot be established without that
shared knowledge.

This, however, requires both client UI software, and an
api to server side scripts such as PHP, Perl, or Python
(the P in LAMP).  On the server side, we need a request
object in the script language that tells the script that
this request comes from an entity that established a
secure connection using shared secrets associated with
such and such a database record entered in response to
such and such a web page, an object to which the script
generating a page can associate data that persists for
the duration of the session - an object that has session
scope rather than page scope, scope longer and broader
than that of the thread of execution that generates the
page, but shorter and narrower than that of the database
record containing the shared secrets, a script
accessible object that can only be associated with one
server, one server side process and one server side
thread at a time.  This is non trivial to implement in
an environment where servers are massively
multithreaded, and often massively multiprocess.

 Certificates on the other hand are an apparently
 intractable business, commercial, user education,
 programming, social, and technical problem.  I'd much
 rather try and solve the former than the latter.

What makes certificates such a problem is that there is
someone in the middle issuing the certificate - usually
someone who does not know or trust either of the
entities trying to establish a trust relationship.

While certificates frequently makes cryptography
unnecessarily painful and complicated, certificate issue
offers the opportunity to make money out of providing
encryption by being that someone in the middle, hence
the remarkable enthusiasm for this technology, and
stubborn efforts to apply it to cases where its value is
limited, and it is far from being the most convenient,
practical, and straightforward solution.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-11 Thread Frank Siebenlist

[Moderator's note: top posting considered harmful:
 http://www.mail-archive.com/cryptography@metzdowd.com/msg09287.html
   --Perry]

Just to complicate things a little... we're working with a number of  
groups now who are using onlineCAs that issue short-lived x509 certs  
derived from a primary authN mechanism like passwords or OTP.


It would be great to bake that functionality into chrome: use TLS-SRP/ 
PSK to authN to an onlineCA to obtain your short-lived cert in real- 
time.


-Frank.


On Aug 6, 2009, at 5:49 AM, Peter Gutmann wrote:


Ben Laurie b...@google.com writes:


So, I've heard many complaints over the years about how the UI for
client certificates sucks. Now's your chance to fix that problem -
we're in the process of thinking about new client cert UI for Chrome,
and welcome any input you might have. Obviously fully-baked proposals
are more likely to get attention than vague suggestions.


This is predicated on the assumption that it's possible to make  
certificates
usable for general users.  All the empirical evidence we have to  
date seems to
point to this not being the case.  Wouldn't it be better to say  
What can we
do to replace certificates with something that works?, for example  
TLS-SRP

or TLS-PSK?

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


---
Frank Siebenlist - fra...@mcs.anl.gov
The Globus Alliance | Argonne National Laboratory | University of  
Chicago


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-11 Thread Peter Gutmann
James A. Donald jam...@echeque.com writes:

This, however, requires both client UI software, and an api to server side
scripts such as PHP, Perl, or Python (the P in LAMP).  On the server side, we
need a request object in the script language that tells the script that this
request comes from an entity that established a secure connection using
shared secrets associated with such and such a database record entered in
response to such and such a web page, an object to which the script
generating a page can associate data that persists for the duration of the
session - an object that has session scope rather than page scope, scope
longer and broader than that of the thread of execution that generates the
page, but shorter and narrower than that of the database record containing
the shared secrets, a script accessible object that can only be associated
with one server, one server side process and one server side thread at a
time. This is non trivial to implement in an environment where servers are
massively multithreaded, and often massively multiprocess.

Ah, that is a good point, you now need the credential information present at
the TLS level rather than the tunneled-protocol level (and a variation of
this, although I think one that way overcomplicates things because it starts
diverting into protocol redesign, is the channel binding problem (see RFC 5056
and, specific to TLS, draft-altman-tls-channel-bindings-05.txt)).  On the
other hand is this really such an insurmountable obstable?  For client-cert
usage you already need to perform a lookup based on a given cert (well, unless
you blindly trust anyone displaying a cert coming from a particular CA or set
of CAs, which I know some sites do), so now all you'd be doing is looking up a
shared-secret value instead of a cert based on a client ID.  I don't really
see why you'd need complex scripting interfaces though, just return the
shared-secret value associated with this ID in response to a request from the
TLS layer.  The only problem I can see is if you have an auth system built
around is this authenticator valid rather than return the authenticator for
this ID.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-09 Thread James A. Donald

Peter Gutmann wrote:
 This is predicated on the assumption that it's
 possible to make certificates usable for general
 users.  All the empirical evidence we have to date
 seems to point to this not being the case.  Wouldn't
 it be better to say What can we do to replace
 certificates with something that works?, for example
 TLS-SRP or TLS-PSK?

For password-authenticated key agreement such as TLS-SRP
or TLS-PSK to work, login has to be in the chrome.

Of course, for certificate distribution to work, we also
need password-authenticated key agreement in the chrome,
for in practice, certificates are distributed via
username and password based logins, making their use
case necessarily small.  No matter what we do with
certificates, have to fix username and password based
logins first.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-09 Thread James A. Donald

Thomas Hardjono wrote:

Having worked at a large CA for along time (trying to push for client-side 
certs with little luck), here are some thoughts on what Chrome could provide:


There are use cases where a centralized authority is useful.
Client side is not one of them.

Typical usage is is this client one of our gang?.
Obviously the CA just gets in the way.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-06 Thread James A. Donald

Ben Laurie wrote:

So, I've heard many complaints over the years about how the UI for
client certificates sucks. Now's your chance to fix that problem -
we're in the process of thinking about new client cert UI for Chrome,
and welcome any input you might have. Obviously fully-baked proposals
are more likely to get attention than vague suggestions.


The fundamental problem with certificates is getting them.

OK, suppose you hit a web site that wants a client side certificate, 
maybe it wants a claimed email address with proof that you can receive 
email at that address, maybe it wants proof you are over 18, maybe it is 
run by the company you work for and wants proof you are an employee and 
wants to know which employee you are.  Maybe it wants evidence that you 
a member in good standing of the committee to slay infidels.


If we suppose your browser *has* such a certificate, and merely needs 
permission from you, the user, to show it, then the problem is 
relatively easy - which however does not stop existing browsers from 
fouling up mightily, perhaps because they are designed around verisign's

business model, rather than anything the user might actually want to
do.

But the problem is much harder, much much harder, if we suppose you do 
*not* have the certificate.


I will ignore the easy problem, because I am sure that anyone worth 
talking to can figure out the solution, even though existing browser 
writers have failed to do so.


OK. Hard Problem:  You the user have hit a website that wants a 
certificate with certain characteristics, and either you do not have it, 
or you have it somewhere, but your browser does not know you have it, 
perhaps because it is on another browser on another computer.


It appears to me that existing solutions to this problem are designed 
around Verisign's business model, rather than user needs.  If a client 
certificate is to identify you to examplecorp as an employee of 
examplecorp, why does Verisign need to get involved?  It's easier for 
examplecorp to issue its own @#$%^ certificates.


So, assuming you are pretty smart, as I know you to be, and assuming 
your boss is not evil and not in Verisign's pocket, which I do not know 
at all ...


So where *would* you have a certificate?  Where would you keep it, and 
what would it look like?


The kind of things that people are used to storing in a browser are 
bookmarks:  Bookmarks have the convenient property that they implement 
Zooko's triangle: petname, nickname, and guid.  They also have the 
property that if you click on them they take you somewhere.  So a 
certificate should act like some kind of smart bookmark and look to the 
user like a smart bookmark,  which if clicked on should bring you to 
your logged in web page with the authority issuing the certificate. 
Your secret key is something like a a secret link or bookmark that 
automatically logs you in to something like your facebook page, and your 
public key is something like a link or bookmark that enables other 
people to view something like your facebook page.  Maybe it is your 
employee page at examplecorp, which shows any records pertaining to you 
in the company database, some of which, such as contact information, are 
editable by you, but most of which are not.


And the something like your facebook page as seen by others is almost 
the same link the live authorization that your certificate is still valid.


So how do you *get* a certificate?  Suppose, for example, your 
certificate identifies you to your company, in which case your boss 
probably gave it to you.  What would he give you? Well, obviously, he 
would give you a username and password, or more likely you would create 
an account, a username and password, which he would then authorize.


Which username and password would I expect enable you to get to that 
logged in web page with the authority issuing the certificate, in this 
case some location on the company web server.  And you get to that web 
page, you would then get an install certificate title dialog, and if 
you accept, get something that looks and acts like a bookmark, though it 
is in fact a company issued certificate, certifying that you are 
username, where username is also a primary key in the company employee 
database.


But the trouble with this, of course, is that usernames and passwords 
can be phished.


The solution to that is password login and account creation in the 
chrome, not in the web page implementing password-authenticated key 
agreement, so that the phisher can gain nothing, so long as the user 
attempting to use the chrome login facilities, rather than html web page 
login facilities.


It should have been obvious that logging in on a user interface provided 
by a web page, provided by html code, was entirely insecure - the 
problem of spoofed logins was well known at the time. So what we
needed, from day one, was a secure login that was in the browser chrome, 
not the web page - and no other form of 

Re: Client Certificate UI for Chrome?

2009-08-06 Thread Peter Gutmann
Ben Laurie b...@google.com writes:

So, I've heard many complaints over the years about how the UI for
client certificates sucks. Now's your chance to fix that problem -
we're in the process of thinking about new client cert UI for Chrome,
and welcome any input you might have. Obviously fully-baked proposals
are more likely to get attention than vague suggestions.

This is predicated on the assumption that it's possible to make certificates 
usable for general users.  All the empirical evidence we have to date seems to 
point to this not being the case.  Wouldn't it be better to say What can we
do to replace certificates with something that works?, for example TLS-SRP
or TLS-PSK?

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-06 Thread Anne Lynn Wheeler

On 08/06/09 07:33, James A. Donald wrote:

The fundamental problem with certificates is getting them.


digital certificate design point supposedly was the dial-up email of the early 
80s,
dial-up, exchange email, hang-up ... and then faced with how to deal with first
time email from complete stranger. basically electronic analog for letters of
credit/introduction from sailing ship days.

in the 90s, because of numerous privacy and liability issues ... there
was some number of relying-party only certificates; individual registered
their public key with the institution, institution then created a digital
certificate with the public key, archived it, and returned a copy to the
individual. the individual, in communication with the institution would
digitally sign the communication and then append the digital certificate.
However, it was trivial to prove that the institution/relying-party already
had a copy of the information ... and the appended digital certificate
was redundant and superfluous. misc. past posts discussion relying-party only
digital certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

furthermore, major foreys into this sector were by financial institutions
for the purpose of payment transactions. a complicating factor ... besides
the digital certificates being redundant and superfluous ... they added
a 100 times payload size bloat to the typical payment transactions. misc.
past posts
http://www.garlic.com/~lynn/subpubkey.html#bloat

there was a financial standards effort that looked at possibly doing
compressed digital certificates (trying to achieve only ten times bloat)
... eliminating redundant fields and information already in the possession
of the individual's financial institution. we showed that the individual's
financial institution already had superset of the information in the
digital certificate ... so it was possible to compress digital certificates
to zero bytes ... and then mandate that financial transactions would always
have zero-byte certificates appended (as opposed to no appended digital
certificate).

Something similar was demonstrated for RADIUS and Kerberos ... registering
a public key in lieu of password ... some past references
http://www.garlic.com/~lynn/subpubkey.html#radius
and
http://www.garlic.com/~lynn/subpubkey.html#kerberos

and also something similar for registering public key with domain
name registration with domain name infrastructure ... for use in
lieu of SSL digital certificates
http://www.garlic.com/~lynn/subpubkey.html#catch22

that left institutions and relying party with no-value business processes
as digital certificate opportunities ... i.e. no-value transactions where
the relying party couldn't justify the cost of their own entity repository
and/or justify the cost of doing an online transactions to obtain such entity
information ... and of course ... the original design point, the offline
email scenario with first time communication with complete strangers.

One of the problems with no-value market segment is that it is hard for
institutions and individuals to justify paying for things without
any value ... and therefor it is hard to find entities looking
at selling things for nothing.

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


RE: Client Certificate UI for Chrome?

2009-08-06 Thread Thomas Hardjono
Ben,

Having worked at a large CA for along time (trying to push for client-side 
certs with little luck), here are some thoughts on what Chrome could provide:

(a) Association with net identities: Provide some way for the user to associate 
his/her X.509 cert with an internet identity string (eg. OpenID, email 
address, etc etc) in the browser. (Yes, we could add such an identity in the 
SubjAltName, but that's outside the control of the end-user). This would allow 
the user to choose which cert to deliver to the server when the user is 
engaging the server using one of his/her identities. 

(PS. being able to associate with a small image/icon/photo of the user would 
also be nice).

The UI should be a simple as click cert and click identity, and then click 
associate.


(b) Export of certs: Provide an easy way to export client-certs to other apps.  
Currently some CAs use the browser as the primary means for cert enrollment. 
Currently in IE this is somewhat a lengthy process and the response (ie. export 
of cert successful or not) is also not very clear to the end-user.

The UI should not even talk about export. It should say something along the 
lines of Do you want to make your certificate available to the following Apps.


(c) Lock showing which cert/identity used: It would be useful if in addition to 
the Lock symbol (ie. SSL session established) there is a string (next to the 
Lock symbol) showing which client-side cert the browser is using for that SSL 
session. This is related to item (a) above, where a human-readable net identity 
is associate with the cert.

This helps the user in distinguishing which identity he/she is using when 
connecting to a Bank versus a Blog versus a corporate web-mail (all of which 
could be using distinct cert/identity). If there is a mismatch, the user can 
see this visually.


(d) Notification of expired certs:  It would be good if the browser could 
somehow notify the user if there are some expired certs (belonging to the user) 
in the browser. I'm finding that some browsers deliver the first cert in the 
list even when it has expired (thus causing the server to reject).


(e) Better notification/alerts of errors regarding server-certs:  This is a 
hard one as the average user (eg. my Mom) does not understand about certs to 
begin with. Since one of the main aims of SSL server-certs today is to prevent 
phishing, perhaps those messages should be phishing-oriented.

This one need further thought, but perhaps a third button/option could be 
provided (in addition to the Cancel and Continue buttons). This third button 
could provide the user with some alternate sites with similar sounding domain 
names but with proven/valid server-certs.


(f) Better graphical representation of cert hierarchy: Perhaps not crucial, but 
a nice graphical representation of the cert hierarchy/tree might help educate 
the average user (my Mom/Dad) about what a CA is and where the user is located 
in the hierarchy. This would even help the average employee when his/her 
company is using a subordinate CA off a public CA.

When the user clicks on a node in the tree, it should show the organization 
name and other human friendly details.


(g) Easy check button for server-certs: It would be great if I could 
right-click the Lock symbol on the browser and be able to choose an action 
along the lines of Validate Server Certificate. The browser would then hit 
the corresponding OCSP Responder (as denoted in the server-cert) and report the 
status to the user using some graphical notation (eg. icon of server with a big 
X if the server-cert is invalid or status unknown).



That's all for now. Will send more thoughts if any come up :)

/thomas/





 -Original Message-
 From: owner-cryptogra...@metzdowd.com [mailto:owner-
 cryptogra...@metzdowd.com] On Behalf Of Ben Laurie
 Sent: Wednesday, August 05, 2009 9:59 AM
 To: Cryptography
 Subject: Client Certificate UI for Chrome?
 
 So, I've heard many complaints over the years about how the UI for
 client certificates sucks. Now's your chance to fix that problem -
 we're in the process of thinking about new client cert UI for Chrome,
 and welcome any input you might have. Obviously fully-baked proposals
 are more likely to get attention than vague suggestions.
 
 I imagine I may well hear what about the UI around server
 certificates? - fair enough, feel free, and I'll see what I can do.
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to
 majord...@metzdowd.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com