[18354] in cryptography@c2.net mail archive
Re: Another entry in the internet security hall of shame....
daemon@ATHENA.MIT.EDU (Stephan Neuhaus)
Thu Sep 1 11:48:18 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Thu, 01 Sep 2005 09:39:50 +0200
From: Stephan Neuhaus <neuhaus@st.cs.uni-sb.de>
To: "James A. Donald" <jamesd@echeque.com>
Cc: cryptography@metzdowd.com
In-Reply-To: <43158188.29849.702CF09@localhost>
This is a multi-part message in MIME format.
--------------080009090902050109010609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
James A. Donald wrote:
> But does not, in fact, prevent.
Let me rephrase that. Are we now at a point where we must admit that
PKI isn't going to happen for the Web and that we therefore must face
the rewriting of an unknown (but presumably large) number of lines of
code to accomodate PSKs? If that's so, I believe that PSKs will have
deployment problems as large as PKI's that will prevent their widespread
acceptance.
That's because PSKs (as I have understood them) have storage and
management issues that CA certificates don't have, four of which are
that there will be a lot more PSKs than CA certificates, that you can't
preinstall them in browsers, that the issue of how to exchange PSKs
securely in the first place is left as an exercise for the reader (good
luck!), and that there is a revocation problem.
To resolve any of those issues, code will need to be written, both on
the client side and on the server side (except for the secure exchange
of PSKs, which is IMHO unresolvable without changes to the business
workflow). The client side code is manageable, because the code will be
used by many people so that it may be worthwhile to spend the effort.
But the server side? There are many more server applications than there
are different Web browsers, and each one would have to be changed. At
the very least, they'd need an administrative interface to enter and
delete PSKs. That means that supporting PSKs is going to cost the
businesses money (both to change their code and to change their
workflow), money that they'd rather not spend on something that they
probably perceive as the customer's (i.e., not their) problem, namely
phishing.
Some German banks put warnings on their web pages that they'll never ask
you for private information such as passwords. SaarLB
(http://www.saarlb.de) even urges you to check the certificate
fingerprint and provides well-written instructions on how to do that.
In return, they'll assume no responsibility if someone phishes your PIN
and TANs. They might, out of goodwill, reimburse you. Then again, they
might not. I believe that SaarLB could win in court. So where is the
incentive for SaarLB to spend the money for PSK support?
Fun,
Stephan
--------------080009090902050109010609
Content-Type: text/x-vcard; charset=utf-8;
name="neuhaus.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="neuhaus.vcf"
begin:vcard
fn:Stephan Neuhaus
n:Neuhaus;Stephan
org;quoted-printable:Universit=C3=A4t des Saarlandes;Department of Informatics
adr;quoted-printable:;;Postfach 15 11 50;Saarbr=C3=BCcken;;66041;Germany
email;internet:neuhaus@st.cs.uni-sb.de
title:Researcher
tel;work:+49-681/302-64018
tel;fax:+49-681/302-64012
x-mozilla-html:FALSE
url:http://www.st.cs.uni-sb.de/~neuhaus
version:2.1
end:vcard
--------------080009090902050109010609--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
