Re: [cryptography] Client TLS Certificates - why not?

[James A. Donald]

James A. Donald"  writes:

The key, and the hash of the key, is a long string of random
gibberish.  It should not be visible to end users.  Experience
demonstrates that showing it repels 99% of end users.

On 2013-03-06 9:33 PM, StealthMonger wrote:


Merchant includes its telephone number in every advertisement and 
repeatedly admonishes prospects to call.


That is a short string of gibberish.

Your only argument is that the key ID is "longer" or more "random".


Exactly so.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Jeffrey Walton]

On Wed, Mar 6, 2013 at 6:33 AM, StealthMonger
 wrote:
> ...
>
>> The key, and the hash of the key, is a long string of random
>> gibberish.  It should not be visible to end users.  Experience
>> demonstrates that showing it repels 99% of end users.
>
> Merchant includes its telephone number in every advertisement and
> repeatedly admonishes prospects to call.
>
> The telephone number may be a long string of random digits.  Yet end
> users understand that they have to use it if they want to follow up.
You've moved the problem around again :)

I have thought about a pre-recorded telephone messages to provide
authenticity assurances. What do we do when the telecoms are in bed
with the government? Its happened in real life: the US Congress passed
a law that it [unauthorized wiretapping and domestic spying] was OK
after the fact, even though it was illegal before the incident
(https://www.eff.org/nsa-spying). Is there any difference between
spying and tampering?

In the end, I think telephone based assurances are an untrusted
channel. The risk may be acceptable to you based on your data
sensitivity. I choose not to trust them (it's part of my
'infrastruture is insecure' mantra).

Jeff
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Michael Rogers]

I don't think most non-programmers would differentiate between a string of hex 
digits and an arbitrary alphanumeric string, so you might as well use base 32. 
But do you really need to encode more bits? With a ZRTPish hash commitment / 
key exchange / confirmation code structure you can detect a MITM attack with 
probability 1 - 1/2^b, where b is the number of bits in the confirmation code. 
A 19-bit code fits into six decimal digits and fails to detect a MITM attack 
with a probability less than one in half a million, which strikes me as a good 
tradeoff between convenience and security.

Cheers,
Michael


ianG  wrote:

>On 6/03/13 14:33 PM, StealthMonger wrote:
>
>> Your only argument is that the key ID is "longer" or more "random".
>
>This of course is the ZT challenge.  The issue isn't that Zooko's 
>Triangle can or can't be squared, but that we the developer have to 
>square it [0].
>
>
>> A
>> solution is redesign of the hash code so it doesn't have to be so long
>> plus maybe merchant generating and discarding lots of keys until
>> stumbling on one with a pronounceable hash.
>
>
>I'm currently working on an invite process from phone to phone.  For now 
>I'm just using 6 char hex codes (24 bits).
>
>There's an easy MITM possibility here, which is fineessed by human 
>processes, time and code space.  But once the invite process is over, 
>assuming no MITM, the phones are locked together (in that the internal 
>addressbooks know each other at 1st class crypto level).
>
>I am musing on whether to go to Base 32, like the airline reservation 
>codes.  That seems to be workable, in that I personally manage to not 
>miss my plane most of the time.
>
>Has anyone got any view as to how complicated a handshake code could be 
>before users start making more mistakes than it is worth?
>
>
>
>iang
>
>
>PS: in stricter metaphorical terms, we are pyramiding the triangle into 
>a 4 sided die, but squaring sounds easier on the ear.
>___
>cryptography mailing list
>cryptography@randombit.net
>http://lists.randombit.net/mailman/listinfo/cryptography
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[ianG]

On 6/03/13 14:33 PM, StealthMonger wrote:


Your only argument is that the key ID is "longer" or more "random".


This of course is the ZT challenge.  The issue isn't that Zooko's 
Triangle can or can't be squared, but that we the developer have to 
square it [0].




A
solution is redesign of the hash code so it doesn't have to be so long
plus maybe merchant generating and discarding lots of keys until
stumbling on one with a pronounceable hash.



I'm currently working on an invite process from phone to phone.  For now 
I'm just using 6 char hex codes (24 bits).


There's an easy MITM possibility here, which is fineessed by human 
processes, time and code space.  But once the invite process is over, 
assuming no MITM, the phones are locked together (in that the internal 
addressbooks know each other at 1st class crypto level).


I am musing on whether to go to Base 32, like the airline reservation 
codes.  That seems to be workable, in that I personally manage to not 
miss my plane most of the time.


Has anyone got any view as to how complicated a handshake code could be 
before users start making more mistakes than it is worth?




iang


