RE: [TLS] Straw poll on TLS SRP status

["Kemp, David P." <DPKemp at missi.ncsc.mil>]

We all know that there are communities where client certs have worked
quite well in practice.  Based on that experience, we are at the point
of arguing not over whether client certs should be used (they are) but
whether smartcards should be required or software is good enough.  Try
banging on Google's top entry for "defense online" without a cert; there
is a huge community of users with certs who use it every day.

But if password-based authentication must be used, I agree that it must
be as tightly bound to session establishment as client certs currently
are.  Perhaps that will be achieved in practice with "separate subsystem
with channel bindings", perhaps not.  Cert operations are handed over to
the PKCS-11 subsystem yet are still bound to the handshake; in principle
a PBE subsystem and binding interface could be implemented with equal
care.

Dave


-----Original Message-----
From: Peter Gutmann [mailto:pgut001 at cs.auckland.ac.nz] 
Sent: Friday, May 25, 2007 9:36 PM
To: paul.hoffman at vpnc.org
Cc: tls at ietf.org
Subject: Re: [TLS] Straw poll on TLS SRP status

"Chris Newman" <Chris.Newman at Sun.COM> writes:

> Client certificate authentication has been there long enough that it's
a 
> known quantity how to dig the necessary details out of the TLS layer
for an 
> application to consume

And we all know how well client certs haved worked out in practice.  The
abject failure of TLS client-cert authentication is probably the
strongest
argument in favour of providing new authentication mechanisms that do
actually
work.

> I'd much rather keep user-level authentication as a separate subsystem
and
> promote channel bindings on the standards track instead.

>From a very abstract protocol point of view that sounds good.  From a
UI point
of view it's terrible: You need to integrate mutual authentication
directly
into the crypto handshake, not have it as a separate layer.  If you
don't, you
fall into the "connect to anything listening on the appropriate port,
then
hand over your credentials" trap that makes HTTP-over-TLS the phisher's
best
friend.  A TLS handshake can have only two possibile outcomes,
"connected with
both sides authenticated" or "not connected".  Anything else and you're
just
providing substrate for phishing attacks.

Peter.

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls