Another entry in the internet security hall of shame....

[Alaric Dailey]

If I may inject my humble opinion(that isn't necessarily a response to
this peticular email), I may not be as informed as some but....

While I admit that PKI is flawed, I don't see anyway that PSK could used
effectively.

How are PSKs going to be shared in a secure way?
are we talking about generating a new key for every connection?
    if so how do you validate the key?
    if not, how do you validate that the key hasn't been compromised by
someone who put up a phishing site?
   
In my opinion, PSK has the same problems as all symmetric encryption,
its great if you can share the secret securely, but distribution to the
masses makes it infeasible.

>From the way I see it, if site logins were done using a client
certificate, like the USPS electronic postmark site
<https://www.uspsepm.com> allows and should enforce, then the security
issues wouldn't be issues, as there would be nothing usable handed off
to an attacker. Furthermore the site could be sure of the users
identity, something none of the other solutions I have seen address.



-- 
 *Alaric Dailey* 	Everyone deserves privacy.

Thawte 'Web of Trust' Notary Seal <http://www.thawte.com/wot> 	Thawte
'Web of Trust' Notary <http://www.thawte.com/wot>
CAcert 'Web of Trust' Assurer <http://www.cacert.org/wot.php?id=3>
Notary Public 	CAcert 'Web of Trust' Assurer Seal <http://www.cacert.org>

ATTENTION USERS OF MICROSOFT OUTLOOK AN MICROSOFT OUTLOOK EXPRESS:
Some versions of these products have trouble replying to digitally
signed emails, like this one.
For more information on this error, and how to fix it please visit Mark
Nobles website here <http://www.marknoble.com/tutorial/smime/smime.aspx>.



Stephan Neuhaus wrote:

> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20050901/ecae753d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: seal_wot.gif
Type: image/gif
Size: 4348 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20050901/ecae753d/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cacert-wotseal73.gif
Type: image/gif
Size: 3556 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20050901/ecae753d/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3544 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20050901/ecae753d/attachment.bin>