PS: in stricter metaphorical terms, we are pyramiding the triangle into 
a 4 sided die, but squaring sounds easier on the ear.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[StealthMonger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

"James A. Donald"  writes:

> On 2013-03-06 4:41 AM, StealthMonger wrote:
>> 2. Prospective customer verification of merchant: Merchant includes
>> the ID of its signing key in every advertisement and repeatedly
>> admonishes prospects to "Accept No Substitutes".

> The key, and the hash of the key, is a long string of random
> gibberish.  It should not be visible to end users.  Experience
> demonstrates that showing it repels 99% of end users.

Merchant includes its telephone number in every advertisement and
repeatedly admonishes prospects to call.

The telephone number may be a long string of random digits.  Yet end
users understand that they have to use it if they want to follow up.

Your only argument is that the key ID is "longer" or more "random".  A
solution is redesign of the hash code so it doesn't have to be so long
plus maybe merchant generating and discarding lots of keys until
stumbling on one with a pronounceable hash.

These are not easily accomplished, but they would enable slaying the
CA dragon.


- -- 


 -- StealthMonger 
Long, random latency is part of the price of Internet anonymity.

   anonget: Is this anonymous browsing, or what?
   
http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=source&output=gplain

   stealthmail: Hide whether you're doing email, or when, or with whom.
   mailto:stealthsu...@nym.mixmin.net?subject=send%20index.html


Key: mailto:stealthsu...@nym.mixmin.net?subject=send%20stealthmonger-key

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.9 

iEYEARECAAYFAlE2+ZEACgkQDkU5rhlDCl7YdQCgqjS4QRv3XmyOgRC/Clf4pDHR
V9IAnikryad50gCwnaugi6YOyslXFlNN
=i1I8
-END PGP SIGNATURE-

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Martin Paljak]

On Wed, Mar 6, 2013 at 10:40 AM, James A. Donald  wrote:
> Can you implement your above design while hiding the keys in urls, rather
> than inflicting them on the suffering user?

There's a saying in Estonian, literally translated: "who wants to eat
sausages is better off not knowing how sausages are made".

Sausages look tasty, meaty and easy to consume. In reality such
products often contain 70% "garbage" instead of  meat. Which also
means that even if some company wants to do a "real meat" sausage
people who know what meat is and care about what they eat are still
suspicious. Those who don't care can easily be fed sausages that
contain "100% artificial taste, coloring, smell and filling materials"
(in small print) and "100% of needed daily vitamins and minerals" in
large print.

Eventually keys, hashes and similar parameters need to be exposed, if
the system is supposed to be used by people who are not sheep.

Martin
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[James A. Donald]

On 2013-03-06 4:41 AM, StealthMonger wrote:

What's wrong with the following simple idea:

1. p2p: The parties opportunistically verify out-of-band after
exchanging keys via public key servers or (insecure) email.

2. Prospective customer verification of merchant: Merchant includes
the ID of its signing key in every advertisement and repeatedly
admonishes prospects to "Accept No Substitutes".

3.  Merchant authentication of Customer: Merchants don't deal with
people.  They deal with keys.  It's the key that has the purchasing
power, not some person.  Nobody has the illusion that correlation
between key and person is any stronger than that person's security
habits.

4.  Etc.



Let us suppose we have urls that contain public keys, or hashes of them, 
or shared secrets, and let us suppose that clients and servers know how 
to handle them:  That the client will insist that the server proves 
knowledge of the corresponding secret key, or knowledge of the shared 
secret, without spilling the shared secret to all and sundry.


Can you implement your above design while hiding the keys in urls, 
rather than inflicting them on the suffering user?

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[James A. Donald]

On 2013-03-06 4:41 AM, StealthMonger wrote:

2. Prospective customer verification of merchant: Merchant includes
the ID of its signing key in every advertisement and repeatedly
admonishes prospects to "Accept No Substitutes".


The key, and the hash of the key, is a long string of random gibberish.  
It should not be visible to end users.  Experience demonstrates that 
showing it repels 99% of end users.



We have to do all the things you describe, without the end user ever 
seeing the key or the hash of the key.



___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Jeffrey Walton]

On Tue, Mar 5, 2013 at 2:38 PM, James A. Donald  wrote:
> On 2013-03-06 1:18 AM, Jeffrey Walton wrote:
>>
>> That's Patient 0. Its the key distribution problem. Its the cause of
>> all the troubles.
>>
>> Web of Trust, Hierarchy of Trust, DNSSEC/DANE, Sovereign Keys,
>> Convergence, {Certificate|Public Key} Pinning, Key Continuity, etc are
>> all band-aides for the first patient.
>
> Wrong phrase.  You seldom want to distribute keys.  You want to distribute
> information about public keys.
Perhaps I should call it the info-distribution problem?

In the case of information distribution, it seems to me the problem
was just moved around (to paraphrase Ian, Dr. Gutmann, et al).

Jeff
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[James A. Donald]

On 2013-03-06 1:18 AM, Jeffrey Walton wrote:

That's Patient 0. Its the key distribution problem. Its the cause of
all the troubles.

Web of Trust, Hierarchy of Trust, DNSSEC/DANE, Sovereign Keys,
Convergence, {Certificate|Public Key} Pinning, Key Continuity, etc are
all band-aides for the first patient.


Wrong phrase.  You seldom want to distribute keys.  You want to 
distribute information about public keys.


Key distribution and key management should follow existing practice with 
managing non memorable email addresses, urls and guids, which 
approximates Zooko's triangle

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Ben Laurie]

On 5 March 2013 18:41, StealthMonger  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jeffrey Walton  writes:
>
>> Its the key distribution problem. Its the cause of all the troubles.
>
> I don't understand.  Please explain.
>
> What's wrong with the following simple idea:
>
> 1. p2p: The parties opportunistically verify out-of-band after
> exchanging keys via public key servers or (insecure) email.
>
> 2. Prospective customer verification of merchant: Merchant includes
> the ID of its signing key in every advertisement and repeatedly
> admonishes prospects to "Accept No Substitutes".
>
> 3.  Merchant authentication of Customer: Merchants don't deal with
> people.  They deal with keys.  It's the key that has the purchasing
> power, not some person.  Nobody has the illusion that correlation
> between key and person is any stronger than that person's security
> habits.
>
> 4.  Etc.

