Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-03-15 Thread Ben Laurie

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 rocket science. You have a public/private keypair. You can sign 
emails. For example, import your cardspace key into PGP.




--
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-22 Thread Peter Gutmann
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 would do,

Correction, exactly like phishing criminals are actively doing right now
(hat tip to Don Jackson of SecureWorks who's investigated and documented this
practice).  Given the almost complete failure of client certs in the
marketplace, I found it most amusing that the current active users of client
certs are phishers.  It reminded me of spammers and SPF.

   Title:   Sender driven certification enrollment system
   Document Type and Number:  United States Patent 6651166
   Link to this page:  http://www.freepatentsonline.com/6651166.html

   Filing Date: 04/09/1998
   Publication Date: 11/18/2003

Thus postdating Microsoft's CertEnroll/Certenr3/Xenroll ActiveX control by
several years.  The only difference here is that the user generates the cert
directly rather than involving a CA.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-21 Thread Thierry Moreau



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:  http://www.freepatentsonline.com/6651166.html
Abstract:
A sender driven certificate enrollment system and methods of its
use are provided, in which a sender controls the generation of a
digital certificate that is used to encrypt and send a document
to a recipient in a secure manner. The sender compares
previously stored recipient information to gathered information
from the recipient. If the information matches, the sender
transfers key generation software to the recipient, which
produces the digital certificate, comprising a public and
private key pair. The sender can then use the public key to
encrypt and send the document to the recipient, wherein the
recipient can use the matching private key to decrypt the
document.



Some feedback on the above security certificate issuance process.

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 would do, and

a java software utility downloaded from the web should not be allowed to
modify security-critical parameters on the local machine.


According to my records, this issuance process is nonetheless
representative of research directions for user enrollment, i.e. there
aren't too many other documented processes in this area.

Regards,


--

- Thierry Moreau

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

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [EMAIL PROTECTED]



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-14 Thread Bill Squier


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 the market ...


We (Morgan Stanley) were able to pressure them into a rapid fix, and  
they have committed to delivering it in SP1.  Keep your fingers crossed.


If anyone needs more information how to upgrade your Web-based CA  
for IE7:

http://wiki.cacert.org/wiki/IE7VistaSource


Step (2), On Vista you have to add this website to the list of  
trusted sites in the internet-settings. can be quite unpalatable.   
Depending on your customers' situations, an alternative might be more  
palatable: Generate the key and deliver a PKCS#12.


This depends on whether you believe in the non-repudiation fairy or  
not -- or more accurately, whether you're already assuming the  
repudiation risk.


-wps

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-14 Thread RL 'Bob' Morgan


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 authenticate itself.  For instance, boa.com might 
instruct my browser to create one private key for use with *.boa.com; 
later, citibank.com could instruct my browser to create a private key 
for use with *.citibank.com.  By associating the private key with a 
specific DNS domain (just as cookies are), this means that the privacy 
implications of client authentication would be comparable to the privacy 
implications of cookies.  Also, in this scheme, there wouldn't be any 
need to have your public key signed by a CA; the site only needs to know 
your public key (e.g., your browser could send self-signed certs), which 
eliminates the dependence upon the third-party CAs. Any thoughts on 
this?


You don't have to imagine this.  It is exactly how Infocard (the generic 
name of the technology of which Microsoft's CardSpace is one 
implementation of one component) works in its most common mode (the 
personal or self-issued card).  It has lots of other benefits as well even 
in this mode (user-managed attributes, graphical UI) as well as other 
modes to support identity providers (managed cards).


Lest you think that this is Microsoft-only, be assured that there is a 
large community building implementations for many other platforms and 
systems.  OSIS (http://osis.idcommons.net/) is the prime venue for people 
to work on interoperability across the spectrum of implementations. 
There's a big interop event coming up at the RSA conference in April.


If you'd like to help make your scenario a pervasive reality, check it 
out.


 - RL Bob

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-14 Thread RL 'Bob' Morgan


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 good idea.  If your monitor starts
   smoking due to the friction generated, please cutpaste one of the two
   elsewhere.


Actually lots of Liberty and WS/Infocard/etc people are working on interop 
scenarios, see:


  http://projectconcordia.org/index.php/Main_Page

 - RL Bob

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-13 Thread James Cloos
 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 package of its own
on several dists, is written in C, is MPL|GPL|LGPL and has its own page at:

http://www.mozilla.org/projects/security/pki/nss/

The Gentoo ebuild even installs a pkgconfig file.

I don't recall seeing anything !zilla using it, though.

-JimC
-- 
James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-13 Thread Philipp Gühring
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 the IE7 browser APIs for this are completely different and rather
 minimally documented. The interfaces are not portable between browsers,
 ... It's a mess.

I can fully confirm this.

Microsoft claimed that they had to rewrite the API to make it more secure, but 
I only found one small security-relevant weakness that they fixed, the others 
are still there. (And even that fix wouldn´t have justified a rewrite of the 
API for websites. They could have kept the frontend-API compatible in my 
opinion.)

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 ...

If anyone needs more information how to upgrade your Web-based CA for IE7:
http://wiki.cacert.org/wiki/IE7VistaSource

Best regards,
Philipp Gühring

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-10 Thread James A. Donald

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 banks and health care, initial account setup always
involves out of band communication, so certificate
checking not needed.

We need to build our security mechanisms to fit
characteristic human out of band security, rather than
trying to force humans to imitate computers.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-10 Thread Leichter, Jerry
| 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 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
| authenticate itself.  For instance, boa.com might instruct my browser
| to create one private key for use with *.boa.com; later,
| citibank.com could instruct my browser to create a private key for
| use with *.citibank.com.  By associating the private key with a specific
| DNS domain (just as cookies are), this means that the privacy
| implications of client authentication would be comparable to the
| privacy implications of cookies.  Also, in this scheme, there wouldn't
| be any need to have your public key signed by a CA; the site only needs
| to know your public key (e.g., your browser could send self-signed
| certs), which eliminates the dependence upon the third-party CAs.
| Any thoughts on this?
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:  http://www.freepatentsonline.com/6651166.html
Abstract:
A sender driven certificate enrollment system and methods of its
use are provided, in which a sender controls the generation of a
digital certificate that is used to encrypt and send a document
to a recipient in a secure manner. The sender compares
previously stored recipient information to gathered information
from the recipient. If the information matches, the sender
transfers key generation software to the recipient, which
produces the digital certificate, comprising a public and
private key pair. The sender can then use the public key to
encrypt and send the document to the recipient, wherein the
recipient can use the matching private key to decrypt the
document.

This was work done a Xerox.  I was trying to find a different report
at Xerox in response to Peter Gutmann's comment that certificate aren't
used because they are impractical/unusable.  Parc has done some wonderful
work on deal with those problems.  See:

http://www.parc.com/research/projects/usablesecurity/wireless.html

Not Internet scale, but in an enterprise, it should work.

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-10 Thread Anne Lynn Wheeler

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. recent reference
http://www.garlic.com/~lynn/2008c.html#31 Kerberized authorization service

part of the scenario for cookie/ticket encryption ... involving
servers, is brute force attack on the server secret key. the cookie
instead of all encrypted data ... has some sort of client registration
value ... analogous to an account number or userid. the cookie caries the
registration value followed by the server encrypted data.  the
encryption part uses a derived key ... formed by combination of the
server's secret key and the client's registration value. these derived
key scenarios are also found in transit system operation (both
magstripe and memory chip) as well as financial transactions.

the issue then is initial registration ... the part where the user
chooses their userid (and/or the client registration value is
otherwise selected) and supplies a password (but in this case a public
key). m'soft and others have been using CAPTCHA to weed-out the
non-humans, but this has come under attacks. reference to recent news
items
http://www.garlic.com/~lynn/2008d.html#2 Spammer' bot cracks Microsoft's 
CAPTCHA


the ticket/cookie carries the clients public key (and whatever other
characteristics) ... which then can be used by the server(s) to
perform dynamic authentication (digital signing of some server
supplied, random data, countermeasure to replay attacks). this is in
lieu of server having to maintain the client account record ... ala a
RADIUS scenario where public key has been registered in lieu of a
password (some sort of online access to RADIUS account
records). various RADIUS public key in lieu of password postings:
http://www.garlic.com/~lynn/subpubkey.html#radius

the ticket/cookie scenario (with derived key encryption) is cross
between dynamic server-side account record data (say RADIUS
repository) and stale, static digital certificate scenario. as in the
transit gate operation, the ticket/cookie could also be retrieved,
decrypted, updated, re-encrypted, and returned as part of the
operation. initial server hand-shakes can include server sending some
random challenge data. The client returns the digital signature
and their previously obtained cookie. in the straight RADIUS public
key handshake scenario, just the digital signature and client
userid/account-number is returned since the rest of the cookie/ticket
equivalent info is online in the RADIUS account repository.

The straight RADIUS scenario would be to combine the server-side
random challenge data and combine it with the client registration
value (account number, userid) and whatever else the client-side
digital signing requires ... and return the userid/account-number
any other data and digital signature (i.e. server-side has to be
able to reconstruct what the client actually digitally signed
as part of verifying the digital signature). In the straight RADIUS
scenario, the public key (and any associated permissions, authorization,
etc) is obtained from the RADIUS repository. In cookie/ticket
scenario, it is obtained from the cookie/ticket appended to the
message.

The business process still has the initial registration phase
... where the original cookie is created (or in the RADIUS
scenario, where the userid definitiion is initially created) and the
public key is supplied (in lieu of a password).

This is also effectively the original certificateless pk-init scenario
for kerberos (aka public key in lieu of password)
http://www.garlic.com/~lynn/subpubkey.html#kerberos

The cookie scenario is standard client/server ... attempting
to eliminate the server having to retain the account
record on behalf of every client (as in either the RADIUS
and/or KERBEROS scenario). Encrypting of the cookie data
is standard ... although transit systems and financial transactions
have gone to derived key for the situation ... as countermeasure
to brute force attack on the infrastructure secret key.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-10 Thread Ian G

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 wondering... why not
release it with TLS-PSK/SRP anyway (particularly with 3.0 being in the beta
stage, it'd be the perfect time to test new features), tested against existing
implementations, then at least it's ready for when server support appears.  At
the moment we seem to be in a catch-22, servers don't support it because
browsers don't, and browsers don't support it because servers don't.



I would say that this would not hold the FF developers back, 
as they were definately capable of implementing TLS/SNI 
extension a year or two back, without any support from 
stable libraries in Apache httpd, Microsoft IIS, etc (still 
waiting...).


I'd also suggest that the TLS/SNI (which will apparently 
turn up one day in Apache) will have a much more dramatic 
effect on phishing than TLS-PSK/SRP ... because of the 
economics of course.  Lowering the barriers on all TLS use 
is far more important than making existing TLS use easier.


Of course, this is not a competition, as the effect adds, 
not competes.  The good thing is that we may actually get to 
see the effects of both fixes to TLS rollout at similar 
times.  In economics, it is a truism that we can't run the 
experiment, we have to watch real life, Heisenberg style, 
and this may give us a chance to do that.


Also, we can observe another significant factor in the mix: 
 the rollout of virtual machine platforms (xen and the 
like) is dramatically changed the economics of IP#s, these 
now becoming more the limiting factor than they were, which 
might also put more pressure on Apache ... to release 
earlier and more often.


iang

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-10 Thread Werner Koch
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 OpenSSL and how do they solve the
GPL/OpenSSL license incompatibility?


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-09 Thread Peter Gutmann
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 with TLS-PSK/SRP anyway (particularly with 3.0 being in the beta
stage, it'd be the perfect time to test new features), tested against existing
implementations, then at least it's ready for when server support appears.  At
the moment we seem to be in a catch-22, servers don't support it because
browsers don't, and browsers don't support it because servers don't.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-09 Thread Steven M. Bellovin
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 browser developers, (2) is a bit more
 complex to estimate because it's on a per-site basis, but in general
 since the raw data (username+pw) is already present it's mostly a
 case of redoing the data flow a bit, and not necessarily rebuilding
 the whole system from scratch.  To give one example, a healthcare
 provider, they currently trigger an SQL query from an HTTP POST that
 looks up the password with the username as key, and the change would
 be to do the same thing at the TLS stage rather than the post-TLS
 HTTP stage.

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.


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

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-09 Thread Peter Gutmann
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 opportunities for free
browser like Firefox, but this seems to be stalled pretty much idefinitely
because since CAcert doesn't charge for certificates, including it in Firefox
would upset the commercial CAs that do (there's actually a lot more to it than
this, see the interminable flamewars on this topic on blogs and whatnot for
more information).

If Firefox would support these secure password protocols, and the banks would
openly recommend their customers to use Firefox because its safer and
protects them better from phishing, that would be great publicity for
Firefox, draw more users, and force M$ to support it too in the long run...

Here's a suggestion to list members:

- If you know a Firefox developer, go to them and tell them that TLS-PSK and
  TLS-SRP support would be a fantastic selling point and would allow Firefox
  to trump IE in terms of resisting phishing, which might encourage banks to
  recommend it to users in place of IE.

- If you know anyone with some clout at Microsoft, tell them that your
  organisation is thinking of mandating a switch to Firefox because IE doesn't
  support phish-resistant authentication like TLS-PSK/TLS-SRP, and since you
  have x million paying customers this won't look good for MS.

- If you work for any banking regulators (for example the FFIEC), require
  failsafe authentication (in which the remote site doesn't get a copy of your
  credentials if the authentication fails) rather than the current two-factor
  auth (which has lead to farcical two-factor mechanisms like SiteKey).

Oh, and don't tell them I put you up to this :-).

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-09 Thread Peter Gutmann
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 really depends on the value of the account, for high-value ones I would
hope it's done out-of-band (so you can't just sign up for online banking by
going to a bank's purported web page and saying Hi, I'm Bob, give me access
to my account), and for low-value stuff like Facebook I'm not sure how much
effort your password is worth to an attacker when they can get a million
others from the same site.  I agree that it's still a problem, but switching
to failsafe auth is a major attack surface reduction since now an attacker has
to be there at the initial signup rather than at any arbitrary time of their
choosing.  It's turning an open channel into a time- and location-limited
channel.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-09 Thread Victor Duchovni
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 devlopers' reason for holding back?  Just wondering... why not
 release it with TLS-PSK/SRP anyway (particularly with 3.0 being in the beta
 stage, it'd be the perfect time to test new features), tested against existing
 implementations, then at least it's ready for when server support appears.  At
 the moment we seem to be in a catch-22, servers don't support it because
 browsers don't, and browsers don't support it because servers don't.

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,
with binaries (dynamically) linked against the default OpenSSL on the
oldest supported release of each platform... For RedHat 4.x systems,
for example, that means that binary packages use 0.9.7...

Distributions that build their own Firefox from source may at some point
have PSK (once they ship OpenSSL 0.9.9). I don't think we will see this
available in many user's hands for 2-3 years after the code is written
(fielding new systems to the masses takes a long time...).

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-09 Thread David Wagner
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 least, the problem of theft of web authenticators
-- it obviously won't help with theft of SSNs).  If users don't know
the authentication secret, they can't reveal it.  The nice thing about
using client certs instead of passwords is that users don't know the
private key -- only the browser knows the secret key.

The standard concerns I've heard are: (a) SSL client supports aren't
supported very well by some browsers; (b) this doesn't handle the
mobility problem, where the user wants to log in from multiple different
browsers.  So you'd need a different mechanism for initially registering
the user's browser.

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 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
authenticate itself.  For instance, boa.com might instruct my browser
to create one private key for use with *.boa.com; later,
citibank.com could instruct my browser to create a private key for
use with *.citibank.com.  By associating the private key with a specific
DNS domain (just as cookies are), this means that the privacy
implications of client authentication would be comparable to the
privacy implications of cookies.  Also, in this scheme, there wouldn't
be any need to have your public key signed by a CA; the site only needs
to know your public key (e.g., your browser could send self-signed
certs), which eliminates the dependence upon the third-party CAs.
Any thoughts on this?

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-09 Thread Anne Lynn Wheeler

David Wagner wrote:

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 least, the problem of theft of web authenticators
-- it obviously won't help with theft of SSNs).  If users don't know
the authentication secret, they can't reveal it.  The nice thing about
using client certs instead of passwords is that users don't know the
private key -- only the browser knows the secret key.

The standard concerns I've heard are: (a) SSL client supports aren't
supported very well by some browsers; (b) this doesn't handle the
mobility problem, where the user wants to log in from multiple different
browsers.  So you'd need a different mechanism for initially registering
the user's browser.

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 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
authenticate itself.  For instance, boa.com might instruct my browser
to create one private key for use with *.boa.com; later,
citibank.com could instruct my browser to create a private key for
use with *.citibank.com.  By associating the private key with a specific
DNS domain (just as cookies are), this means that the privacy
implications of client authentication would be comparable to the
privacy implications of cookies.  Also, in this scheme, there wouldn't
be any need to have your public key signed by a CA; the site only needs
to know your public key (e.g., your browser could send self-signed
certs), which eliminates the dependence upon the third-party CAs.
Any thoughts on this?
   


in AADS
http://www.garlic.com/~lynn/x959.html#aads
and certificateless public key
http://www.garlic.com/~lynn/subpubkey.html#certless

we referred to the scenario as person-centric ... as a contrast
to institutional-centric oriented implementations.

past posts in this thread:
http://www.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (was Re: Dutch 
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 Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-09 Thread Taral
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 system or a
system that has lost its cert.

-- 
Taral [EMAIL PROTECTED]
Please let me know if there's any further trouble I can give you.
-- Unknown

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-09 Thread Victor Duchovni
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 website.  This all happens automatically.  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
 authenticate itself.  For instance, boa.com might instruct my browser
 to create one private key for use with *.boa.com; later,
 citibank.com could instruct my browser to create a private key for
 use with *.citibank.com.

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 the IE7 browser APIs for this are completely different and rather
minimally documented. The interfaces are not portable between browsers,
... It's a mess.

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-06 Thread John Levine
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 week, they
can still do traffic analysis on me (oh him, he's a regular
customer) unless I go out of my way to obscure my routine like asking
other people to buy stuff for me.

It's not clear to me what the object of this argument is.  Yes, the
harder you work, the more difficult you can make it for other people
to tie your transactions to you.  This shouldn't be news to anyone.

R's,
John


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-06 Thread Nicolas Williams
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.  TCP is a poor fit to a transactional protocol, as the 
 gyrations with Keep-alive and its successors illustrate.

In the beginning most pages were simple enough that to speak of
transactional protocol is almost an exageration.  Web techonologies
grew organically.  Solutions to the various resulting problems will, I
bet, also grow organically.

A complete revamping is probably not in the cards.  But if one should be
then it should not surprise you that I'm all in favor of piercing
abstraction layers.  User authentication should happen that the
application layer, and session crypto should happen at the transport
layer, with everything cryptographically bound up.  In any case we
should re-use what we know works (e.g., ESP/AH for transport session
crypto, IKEv2/TLS/DTLS for key exchange, ...).

 In rough summary outline, what I propose is to introduce a distinction 
 between connections and streams, that a single long lasting connection 
 contains many transient streams.  This is equivalent to TCP in the case 
 that a single connection always contains exactly two streams, one in 
 each direction, and the two streams are created when the connection is 
 created and shut down when the connection is shut down, but the main 
 objective is to support usages that are not equivalent to TCP. This is 
 pretty much the same thing as T/TCP, except that a connection can have 
 a large shared secret associated with it to encrypt the streams.  For an 
 unencrypted connection, it can be spoof flooded the same way as T/TCP 
 can be spoof flooded, 

Sounds a bit like SCTP, with crypto thrown in.

   but the main design objective is to make 
 encryption efficient enough that one always encrypts everything.

I thought it was the latency cause by unnecessary round-trips and
expensive key exchange crypto that motivated your proposal.  The cost of
session crypto is probably not as noticeable as that of the latency of
key exchange and authentication.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-06 Thread Peter Gutmann
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 getting vendors to support it,
 several smaller implementations support it, it's in the (still
 unreleased) OpenSSL 0.99, and the browser vendors don't seem to be
 interested at all, which is a pity because the mutual auth (the
 server has to prove possession of the shared secret before the client
 can connect) would significantly raise the bar for phishing attacks.

 (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 busy chasing phantoms like EV certs).

The big issue is prompting the user for a password in a way that no one will
confuse with a web site doing so.

HCI people have been studying this for quite some time, and there's been a lot
of good work done in this area.  Because of the amount of information, I'll
answer indirectly via a link (warning, it's a partial book draft and is
currently ~140 pages long):

http://www.cs.auckland.ac.nz/~pgut001/pubs/usability.pdf

Even without this detailed analysis, one of the Mac browsers (Safari?) already
has a quite distinctive password prompt that rolls down out of the menu bar at
the top.  Sure, you can spoof that if you own the browser, but if malware owns
your browser then you're toast anyway.

It might have been the right thing, once upon a time, but the horse may be
too far out of the barn by now to make it worthwhile closing the barn door.

That's the response I got from a browser developer when I talked about this
about a year ago, Sufficiently sophisticated malware can spoof any piece of
browser UI, so let's just give up and admit that the phishers have won.  At
the moment, after 15-odd years of work, the state of the art for both major
secure-channel protocols is to connect to anything listening on port 22 or 443
and then hand over the user's password in plaintext form (although inside a
secure tunnel, as if that made any difference) [0].  This is only just barely
better than the 1970s-era telnet in that the authenticator is still handed
over in plaintext, but at least you can't capture it with a packet sniffer.
Moving to a challenge-response mechanism (which PSK and SRP aren't really,
it's more a bit-commitment since there's no real challenge or response process
[1]) would at least move the security into the late 1980s.

As a side-note, I was talking to a security person from a large (multi-
national) bank recently and they mentioned that they were slowing down on the
push to move to two-factor auth (real two-factor auth with SecurIDs and the
like, not the gimmicks that US banks are using :-) because the problem isn't
authenticating the user, it's authenticating the server and/or the
transaction, and most two-factor auth tokens can't do that.  As a result
they're not going to commit to sinking much more money into something that
doesn't actually solve the problem.  So mutual client/server auth is something
that's of concern to more than just some geeks on security mailing lists, it's
coming onto the radar of large financial institutions as well.

Peter.

[0] By 443 I mean HTTP over SSL/TLS, obviously.

[1] Actually this is neither challenge-response nor bit-commitment so in the
absence of anything better I'll propose failsafe authentication because
the other side doesn't get your authenticator unless they can prove they
already possess it.  In other words if the authentication process fails,
it fails safe.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-06 Thread Ivan Krstić

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 Window  
Snyder who I'd easily describe as a pretty top-notch security person.


--
Ivan Krstić [EMAIL PROTECTED] | http://radian.org
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-06 Thread Peter Gutmann
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 of organisations (mostly governmental, but also some
financial) in various countries who are really, really keen to get support for
(as James Donald pointed out) cryptographically secured relationships (not
requiring PKI would be a big feature) into browsers, but no-one knows who to
beat over the head about it.  The last group I talked to (banks) were hoping
to use commercial pressure to get MS to add support for it in IE7^H^H8 at
which point Firefox would be forced to follow, but it's a slow process.

Why do the browser companies not care?
What is the adoption issue?
Still the dark cloud of patents looming over it?
Not enough understanding about the benefits? (marketing)
Economic reasons that we wouldn't buy anymore server certs?

I think it's a combination of two factors:

1. Everyone knows that passwords are insecure, so it's not worth trying to do
   anything with them.

   (My counter-argument to this is that passwords are only insecure because
   protocol designers have chosen to make them insecure, see my previous post
   about the quaint 1970s-vintage hand-over-the-password model used by SSH and
   SSL/TLS).

2. If you add failsafe authentication to browsers, CAs become redundant.

   (My counter-argument to this is to ask whether browser security exists in
   order to provide a business model for CAs or to protect users.  Currently
   it seems to be the former, with EV certs being a prime example).

There are probably other contributory reasons as well.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-06 Thread James A. Donald

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
 round-trips and expensive key exchange crypto that
 motivated your proposal.  The cost of session crypto
 is probably not as noticeable as that of the latency
 of key exchange and authentication.

The big problem is that between the time one logs on to
one's bank, and the time one logs off, one is apt to
have done lots and lots of cryptographic key exchanges.
One key exchange per customer session is a really small
cost, but we have a storm of them.

Whenever the web page shows what is particular to the
individual rather than universal, it uses a session
cookie, visible to server side web page code.
Encryption, the bundle of shared secrets that enable
encrypted communications, should be visible at that
level, should be a session cookie characteristic rather
than a low level transport characteristic, should have
the durability and scope of a session cookie, instead of
the durability and scope of a transaction.

Because we use encryption merely at a level where it is
logically transient, because it protects transactions
rather than relationships, the connections are too
costly, and fail to provide the information about
relationships that are needed to protect the user.

If we had implemented http over something like SCTP,
then an SCTPlike connection value should have been a
cookie.  One should have been able to look at the
SCTPlike connection value in the server side page code,
and be pretty sure that if the person is the same, the
connection value will be unchanged, so that one could
then associate additional state with the connection
value - encryption being some more state.

Encryption parameters have more in common with session
cookies than with transactions.  They should be about
relationships, not data transport.

If encryption setups were made and discarded only as
often as session cookies, not so costly.  It is making
them and discarding them as often as transactions that
hurts. Also, the fact that they are so frequently
discarded means that scope information is unavailable to
secure relationships, means we cannot provide useful
information to the end user about who he is really
talking to, because the encryption does not know about
relationships, even though encryption should be about
relationships.

With encryption merely at the transactional level, the
browser can know the true name of website you are
looking at, that being merely a page property, but
cannot know what relationship you think you are
participating in.  To provide security, client side
code, browser chrome, needs to know not the true name of
the web site, but if you are at a web site where you
have user name or durable user ID.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-06 Thread Nicolas Williams
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 quite
 exist.

Proposing something new won't help make that available sooner than SCTP
if that something new, like SCTP, must be implemented in kernel-land.

  I thought it was the latency cause by unnecessary
  round-trips and expensive key exchange crypto that
  motivated your proposal.  The cost of session crypto
  is probably not as noticeable as that of the latency
  of key exchange and authentication.
 
 The big problem is that between the time one logs on to
 one's bank, and the time one logs off, one is apt to
 have done lots and lots of cryptographic key exchanges.
 One key exchange per customer session is a really small
 cost, but we have a storm of them.

This is what session resumption is all about, and now that we have a way
to do it without server-side state (RFC4507) there should be no more
complaints.

If the latency of multiple key exchanges is the issue then we should
push for deployment of RFC4507 before we go push for a brand new
transport protocol.

 Whenever the web page shows what is particular to the
 individual rather than universal, it uses a session
 cookie, visible to server side web page code.
 Encryption, the bundle of shared secrets that enable
 encrypted communications, should be visible at that
 level, should be a session cookie characteristic rather
 than a low level transport characteristic, should have
 the durability and scope of a session cookie, instead of
 the durability and scope of a transaction.

If I understand what you mean then the ticket in RFC4507 is just that.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-06 Thread Frank Siebenlist

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 this...


I know of a number of organisations (mostly governmental, but also some
financial) in various countries who are really, really keen to get support for
(as James Donald pointed out) cryptographically secured relationships (not
requiring PKI would be a big feature) into browsers, but no-one knows who to
beat over the head about it.  The last group I talked to (banks) were hoping
to use commercial pressure to get MS to add support for it in IE7^H^H8 at
which point Firefox would be forced to follow, but it's a slow process.



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 customers to use Firefox because its safer 
and protects them better from phishing, that would be great publicity 
for Firefox, draw more users, and force M$ to support it too in the long 
run...




Why do the browser companies not care?
What is the adoption issue?
Still the dark cloud of patents looming over it?
Not enough understanding about the benefits? (marketing)
Economic reasons that we wouldn't buy anymore server certs?


I think it's a combination of two factors:

1. Everyone knows that passwords are insecure, so it's not worth trying to do
   anything with them.

   (My counter-argument to this is that passwords are only insecure because
   protocol designers have chosen to make them insecure, see my previous post
   about the quaint 1970s-vintage hand-over-the-password model used by SSH and
   SSL/TLS).



...these protocol would even make the use of one-time-passwords more 
secure (no MITM exposure - phishing), and make them securely usable 
without any server-certs...




2. If you add failsafe authentication to browsers, CAs become redundant.

   (My counter-argument to this is to ask whether browser security exists in
   order to provide a business model for CAs or to protect users.  Currently
   it seems to be the former, with EV certs being a prime example).



I was afraid that this cynical argument would play a role... so the 
server-cert racketeering scheme has just been made more profitable 
through more expensive but equally trustworthy EV-certs, which makes 
it more difficult to introduce alternatives that don't fit into this 
business model...


On the other hand, I'm sure that the marketeers will be able to sell 
server-certs together with those secure passwords protocols to the naive 
customers as it will be very difficult to explain why you do/don't need 
the certs and why it would more/less secure...


-Frank.

--
Frank Siebenlist   [EMAIL PROTECTED]
The Globus Alliance - Argonne National Laboratory

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-06 Thread Anne Lynn Wheeler

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
http://www.arnnet.com.au/index.php/id;1270745171;fp;4194304;fpid;1
Paper Outlines Methods for Beating Anonymity Technology
http://www.darkreading.com/document.asp?doc_id=144606

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-06 Thread Victor Duchovni
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 customers to use Firefox because its safer 
 and protects them better from phishing, that would be great publicity 
 for Firefox, draw more users, and force M$ to support it too in the long 
 run...

It is a bit early. OpenSSL 0.9.9 is not yet released. I wish OpenSSL
releases were more frequent, and each added fewer features, allowing
features to be released as they mature, this would also reduce pressure
to add features to stable releases (which occasionally break binary
compatibility, and lead to vendors back-porting fixes rather than deploying
the next patch level of the stable release).

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.

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-03 Thread Nicolas Williams
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, http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf.  It
  compares (among other things) the cost in RTT of several variations of SSL 
  and
  SSH.  It's not the TCP RTTs that hurt, it's all the handshaking that takes
  place during the crypto connect.  SSH is particularly bad in this regard.
 
 Thanks, an excellent reference! Section 6.2 is most enlightening, we were
 already considering adopting HPN fixes in the internal OpenSSH deployment,
 this provides solid material to motivate the work...

To be fair, the handbrake in SFTP isn't -- the clients and servers
should be using async I/O and support interleaving the transfers of many
files concurrently, which should allow the peers to exchange data as
fast as it can be read from disk.

The same is true of NFS, and keep in mind that SFTP is more of a remote
filesystem protocol than a file transfer protocol.

But nobody writes archivers that work asynchronously (or which are
threaded, since, e.g., close(2) has no async equivalent, and is required
to be synchronous in the NFS case).  And nobody writes SFTP clients and
server that work asynchronously.  But, we could, and we should.

And the handbrake in the SSHv2 connection protocol has its rationale as
well (namely to allow interactive sessions to be responsive).  As
described in Peter's paper, it can be turned off, effectively.  It's
most useful when mixing interactive sessions and X11 display forwarding
(and port forwarding which don't involve bulk data transfers).  It's
most useless when doing bulk transfers.  So use separate connections for
bulk transfers.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-03 Thread StealthMonger
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 infrastructure at
 least a couple decades to the time when online, real-time
 transactions weren't being done.  The online, real-time transaction
 provides much higher quality and useful information than a stale,
 static digital certificate (with an offline paradigm from before
 modern communication).  Having an available repository about the
 party being dealt with ... including things like timely, aggregated
 information (recent transactions) is significantly mover valuable
 than the stale, static digital certificate environment (the only
 thing that it has going for it, is it is better than nothing in the
 oldtime offline environment).


 [...]

 EU had also made a statement in the mid-90s that electronic retail
 payments should be as anonymous as cash.

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 for it is the possibility of true,
untraceable anonymity through the use of anonymizing remailers and
related technologies.


 -- StealthMonger [EMAIL PROTECTED]

 --
   stealthmail: Scripts to hide whether you're doing email, or when,
   or with whom.  http://stealthsuite.afflictions.org

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-03 Thread Alex Alten

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 are completely at sea when it comes to 
systemic security failings or designing new systems.


An excellent observation Ian!!

I too have run into this mindset at enterprises with inhouse security teams 
(mostly in Silicon Valley).  They focus on the nuts and bolts like 
producing/using cryptographic libaries, fixing security bugs in code or 
configuring network appliances to stop intrusions.  But it is really hard 
to find any of them with decent experience or knowledge at the overall 
software/hardware/people system design level. They are often very smart and 
educated engineers. I find that there's this mindless focus on using 
groups of security standards, e.g PKI / LDAP / SSL type of combinations, 
etc.  The DoD contractor firms seem to be a little bit better at 
recognizing the system level aspects of security, although they too are 
often blinded by the emphasis on COTS security products.


- Alex
--

Alex Alten
[EMAIL PROTECTED]



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-03 Thread Anne Lynn Wheeler

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 for it is the possibility of true,
untraceable anonymity through the use of anonymizing remailers and
related technologies.

   


most people who heard the statement, understood that.

i think that possibly 2nd level detail was that they didn't want
PII easily associated by casual merchant. Initial response was to remove
name from payment cards  magstripes. This also precluded
merchants from requesting other forms of identification to
see if the names matched the name on the payment card.
The implication being that the payment infrastructure would
have to come up with other mechanisms to improve
the infrastructure integrity.

The offline payment paradigms ... while touting true
anonymity were actually primarily justified based on
other factors.

We had been asked to design and cost the dataprocessing
supporting US deployments of some of the offline products
(that were being used in Europe). Along the way, we did
some business process and revenue analysis and realized
that the primary motivation behind these system deployments
was the float.

About the same time that there was the EU about the
privacy of electronic retail payments ... there was also
a statement by the EU (and some of the country central
banks) that the offline products would be allowed to
keep the float for a short grace period  to help in
the funding of the infrastructure deployment ... but
after the grace period ... the operators would have to
start paying interest on the balance held in the offline
instruments (eliminating float from the equation).
After that, much of the interest in the offline
deployments drifted away.

In that time frame we had also done design, implementation
and deployment of a payment transaction infrastructure
supporting target marketing ... recent reference
http://www.garlic.com/~lynn/2008c.html#27 Diversity

support was for a small pilot of 60mil accounts and
1.5million transaction/day ... but capable of scaling
up to 20-30 times that amount. There was significant
attention paid to privacy issues and it was subject
to quarterly auditing by some dozen or so privacy
organizations. there had to be a large amount
of sensitive treatment of the information along
the lines of what HIPAA specifies for health information.

aka:

anonymized
 Previously identifiable data that have been deidentified and for
 which a code or other link no longer exists. An investigator would
 not be able to link anonymized information back to a specific
 individual. [HIPAA] (see also anonymous, coded, directly
 identifiable, indirectly identifiable)

as part of co-authoring x9.99 financial privacy standard, one
of the things we created was a privacy merged glossory and
taxonomy ... including GLBA, HIPAA, and EU-DPD references
some notes:
http://www.garlic.com/~lynn/index.html#glosnote

in our work on x9.59 financial transaction standard
http://www.garlic.com/~lynn/x959.html#x959

we made the statement that it was privacy agnostic ... since
the transactions were tied to accounts ... but then whether or
not the accounts were tied to individuals was outside the x9.59
standard
http://www.garlic.com/~lynn/subpubkey.html#x959

As a total aside ... as part of the Digicash liquidation,
we were brought in to evaluate the patent portfolio.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-01 Thread Anne Lynn Wheeler

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).

DATACRLF354 Go ahead
Message-Content Lots of acks
.CRLFQUITCRLF   250 Ok

and will disconnect after reading the 250 response without waiting
for the 221 response. The TCP 3-way shutdown (FIN, FIN-ACK, ACK) happens
in the kernel in the background, the SMTP server and client are by that
point handling different connections. So the reliable shutdown latency
is of no consequence for application throughput.

A pipelined SMTP delivery can be completed over TCP in 5 RTTs not 7.

0. SYN  SYN-ACK
1. ACK  220
2. EHLO 250
3. MAIL RCPT DATA   250 250 354
4. MSG . QUIT   250 221
5. close socket

TCP is fine, latency is primarily the result of application protocol
details, not TCP overhead. The only TCP overhead above is 1 extra RTT
for the connection setup. Everything else is SMTP not TCP, and running
SMTP over UDP (with ideal conditions and no lost packets, ...) would
save just 1 RTT.

   

re:
http://www.garlic.com/~lynn/aadsm28.htm#21 Dutch Transport Card Broken

sorry, I didn't say that TCP required seven round-trips for reliable 
exchange;

the statement was that minimum TCP operation was seven packet
exchange (for reliable operation)  sort of 3.5 round-trips. That
VMTP (rfc 1045) reduced that to minimum of five packet exchange
(sort of 2.5 round-tips) ... and that XTP got it to a minimum of three
packet exchange (sort of 1.5 round-trips) for reliable operation.

from my RFC index
http://www.garlic.com/~lynn/rfcietff.htm

rfc 1045 summary
http://www.garlic.com/~lynn/rfcidx3.htm#1045

1045 E
 VMTP: Versatile Message Transaction Protocol: Protocol specification,
 Cheriton D., 1988/02/01 (123pp) (.txt=264928) (Refs 955, 966, 969)
 (Ref'ed By 1050, 1072, 1105, 1106, 1190, 1263, 1323, 1453, 1458,
 1700, 2018, 2375, 2757) (VMTP)

as always, clicking on the .txt=nnn field (in rfc summary) retrieves 
the actual RFC.



If there is more than minimum amount of data ... TCP might involve more
than seven packet exchange ... but the minimum packet exchange is
seven packets (not round-trips).

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-01 Thread Dan Kaminsky

 (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 is
pretty bad too.
 And there are hundreds of internal systems I heard of that are using client 
 certificates in reality every day.
   
There's always a few people using a technology.  It's certainly a
nonplayer out there.  Probably more servers out there authing with
Digest, honestly.
 Validated email addresses for spamming. Spear-phishing perhaps, ...

   
 There are CA´s on this planet that put things like social security numbers 
 into certificates.

   
Who?  Seriously, that's pretty significant, I'd like to know who does this.
 Where does the SSL specification say that certificates shouldn´t contain 
 sensitive information? I am missing that detail in the security consideration 
 section of the RFC.
   
The word public in Public Key isn't exactly subtle.

 Do we have any more ideas how we can get this flaw fixed before it starts 
 hurting too much?
   
Make it really easy to use some future version of SSL client certs, and
quietly add the property you seek.  Ease of use drives technology
adoption; making the tech actually work is astonishingly secondary.

Heh, you asked :)
 We have an issue here. And the issue isn´t going to go away, until we 
 deprecate SSL/TLS, or it gets solved.
   
To be clear, we'd *have* an issue, if any serious number of people used
SSL client certs. I think you have a point that if SSL client certs
become very popular going forward, then every website you go to will
quietly grab your identity through their ad banners. 
 * We fix SSL  
 Does anyone have a solution for SSL/TLS available that we could propose on 
 the 
 TLS list? 
 If not: Can anyone with enough protocol design experience please develop it?
   
What solution could there be?  You're actually going to SSL to the
banner ad network, and you're going to give them your client cert.
 * We deprecate SSL for client certificate authentication.
 We write in the RFC that people MUST NOT use SSL for client authentication.
 (Perhaps we get away by pretending that client certificates accidently 
 slipped 
 into the specification.)
   
People by in large do not use SSL client cert authentication.  This is
problematic, as there's some very nice cryptographic aspects of the system.
 * We switch from TLS to hmmm ... perhaps SSH, which has fixed the problem 
 already.
 Hmm, there we would have to write all the glue RFCs like HTTP over SSH 
 again ...
   
I used to code for SSH.  SSL is an entire top-to-bottom stack, replete
with a deep PKI infrastructure.  SSH?  Tunneling transport, barely even
librarized.

 Try to send a DVD iso image (4GB) over a SSL or SSH encrypted link with bit 
 errors every 1 bits with a client software like scp that cannot resume 
 downloads. I gave up after 5 tries that all broke down in average after 1 GB.
 (In that case it was a hardware (bad cable) initiated denial of service 
 attack ;-)
   
The problem here isn't checksums.  SSH is notoriously buggy when packets
are dropped.  I think there are certain windows in which OpenSSH assumes
it will get a response.  If it doesn't, it just dies.  So, outages more
than a few hundred milliseconds have a small percentage chance of
causing the session to permanently stall.

Corrupted MAC on input -- this is a decent sign of corruption at the
app layer.

Did you really try this with OpenSSL?  I've had much better luck there.

 If the link layer gives you 1/256, and the TCP layer gives you 1/65536, and 
 the SSL layer demands 0/16777216, then end up with 1/16777216 too much.

   
Actually, 256*65536 = 1677216 :)  In actuality, you have both IP and TCP
checksums.  So you get 8 bits from link, 16 bits from IP, and 16 bits
from TCP.  A random corrupt packet has about 2^40 odds of getting through.

Of course, one real problem is that the checksum algorithms don't
exactly distribute noise randomly, and noise is not random.  Still,
corruption doesn't start being a problem until you get some pretty
serious amounts of transfer.  (Interestingly, I've been looking at IPsec
lately, not for encryption, but for better checksumming.)

 Best regards,
 Philipp Gühring

 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
   

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-01 Thread James A. Donald

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
1. ACK  220
2. HELO 250
3. MAIL 250
4. RCPT 250
... n recipients
   RCPT 250
4+n DATA 354
5+n ... stream of message content segments CRLF.CRLF
 250

so it takes at least 6 RTTs to perform a delivery (of a short
single-recipient message), but only 1 of the 6 RTTs is TCP
overhead. This is improved with PIPELINING:

0. SYN  SYN-ACK
1. ACK  220
2. EHLO 250 ... PIPELINING ...
3. MAIL RCPT(n times) DATA  250 250 (n times) 354
4. ... stream of message content segments CRLF.CRLF
250

Here the application protocol is pipelined, and 5+n RTTs becomes 4 RTTs.
The solution is not replacing TCP, but reducing the number of lock-step
interactions in the application protocol.

If someone has a faster than 3-way handshake connection establishment
protocol that SSL could leverage instead of TCP, please explain the
design.


You are asking for a layered design that works better than the existing 
layered design.  My claim is that you get an additional round trip for 
each layer - which your examples have just demonstrated.


SSL has to be on top of a reliable transport layer, hence has to have an 
extra round trip.  I was not proposing something better *for* SSL, I was 
proposing something better *instead* *of* SSL.  If one takes SSL as a 
given, then indeed, *three* round trips are needed before the client can 
send any actual data - which is precisely my objection to SSL.






The TCP handshake adds a 1-RTT delay at the start of the connection.
What 0-RTT algorithm will allow the server to delay creating expensive
connections to clients until the client acks the server response or
discover the MSS before sending the first segment? With TCP, at least
SYN floods require unspoofed client IPs.

Most of the application protocols we wrap in TLS are not DNS. Sure if
you can guarantee a single packet response to a single packet request,
TCP is not the answer. Otherwise, claiming that SSL is less efficient
over TCP smacks of arrogance.



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-01 Thread Victor Duchovni
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 anyone's interested, I did an analysis of this sort of thing in an
 unpublished draft Performance Characteristics of Application-level Security
 Protocols, http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf.  It
 compares (among other things) the cost in RTT of several variations of SSL and
 SSH.  It's not the TCP RTTs that hurt, it's all the handshaking that takes
 place during the crypto connect.  SSH is particularly bad in this regard.

Thanks, an excellent reference! Section 6.2 is most enlightening, we were
already considering adopting HPN fixes in the internal OpenSSH deployment,
this provides solid material to motivate the work...

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-01 Thread Nicolas Williams
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 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 IETF BTNS
WG) that it's not too farfetched, but for web stuff I just don't think
they're remotely likely.

Prior to the advent of AJAX-like web design patterns the most noticeable
latency in web apps was in the server (for dynamic content) and the
client (re-rendering the whole page on every click).  Applying GUI
lessons to the web (asynchrony!  callbacks/closures!) fixed that.

TLS was not to blame.

TLS probably still isn't to blame for whatever latency users might be
annoyed by in web apps.

It's *much* easier to look for improvements in the app layer first given
that web app updates are much easier to deploy than TLS (which in turn
is much easier to deploy than changes to TCP or IPsec).

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-01 Thread Ian G

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 choose not
to use certs because of this kind of privacy issue--but I know
of plenty that they find getting certs way too inconvenient.



In a CA I have something to do with, I'm observing a site 
that just started experimenting with client certs (100 
users, will reach 1000, maybe more).


When we discovered that the certificate includes PII 
(personally identifying information) and the website stores 
additional PII, the service was directed to drop all 
additional PII, and some thought was put into the in-cert PII.


Current view is that the service must engage the user in a 
contract to accept the storing of that in-cert PII, 
otherwise it must not store the info in the cert (which 
means no identity, no persistence, and no point to the 
client certs).


Writing contracts and securing agreement of course is a 
barrier, a burden.  If this were a general requirement, then 
this would be enough (imho) to not recommend client certs, 
because contracts need lawyers, they cost real money, they 
don't solve the problem, and not recommending them is 
likewise unacceptable.


(Then, as you say, there are convenience issues.)

This is an experiment to force client certs to be used, so 
they are plugging on.  It's a CA so it is trying to prove 
that there is value in these things.


So... there are two slight variations that could be 
employed.  Firstly, all data placed in the cert could be 
declared public in advance, and then no contract is required 
to use it in a context that is compatible with public data. 
 That is, the question of the contract is pushed to the CA/CPS.


(You mentioned that the premise is that it is all public 
data...)


Another variation is to switch to username + password, of 
course, in which case the username is freely given and 
expected to be stored (certs being more or less invisible to 
users, so we can presume no such).


(definately open to other ideas...)

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 security are 
different fields with different logics.  If that is true, 
the liability is far too high for something that should be 
private, but is already public by dint of its exposure in 
certificates.  Privacy liabilities are sky-high in some 
places, and not only that, they are incalculable, 
unknowable, and vary with the person you are talking to.


So a superficial conclusion would be don't use client 
certificates because of the privacy issues although the 
issues are somewhat more complex than PII revealed in SSL 
key exchange.


As I say, they'll plug on, as they need to prove that the 
cert is worth issuing.  It's a data point, no more, and it 
doesn't exactly answer your spec above.  But I'm having fun 
observing them trying to prove that client certs are worth 
any amount of effort.


iang

PS: normal disclosures of interest + conflicts, included.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-01 Thread Peter Gutmann
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
unpublished draft Performance Characteristics of Application-level Security
Protocols, http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf.  It
compares (among other things) the cost in RTT of several variations of SSL and
SSH.  It's not the TCP RTTs that hurt, it's all the handshaking that takes
place during the crypto connect.  SSH is particularly bad in this regard.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-01 Thread Anne Lynn Wheeler

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 security are different fields with different logics.  If that is 
true, the liability is far too high for something that should be 
private, but is already public by dint of its exposure in 
certificates.  Privacy liabilities are sky-high in some places, and 
not only that, they are incalculable, unknowable, and vary with the 
person you are talking to.


So a superficial conclusion would be don't use client certificates 
because of the privacy issues although the issues are somewhat more 
complex than PII revealed in SSL key exchange.


As I say, they'll plug on, as they need to prove that the cert is 
worth issuing.  It's a data point, no more, and it doesn't exactly 
answer your spec above.  But I'm having fun observing them trying to 
prove that client certs are worth any amount of effort.
the problem that digital certificates were suppose to address was first 
time communication
between strangers ... the electronic analogy of the letters of 
credit/introduction from
sailing ship days. this harks back to the offline email days of the 
early 80s ... dial-up
electronic post-office, exchange email, hangup, and now authenticate 
first-time email

from total stranger.

the design point assumptions are invalidated if the relying party has 
their own
repository of information about the party being dealt with (and therefor 
can
included that party's public key) and/or has online, timely electronic 
access to

such information.

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 infrastructure at least a couple decades to the time when
online, real-time transactions weren't being done. The online, real-time
transaction provides much higher quality and useful information than
a stale, static digital certificate (with an offline paradigm from before
modern communication). Having an available repository about the party
being dealt with ... including things like timely, aggregated information
(recent transactions) is significantly mover valuable than the stale,
static digital certificate environment (the only thing that it has going
for it, is it is better than nothing in the oldtime offline environment).

misc. past posts referencing certificate-less public key operation
http://www.garlic.com/~lynn/subpubkey.html#certless

for some real topic drift ... i've mentioned x9.59 financial
standard protocol that can use digital signatures for
authentication w/o requiring digital certificates
http://www.garlic.com/~lynn/x959.html#x959

part of the issue included that digital certificates
(even relying party only digital certificates) can
add a factor of one hundred times payload bloat
to a typical payment transaction
http://www.garlic.com/~lynn/subpubkey.html#bloat

however, we were also got involved in co-authoring
the x9.99 privacy standard ... as part of that we had
to look at a number of things, HIPAA, GLBA ... as
well as EU-DPD. as part of that we had also done
a privacy merged taxonomy and glossary ... some
notes
http://www.garlic.com/~lynn/index.html#glosnote

EU had also made a statement in the mid-90s that
electronic retail payments should be as anonymous
as cash. The dominant use of SSL in the world
today is electronic commerce between a consumer
and a merchant. Passing a client certificate (with
PII information) within an encrypted SSL channel
to a merchant ... still exposes the information to
the merchant ... also violating making purchases
as anonymous as cash.








-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-01 Thread Anne Lynn Wheeler

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 IETF BTNS
WG) that it's not too farfetched, but for web stuff I just don't think
they're remotely likely.

   


my view of ipsec was that it faced a significant barrier to entry since
it required upgrading lots of installed kernels all over the infrastructure
(aka tcp/ip protocol stack have been integrated kernel implementations)

both SSL and VPN offered implementations that require having to
upgrade existing deployed kernels (something that has gotten
somewhat easier in the last decade plus).

about the same time as SSL, a friend that we had worked on  off with
over a couple decades introduced what was to become called VPN
in gateway committee at fall '94 IETF meeting in san jose.

my view was this resulted in some amount of consternation
with the ipsec forces as well as some of the router vendors.
the ipsec forces were somewhat mollified by being able
to refer to vpn as lightweight ipsec (while others then
would refer to ipsec as heavyweight ipsec).

the initial proposal involved border routers providing
authentication and (encryption) tunneling through the
internet. some of the router vendors had processors
that could handle the encryption load. however, there
was opposition from the router vendors that didn't
have products with processors that could handle
the encryption load (or at least stalling until they
had such a product).

in any case, uptake of both SSL and VPN ... was
the significantly easier and less complex deployment
... vis-a-vis ipsec.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-01 Thread Peter Gutmann
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
mutual authentication of client and server without any use of X.509.  The only
problem has been getting vendors to support it, several smaller
implementations support it, it's in the (still unreleased) OpenSSL 0.99, and
the browser vendors don't seem to be interested at all, which is a pity
because the mutual auth (the server has to prove possession of the shared
secret before the client can connect) would significantly raise the bar for
phishing attacks.

(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 busy
chasing phantoms like EV certs).

 The particular digital certificate format necessarily imply a PKI
 structure

No, James Donald/George W. Bush, that's not even remotely true. There is no
requirement that you use the certs as anything other than key containers.

There's actually no requirement that you use certs at all.  In fact if
everyone dropped them (i.e. stopped pretending that they work and moved
towards something that does) we might all be a whole lot better off.

Peter.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-01 Thread Frank Siebenlist

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 and TLS-PSK provide
mutual authentication of client and server without any use of X.509.  The only
problem has been getting vendors to support it, several smaller
implementations support it, it's in the (still unreleased) OpenSSL 0.99, and
the browser vendors don't seem to be interested at all, which is a pity
because the mutual auth (the server has to prove possession of the shared
secret before the client can connect) would significantly raise the bar for
phishing attacks.

(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 busy
chasing phantoms like EV certs).


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...

Why do the browser companies not care?
What is the adoption issue?
Still the dark cloud of patents looming over it?
Not enough understanding about the benefits? (marketing)
Economic reasons that we wouldn't buy anymore server certs?

-Frank.

--
Frank Siebenlist   [EMAIL PROTECTED]
The Globus Alliance - Argonne National Laboratory


smime.p7s
Description: S/MIME Cryptographic Signature


Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)

2008-02-01 Thread Ian G

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 
of why it is impractical / impossible to interest the 
browser vendors in new ideas and new security might be 
summed as this:


* Browser vendors operate a closed security shop.  I think 
this is because of a combination of things.  Mostly, all 
security shops are closed, and there aren't any good 
examples of open security shops (at least that I can think 
of).  We see some outreach in the last few years (blogs or 
lists by some) but they are very ... protected, the moat is 
still there.


* Browser vendors are influenced heavily by companies, which 
have strong agendas.  Security programmers at the open 
browsers are often employed by big companies who want their 
security in.  They are not interested in user security. 
Security programmers need jobs, they don't do this stuff for 
fun.  So it is not as if you can blame them.


* 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 are completely at sea when it comes 
to systemic security failings or designing new systems.


* Which also means it is rather difficult to have a 
conversation with them.  For example, programmers don't know 
what governance is, so they don't know how to deal with PKI 
(which is governance with some certificate sugar), and they 
can't readily map a multi-party failure.  OTOH, they know 
what code is, so if you code it up you can have a 
conversation.  But if your conversation needs non-code 
elements ... glug glug...


* Browser vendors work to a limited subset of the old PKI 
book.  Unfortunately, the book itself isn't written, with 
consequent problems.  So certain myths (like all CAs must 
be the same) have arisen which are out of sync with the 
original PKI thinking ... and out of sync with reality ... 
but there is no easy way to deal with this because of the 
previous points.


* Browser vendors may be on the hook for phishing.  When you 
start to talk in terms like that, legal considerations make 
people go gooey and vague.  Nobody in a browser vendor can 
have that conversation.


Which is all to say ... it's not the people!  It's the 
assumptions and history and finance and all other structural 
issues.  That won't change until they are ready to change, 
and there are only limited things that outsiders can do.


Just a personal opinion.

iang

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-01 Thread Nicolas Williams
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 busy chasing phantoms like EV certs).
  
 The big issue is prompting the user for a password in a way that no one
 will confuse with a web site doing so.  Given all the effort that's
 been put into making Javascript more and more powerful, and given
 things like picture-in-picture attacks, I'm not optimistic.   It might
 have been the right thing, once upon a time, but the horse may be too
 far out of the barn by now to make it worthwhile closing the barn door.

And on top of that web site designers don't want browser dialogs for
HTTP/TLS authentication.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-01-31 Thread Dave Howe

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 assumes an
active attack in case of integrity problems of the lower layer, and
terminates the connection.


TBH I can't see the problem - the unix philosophy of doing one thing
well, and chaining simple tools to make complex ones, works well here.

we have:

TCP - well understood, has crude integrity and reliability checks built
in, works reasonably well at converting a bunch of packets leaving and
arriving via your network connection into something vaguely like a
stream point-to-point connection. Provided by every ISP across the
planet, problems at this level can be handed off to experienced network
engineers who will at least understand the problem.

SSL - Cludge thrown together by a browser manufacturer, probably to
create a market for a bunch of companies who generated two prime numbers
and now sell the answers to simple math queries involving the numbers.
However, works reasonably well, has some crude authentication of the
server built in (via the aformentioned bunch of companies) which at
least limits potential hackers to those whose money the bunch of
companies will accept ;)
  Again, works well in its domain, but requires a reasonably reliable
channel to talk over, and a message to carry. Effectively turns an
unencrypted channel into an encrypted one, Would work as well over a
serial link as a tcp link (modulo the domain name check in the cert)

HTTP - pretty basic file transfer protocol, with limited scope for
negotiation, but designed largely to move text files from a server to a
client. requires transport, can use tcp, ssl-over-tcp, serial, whatever
your server will listen on and your client request on.

add them together and you get HTTPS. leave out the SSL, and you get HTTP
as-normally-spoke, so the SSL and HTTP are pretty much drop in modules.
you could define HTTPG (HTTP over a security protocol other than SSL)
and if a browser could support it, both TCP and HTTP would still be
happy. you could also define HTTPS-over-adis-lamp and provided the
operators were sufficiently accurate, securely download your web page
from a server on a nearby hilltop after dark by replacing the TCP layer :)

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-01-31 Thread James A. Donald

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 be using them.

Another problem is that in practice the system merely
ensures you are getting the purported domain name. Since
we are overwhelmed by a multitude of irrelevant and
confusing domain names, this is not much help. Further,
I frequently get the warning that the certificate does
not agree with the domain name when I know well that I
am communicating with the intended entity - frequent
misconfiguration results in false warnings, which I am
thus trained to ignore, rendering the system entirely
useless.

Since we rely on passwords, social security numbers, and
so forth, shared secrets, people are trained to give
away secrets to purported authority, which creates the
phishing hazard. We need to fix both problems.

Of course, if the phishing hazard was fixed, we would
still have the malware hazard, but we now know how to
fix the malware hazard.

We should fix both problems, rather than using one as an
excuse for not fixing the other.  We need to fix the
network assuming the node is going to be made safe, and
fix the node assuming the network is going to be made
safe.

 Does anyone have an idea how we can fix this flaw
 within SSL/TLS within a reasonable timeframe, so that
 it can be implemented and shipped by the vendors in
 this century?

Eric Rescorla wrote:
 This gets discussed on the TLS mailing list
 occasionally, but the arguments for making this change
 aren't very convincing. If you have an actual credible
 security argument you should post it to [EMAIL PROTECTED]

I don't think that is a useful discussion forum.  The
IETF is moribund, paralyzed and increasingly irrelevant.
If the internet is to be fixed, the fixes have to bypass
the IETF.

When one has a large group, group dynamics can make the
large group a little bit smarter than its smartest
members, but more commonly, make it a lot dumber than
its dumbest members.  If the IETF was capable of
handling, or even noticing, the crisis that we in then
we would not be in this crisis.

To fix the phishing problem, we need to
cryptographically secure relationships, rather than
attempting to cryptographically secure true names, and
to greatly reduce reliance on revealing shared secrets.
It should be unusual and disturbing to reveal shared
secrets, rather than routine, and it should only be done
with humans, not machines.

1.  As with Skype to Skype IM, the fact that you can
receive a message from what purports to be an entity
with which you have a relationship, should be compelling
evidence that it really is that entity, the entity to
which you have given a petname on your contacts list.
Thus phishing is hard to initiate.  As with Skype, what
we seek to secure is petnames, not true names.  We want
to secure the bookmark list, and the list that comes up
in a Google search.  We want to secure that when you
click on a the top entry of the Google list, you are
contacting the intended entity.

2.  As with Skype to Skype IM, this should be symmetric.
If you respond to a message from your bank, or initiate
a message to your bank, you should not have to reveal
some shared secrets to prove an existing relationship
before getting on with your task. Thus phishing should
fail to catch any phish.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-31 Thread James A. Donald

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
 to do with SSL per se.)

The two actually working, widely used, secure systems
are SSH and Skype, neither of which uses SSL/TLS/PKI
The proof of the pudding is in the eating.  When large
numbers of people use cryptography that really does make
them secure, they are not using SSL/TLS/PKI.

