Re: [TLS] Straw poll on TLS SRP status

[Yoav Nir <ynir at checkpoint.com>]

I agree about the need to implement authentication systems that work  
in practice (passwords, token cards, OTP) into TLS.

But still, I think the IPR issue is important here.  I think it will  
deter all browser makers, both commercial and open source. If our  
goal is to allow passwords for authenticating SSL, this is not the way.

So I'm going to go with
   [X] I think Informational/Experimental is better.

Disclaimer: my opinion is somewhat biased. I'm one of the authors of  
http://www.ietf.org/internet-drafts/draft-nir-tee-pm-00.txt and I  
really think you should give the user the choice between IPR-laden  
methods (such as EAP-SRP) and IPR-free methods such as EAP-MD5.


On May 26, 2007, at 4:36 AM, Peter Gutmann wrote:

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