Whilst all these ideas are useful parts of the picture, the challenge
is to construct something that is:

1. Robust - or at least as robust as what we have.

2. Usable - or at least as usable as what we have.

3. Cheap - or at least as cheap as what we have.

4. Secure - or at least as secure as what we have.

5. Fast - or at least as fast as what we have (and by this I
specifically mean extra round trips, DNS resolutions, etc. are not
acceptable).

There may be more. And presumably any new proposal will have to also
excel in at least one area, or why change?

In any case, this short list is hard enough to satisfy.

This is why I favour PKI + Certificate Transparency as a way forward.
CT should not make things much worse along any axis, and it has a
convincingly strong story for a tangible security improvement.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Jeffrey Walton]

On Tue, Mar 5, 2013 at 1:41 PM, StealthMonger
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jeffrey Walton  writes:
>
>> Its the key distribution problem. Its the cause of all the troubles.
>
> I don't understand.  Please explain.
>
> What's wrong with the following simple idea:
>
> 1. p2p: The parties opportunistically verify out-of-band after
> exchanging keys via public key servers or (insecure) email.
That's basically SneakerNet. You moved the problem around. If you met
and exchange keys, you wouldn't need to make the phone call. Do it at
the pub over drink.

The problems are (1) It is often not practiced and (2) it surely does
not scale. When is the last time you called a business and asked them
to verify their certificate thumbprint before entering your credit
card?

You also have the problem of explaining it to your grandmom.

Jeff
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[StealthMonger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeffrey Walton  writes:

> Its the key distribution problem. Its the cause of all the troubles.

I don't understand.  Please explain.

What's wrong with the following simple idea:

1. p2p: The parties opportunistically verify out-of-band after
exchanging keys via public key servers or (insecure) email.

2. Prospective customer verification of merchant: Merchant includes
the ID of its signing key in every advertisement and repeatedly
admonishes prospects to "Accept No Substitutes".

3.  Merchant authentication of Customer: Merchants don't deal with
people.  They deal with keys.  It's the key that has the purchasing
power, not some person.  Nobody has the illusion that correlation
between key and person is any stronger than that person's security
habits.

4.  Etc.

- -- 


 -- StealthMonger 
Long, random latency is part of the price of Internet anonymity.

   anonget: Is this anonymous browsing, or what?
   
http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=source&output=gplain

   stealthmail: Hide whether you're doing email, or when, or with whom.
   mailto:stealthsu...@nym.mixmin.net?subject=send%20index.html


Key: mailto:stealthsu...@nym.mixmin.net?subject=send%20stealthmonger-key

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.9 

iEYEARECAAYFAlE2G5kACgkQDkU5rhlDCl5QggCdHIykKqh1NSupIu5/85okO50C
fr0AoK95/a+NHJheC+78w6op8dooFuto
=lSEg
-END PGP SIGNATURE-

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Thierry Moreau]

str...@riseup.net wrote:

Hi,

Can anyone enlighten me why client TLS certificates are used so rarely? It
used to be a hassle in the past, but now at least the major browsers offer
quite decent client cert support, and seeing how most people struggle with
passwords, I don't see why client certs could not be beneficial even to
"ordinary users".



Hi,

If you ask the question, you may be unaware of the many implications 
explained by other contributions. I take a chance at dropping my 
analysis, which is oriented towards innovation in IT security operations.


First of all, there is an abuse of language with the term "client 
certificates": what protects the client is its public-private key pair 
(PPKP). So you may ask yourself "Client PPKP, why not?"


Then you realize that the X.509 certificates come with the complexity of 
the CA operations, and relying parties (server operators now eating the 
same dog food that they served to their end-users).


With the first party certification paradigm, drop the CA operations 
altogether and let the service providers maintain their own trusted 
client PPKP (I mean the client public keys).


The evil is in the details. I found more evils in removing the CA than 
in bringing forward the new paradigms -- the X.509 mindset is in one's 
brain very deep (not only in browser software where it can be 
circumvented easily with auto-issued dummy X.509 security certificates).


Still, the client PPKP usage along with the first party certification 
paradigm is not for an ordinary user if unable to "mind the P and Q's" 
of the RSA core operating principle (I postulated client PPKP usage, I'm 
stuck with client PPKP usage). A realistic goal is to get the 
installation instructions from 60 pages to 10-15 (OK 25-30 if we have to 
undo the X.509 mindset).


Trust at the enrollment phase is obviously delicate and can not be fully 
automated. I'm working on that part.


There are closed PKI deployments using client PPKP in a X.509 
PKI-centric perspective. The cost per user is significant. The 
alternative I am hinting about (a- client PPKP usage b- first party 
certification paradigm c- the enrollment scheme) would be an 
intermediate-level client authentication approach.


So why not PKI client certificates for ordinary users? Because even 
client PPKP usage for ordinary users is hardly conceivable.



With CAcert, there is even an excellent infrastructure in place that could
allow people to generate signed pseudonymous client certificates. A
service provider could limit the amount of certificates allowed per user
(as validated by CAcert), maybe even the amount of points required etc.

That way, one could provide services without the requirement of
registration, and still effectively limit abuse?


That's the early dream of a global PKI. Nowadays, we know more.

Regards,


--
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Jeffrey Walton]

