Philipp Gühring wrote:
I had the feeling that Microsoft wants to abandon the usage of client
certificates completely, and move the people to CardSpace instead.
But how do you sign your emails with CardSpace? CardSpace only does the
realtime authentication part of the market ...
It's not
Thierry Moreau [EMAIL PROTECTED] writes:
At first, it seems neat. But then, looking at how it works in practice: the
client receives an e-mail notification soliciting him to click on a HTML link
and then enroll for a security certificate, the client is solicited exactly
like a phishing criminal
Leichter, Jerry wrote:
While trying to find something else, I came across the following
reference:
Title: Sender driven certification enrollment system
Document Type and Number: United States Patent 6651166
Link to this page:
On Feb 11, 2008, at 8:28 AM, Philipp Gühring wrote:
I had the feeling that Microsoft wants to abandon the usage of client
certificates completely, and move the people to CardSpace instead.
But how do you sign your emails with CardSpace? CardSpace only does
the
realtime authentication part of
Philipp =?iso-8859-1?q?G=FChring?= [EMAIL PROTECTED] writes:
I had the feeling that Microsoft wants to abandon the usage of client
certificates completely, and move the people to CardSpace instead.
While there's an obvious interpretation of that (Microsoft want to lock
everyone into CardSpace),
Imagine if a website could instruct your browser to transparently
generate a public/private keypair for use with that website only and
send the public key to that website. Then, any time that the user
returns to that website, the browser would automatically use that
private key to
Is anyone aware of any third-party usability studies on CardSpace,
OpenID, ...?).
I'm not. It would be a good opportunity for security usability
researchers to contribute though.
[0] I'm not sure whether putting CardSpace and Liberty in such close
proximity in the above line was a
Werner == Werner Koch [EMAIL PROTECTED] writes:
Werner The last time I checked the Mozilla code they used their own crypto
Werner stuff. When did they switched to OpenSSL and how do they solve the
Werner GPL/OpenSSL license incompatibility?
Indeed they do. It is called nss, is available as a
Hi,
Microsoft broke this in IE7... It is no longer possible to generate and
enroll a client cert from a CA not on the trusted root list. So private
label CAs can no longer enroll client certs. We have requested a fix,
so this may come in the future, but the damage is already done...
Also
Steven M. Bellovin wrote:
There's another issue: initial account setup. [Even
with SRP] people will still need to rely on
certificate-checking for that. It's a real problem at
some hotspots, where Evil Twin attacks are easy and
lots of casual users are signing up for the first
time.
For
| By the way, it seems like one thing that might help with client certs
| is if they were treated a bit like cookies. Today, a website can set
| a cookie in your browser, and that cookie will be returned every time
| you later visit that website. This all happens automatically. Imagine
| if a
re:
http://www.garlic.com/~lynn/aadsm28.htm#30 Fixing SSL
so lots of the AADS
http://www.garlic.com/~lynn/x959.html#aads
scenarios are that every place a password might appear, have
a public key instead.
for various of the cookie authentication operations ... also
think kerberos tickets.
Peter Gutmann wrote:
Victor Duchovni [EMAIL PROTECTED] writes:
While Firefox should ideally be developing and testing PSK now, without
stable libraries to use in servers and browsers, we can't yet expect anything
to be released.
Is that the FF devlopers' reason for holding back? Just
On Thu, 7 Feb 2008 16:37, [EMAIL PROTECTED] said:
I don't have any idea why or why not, but all they can release now is
source code with #ifdef openssl = 0.9.9 ... do PSK stuff ... #endif,
The last time I checked the Mozilla code they used their own crypto
stuff. When did they switched to
James A. Donald [EMAIL PROTECTED] writes:
However, seems to me that logging into the website using SRP is a non trivial
refactoring, and not just a matter of dropping in TLS-SRP as a simple
replacement of TLS-DSA-X509
I've discussed this with (so far) a small sample of assorted corporate TLS
Victor Duchovni [EMAIL PROTECTED] writes:
While Firefox should ideally be developing and testing PSK now, without
stable libraries to use in servers and browsers, we can't yet expect anything
to be released.
Is that the FF devlopers' reason for holding back? Just wondering... why not
release it
On Thu, 07 Feb 2008 17:37:02 +1300
[EMAIL PROTECTED] (Peter Gutmann) wrote:
The real issues occur in two locations:
1. In the browser UI.
2. In the server processing, which no longer gets the password via an
HTTP POST but as a side-effect of the TLS connect.
(1) is a one-off cost for the
Frank Siebenlist [EMAIL PROTECTED] writes:
With the big browser war still going strong, wouldn't that provide fantastic
marketing opportunities for Firefox?
There's always the problem of politics. You'd think that support for a free
CA like CAcert would also provide fantastic marketing
Steven M. Bellovin [EMAIL PROTECTED] writes:
There's another issue: initial account setup. People will still need to rely
on certificate-checking for that. It's a real problem at some hotspots,
where Evil Twin attacks are easy and lots of casual users are signing up for
the first time.
It
On Thu, Feb 07, 2008 at 08:47:20PM +1300, Peter Gutmann wrote:
Victor Duchovni [EMAIL PROTECTED] writes:
While Firefox should ideally be developing and testing PSK now, without
stable libraries to use in servers and browsers, we can't yet expect anything
to be released.
Is that the FF
Tim Dierks writes:
(there are totally different reasons that client certs aren't being
widely adopted, but that's beside the point).
I'd be interested in hearing your take on why SSL client certs aren't
widely adopted. It seems like they could potentially help with the
phishing problem (at
Transport Card Broken)
http://www.garlic.com/~lynn/aadsm28.htm#24 Fixing SSL (was Re: Dutch
Transport Card Broken)
http://www.garlic.com/~lynn/aadsm28.htm#26 Fixing SSL (was Re: Dutch
Transport Card Broken)
-
The Cryptography
On 2/9/08, David Wagner [EMAIL PROTECTED] wrote:
By the way, it seems like one thing that might help with client certs
is if they were treated a bit like cookies.
I don't see how this helps with phishing. Phishers will just go after
the password or other secrets used to authenticate a new
On Sat, Feb 09, 2008 at 05:04:28PM -0800, David Wagner wrote:
By the way, it seems like one thing that might help with client certs
is if they were treated a bit like cookies. Today, a website can set
a cookie in your browser, and that cookie will be returned every time
you later visit that
They can't be as anonymous as cash if the party being dealt with
can be identified. And the party can be identified if the
transaction is online, real-time. Even if other clues are erased,
there's still traffic analysis in this case.
If I show up at a store and pay cash for something every
On Sun, Feb 03, 2008 at 09:24:48PM +1000, James A. Donald wrote:
Nicolas Williams wrote:
What, specifically, are you proposing?
I am still writing it up.
Running the web over UDP?
In a sense.
That should have been done from the beginning, even before security
became a problem.
Steven M. Bellovin [EMAIL PROTECTED] writes:
On Fri, 01 Feb 2008 13:29:52 +1300
[EMAIL PROTECTED] (Peter Gutmann) wrote:
Actually it doesn't even require X.509 certs. TLS-SRP and TLS-PSK
provide mutual authentication of client and server without any use of
X.509. The only problem has been
On Feb 1, 2008, at 9:34 PM, Ian G wrote:
* Browser vendors don't employ security people as we know them on
this mailgroup [...] But they are completely at sea when it comes
to systemic security failings or designing new systems.
I don't know about other browsers, but Mozilla's CSO-type is
Frank Siebenlist [EMAIL PROTECTED] writes:
That's actually a sad observation.
I keep telling my colleagues that this technology is coming any day now to
a browser near you - didn't realize that that there was no interest with the
browser companies to add support for this...
I know of a number
Nicolas Williams wrote:
Sounds a bit like SCTP, with crypto thrown in.
SCTP is what we should have done http over, though of
course SCTP did not exist back then. Perhaps, like
quite a few other standards, it still does not quite
exist.
I thought it was the latency cause by unnecessary
On Tue, Feb 05, 2008 at 08:17:32AM +1000, James A. Donald wrote:
Nicolas Williams wrote:
Sounds a bit like SCTP, with crypto thrown in.
SCTP is what we should have done http over, though of
course SCTP did not exist back then. Perhaps, like
quite a few other standards, it still does not
Peter Gutmann wrote:
Frank Siebenlist [EMAIL PROTECTED] writes:
That's actually a sad observation.
I keep telling my colleagues that this technology is coming any day now to
a browser near you - didn't realize that that there was no interest with the
browser companies to add support for
a recent reference
Research unmasks anonymity networks
http://www.techworld.com/security/news/index.cfm?newsID=11295
Research unmasks anonymity networks
http://www.networkworld.com/news/2008/020108-research-unmasks-anonymity.html
Research unmasks anonymity networks
On Wed, Feb 06, 2008 at 09:21:47AM -0800, Frank Siebenlist wrote:
With the big browser war still going strong, wouldn't that provide
fantastic marketing opportunities for Firefox?
If Firefox would support these secure password protocols, and the banks
would openly recommend their
On Thu, Jan 31, 2008 at 11:12:45PM -0500, Victor Duchovni wrote:
On Fri, Feb 01, 2008 at 01:15:09PM +1300, Peter Gutmann wrote:
If anyone's interested, I did an analysis of this sort of thing in an
unpublished draft Performance Characteristics of Application-level Security
Protocols,
Anne Lynn Wheeler [EMAIL PROTECTED] write:
one of my favorite exchanges from the mid-90s was somebody claiming
that adding digital certificates to the electronic payment
transaction infrastructure would bring it into the modern age. my
response was that it actually would regress the
At 09:34 PM 2/1/2008 +0100, Ian G wrote:
* Browser vendors don't employ security people as we know them on this
mailgroup, they employ cryptoplumbers. Completely different layer. These
people are mostly good (and often very good) at fixing security bugs. We
thank them for that! But they
StealthMonger wrote:
They can't be as anonymous as cash if the party being dealt with can
be identified. And the party can be identified if the transaction is
online, real-time. Even if other clues are erased, there's still
traffic analysis in this case.
What the offline paradigm has going
Victor Duchovni wrote:
SMTP does not need TCP to provide reliability for the tail of the session,
the application-level . (end-of-data) and server 250 response complete
a transaction, everything after that is optional, so for example Postfix
will send (when PIPELINING).
DATACRLF
(as if anyone uses client certificates anyway)?
Guess why so few people are using it ...
If it were secure, more people would be able to use it.
People don't use it because the workload of getting signed up is vastly
beyond their skillset, and the user experience using the things
Victor Duchovni wrote:
Jumping in late, but the idea that *TCP* (and not TLS protocol design)
adds round-trips to SSL warrants some evidence (it is very temping to
express this skepticism more bluntly).
With unextended SMTP for example, the minimum RTT count is:
0. SYN SYN-ACK
On Fri, Feb 01, 2008 at 01:15:09PM +1300, Peter Gutmann wrote:
Victor Duchovni [EMAIL PROTECTED] writes:
Jumping in late, but the idea that *TCP* (and not TLS protocol design) adds
round-trips to SSL warrants some evidence (it is very temping to express this
skepticism more bluntly).
If
On Wed, Jan 30, 2008 at 02:47:46PM -0500, Victor Duchovni wrote:
If someone has a faster than 3-way handshake connection establishment
protocol that SSL could leverage instead of TCP, please explain the
design.
I don't have one that exists today and is practical. But we can
certainly imagine
Eric Rescorla wrote:
(as if anyone uses client certificates anyway)?
Guess why so few people are using it ...
If it were secure, more people would be able to use it.
No, if it were *convenient* people would use it. I know of absolutely
zero evidence (nor have you presented any) that people
Victor Duchovni [EMAIL PROTECTED] writes:
Jumping in late, but the idea that *TCP* (and not TLS protocol design) adds
round-trips to SSL warrants some evidence (it is very temping to express this
skepticism more bluntly).
If anyone's interested, I did an analysis of this sort of thing in an
Ian G wrote:
The PII equation is particularly daunting, echoing Lynn's early '90s
experiences. I am told (but haven't really verified) that the
certificate serial number is PII and therefore falls under the full
weight of privacy law regs ... this may sound ludicrous, but privacy
and
Nicolas Williams wrote:
I don't have one that exists today and is practical. But we can
certainly imagine possible ways to improve this situation: move parts of
TLS into TCP and/or IPsec. There are proposals that come close enough
to this (see the last IETF SAAG meeting's proceedings, see the
Perry E. Metzger [EMAIL PROTECTED] writes:
SSL involves digital certificates.
Not really, James Donald/George W. Bush. It involves public keys, and it
provides a channel by which X.509 certificates can be exchanged,
Actually it doesn't even require X.509 certs. TLS-SRP and TLS-PSK provide
Peter Gutmann wrote:
Perry E. Metzger [EMAIL PROTECTED] writes:
SSL involves digital certificates.
Not really, James Donald/George W. Bush. It involves public keys, and it
provides a channel by which X.509 certificates can be exchanged,
Actually it doesn't even require X.509 certs. TLS-SRP
Frank Siebenlist wrote:
Why do the browser companies not care?
I spent a few years trying to interest (at least) one
browser vendor with looking at new security problems
(phishing) and using the knowledge that we had to solve this
(opportunistic cryptography). No luck whatsoever. My view
On Fri, Feb 01, 2008 at 07:58:16PM +, Steven M. Bellovin wrote:
On Fri, 01 Feb 2008 13:29:52 +1300
[EMAIL PROTECTED] (Peter Gutmann) wrote:
(Anyone have any clout with Firefox or MS? Without significant
browser support it's hard to get any traction, but the browser
vendors are too
Philipp Gühring wrote:
I once implemented SSL over GSM data channel (without PPP and without
TCP), and discovered that SSL needs better integrity protection than
raw GSM delivers. (I am quite sure that´s why people normally run PPP
over GSM channels ...) SSH has the same problems. It also
Eric Rescorla wrote:
Huh? What are you claiming the problem with sending
client certificates in plaintext is (as if anyone uses
client certificates anyway)?
Well that is one problem - no one uses them, and no one
should use them, while PKI was designed under the
assumption that everyone would
Perry E. Metzger wrote:
(No, I'm not a fan of X.509 certs, but those are not
core to the protocol, and you can think of them as
nothing more than a fancy key container format if you
like. Key management is not addressed by SSL, so there
is no reason that fixing key management has anything
Hi,
Huh? What are you claiming the problem with sending client certificates
in plaintext is
* It´s a privacy problem
* It´s a security problem for people with a security policy that requires the
their identities to be kept secret, and only to be used to authenticate to
the particular server
Philipp Gühring wrote:
Hi,
SSL key distribution and management is horribly broken,
with the result that everyone winds up using plaintext
when they should not.
Yes, sending client certificates in plaintext while claiming that SSL/TLS is
secure doesn´t work in a world of phishing and
On Wed, Jan 30, 2008 at 06:08:37PM -, Dave Korn wrote:
On 30 January 2008 17:01, Jim Cheesman wrote:
James A. Donald:
SSL is layered on top of TCP, and then one layers
one's actual protocol on top of SSL, with the result
that a transaction involves a painfully large number
of
At Thu, 31 Jan 2008 03:04:00 +0100,
Philipp Gühring wrote:
Hi,
Huh? What are you claiming the problem with sending client certificates
in plaintext is
* It´s a privacy problem
* It´s a security problem for people with a security policy that requires the
their identities to be kept
James A. Donald [EMAIL PROTECTED] writes:
Perry E. Metzger wrote:
(No, I'm not a fan of X.509 certs, but those are not
core to the protocol, and you can think of them as
nothing more than a fancy key container format if you
like. Key management is not addressed by SSL, so there
is no reason
(was Re: Dutch
Transport Card Broken)
TCP requires minimum of seven message exchange for reliable transport
VMTP (rfc 1045) got that down to minimum of five messages, and XTP
then
got it down to three messages minimum for reliable transport (disclaimer
we were on the XTP technical advisory
On Jan 30, 2008 9:04 PM, Philipp Gühring [EMAIL PROTECTED] wrote:
Hi,
Huh? What are you claiming the problem with sending client certificates
in plaintext is
* It´s a privacy problem
* It´s a security problem for people with a security policy that requires
the
their identities to be
de 2008 3:04
Para: Eric Rescorla
CC: Cryptography; Rasika Dayarathna
Asunto: Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Hi,
Huh? What are you claiming the problem with sending client certificates
in plaintext is
* It´s a privacy problem
* It´s a security problem for people
On Thu, Jan 31, 2008 at 02:28:30PM -0500, Anne Lynn Wheeler wrote:
TCP requires minimum of seven message exchange for reliable transport
VMTP (rfc 1045) got that down to minimum of five messages, and XTP
then
got it down to three messages minimum for reliable transport (disclaimer
we
SSL is layered on top of TCP, and then one layers one's
actual protocol on top of SSL, with the result that a
transaction involves a painfully large number of round
trips.
Perhaps theoretically painful, but in practice this is not the case;
commerce on the web is the counter-example. The
James A. Donald:
SSL is layered on top of TCP, and then one layers
one's actual protocol on top of SSL, with the result
that a transaction involves a painfully large number
of round trips.
Richard Salz wrote:
Perhaps theoretically painful, but in practice this is
not the case; commerce on
Hi,
SSL key distribution and management is horribly broken,
with the result that everyone winds up using plaintext
when they should not.
Yes, sending client certificates in plaintext while claiming that SSL/TLS is
secure doesn´t work in a world of phishing and identity theft anymore.
We
At Wed, 30 Jan 2008 09:04:37 +1000,
James A. Donald wrote:
Ivan Krstic' wrote:
Some number of these muppets approached me over the
last couple of years offering to donate a free license
for their excellent products. I used to be more polite
about it, but nowadays I ask that they
Why require contactless in the first place?
Is swiping one's card, credit-card style too difficult for the average
user? I'm thinking two parallel copper traces on the card could be
used to power it for the duration of the swipe, with power provided
by the reader. Why, in a
James A. Donald:
SSL is layered on top of TCP, and then one layers
one's actual protocol on top of SSL, with the result
that a transaction involves a painfully large number
of round trips.
Richard Salz wrote:
Perhaps theoretically painful, but in practice this is
not the case;
James A. Donald [EMAIL PROTECTED] writes:
James A. Donald:
SSL is layered on top of TCP, and then one layers
one's actual protocol on top of SSL, with the result
that a transaction involves a painfully large number
of round trips.
Richard Salz wrote:
Perhaps theoretically painful, but in
I don't disagree with your posting in general. I will note one thing:
Steven M. Bellovin [EMAIL PROTECTED] writes:
A transit system has to move people. For all that the New York City
Metrocard works, it's slower than a contactless wireless system.
As a consultant, I happen to have a lot of
Folks on this list and its progenitors have long noted that
cryptography is a matter of economics.
Agreed, but using an insecure technology doesn't make sense from even an
economic perspective. They spent enough money that they could have
implemented a secure system, but instead, made two
Philipp Gühring wrote:
Yes, sending client certificates in plaintext while claiming that SSL/TLS is
secure doesn´t work in a world of phishing and identity theft anymore.
We have the paradox situation that I have to tell people that they should use
HTTPS with server-certificates and
At Wed, 30 Jan 2008 17:59:51 -,
Dave Korn wrote:
On 30 January 2008 17:03, Eric Rescorla wrote:
We really do need to reinvent and replace SSL/TCP,
though doing it right is a hard problem that takes more
than morning coffee.
TCP could need some stronger integrity protection. 8
On 30 January 2008 17:01, Jim Cheesman wrote:
James A. Donald:
SSL is layered on top of TCP, and then one layers
one's actual protocol on top of SSL, with the result
that a transaction involves a painfully large number
of round trips.
Richard Salz wrote:
Perhaps theoretically painful,
On 30 January 2008 17:03, Perry E. Metzger wrote:
My main point here was, in fact, quite related to yours, and one that
we make over and over again -- innovation in such systems for its own
sake is also not economically efficient or engineering smart.
Hear hear! This maxim should be
On 30 January 2008 17:03, Eric Rescorla wrote:
We really do need to reinvent and replace SSL/TCP,
though doing it right is a hard problem that takes more
than morning coffee.
TCP could need some stronger integrity protection. 8 Bits of checksum isn´t
enough in reality. (1 out of 256
On Jan 25, 2008, at 4:27 PM, Perry E. Metzger wrote:
However, you should be very skeptical when someone claims that they
need to use a home grown crypto algorithm or that they need to
use a home grown protocol instead of
a well proven one.
I'm beginning to suspect that more often than
Perez
Cc: Cryptography
Subject: Re: Dutch Transport Card Broken
Not to defend the designers in any way or fashion, but I'd like to
ask, How much security can you put into a plastic card, the size of a
credit card, that has to perform its function in a secure manner, all
in under
2 seconds
Crawford Nathan-HMGT87 wrote:
Why require contactless in the first place?
Is swiping one's card, credit-card style too difficult for the average
user?
As compared to slapping your wallet on the reader? yes.
I swipe my Visa / debit / Tim Horton's cards regularly. With the
plethora of bad
Harald Koch [EMAIL PROTECTED] writes:
Crawford Nathan-HMGT87 wrote:
Why require contactless in the first place?
Is swiping one's card, credit-card style too difficult for the average
user?
As compared to slapping your wallet on the reader? yes.
I swipe my Visa / debit / Tim Horton's
Ivan Krstic' wrote:
Some number of these muppets approached me over the
last couple of years offering to donate a free license
for their excellent products. I used to be more polite
about it, but nowadays I ask that they Google the
famous Gutmann Sound Wave Therapy[0] and mail me
Not to defend the designers in any way or fashion, but I'd like to ask,
How much security can you put into a plastic card, the size of a credit
card, that has to perform its function in a secure manner, all in under
2 seconds (in under 1 second in parts of Asia)? And it has to do this
while
The per-card cost need not be such a big problem. Singapore has a
proximity-card-based system. They use the same card both for the
long-term cards and for the single-use cards. There is a S$ 2 (IIRC)
deposit on the card, which is refunded after the card is used. Waste
not want not!
/ji
Moin,
Am Thu, 24 Jan 2008 20:58:38 -0800 schrieb Aram Perez:
Not to defend the designers in any way or fashion, but I'd like to
ask, How much security can you put into a plastic card, the size of
a credit card, that has to perform its function in a secure manner,
all in under 2 seconds (in
How much security can you put into a plastic card, the size of a
credit card, that has to perform its function in a secure manner, all
in under 2 seconds (in under 1 second in parts of Asia)? And it has to
do this while receiving its power via the electromagnetic field being
generated by the
Hi Folks,
Ed Felten has an interesting post on his blog about a Dutch smartcard
based transportation payment system that has been broken. Among other
foolishness, the designers used a custom cryptosystem and 48 bit keys.
Not to defend the designers in any way or fashion, but I'd like to
Perry E. Metzger wrote:
Ed Felten has an interesting post on his blog about a Dutch smartcard
based transportation payment system that has been broken. Among other
foolishness, the designers used a custom cryptosystem and 48 bit keys.
http://www.freedom-to-tinker.com/?p=1250
The Dutch
Aram Perez wrote:
Not to defend the designers in any way or fashion, but I'd like to
ask, How much security can you put into a plastic card, the size of a
credit card, that has to perform its function in a secure manner, all
in under 2 seconds (in under 1 second in parts of Asia)? And it has
my impression has been that with lack of takeup of various kinds of security
solutions that were extensively marketed in the 90s ... that the current
situation has many of those same organizations heavily involved in behind
the scenes lobbying
saw some of that nearly a decade ago when we were
Aram Perez [EMAIL PROTECTED] writes:
Ed Felten has an interesting post on his blog about a Dutch smartcard
based transportation payment system that has been broken. Among other
foolishness, the designers used a custom cryptosystem and 48 bit keys.
Not to defend the designers in any way or
91 matches
Mail list logo