SSL involves digital certificates.  The particular
digital certificate format necessarily imply a PKI
structure with the same sort of defects as the existing
PKI structure, which secures what does not matter much,
and fails to secure that which does matter.  In this
sense, X.509 certificates are core to the protocol, and
that is the big problem with the protocol, though
neither am I happy about the fact that when the client
initiates a communication, the data it actually wants to
send only gets sent after the the *third* round trip.

 My opinion (and just about everyone else's) is well
 known.

There is a serious security problem in the network.  It
needs fixing. SSL/TLS/PKI exists, yet is entirely
ineffectual in fixing it.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-01-31 Thread Philipp Gühring
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 they need
* It´s an availability problem for people that need high-security 
authentication mechanisms, combined with high-privacy demands
* It´s a identity theft problem in case the certificate contains personal data 
that can be used for identity theft

Quoted from Lynns email:
i.e. the x.509 identity digital certificates from the early 90s, were 
becoming
more and more overloaded with personal information ... and by the
mid-90s, lots of institutions were starting to realize all that personal
information represented significant privacy and liability issues ... and
the RPO digital certificates were born.

* It´s a liability issue

(Lynn, can you go into more details here? On the other hand, I would say it´s 
self-explaining ...)

 (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.

If you want a public example of client certificate usage:
https://secure.cacert.org/
(You need a (free) client certificate from www.CAcert.org to be able to access 
this page)

There are ISPs out there who provide internet access based on client 
certificates, authenticated in HTTPS sessions

Creative Commons is running a registry for digital works, based on authors 
client certificate authentication:
http://www.registeredcommons.org/

The Austrian governmental inhabitant register is using client certificates for 
about 10,000 users all around Austria since 2001. (If I remember the details 
correctly)  http://zmr.bmi.gv.at/pages/home.htm

And there are hundreds of internal systems I heard of that are using client 
certificates in reality every day.

 That the phisher gets to see the client's identity?

Validated email addresses for spamming. Spear-phishing perhaps, ...

 So what? 

Why doesn´t SSH leak the client identity in plaintext?

The problem isn´t a key-agreement problem. The problem is a 
client-authentication problem. 

 It doesn't let them impersonate the client to anyone. 

It does let them impersonate the client to anyone who doesn´t care about the 
public key. (There are applications that just use the DN+Issuer information 
that they normally extract out of the certificates, ...)
But impersonation is just one threat out of the huge SSL/TLS threat-model.

 Certificates 
 shouldn't contain sensitive information anyway.

There are CA´s on this planet that put things like social security numbers 
into certificates.

(I guess those CA´s would say that SSL shouldn´t leak certificates in 
plaintext anyway.) Shovling around responsibility won´t help us. Let´s fix 
the problems. (Yes, we are already trying to get those CA´s to stop doing 
that ... but it´s a bit like asking credit card companies to not print those 
sensitive creditcard numbers on those credit cards ...)

And there are a lot of people who would be interested to use certificates for 
more applications than pure identity. (which aren´t necessarily sensitive, 
but they are personal related data)

Where does the SSL specification say that certificates shouldn´t contain 
sensitive information? I am missing that detail in the security consideration 
section of the RFC.

There is a market demand for using sensitive information in certificates, 
dating back to the mid 90's (according to Lynn), and showing itself in 
various forms like Stefan Brands credentials, Attribute Certificates, and 
even the OACerts by Jiangtao Li and Ninghui Li. 
I have been talking to many people about client certificates and client 
authentication, and a lot of them are interested in using client certificates 
for authentication, and also to add other attributes to the certificates.

  We have the paradox situation that I have to tell people that they should
  use HTTPS with server-certificates and username+password inside the HTTPS
  session, because that´s more secure than client certificates ...

 No it isn't more secure.

Using username+password inside HTTPS does not leak the client´s identity in 
cleartext on the line. (If I am wrong and HTTPS leaks usernames sent as HTTP 
Forms or with HTTP Basic Authentication, please tell me)

  Does anyone have an idea how we can fix this flaw within SSL/TLS within a
  reasonable timeframe, so that it can be implemented and shipped by the
  vendors in this century?

Do we have any more ideas how we can get this flaw fixed before it starts 
hurting too much?


 This gets discussed on the TLS mailing list occasionally, but the
 arguments for making this change aren't very convincing.

Yes, there are regularly people popping up there that need it, but they always 
get ignored there, it seems.

I think we have the boiling frog problem here. (Frog not recognizing 

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-01-31 Thread Thierry Moreau



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 identity theft anymore.


We have the paradox situation that I have to tell people that they should use 
HTTPS with server-certificates and username+password inside the HTTPS 
session, because that´s more secure than client certificates ...


Does anyone have an idea how we can fix this flaw within SSL/TLS within a 
reasonable timeframe, so that it can be implemented and shipped by the 
vendors in this century?


(I don´t think that starting from scratch and replacing SSL makes much sense, 
since it´s just one huge flaw ...)




If I recall correctly, SSL was designed chronologically after ISO OSI 
Network-Layer Security Protocol (yes, the official WAN was actually X.25 
at one point) or Transport Layer Security Protocol, both in their 
connection-oriented flavor, which used ideas originating from DecNET 
designs (researcher names Tardo, Alagappan; I once had a patent number 
in this thread of protocol engineering, but I lost it). Anyway, the key 
point in these visionary ideas is that the D-H exchange occurs *before* 
the exchange of security certificates. This provided the traffic-flow 
confidentiality that becomes desirable to protect privacy these days.


So, you got your fix with OSI NLSP or TLSP, you just have to overcome 
the *power of the installed base*!


Regards,

--

- Thierry Moreau

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

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-31 Thread Victor Duchovni
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 round trips.

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
1. ACK  220
2. HELO 250
3. MAIL 250
4. RCPT 250
... n recipients
   RCPT 250
4+n DATA 354
5+n ... stream of message content segments CRLF.CRLF
 250

so it takes at least 6 RTTs to perform a delivery (of a short
single-recipient message), but only 1 of the 6 RTTs is TCP
overhead. This is improved with PIPELINING:

0. SYN  SYN-ACK
1. ACK  220
2. EHLO 250 ... PIPELINING ...
3. MAIL RCPT(n times) DATA  250 250 (n times) 354
4. ... stream of message content segments CRLF.CRLF
250

Here the application protocol is pipelined, and 5+n RTTs becomes 4 RTTs.
The solution is not replacing TCP, but reducing the number of lock-step
interactions in the application protocol.

If someone has a faster than 3-way handshake connection establishment
protocol that SSL could leverage instead of TCP, please explain the
design.

The TCP handshake adds a 1-RTT delay at the start of the connection.
What 0-RTT algorithm will allow the server to delay creating expensive
connections to clients until the client acks the server response or
discover the MSS before sending the first segment? With TCP, at least
SYN floods require unspoofed client IPs.

Most of the application protocols we wrap in TLS are not DNS. Sure if
you can guarantee a single packet response to a single packet request,
TCP is not the answer. Otherwise, claiming that SSL is less efficient
over TCP smacks of arrogance.

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-01-31 Thread Eric Rescorla
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 secret, and only to be used to authenticate to 
 the particular server they need
 * It´s an availability problem for people that need high-security 
 authentication mechanisms, combined with high-privacy demands
 * It´s a identity theft problem in case the certificate contains personal 
 data 
 that can be used for identity theft

I don't find this at all convincing. There are a variety of different
threat vectors here:

1. Phishing.
2. Pharming (DNS spoofing).
3. Passive attacks.

In the case of phishing, the fact that the client sends its certificates
in the clear is totally irrelevant, since the client would simply send
its identity encrypted under the server's certificate. The only
fix for this alleged privacy leak in the phishing context is for
the client to refuse to deliver his certificate to anyone but people
who present valid certs that he otherwise trusts.

Now, this is potentially an attack if the attacker is passive but
on-path, either via pharming or via subverting some router, but
I'm unaware of any evidence that this is used as a certificate
disclosure attack vector.


  (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 choose not
to use certs because of this kind of privacy issue--but I know
of plenty that they find getting certs way too inconvenient.


  That the phisher gets to see the client's identity?
 
 Validated email addresses for spamming. Spear-phishing perhaps, ...

Validated email addresses are not exactly hard to obtain.


  It doesn't let them impersonate the client to anyone. 
 
 It does let them impersonate the client to anyone who doesn´t care about the 
 public key. (There are applications that just use the DN+Issuer information 
 that they normally extract out of the certificates, ...)

If those applications do not force the client to do proof of possession
of the private key, then they are fatally broken. It's not our job
to fix them.


   We have the paradox situation that I have to tell people that they should
   use HTTPS with server-certificates and username+password inside the HTTPS
   session, because that´s more secure than client certificates ...
 
  No it isn't more secure.
 
 Using username+password inside HTTPS does not leak the client´s identity in 
 cleartext on the line. (If I am wrong and HTTPS leaks usernames sent as HTTP 
 Forms or with HTTP Basic Authentication, please tell me)

No, it just leaks the password to the phishing server. Yeah, that's totally
a lot better.



  This gets discussed on the TLS mailing list occasionally, but the
  arguments for making this change aren't very convincing.
 
 Yes, there are regularly people popping up there that need it, but they 
 always 
 get ignored there, it seems.

Because the arguments they present are handwavy and unconvincing, just like
yours.



  If you have 
  an actual credible security argument you should post it to
  [EMAIL PROTECTED]
 
 Do you think the the security arguments I summed up above qualify on the tls 
 list?

It's an open list. Feel free to make these arguments.


 Should I go into more detail? Present practical examples?

I would certainly find practical examples more convincing than the ones
you've presented.



 I see several possible options:
 * We fix SSL  
 Does anyone have a solution for SSL/TLS available that we could propose on 
 the 
 TLS list? 
 If not: Can anyone with enough protocol design experience please develop it?

There's already a solution: double handshake. You do an ordinary
handshake with server auth only and then you do a second handshake
with client auth. This hides the certificate perfectly well.  Yes, you
have to do two private key ops on the server, but if this issue is as
important as you say, this is a tradeoff you should be happy to make.
I've pointed this out on the TLS mailing list a number of times, but
maybe you missed it.


 * We change the rules of the market, and tell the people that they MUST NOT 
 ask for additional data in their certificates anymore

Fundamentally, this *is* the fix. Even if SSL guaranteeed that nobody
but the person you were handshaking with got the certificate, this
is still incredibly brittle because any random server can ask you
for your cert and users can't be trusted not to hand them over.
The basic premise of certs is that they're public info. If you
want to carry private data around in them then you should encrypt
that data.



   TCP could need some stronger integrity protection. 8 Bits of checksum
   isn´t 

Re: Dutch Transport Card Broken

2008-01-31 Thread Perry E. Metzger

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 that fixing key management has anything
 to do with SSL per se.)

 The two actually working, widely used, secure systems
 are SSH and Skype,

SSL is in use just about everywhere, James. https: is used constantly,
and there are many other applications that make use of it. My mom uses
SSL regularly, but by contrast I don't think she's ever touched SSH.

Perhaps you argue that SSL is not secure, but it appears to have
withstood all attacks to date. You might claim that it does not
prevent phishing attacks or some such, but then you are making a claim
about how people use https in practice,, not about SSL at all. The SSL
part of that protocol is fine, just as the RSA and AES or 3DES parts
of that protocol are fine.

 neither of which uses SSL/TLS/PKI

I'm going to start referring to you as James Donald/George W. Bush.

Why does James Donald/George W. Bush persist in involving us in wars
in foreign countries, I wonder? Please don't claim that you're not
somehow part of James Donald/George W. Bush, because as you see I've
juxtaposed your names, which is proof that you must be part of the
same entity.

If you don't like my doing that, then stop referring to SSL/TLS/PKI
because SSL has nothing to do with PKI.

SSL has nothing to do with PKI. X.509 certs are just a key container
format. The applications get to decide what to do with them. You
persistently claim that SSL has something to do with public key
infrastructure, but it has no more to do with public key
infrastructure at all. You shouldn't mention them at the same
time. You are free to write applications that use SSL with a PKI, or
without it -- the two have nothing to do with each other whatsoever. I
know of many apps that use SSL and don't touch PKI at all.

Constantly mentioning PKI and SSL at the same time betrays a
substantial ignorance of the system architecture we're mentioning --
it would make as much sense to claim that SSL has something to do with
IKE because both use X.509 certificates.

 The proof of the pudding is in the eating.  When large
 numbers of people use cryptography that really does make
 them secure, they are not using SSL/TLS/PKI.

Well, James Donald/George W. Bush, I presume this means that you have
a way of breaking SSL. Could you share it with us? If not, please stop
conflating things that are unconnected.

 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,
but by the same token, SSH also provides a channel by which X.509
certs can be exchanged. Should we therefore refer to SSH/PKI

 The particular digital certificate format necessarily imply a PKI
 structure

No, James Donald/George W. Bush, that's not even remotely true. There
is no requirement that you use the certs as anything other than key
containers.

 My opinion (and just about everyone else's) is well
 known.

 There is a serious security problem in the network.  It
 needs fixing. SSL/TLS/PKI exists, yet is entirely
 ineffectual in fixing it.

Well, James Donald/George W. Bush, perhaps that is because SSL has
nothing to do with the issue. SSL works perfectly so far as we
know. The issue is that higher levels of the stack (like key
management) aren't properly designed, but SSL itself is just fine.


-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-31 Thread Anne Lynn Wheeler

Victor Du

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
1. ACK  220
2. HELO 250
3. MAIL 250
4. RCPT 250
... n recipients
   RCPT 250
4+n DATA 354
5+n ... stream of message content segmentsCRLF.CRLF
250

so it takes at least 6 RTTs to perform a delivery (of a short
single-recipient message), but only 1 of the 6 RTTs is TCP
overhead. This is improved with PIPELINING:

0. SYN  SYN-ACK
1. ACK  220
2. EHLO 250 ... PIPELINING ...
3. MAIL RCPT(n times) DATA  250 250 (n times) 354
4. ... stream of message content segmentsCRLF.CRLF
250
   

re:
http://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (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 board).

i've frequently pontificated that with reliable registration of public keys
in the dns system and then piggy-backing any registered public key in
standard DNS response  then it would be possible to encode the
randomly generated secret key (with that public key) and the encrypted
message in the XTP packet for minimum 3 packet exchange.
http://www.garlic.com/~lynn/subtopic.html#subpubkey.html#catch22

http already went thru its period of problems of implicit assumptions
with tcp. tcp sessions were assumed to be long lived and session shutdown
was assumed to be relatively infrequently. non-session activity like http
was always assumed to use udp for efficiency. the http ignored all of
that and used tcp for non-session activity. as a result, webserver systems
went thru a period where the processors was spending 95+ percent of
processor in the session shutdown processing. systems then were retrofited
with new kind of tcp session shutdown implementation to handle the
misuse by http.

the original ssl deployment was to 1) encrypt data in transit and
2) authenticate the server. the implicit assumption was that the
user understood the binding between the business and the url.
the browser then provided the second part, verifying the binding
between the url and the server contacted (was the server that
the user thot they were talking to, the server they were actually
talking to).

The dependency for valid ssl operation was violated almost
immediately when merchants found that ssl overhead reduced thru
thruput by 5-10 times. the regression was instead of initial contact
of the webserver (presumably url supplied by user) being ssl,
ssl was moved to checkout/pay phase where the user clicked
on a button (and url) provided by the webserver (not a url
provided by the user). It was no longer possible to provide
any assurances as to the authentity of the webserver contacted
(ssl purely being reduced to encrypting data in transmission).

we had been called in to consult with the small client/server
company on using this technology (they created) called SSL
for payment transactions
http://www.garlic.com/~lynn/subnetwork.html#gateway

and had to go thru detailed walk thrus of the technology as
it applied to actual business processes (and the associated
implicit dependencies) ... as well as detailed walk thrus of the
new business operations that were calling themselves
certification authorities.

the other issue that we came up in applying this SSL technology
was communication between webservers and something called
the payment gateway. for  this communication we mandated mutual
authentication ... this was before mutual authentication had
been implemented in SSL. It turns out that by the time
we had it all implemented and deployed ... it also became
very apparent that the things called digital certificates
were redundant and superfluous.

the basic design point for digital certificates is first time
communication between total strangers. the payment gateway
business processes required that all the merchants had
to be pre-registered with the payment gateway and the payment
gateway pre-registered with all the merchants  violating the
basic justification for having digital certificates.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-01-31 Thread Jim Cheesman
To add to the examples Philipp has mentioned, I've been closely involved in
the design and implementation of a number of projects for the Spanish
government using SSL + client certificates; indeed, the new Spanish ID card
includes two certificates, one for authentication and the other for digital
signature.

There are some examples of services using SSL+client certs at:
http://www.mir.es/MIR/Servicios_Telematicos/ConCertificacion/

Regards,
Jim Cheesman



-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
En nombre de Philipp Gühring
Enviado el: jueves, 31 de enero 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 with a security policy that requires
the 
their identities to be kept secret, and only to be used to authenticate to 
the particular server they need
* It´s an availability problem for people that need high-security 
authentication mechanisms, combined with high-privacy demands
* It´s a identity theft problem in case the certificate contains personal
data 
that can be used for identity theft

Quoted from Lynns email:
i.e. the x.509 identity digital certificates from the early 90s, were 
becoming
more and more overloaded with personal information ... and by the
mid-90s, lots of institutions were starting to realize all that personal
information represented significant privacy and liability issues ... and
the RPO digital certificates were born.

* It´s a liability issue

(Lynn, can you go into more details here? On the other hand, I would say
it´s 
self-explaining ...)

 (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.

If you want a public example of client certificate usage:
https://secure.cacert.org/
(You need a (free) client certificate from www.CAcert.org to be able to
access 
this page)

There are ISPs out there who provide internet access based on client 
certificates, authenticated in HTTPS sessions

Creative Commons is running a registry for digital works, based on authors 
client certificate authentication:
http://www.registeredcommons.org/

The Austrian governmental inhabitant register is using client certificates
for 
about 10,000 users all around Austria since 2001. (If I remember the details

correctly)  http://zmr.bmi.gv.at/pages/home.htm

And there are hundreds of internal systems I heard of that are using client 
certificates in reality every day.

 That the phisher gets to see the client's identity?

Validated email addresses for spamming. Spear-phishing perhaps, ...

 So what? 

Why doesn´t SSH leak the client identity in plaintext?

The problem isn´t a key-agreement problem. The problem is a 
client-authentication problem. 

 It doesn't let them impersonate the client to anyone. 

It does let them impersonate the client to anyone who doesn´t care about the

public key. (There are applications that just use the DN+Issuer information 
that they normally extract out of the certificates, ...)
But impersonation is just one threat out of the huge SSL/TLS threat-model.

 Certificates 
 shouldn't contain sensitive information anyway.

There are CA´s on this planet that put things like social security numbers 
into certificates.

(I guess those CA´s would say that SSL shouldn´t leak certificates in 
plaintext anyway.) Shovling around responsibility won´t help us. Let´s fix 
the problems. (Yes, we are already trying to get those CA´s to stop doing 
that ... but it´s a bit like asking credit card companies to not print those

sensitive creditcard numbers on those credit cards ...)

And there are a lot of people who would be interested to use certificates
for 
more applications than pure identity. (which aren´t necessarily sensitive, 
but they are personal related data)

Where does the SSL specification say that certificates shouldn´t contain 
sensitive information? I am missing that detail in the security
consideration 
section of the RFC.

There is a market demand for using sensitive information in certificates, 
dating back to the mid 90's (according to Lynn), and showing itself in 
various forms like Stefan Brands credentials, Attribute Certificates, and 
even the OACerts by Jiangtao Li and Ninghui Li. 
I have been talking to many people about client certificates and client 
authentication, and a lot of them are interested in using client
certificates 
for authentication, and also to add other attributes to the certificates.

  We have the paradox situation that I have to tell people that they
should
  use HTTPS with server-certificates and username+password inside the
HTTPS
  session, because that´s more secure than client certificates ...

 No it isn't more secure.

Using username+password inside HTTPS does not leak the client

Re: Dutch Transport Card Broken

2008-01-31 Thread Victor Duchovni
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 were on the XTP technical advisory board).
 

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).

DATA CRLF 354 Go ahead
Message-Content Lots of acks
.CRLFQUITCRLF   250 Ok

and will disconnect after reading the 250 response without waiting
for the 221 response. The TCP 3-way shutdown (FIN, FIN-ACK, ACK) happens
in the kernel in the background, the SMTP server and client are by that
point handling different connections. So the reliable shutdown latency
is of no consequence for application throughput.

A pipelined SMTP delivery can be completed over TCP in 5 RTTs not 7.

0. SYN  SYN-ACK
1. ACK  220
2. EHLO 250
3. MAIL RCPT DATA   250 250 354
4. MSG . QUIT   250 221
5. close socket

TCP is fine, latency is primarily the result of application protocol
details, not TCP overhead. The only TCP overhead above is 1 extra RTT
for the connection setup. Everything else is SMTP not TCP, and running
SMTP over UDP (with ideal conditions and no lost packets, ...) would
save just 1 RTT.

-- 
Viktor.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-30 Thread Richard Salz
 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 benefits of layering for 
outweigh the perceived gains of just merging it all together into one 
glob.  For example, the ability to replace layers, or replace them by just 
dropping in a new library.

/r$

--
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-30 Thread James A. Donald

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 the web is the
 counter-example.

The delay is often humanly perceptible.  If humanly
perceptible, too much.

 The benefits of layering for outweigh the perceived
 gains of just merging it all together into one glob.
 For example, the ability to replace layers, or replace
 them by just dropping in a new library.

Compilation would provide the same benefits, and a fair
bit more - such as built in protocol negotiation, rather
than protocol negotiation being reinvented ad hoc in a
different and incompatible way each, and bolted on after
the fact in a different way each time.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Fixing SSL (was Re: Dutch Transport Card Broken)

2008-01-30 Thread Philipp Gühring
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 have the paradox situation that I have to tell people that they should use 
HTTPS with server-certificates and username+password inside the HTTPS 
session, because that´s more secure than client certificates ...

Does anyone have an idea how we can fix this flaw within SSL/TLS within a 
reasonable timeframe, so that it can be implemented and shipped by the 
vendors in this century?

(I don´t think that starting from scratch and replacing SSL makes much sense, 
since it´s just one huge flaw ...)

 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.

SSL already looks quite round-trip optimized to me (at least the key-agreement 
part)

 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 broken packets gets injected into your TCP 
stream)  Does IPv6 have a stronger TCP?

 As discussed earlier on this list, layering induces
 excessive round trips.

The SSL implementations I analyzed behaved quite nicely, I didn´t noticed any 
round trip problems there. (But feel free to send me a traffic capture file 
that shows the problem)

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 assumes an active attack in case of 
integrity problems of the lower layer, and terminates the connection.

 Layering communications 
 protocols is analogous to having a high level
 interpreter written in a low level language. What we
 need instead of layering is a protocol compiler,
 analogous to the Microsoft IDL compiler.  The Microsoft
 IDL compiler automatically generates a C++ interface
 that correctly handles run time version negotiation,
 which hand generated interfaces always screw up, with
 the result that hand generated interfaces result in
 forward and backward incompatibility, resulting in the
 infamous Microsoft DLL hell.  Similarly we want a
 compiler that automatically generates secure message
 exchange and reliable transactions from unreliable
 packets. (And of course, run time version negotiation)

Sounds like an interesting idea to me.

Best regards,
Philipp Gühring

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-30 Thread Eric Rescorla
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 Google the
   famous Gutmann Sound Wave Therapy[0] and mail me
   afterwards.
 
   Gutmann Sound Wave Therapy: Gutmann recommends:
 : :   Whenever someone thinks that they can replace
 : :   SSL/SSH with something much better that they
 : :   designed this morning over coffee, their
 : :   computer speakers should generate some sort
 : :   of penis-shaped sound wave and plunge it
 : :   repeatedly into their skulls until they
 : :   achieve enlightenment.
 
 On SSL, Gutmann is half wrong:
 
 SSL key distribution and management is horribly broken,
 with the result that everyone winds up using plaintext
 when they should not.
 
 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.

 We really do need to reinvent and replace SSL/TCP,
 though doing it right is a hard problem that takes more
 than morning coffee.

I can't believe I'm getting into this with James.

Ignoring the technical question of broken, I know of no evidence
whatsoever that round trip latency is in any way a limiting factor for
people to use SSL/TLS.  I've heard of people resisting using SSL for
performance concerns, but they're almost always about the RSA
operation on the server (and hence the cost of server hardware).

If you have some evidence I'd be interested in hearing it.

-Ekr

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-30 Thread Steven M. Bellovin

 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 billion-dollar project, one must use COTS
 RFIDs - with their attendant privacy and security problems - is
 beyond me. 
 
 A little ingenuity would have gone a long way.
 
OPs deliberately elided.

This posting (and several others in this thread) disturb me.  Folks on
this list and its progenitors have long noted that cryptography is a
matter of economics.  That is, cryptography and security aren't
absolute goals; rather, they're tools for achieving something else.
The obvious answers in this case are prevent fare fraud or make
money, and even those would suffice.  However, there are other issues
less easily monetized, such as make the trams and buses run
efficiently.

A security system doesn't have to be perfect.  Rather, it has to be
good enough that you save more than you lose via the holes, including
the holes you know about up front.  Spending more than you have to is
simply bad engineering.  Speaking as an engineer, rather than as a
scientist, the real failure mode is too high a net loss.  As a
cryptographer and security guy, I'd rather there were no loss -- but
that's not real.

A transit system has to move people.  For all that the New York City
Metrocard works, it's slower than a contactless wireless system.  How
much longer will it take people to board trams with a stripe reader
than with a contactless smart card?  What is your power budget (which
affects range)?  Even leaving out the effect that delays have on
ridership, a transit system that wants to move N people needs more
units if the latency per rider is above a certain threshold.

Let's take a closer look at the New York system, since it was touted as
superior.  It's optimized for subways, not buses, which has several
implications.  (Subway ridership in New York is twice bus
ridership -- see
http://www.crainsnewyork.com/apps/pbcs.dll/article?AID=/20070223/FREE/70223008/1066)
First, subway turnstiles are much more easily used as part of an online
system than are bus fare card readers.  The deployment started in 1994,
when cellular data simply wasn't an option, based on cost, bandwidth,
availability, and much more.  Second, on a subway you use your fare
card well in advance of boarding; there is thus little latency effect
on the system.  Third, wireless is *still* faster -- according to some
reports (http://www.dslreports.com/forum/r19222677-The-Next-MetroCard),
the MTA is considering replacing the current system with a wireless one.

Online systems have another issue: they require constant communication
to a high-availability server.  When that's not an option (i.e., New
York buses, or subway turnstiles when the server is down), the system
has to fall back to some other scheme.  This scheme is more restrictive,
precisely because of the fraud issue.   Back when I was in high school,
some students got bus passes.  I recall a frequent sight: those who had
boarded early moving to the back of the bus and handing their passes to
other students still waiting to board the bus.  Replay worked well
against an overloaded driver...  Metrocards don't have that failure
mode -- but the failure mode they do have is a limitation on how many
times they can be used in a short time interval.  This affects, for
example, a family of five or more trying to travel on a single card,
even on subways.  

How much of this applies to the Dutch farecards?  I have no idea.  But
this group is trying to *engineer* a system without looking at costs
and other constraints.  That leads to security by checklist, an
all-too-common failing.

Systems like this have two primary failure modes -- failure in the
sense of losing more money (or time, or what have you) than
anticipated.  First, the designers may not have understood the
available technology and its limitations.  That was certainly the case
with WEP; I suspect it's the case here, but I don't know.  Even so, it
is far from clear that exploitation of the hole will have an economic
impact; that's as much a sociological question as a technical one.
(Maybe the incremental cost per card of better crypto is ?.01.  One
web site I found put tram ridership in Amsterdam at 1,000,000/year
(http://blog.wired.com/cars/2007/10/trams-dominate-.html), which means
that the cost might be ?10,000/year.  How many riders will try to cheat
the system?  Enough that to be an issue?  I don't know -- but that's
precisely my point; I don't know and I doubt very much that most other
posters here know.  That said, I do suspect that stronger crypto would
be economical.)

The second failure mode comes from misunderstanding the threat model.
That's why the old American AMPS cellular phones were subject to
cloning attacks.  It was *not* that the designers didn't anticipate 

RE: Dutch Transport Card Broken

2008-01-30 Thread Jim Cheesman

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 the web is the
  counter-example.

James A. Donald:

 The delay is often humanly perceptible.  If humanly
 perceptible, too much.

I respectfully disagree - I'd argue that a short wait is actually more
reassuring to the average user (Hey! The System's checking me out!) than an
instantaneous connection would be.

Adding in a false wait (a nice pop-up, a progress bar and a snake-oily
security message) would be even better...

Regards,
Jim Cheesman




-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-30 Thread Perry E. Metzger

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 practice this is
 not the case; commerce on the web is the
 counter-example.

 The delay is often humanly perceptible.  If humanly
 perceptible, too much.

The initial delay in connecting is usually DNS related, not SSL
related, and is often experienced even in ordinary http: web
surfing. I don't think that the delays involved in the SSL handshake
are particularly perceptible amidst the other delays involved in
connection setup, unless you're on a very high delay network like one
of the older cellular data systems that are now going away
anyway. Protocol hacks also make subsequent connections to the same
server quite fast.

In any case, although SSL has some compromises in the design, it is
pretty good overall, and I can't see a good reason why one would pick
something else in almost any ordinary situation. A real expert might
find corner cases where it is not suitable, but there are very few
experts out there, though lots of people who incorrectly think they
are. I've seen idiots produce many things that were slower and had
horrible security properties, all the while costing far more in
software development, because they thought they knew better -- I've
never seen anyone actually do better, though. For practical purposes,
the rule is don't use something else, and if you think you're smart
enough to do better, you almost certainly aren't.

(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 to do
with SSL per se.)

I'm sure you're going to disagree with me, James, but I won't be
responding -- I don't think you're right, but I also see no reason to
beat a dead horse. My opinion (and just about everyone else's) is well
known. We live in a world where you are free to have a dissenting view.

-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-30 Thread Perry E. Metzger

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 ID badges. I've used
contactless systems for entry at several firms on a regular basis.
I've experienced the equivalent of re-swipe problems even with the
contactless systems -- that is, I've been forced to wave the card past
the reader more than once. I'm told that similar issues can be found
in other RFID systems.

Although I will not disagree that the only important criterion for a
transit system is will we maximize overall economic efficiency with
this design choice, I'm still far from certain that contactless is
always going to be faster. It could in theory be faster -- whether
that theory can be reduced to practice is a different question.

(As an aside, I'll also point out that, in the NYC transit system, it
is fairly rare that the rate limiting step is the speed of turnstile
reads. Far more often, limited space on stairwells, limited numbers of
turnstiles (which are used both for entry and exit), etc., seem to be
the limiting factor on how fast people can flow onto and off of the
platforms.)

I want repeat that I don't disagree with you that all of this is about
economics first, and the security level and costs have to take that
into consideration. We are in violent agreement there. A $100 but
perfect entry token is going to be worthless for most transit
systems, and an attack that costs a system a few dollars a year at
most is unlikely to be worth closing. (Indeed, the Metrocard system
isn't perfect, in that you can clone cards -- you just can't steal
more than a trivial sum before the card will be turned off, so no one
bothers.)

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. If an
existing system works reasonably well and you can use it off the shelf
without paying development and other costs, why not use it? I find the
fact that nearly every city in the world seems to have a custom
designed electronic fare system somewhat peculiar -- I'm not surprised
that several such systems might exist, but surely every city in the
world does not need to sink the costs of custom development of an
entire fare system. The Dutch apparently sunk vast sums into the
development of a brand new fare card system -- one questions what
requirements could not have been met with one of the several hundred
existing systems.


-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Dutch Transport Card Broken

2008-01-30 Thread Crawford Nathan-HMGT87
  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 fundamental errors:

1.) The cost of fraud is probably much less than the cost of the system
- 2 billion.  So, even if the system were completely secure, they still
might have been better off using paper tickets and the honor system.
From all indications, there were no cost controls on this project, so it
seems likely that the technology was not chosen because of technical
reasons or economic reasons, but rather, because someone was familiar
with it.  Perhaps it was suggested by a politician, and his cronies made
it their mission to make it happen.  Perhaps someone thought that it
would impress visitors; maybe it was a matter of national pride.

2.) The implementation was insecure.  Yes, there were probably technical
factors involved, but for the cost of the project, they could have
implemented a secure system, using other means if necessary.  The
problem, as I see it, was not an economic one, but rather, that the
developers relied on the secrecy of the algorithm for security, rather
than the size of the key.  Even unpaid, open-source developers have
produced secure systems for far less than the Dutch spent simply because
they followed good cryptographic design guidelines.

The question about mag strip versus RFID versus physical-contact readers
is a valid one.  For 2 billion, the cost/convenience difference between
radio and contact cards would have to be rather large to justify
implementing an insecure system.  Even a swipe time of 100 ms is enough
to implement a secure solution.  I find it very unlikely that a
competent engineering firm could not implement this in a reliable,
secure, and fast manner given this project's budget.

If the assertions are correct - that the subway is used 1,000,000 times
(or by 1,000,000 people?) a year, spending 2 billion on the fare system
means approximately 2,000 per user/time.  For those math types, that's
~~5.50 per day just to pay for the fare system, not to mention the cost
of electricity, trains, maintenance, etc...  How many people spend more
than 5.50 per day on train/subway/bus fare?  This system, and its
attendant costs - though obsolete even before its inception - will
probably be amortized over a few decades.  Which is why fraud is a very
important issue.  In that time frame, it is very likely that the
criminal underground could produce, and profit from, counterfeit cards
on a large scale.  Unlike turnstyle jumpers, fraud of this kind could
easily become so widespread that the subway system operates at a
significant loss.  A turnstyle jumper is easily caught; a rider with a
cloned card is virtually undetectable (without expensive upgrades to the
system).  If this system had been securely implemented, we might be able
to know if the fraud prevention would ever have exceeded the 2 billion
cost of the system; but because it isn't, the Dutch have essentially
flushed the money into the sewer.

And, bringing economics back into the picture, the purpose of the Mifare
system is *to prevent fraud*.  I seriously doubt that such a system -
especially now that it is broken - will eliminate 2 billion worth of
fraud.  It seems the Dutch would have been better off simply issuing
paper tickets and relying on the honor system.  Most people are honest;
the purpose of the ticket system is to keep people that way.
Unfortunately, it fails from both perspectives: it isn't economically
viable, and neither is it secure.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-01-30 Thread Anne Lynn Wheeler

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 username+password inside the HTTPS
session, because that´s more secure than client certificates ...

Does anyone have an idea how we can fix this flaw within SSL/TLS within a
reasonable timeframe, so that it can be implemented and shipped by the
vendors in this century?

(I don´t think that starting from scratch and replacing SSL makes much sense,
since it´s just one huge flaw ...)

   

re:
http://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken

aka ... that was part of the relying-party-only certificates from the 
mid-90s;

http://www.garlic.com/~lynn/subpubkey.html#rpo

i.e. the x.509 identity digital certificates from the early 90s, were 
becoming

more and more overloaded with personal information ... and by the
mid-90s, lots of institutions were starting to realize all that personal
information represented significant privacy and liability issues ... and
the RPO digital certificates were born.

However, it was trivial to demonstrate that (for all those business 
processes)

that the digital certificates were redundant and superfluous (however, there
was some amount of industry brain washing that digital certificates were
mandatory ... especially if digital signatures was used ... even if they
served no useful purpose).

this also showed up in work on pk-init for kerberos supporting digital
signature authentication ... and got into the confused mess with redundant
and superfluous digital certificates
http://www.garlic.com/~lynn/subpubkey.html#kerberos

and similarly digital signatures for radius
http://www.garlic.com/~lynn/subpubkey.html#radius

(between kerberos and radius, they represent possibly the majority
of authentication in the world today)

part of the confusion regarding the necessity for digital certificates
could be seen in the X9F financial standards work ... the appending
of even a relying-party-only digital certificate (lacking any personal
information) could represent a factor of 100 times payload bloat
http://www.garlic.com/~lynn/subpubkey.html#bloat

for a nominal electronic payment transactions (and also 100 times
processing bloat). as a result, there was some standardization
effort looking at compressed (relying party only) digital certificates
(even tho they were serving no useful purpose), attempting to
get the payload bloat down to possibly only 5-10 times (instead
of 100 times). I took the opportunity to demonstrate that it
would be logically possible to compress such digital certificates
to zero bytes ... totally eliminating the payload bloat. then rather
than advocating the elimination of totally useless, redundant
and superfluous digital certificates
http://www.garlic.com/~lynn/subpubkey.html#certless

there could be an infrastructure that mandated zero-byte
digital certificates appended to every transaction.





-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-01-30 Thread Eric Rescorla
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 Bits of checksum isn´t
  enough in reality. (1 out of 256 broken packets gets injected into your TCP
  stream)  Does IPv6 have a stronger TCP?
  
  Whether this is true or not depends critically on the base rate
  of errors in packets delivered to TCP by the IP layer, since
  the rate of errors delivered to SSL is 1/256th of those delivered
  to the TCP layer. 
 
   Out of curiosity, what kind of TCP are you guys using that has 8-bit
 checksums?

You're right. It's 16 bit, isn't it. I plead it being early in 
the morning. I think my point now applies even moreso :)



  Since link layer checksums are very common,
  as a practical matter errored packets getting delivered to protocols
  above TCP is quite rare.
 
   Is it not also worth mentioning that TCP has some added degree of protection
 in that if the ACK sequence num isn't right, the packet is likely to be
 dropped (or just break the stream altogether by desynchronising the seqnums)?

Right, so this now depends on the error model...

-Ekr

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Dutch Transport Card Broken

2008-01-30 Thread Dave Korn
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, but in practice this is
   not the case; commerce on the web is the
   counter-example.
 
 James A. Donald:
 
 The delay is often humanly perceptible.  If humanly
 perceptible, too much.
 
 I respectfully disagree - I'd argue that a short wait is actually more
 reassuring to the average user (Hey! The System's checking me out!) than an
 instantaneous connection would be.


  I also disagree.  It's not like anyone says to themselves Hey, this website
is taking me several seconds to access - I'll spend a couple of hours
physically going to the shop instead.  It's economics again: what amount of
time or money constitutes too much depends what the alternative choices are.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Dutch Transport Card Broken

2008-01-30 Thread Dave Korn
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 burned into the frontal lobes of every
single member of Microsoft's engineering (and marketing) teams with a red-hot
poker[*].

[  Over-engineered solutions to non-problems and gratuitous marketing-driven
featuritis have been the root cause of almost every windows security disaster
ever - e.g., email featuring 'rich content' such as scripts; web browsers that
download and locally run active-x from random websites; lots of vulnerable RPC
services installed and enabled by default on home user PCs; ... etc etc.;
certainly they have far outnumbered the occasional flaws in core kernel
services.  But - economics again!, and a tip'o the hat to Schneier and his
externalities argument - as long as the extra sales go to Microsoft's coffers,
and the extra costs are all imposed on their victims^Wusers, there's no
incentive for them to do otherwise.  Hence my suggestion that they need a
red-hot one (incentive, that is).  ]

cheers,
  DaveK

[*] - or red-hot Gutmann soundwave 
-- 
Can't think of a witty .sigline today

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-01-30 Thread Dave Korn
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 broken packets gets injected into your TCP
 stream)  Does IPv6 have a stronger TCP?
 
 Whether this is true or not depends critically on the base rate
 of errors in packets delivered to TCP by the IP layer, since
 the rate of errors delivered to SSL is 1/256th of those delivered
 to the TCP layer. 

  Out of curiosity, what kind of TCP are you guys using that has 8-bit
checksums?

 Since link layer checksums are very common,
 as a practical matter errored packets getting delivered to protocols
 above TCP is quite rare.

  Is it not also worth mentioning that TCP has some added degree of protection
in that if the ACK sequence num isn't right, the packet is likely to be
dropped (or just break the stream altogether by desynchronising the seqnums)?


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-29 Thread Ivan Krstić

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 not, this nonsense is a  
result of market forces rather than idiot technologists. In my  
experience, senior decision-maker types outside of the computer  
industry (and even within it, but perhaps a tad less so) are  
sufficiently non-technical as to never have heard of Kerckhoffs'  
principle -- and to disbelieve it when they do, since it opposes their  
intuition of what makes for secure systems. Various companies (or  
departments) then emerge peddling their home-grown crypto and  
trumpeting the fact that it's proprietary as a feature, commonly going  
hand in hand with stupidly large key sizes.


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 afterwards.


I've never heard back.




[0] Last paragraph, http://diswww.mit.edu/bloom-picayune/crypto/14238

--
Ivan Krstić [EMAIL PROTECTED] | http://radian.org

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Dutch Transport Card Broken

2008-01-29 Thread Crawford Nathan-HMGT87
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 billion-dollar project, one must use COTS RFIDs -
with their attendant privacy and security problems - is beyond me. 

A little ingenuity would have gone a long way.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Karsten Nohl
Sent: Monday, January 28, 2008 12:41 AM
To: Aram 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 (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 reader.

You are raising a very interesting point. The constraints under which
RFIDs and contactless smart-cards need to operate seem to vary widely
depending on the application.

The Mifare Classic cards, for example, authenticate in under 2 ms, but
wouldn't need to be that fast as you point out. Their crypto is also
very small, much smaller even than their flash memory. What good is it,
though, to have a lot of memory that is badly protected?

Last, the power consumption of the Mifare cards is certainly lower than
others, which doesn't matter, though, in the near-field where even
micro-processor based designs can operate. This is where contactless
smart-cards and RFIDs get confused often. Only for the latter ones power
consumption is a limiting constraint.

To answer your question directly: Within the limits of Mifare Classic
(48-bit cipher, 16-bit RNG), one can build a 64-bit cipher that
generates 'random' numbers internally. Within the same limits, one could
almost implement TEA which at least has undergone its share of
peer-review. Again: Trading some of the memory for this much higher
level of security would certainly have been worth it.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to
[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-29 Thread Harald Koch

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 reader technology out there, no matter how practiced I 
am it sometimes takes 2-3 tries to get a good read. Heck, sales clerks 
who swipe hundreds of times per day sometimes have trouble. And that's 
with a relatively easy to read magnetic stripe...


GO Transit here in Toronto ran a pilot program with contactless 
stored-value fare cards several years ago, which worked quite well; I'm 
sure technology details are available via Google. Alas, the project got 
squashed by a political movement for a Greater Toronto Area fare card 
project (which still hasn't gone anywhere 5-6 years later...).


--
Harald



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-29 Thread Perry E. Metzger

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 cards regularly. With the
 plethora of bad reader technology out there, no matter how practiced I
 am it sometimes takes 2-3 tries to get a good read. Heck, sales clerks
 who swipe hundreds of times per day sometimes have trouble. And that's
 with a relatively easy to read magnetic stripe...

Here in New York City, we use a swipe based system called Metrocard.
New Yorkers are not known for passive, accepting behavior, and yet no
one seems to complain about the swipe system -- it seems to work more
than well enough, and I have to double swipe at most once every few
dozen times. The system has held up quite well to quite determined
attacks, and the cards themselves are insanely cheap to produce.

I therefore expect no one else will ever use the technology --
anything cheap, secure and well tested in the field can't possibly see
wide adoption.

-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-29 Thread James A. Donald

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
 afterwards.

 Gutmann Sound Wave Therapy: Gutmann recommends:
: : Whenever someone thinks that they can replace
: : SSL/SSH with something much better that they
: : designed this morning over coffee, their
: : computer speakers should generate some sort
: : of penis-shaped sound wave and plunge it
: : repeatedly into their skulls until they
: : achieve enlightenment.

On SSL, Gutmann is half wrong:

SSL key distribution and management is horribly broken,
with the result that everyone winds up using plaintext
when they should not.

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.

We really do need to reinvent and replace SSL/TCP,
though doing it right is a hard problem that takes more
than morning coffee.

As discussed earlier on this list, layering induces
excessive round trips.  Layering communications
protocols is analogous to having a high level
interpreter written in a low level language. What we
need instead of layering is a protocol compiler,
analogous to the Microsoft IDL compiler.  The Microsoft
IDL compiler automatically generates a C++ interface
that correctly handles run time version negotiation,
which hand generated interfaces always screw up, with
the result that hand generated interfaces result in
forward and backward incompatibility, resulting in the
infamous Microsoft DLL hell.  Similarly we want a
compiler that automatically generates secure message
exchange and reliable transactions from unreliable
packets. (And of course, run time version negotiation)

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-28 Thread Karsten Nohl
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 receiving its power via the electromagnetic field being generated 
by the reader.


You are raising a very interesting point. The constraints under which
RFIDs and contactless smart-cards need to operate seem to vary widely
depending on the application.

The Mifare Classic cards, for example, authenticate in under 2 ms, but
wouldn't need to be that fast as you point out. Their crypto is also
very small, much smaller even than their flash memory. What good is it,
though, to have a lot of memory that is badly protected?

Last, the power consumption of the Mifare cards is certainly lower than 
others, which doesn't matter, though, in the near-field where even

micro-processor based designs can operate. This is where contactless
smart-cards and RFIDs get confused often. Only for the latter ones power
consumption is a limiting constraint.

To answer your question directly: Within the limits of Mifare Classic
(48-bit cipher, 16-bit RNG), one can build a 64-bit cipher that
generates 'random' numbers internally. Within the same limits, one could
almost implement TEA which at least has undergone its share of
peer-review. Again: Trading some of the memory for this much higher
level of security would certainly have been worth it.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-25 Thread ji
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

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-25 Thread Henryk Plötz
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 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 reader.

Hmm, how about Triple-DES for starters? :-) There are cards using 3DES
(called Mifare DESfire) available from the same manufacturer (NXP) as
the Mifare Classic cards with the proprietary algorithm that we looked
at. Apparently the main difference is that DESfire cards cost 1.50 EUR
per piece while Classic cards are at 0.50 EUR per piece. Other public
transport systems, such as Madrid, did the sensible thing and chose
DESfire:
http://www.nxp.com/news/identification/articles/otm81/madrid/

-- 
Henryk Plötz
Grüße aus Berlin
~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~


pgpsmBWu8tOGO.pgp
Description: PGP signature


Re: Dutch Transport Card Broken

2008-01-25 Thread sbg
 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 reader.

The 24C3 presenters to their credit made this exact point. But mixing the
16-bit nonce with the card identifier was an optimization too far.  That
said, it's a hard problem.  Inside Picopass is one of many examples that
progress is possible.

IMHO as always.

Cheers, Scott


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-25 Thread Aram Perez

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  
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 receiving its power via the electromagnetic field being  
generated by the reader.


Regards,
Aram Perez

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-25 Thread James A. Donald

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 government paid two billion dollars for stupidity, for 
foolishness that almost anyone on this list could have told them was 
foolish.  Secret algorithm!



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-25 Thread Anne Lynn Wheeler

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 to 
do this while receiving its power via the electromagnetic field being 
generated by the reader.
we sort of saw that in the mid-90s when we were doing the x9.59 
financial standard

http://www.garlic.com/~lynn/x959.html#x959

and getting comments that it wasn't possible to have both low cost and 
high security at
the same time. we looked at it and made the semi-facetious statements 
that we
would take a $500 milspec part and aggresively cost reduce it by 2-3 
orders of magnitude

will improving the security. along the way we got tapped by some in the
transit industry to also be able to meet the (then) transit gate 
requirements

(well under 1 second and do it within iso 14443 power profile).

part of it was having to walk the whole end-to-end process ... all the 
way back

to chip design and fab manufacturing process ... little drift about walking
fab in a bunny suit
http://www.garlic.com/~lynn/2008b.html#13

we effectively did get it on close to the RFID chip (i.e. the one that they
are targeting for UPC) technology curve ... i.e. chip fabrication cost 
is roughly
constant per wafer ... wafer size and circuit size have been leading to 
higher
number of chips per wafer (significantly reducing cost/chip). As circuit 
size

shrank with a corresponding shrinkage in the size of chips (that didn't have
corresponding increase in number of circuits) there was a blip on the
cost/chip curve as the area of the cuts (to separate chips in the wafer)
exceeded the (decreasing) chip size.  Earlier this decade there was
a new cutting process that significantly reduced the cut area ... allowing
yield of (small) chips per wafer to continue to significantly increase
(allowing pushing close to four orders of magnitude reduction ... rather
than 3-4 orders of magnitude reduction).

aads chip strawman references
http://www.garlic.com/~lynn/x959.html#x959




-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-25 Thread Anne Lynn Wheeler

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 brought in to
help wordsmith the cal. state electronic signature legislation which
led to also be brought in on federal electronic signature legislation
... some past posts
http://www.garlic.com/~lynn/subpubkey.html#signature

some other references ...

Hackers break into transport smart card
http://www.dutchnews.nl/news/archives/2008/01/german_hackers_break_transport.php
Transport smart card hacked again (update)
http://www.dutchnews.nl/news/archives/2008/01/transport_smart_card_hacked_ag.php

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-25 Thread Perry E. Metzger

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 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)?

Several other transit systems have payment cards that have proven
remarkably resilient to attack. For example, the NYC Metrocard
system has been attacked repeatedly without significant breaks (but it
does not rely on its cards being tamperproof -- it is an online system
using magstripes.)

The authors of the paper on the Dutch break claim that it would have
been possible to use far more secure means even given the basic
design, such as a non-proprietary crypto algorithm and longer keys. I
see no real reason to disbelieve this. In any case, if it was not
possible to do this with smartcards, existing, well proven mechanisms
that are in use in other transit systems could have been adopted. It
is not necessary to use an unimplementable architecture when
implementable and proven architectures exist.

Often we hear of a false need for engineering tradeoffs in such
circumstances. Engineering tradeoffs do indeed sometimes become
critical in security design. 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. Generally these are not engineering tradeoffs but
reflections of ignorance on the part of the designers.

Perry
-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]