On Tue, Mar 5, 2013 at 9:18 AM, Martin Paljak  wrote:
> On Tue, Mar 5, 2013 at 2:08 PM, ianG  wrote:
>> This whole argument that certs aren't portable across devices is something
>> of a strawman.  Companies deploy SSL certs across accelerators all the time,
>> so why not client certs?  The reason is the assumptions that are designed to
>> stop you doing that.  Get rid of those assumptions, and client certs work.
>
> Because:
>  - Distributing (encryption) keys securely is not that easy to
> accomplish
That's Patient 0. Its the key distribution problem. Its the cause of
all the troubles.

Web of Trust, Hierarchy of Trust, DNSSEC/DANE, Sovereign Keys,
Convergence, {Certificate|Public Key} Pinning, Key Continuity, etc are
all band-aides for the first patient.

Jeff
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Martin Paljak]

On Tue, Mar 5, 2013 at 2:08 PM, ianG  wrote:
> This whole argument that certs aren't portable across devices is something
> of a strawman.  Companies deploy SSL certs across accelerators all the time,
> so why not client certs?  The reason is the assumptions that are designed to
> stop you doing that.  Get rid of those assumptions, and client certs work.

Because:
 - Distributing (encryption) keys securely is not that easy to
accomplish (end-users can screw it up more than a security officer
when initializing modules)
 - There's no goldmine business model in client-side *encryption* to
motivate making it easier: there's no legislation that requires it (a
driving factor behind the business sector) or wide-spread use case
that would mitigate a costly risk for "server-side business" runners
(another factor)
 - When you care about encryption (read: forbidding easy decryption)
you can often forget certificates, because you don't care about
*certificates* but keys (you just need certificates because some
software that makes encryption uses certificates to carry public key
information)


> Smart cards and USB-format PKI are a dead loss.  They are unworkable as a
> tech, 20 years of experiments have shown this beyond a shadow of a doubt.
> If there is any future in smart cards or any other form of fantasy token, it
> will come via its humbler cousin, the cert stored in the browser or the
> software app.  Later on, once that has proved the model, it might be
> possible to pay the huge cost of smart card deployment.

> Yes, I agree that browsers don't really support client certs.  Reasons are
> the same old same old.


I think there's more to smart cards than to USB. "Universal chips" are
here to stay for a while. USB is not that universal.

So here's 10 years of practice of trying to use a *smart card* in real
life, broken down into platforms and browsers, and having two uses for
client certificates: SSL/TLS *and* additional "stuff that needs
plugins to work":

- you always need a bunch of semi-proprietary software to make things work
- Windows has been relatively OK, when IE is used. Things have gone
better with BaseCSP.
- Opera doesn't give a * about smart cards.
- Firefox has lost the game, PKCS#11 on Windows is nineties.
- Chrome may be evil but it works, quite often
- Mac OS X and Chrome worked until 10.6 or so. 10.6, 10.7 and 10.8 do
the "tablet thing" and "apple thing" and have deprecated/obsoleted
most of the software needed to work with smart cards "the apple way".
Things have been stagnated in Mac OS X world for years.
- Firefox and PKCS#11 suck the same way as as it does on other platforms.
- Chrome made things right, meaning that ThingsJustWorkedMagically for
a while on OS X.
- Safari works... To some extent, obviously not a priority for the producer.
- Linux Is Linux. Many options to choose from, possible to make
things work, possible to spend hours trying to get thing to work.

TLS is plumbing, and for pluming to work well, it should go to the
same place where other plumbing (like sockets) are done: the question
is not in the browsers but in platforms (operating systems).

At least for smart cards. It works well if the platform provides means
for working with them and if the browser makes use of the provided
capabilities. Thats why MS/IE, MS/Chrome, OSX/Chrome work pretty well.

As soon as you have more than one certificate from the same provider,
for different purposes.. things get hairy for the browser and also the
user.

All-in-all, it works in smaller scales (a country of 1.3M) and with
constant fighting with breaking updates from all fronts (platforms,
libraries, applications etc).

Martin
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Martin Paljak]

Hello,

On Mon, Mar 4, 2013 at 9:22 AM,   wrote:
> Can anyone enlighten me why client TLS certificates are used so rarely? It
> used to be a hassle in the past, but now at least the major browsers offer
> quite decent client cert support, and seeing how most people struggle with
> passwords, I don't see why client certs could not be beneficial even to
> "ordinary users".

Maybe because "constant wire encryption" is not the most effective
solution for all use cases or applicable in the "web as we know it" at
all ?

Martin
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[ianG]

On 5/03/13 03:26 AM, Joe St Sauver wrote:

Hi,

strife asked:

#Can anyone enlighten me why client TLS certificates are used so rarely? It
#used to be a hassle in the past, but now at least the major browsers offer
#quite decent client cert support,

Not quite seeing eye-to-eye with you on the "quite decent client cert
support" point, I'm afraid. Client cert user interaction still deserves
poor marks for complexity and user opacity, I think.



Yes, I agree that browsers don't really support client certs.  Reasons 
are the same old same old.



I did a preconference seminar for Educause Security Professionals 2012 on
client certificates, and it's actually sort of surprising how deeply buried
many bits of the current browser client cert implementation are. See
http://pages.uoregon.edu/joe/secprof2012/sec-prof-2012-client-certs.pdf


Nice work!
...

Assume the average person has multiple devices these days -- maybe a
desktop at work, a laptop for travel, a tablet at home, a smartphone, etc.

If I want to use client certs for encryption/decryption, I need the *same*
cert on all of those devices,



No you don't - you need the same *claim* on all those devices if you are 
going to treat them all within the same claim domain.


If you have a system that promotes certs, then this is easy enough. 
Unfortunately we don't have that, as for various reasons, certs are seen 
as something one has to attach a high value to by suppliers.  So they 
get what works for that business proposition - nothing.  Which is to 
say, certs can do that job.  It isn't the certs that are at fault; if 
the CAs insist that they can sell an unsellable client cert to people 
for every one of their devices, it's no surprise this market continues 
to say "no thanks, we'll stick to passwords."


This whole argument that certs aren't portable across devices is 
something of a strawman.  Companies deploy SSL certs across accelerators 
all the time, so why not client certs?  The reason is the assumptions 
that are designed to stop you doing that.  Get rid of those assumptions, 
and client certs work.




or on a portable device (such as a USB-format
PKI hard token, or a smart card) so I can take my credentials with me.
Sync'ing certs from one device to another isn't totally impossible, but
backing up, manually transfering and reinstalling certs on multiple devices
really isn't simple enough for most mere mortals. [Attempts to deploy a
unique client cert to each device have issues of their own that we'll
skip for the purposes of this note]



:)


Smart cards or USB-format PKI hard tokens are a nice alternative, but
somewhat expensive, and you can't just run down to your favorite local
office supply store or neighborhood compute supply store and buy one.



Smart cards and USB-format PKI are a dead loss.  They are unworkable as 
a tech, 20 years of experiments have shown this beyond a shadow of a 
doubt.  If there is any future in smart cards or any other form of 
fantasy token, it will come via its humbler cousin, the cert stored in 
the browser or the software app.  Later on, once that has proved the 
model, it might be possible to pay the huge cost of smart card deployment.


Maybe.  But until then, any talk of hardware is in sci-fi fantasy la-la 
land.


(update:  having skimmed your talk, I see your success story, and it's 
only a small matter of inclusion, to whit:  USA federal government is a 
model citizen of sci-fi fantasy la-la land.)


...

Bottom line, I think that there's still a lot of work ahead if you want
to do client certs at scale...




Client Certs work, if they are targeted at website authentication as a 
password replacement.


Unfortunately there is a bit of a chicken and egg problem [0].  Software 
will only evolve if there is a serious amount of market - if lots of 
people demand this.  And nobody will demand this unless the software 
handles it well, which is not generally the case here.


This is actually pretty easy.  Here's the story:  a website runs its own 
CA.  For every enrolment of a customer, it issues a client cert to that 
customer (the browsers include code to trigger creation of that key & 
cert).  It enrolls that cert for that customer for this site only, and 
demands a cert every time someone touches the site.


Done deal.  It works.  Hey presto, passwords gone.  Now, the, security 
question that is going on here is the same one as always:  is this 
operation now *more secure than the alternative* being passwords?


Any larger website could do this - the code isn't that complicated, it's 
about a month or two.


The security *failure* here is to compare it to some 'best practice' 
shlock bible story from the industry that was written for other purposes 
than your security, and ask whether it is better than some mystical 
perfect fairy tale that isn't really relevant.




iang



[0] CAcert solved this chicken and egg by providence, rather than 
design, read here:


http://wiki.cacert.org/Technology/Knowle

Re: [cryptography] Client TLS Certificates - why not?

[Joe St Sauver]

Hi,

strife asked:

#Can anyone enlighten me why client TLS certificates are used so rarely? It
#used to be a hassle in the past, but now at least the major browsers offer
#quite decent client cert support, 

Not quite seeing eye-to-eye with you on the "quite decent client cert 
support" point, I'm afraid. Client cert user interaction still deserves
poor marks for complexity and user opacity, I think.

I did a preconference seminar for Educause Security Professionals 2012 on
client certificates, and it's actually sort of surprising how deeply buried
many bits of the current browser client cert implementation are. See
http://pages.uoregon.edu/joe/secprof2012/sec-prof-2012-client-certs.pdf

Or consider the level of native OS support for USB format PKI hard tokens
or smart cards on some operating systems, just to mention another example
of how client certificate support is still not really ready for prime time
at this point.

[In fact, if anyone's looking for a nice paper topic, I think a terrific
topic might be "Why Johnny Can't Ecrypt Using Client Certs, Either"
modeled on http://static.usenix.org/events/sec99/whitten.html ]

#and seeing how most people struggle with passwords, I don't see why 
#client certs could not be beneficial even to "ordinary users".

Client certs *could* be hugely beneficial to even ordinary users -- 
imagine their use for EAP-TLS authentication, for example. 

The devil, as always, is in the details.

Assume the average person has multiple devices these days -- maybe a 
desktop at work, a laptop for travel, a tablet at home, a smartphone, etc.

If I want to use client certs for encryption/decryption, I need the *same*
cert on all of those devices, or on a portable device (such as a USB-format 
PKI hard token, or a smart card) so I can take my credentials with me. 
Sync'ing certs from one device to another isn't totally impossible, but 
backing up, manually transfering and reinstalling certs on multiple devices
really isn't simple enough for most mere mortals. [Attempts to deploy a 
unique client cert to each device have issues of their own that we'll 
skip for the purposes of this note]

Smart cards or USB-format PKI hard tokens are a nice alternative, but 
somewhat expensive, and you can't just run down to your favorite local
office supply store or neighborhood compute supply store and buy one.

Then there's the fact that not all devices easily accomodate USB-format
PKI hard tokens or smart cards, but if you *are* able to use a USB format 
PKI hard token or smart card, at least the credentials stored on those 
devices can be stored in a non-exportable format, which is good given 
the uptick in malware's that has reportedly been scraping client certs 
of late.

Smart cards or hard tokens are also required if you're shooting for the
highest NIST LOAs, but there's so much more that's required to get there
that in many ways the use of smart cards or hard tokens is a minor 
matter relative to identity proofing requirements and all the rest of
what's require -- and it's hard to find anyone who actually needs LOA-4,
at least in higher ed.

Speaking of identity proofing, many times client certs only map to email
addresses, not to "real names," and not to guaranteed-unique and 
never-to-be-reused arbitrary identifiers (like the EPPN). Some may find 
that choice less than full satisfactory.

Or let's talk about key servers/directory models. Let me wave my magic
wand and magically create an Internet-wide directory for client certs,
perhaps modeled on PGP public key servers. Unfortunately, I don't see 
much interest in fielding an animal of that sort, and w/o it, you're
either reduced to enterprise-level directories, or the painful process
of requesting a signed message to bootstrap key exchange for encryption
purposes (yuck)

And the list goes on...

Bottom line, I think that there's still a lot of work ahead if you want
to do client certs at scale...

Regards,

Joe

Disclaimer: all opinions strictly my own.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Tony Arcieri]

On Sun, Mar 3, 2013 at 11:22 PM,  wrote:

> Hi,
>
> Can anyone enlighten me why client TLS certificates are used so rarely? It
> used to be a hassle in the past, but now at least the major browsers offer
> quite decent client cert support, and seeing how most people struggle with
> passwords, I don't see why client certs could not be beneficial even to
> "ordinary users".


Not sure what your idea of "quite decent client cert support" is, however I
don't think this is the case:

1) It's not easy for users to use client certs instead of passwords. Try to
build a demo of a site that makes use of client certs for logging in. I
think you'll find it an exercise in frustration
2) It's not easy to move client certs around from browser-to-browser, e.g.
if you want to log into the same site from multiple browsers (the sync
features of Chrome and Firefox could potentially make this easier)
3) There's no uniform API for managing client certs from JavaScript

-- 
Tony Arcieri
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Guido Witmond]

On 03/04/2013 11:15 PM, Open eSignForms wrote:

Step 10 will make it impossible for you mom. ;-)



10. You write your message, sign it with your private key, encrypt
it with your public key and deliver the ciphertext to

https://guidos-secure-mail.com/deliver?to=StealthMongersMom&ciphertext=MIIABC...XZY===


(openssl s/mime encoded message, without headers)




You're right. Wrong key for encryption. Should use mom's public key for 
encryption.


Thanks, Guido.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Guido Witmond]

On 03/04/2013 06:10 PM, StealthMonger wrote:

 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1

 Peter Gutmann  writes:


 ... sit behind her with your arms crossed so you can't point to
 anything or type stuff out for her, and walk her through the process
 of acquiring and using one without leaving your chair or performing
 any part of the operation for her.

> Now imagine getting her to do the same using only a sheet of
> instructions you've written.

 Mother sits down at her computer to do email. Computer notices that
 she does not have an encryption key (client-side certificate),
 starts a background process to generate one, and tells her:

 From now on, you will have a new email address. Starting next week,
 the old one will no longer work.

 This will be the only computer on which you can receive email. If
 you ever want to use another computer, press "Add/Change Computer"
 below.

 [Computer finishes generating key with key ID xlzoazsabewlcc.]

 Your new email address is "xlzoazsabewlcc". It is now being
 broadcast worldwide. Tell your bank and all your friends.


How do you get that address communicated over the phone?

Let me try and help your mother:

Mother sits at computer, and asks: "What now?"

Me:
1. open firefox, install the secure email addon from: 
mozilla/addons/guidos-secure-email-plugin.xpi


She installs it.

2. browse to https://guidos-secure-mail.com/

She: how do you spell that?

Me: h-t-t-. dot com (with hands at my back)

3. Web browser connects to server, and the plug in validates server 
certificate against DNSSEC/DANE specified Root certificate. (It won't 
connect if there is an error here)


4. I ask her to press the 'Signup' button at the plugin (on the browser 
chrome, not in the window)


Browser plugin asks for username: Mom types: StealthMongersMom and she 
presses the ok-button.


5. Browser plugin requests client certificate at guidos-secure-mail.com 
with her chosen username. Browser receives certificate from the site, 
signed with a subCa of the same RootCa certificate as the server. 
Username must be unique, otherwise she needs to choose something different.


Mom has all she needs to send and receive secure mail.

6. Mom phones offspring and says I've got an email address: it's  
stmomo@@guisecmail.com (unintelligible due to line noise)


7. You: How do you spell that?

8. She: S-t-e-a. . . m-a-i-l  dot com

9. You type it in and your browser plugin looks up
https://guidos-secure-mail.com/cert-of?id=StealthMongersMom
It validates the server certificate and checks if the client cert 
is chained to the same RootCA.


10. You write your message, sign it with your private key, encrypt it 
with your public key and deliver the ciphertext to 
https://guidos-secure-mail.com/deliver?to=StealthMongersMom&ciphertext=MIIABC...XZY=== 
(openssl s/mime encoded message, without headers)


11. She logs in with her certificate, the site delivers the ciphertext 
and the plugin decrypts it with her private key


12. The plug in retrieves the certificate for the sender-address 
(StealthMonger@@nym), validates it against the DNSSEC/DANE RootCA 
for nym... and has a validated return address.


13. Your mom presses the reply-button, composes a message, her plug 
signs it with her private key, encrypts it with your public key. She 
delivers the message at 
nym...//deliver?to=StealthMonger&ciphertext=MIIDEF...ABC=== (important 
not to send to guidos-secure-email.com)


14. You receive the message and when the message signature matches that 
of the client certificate you got from step 9 you know that there is no 
man in the middle at guidos-secure-mail.com impersonating your mom. My 
site does not have your mom's private key to do so.


Notice that mom didn't validate any keys, nor did she ask you for your 
address. She just assumes that the first mail she gets is from you. It's 
the contents of the message that does the validation for her. Just like 
ordinary email.





 Anyone else who can log into this computer has access to all your
 bank accounts and email.


Please use Qubes-OS, Genode, Minix or any other POLA based OS and user 
interface to prevent the Dancing Pwnies. With Swiss-cheese-OS we can 
never reach security nirvana...




 Make sure your login password is strong.



Please don't use passwords, use a GPG key on a crypto-stick.com. 
Upcoming version 2 of the stick can store plenty of certificates and 
private keys on its secured sd-card.


Cheers, Guido.


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[StealthMonger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter Gutmann  writes:

>  writes:

>>Can anyone enlighten me why client TLS certificates are used so
>>rarely?  It used to be a hassle in the past

> They're still a huge pain to work with, and probably always will be.
> If you don't believe me, go to your mother, sit her in front of a
> computer, sit behind her with your arms crossed so you can't point
> to anything or type stuff out for her, and walk her through the
> process of acquiring and using one without leaving your chair or
> performing any part of the operation for her.

> Now imagine getting her to do the same using only a sheet of
> instructions you've written.

Mother sits down at her computer to do email.  Computer notices that
she does not have an encryption key (client-side certificate), starts
a background process to generate one, and tells her:

   From now on, you will have a new email address.  Starting next
   week, the old one will no longer work.

   This will be the only computer on which you can receive email.  If
   you ever want to use another computer, press "Add/Change Computer"
   below.

   [Computer finishes generating key with key ID xlzoazsabewlcc.]

   Your new email address is "xlzoazsabewlcc".  It is now being
   broadcast worldwide.  Tell your bank and all your friends.

   This computer is the only computer in the world that can receive
   messages to this new address.  You should probably make a backup.
   Press "Make Backup" below.

   Anyone else who can log into this computer has access to all your
   bank accounts and email.  Make sure your login password is strong.

Simple as that.  (Well, almost.)  Admittedly, this is oriented to
email, not browsing.  But the browser can be told to look for the same
key ring for certificate material.

- -- 


 -- StealthMonger 
Long, random latency is part of the price of Internet anonymity.

   anonget: Is this anonymous browsing, or what?
   
http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=source&output=gplain

   stealthmail: Hide whether you're doing email, or when, or with whom.
   mailto:stealthsu...@nym.mixmin.net?subject=send%20index.html


Key: mailto:stealthsu...@nym.mixmin.net?subject=send%20stealthmonger-key

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.9 

iEYEARECAAYFAlE0lwoACgkQDkU5rhlDCl4R9gCfVOs1ynBZUqmE8TGDH9HjSvt6
nhQAn3vZpOK91H+exiJf3gyoRR4OF28r
=NeCP
-END PGP SIGNATURE-

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[dan]

With respect to:

>...
> - repudiation: there is no way deny writing a message; leading to self 
> censoring.
> 
> In other words, everything I sign with my Thawte client certificate is 
> tied to my identity *for life*. That's why I don't use that thing. In 
> fact, I've long since lost the private key for it. With password based 
> accounts, I can decide to write under any pseudonym and keep control of 
> my privacy, at the price of having the hassle with passwords.
>
> I've tried to write a blog[1] on it.
>...
> witmond.nl/blog/2012/11/21/why-we-still-use-passwords.html

I agree with you entirely.  Though tangential enough to
perhaps be off-topic, I wrote on the same theme last month.

Identity as Privacy
geer.tinho.net/ieee/ieee.sp.geer.1301b.pdf

--dan

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Guido Witmond]

On 03/04/2013 08:22 AM, str...@riseup.net wrote:

Hi,

Can anyone enlighten me why client TLS certificates are used so rarely? It
used to be a hassle in the past, but now at least the major browsers offer
quite decent client cert support, and seeing how most people struggle with
passwords, I don't see why client certs could not be beneficial even to
"ordinary users".


Hi Strife,

I'ld like to add a few cents too:

The whole x509 client and server certificates were designed to be used 
with a global directory, called x500. The idea is that you can lookup 
the key of person you want to communicate to. Although this 'secures' 
the communication against tampering and keeps the contents confidential, 
it lacks three properties:
- there is no way to securely communicate with total strangers; you need 
to know their name

- privacy: every person has one-true-certificate-to-bind-them;
- repudiation: there is no way deny writing a message; leading to self 
censoring.


In other words, everything I sign with my Thawte client certificate is 
tied to my identity *for life*. That's why I don't use that thing. In 
fact, I've long since lost the private key for it. With password based 
accounts, I can decide to write under any pseudonym and keep control of 
my privacy, at the price of having the hassle with passwords.


I've tried to write a blog[1] on it.


Another reason why the Crypto-heaven did not materialise is that the 
current crop of operating systems is completely unfit to protect the 
user's interests. As soon as one piece of malware is inside, it's not 
your computer anymore. And with that the malware can abuse your 
expensive client certificate at will.


I believe only micro-kernel operating systems with POLA security layers 
on top of that can bring solace.
See Qubes-OS, Genode, Minix. Without such security any progress to use 
cryptography is doomed. See 'Dancing Pwnies' on wikipedia.


IanG and Peter Gutmann are completely correct that usability is key. 
Browsers have a long way to go. For example, log in at CAcert with your 
client certificate. That's easy. Now try to log out. That's impossible. 
The only thing you can do is to close your browser. Losing all other 
open tabs with it.




I've come up with a way to get out of this mess. I call it Eccentric 
Authentication.[2]


It's a protocol that will provide pseudonymous client certificates, 
eliminates passwords, allows total strangers to communicate securely at 
a dating site. With the addition of a *Cryptographic Same Origin Policy* 
we can end CRSF, block the most obnoxious advertisment-spies while still 
allowing CDN-networks, javascript-applications. I've designed a fully 
anonymous dating site where you _can_ limit abuse.


I've written about that too. In fact, my whole website handles about it. 
Feel free to explore and ask if things are not clear.


Cheers, Guido Witmond.

1: http://witmond.nl/blog/2012/11/21/why-we-still-use-passwords.html
2: http://witmond.nl/ecca/ecca.html


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Peter Gutmann]

 writes:

>Can anyone enlighten me why client TLS certificates are used so rarely? It
>used to be a hassle in the past

They're still a huge pain to work with, and probably always will be.  If you
don't believe me, go to your mother, sit her in front of a computer, sit
behind her with your arms crossed so you can't point to anything or type stuff
out for her, and walk her through the process of acquiring and using one
without leaving your chair or performing any part of the operation for her.

Now imagine getting her to do the same using only a sheet of instructions
you've written.

Whenever anyone asks "why aren't certificates/smart cards/whatever used more?"
they should be required to go through this exercise, and then they will be
enlightened.

NB: Remember to switch to a fresh mother every time you re-try this
experiment with some new technology.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[ianG]

On 4/03/13 10:22 AM, str...@riseup.net wrote:

Hi,

Can anyone enlighten me why client TLS certificates are used so rarely?



My thoughts only, not authoritative.

The big answer today is momentum, I would say.

In the past, I would say that forces were deployed against TLS 
certificates.  The CAs did not push them because the market for selling 
client-side certificates at a commercially sensible price wasn't there, 
it's a loss making proposition.  Still isn't/is.  But what they did do 
successfully is convince people that certificates not signed by 
browser-CAs were evil.  They got their cake and their still eating it.


The combination of these forces pushed all the developers over to 
passwords, and they've been on that since forever.  Same cake, now about 
18 years old, and causing predictable tummy aches.



It
used to be a hassle in the past, but now at least the major browsers offer
quite decent client cert support, and seeing how most people struggle with
passwords, I don't see why client certs could not be beneficial even to
"ordinary users".



Browsers need a couple of things:  create a new cert on the fly, and to 
fix the certs on a per-site level.  But more than anything, they need to 
get their heads out of committee holes and start doing real security 
work for themselves.  Thankfully that seems to be happening over at google.



With CAcert, there is even an excellent infrastructure in place that could
allow people to generate signed pseudonymous client certificates. A
service provider could limit the amount of certificates allowed per user
(as validated by CAcert), maybe even the amount of points required etc.



As you mentioned it:  CAcert tried to move all its infra over to 
certificates.  The results were mixed.  Some things worked very well, 
somethings less well.  However, the places where things worked less well 
were pretty much all to do with the software just not evolving in that 
direction.


My personal experience is that writing the cert-based user 
authentication is easier and more robust than writing the password 
authentication system.  (I've done both in PHP.)  But it does require a 
bit more than copycat design :)  For example, one has to find a way to 
handle multiple certs for the same person, which requires one to stress 
the claims of the CA more than they are capable of being stressed.  In 
particular, if cert A says "John Smith" and cert B says the same "John 
Smith", are we happy?  I was... but I had to windmill it a little.



That way, one could provide services without the requirement of
registration, and still effectively limit abuse?


Certs solve the spam problem, and the password security problem.  And 
the phishing problem.  Oh, and the lost password problem, as a bonus :)


More or less, or, at least, certs lift the bar a long way.

What's more, if they were used more often, and client & server software 
were to evolve to respect them, we'd be halfway to a decent security 
model.  For example, properly used (afair, impossible in current 
browsers because we can't easily get general signing access to the certs 
from say javascript) we'd be able to use the certs for proper 
transaction signing, which would get us decent accounting software 
instead of the "don't click Pay twice" nonsense standard aka online banking.




iang
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Client TLS Certificates - why not?

[strife]

Hi,

Can anyone enlighten me why client TLS certificates are used so rarely? It
used to be a hassle in the past, but now at least the major browsers offer
quite decent client cert support, and seeing how most people struggle with
passwords, I don't see why client certs could not be beneficial even to
"ordinary users".

With CAcert, there is even an excellent infrastructure in place that could
allow people to generate signed pseudonymous client certificates. A
service provider could limit the amount of certificates allowed per user
(as validated by CAcert), maybe even the amount of points required etc.

That way, one could provide services without the requirement of
registration, and still effectively limit abuse?

Wondering
-strife

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography