Re: [TLS] Straw poll on TLS SRP status

[Yoav Nir <ynir at checkpoint.com>]

On Jun 5, 2007, at 1:58 AM, Tom Wu wrote:

> On Sun, 3 Jun 2007, Yoav Nir wrote:
>
> > On Jun 2, 2007, at 10:08 AM, Tom Wu wrote:
> >
> > > Martin Rex:
> > > > The document status is pretty much the only "incentive" that the
> > > > IETF can put out for companies to slow down on their patents race
> > > > or at least to come up with reasonable licensing terms (i.e.  
> > > > royalty free
> > > > for Free and OpenSource software).
> > > Keep in mind that in the context of this discussion, Stanford  
> > > (SRP) and
> > > Lucent (EKE) are competitors.  Knocking down TLS-SRP from  
> > > Proposed to
> > > Informational/Experimental rewards the player that did not do the  
> > > "right"
> > > thing (free licensing) at the expense of the player that did the  
> > > "right"
> > > thing (Stanford).  The last thing you want to do is to create an  
> > > incentive
> > > for players to do an IPR "denial of service" on a competitor's  
> > > technology,
> > > since this encourages "patent race" behavior.
> >
> > It's not about punishing Stanford or rewarding Lucent. It's the  
> > question of whether or not you might get sued for implementing this.
>
> It _is_ precisely about punishment/reward - if you read the context of
> my comments, you'll see that I was addressing Martin Rex's point about
> the use of document status as incentive, and supplying information  
> about
> how the incentives would work in this particular case.

However, Martin is right, in that the incentive works. ECC has been  
slowed down significantly by Certicom's patent claims, both in  
standards and in implementations.  This has finally made Certicom  
issue a royalty-free license for use of ECC in IKE and TLS.

> > Perhaps, but we don't need to have the key mixed into the  
> > encryption keys of TLS. It should be good enough to have the  
> > server prove it has access to the SRP key.  This was the approach  
> > taken in IKEv2, and it should also be good for EAP-in-TLS.
>
> Handwaving with the word "should" is easy, but there still isn't a
> specific protocol that can be analyzed for security, or performance
> for that matter - if there is one D-H exchange for the session
> security keys and a separate key exchange for SRP, then you're
> already at close to a factor-of-two performance disadvantage
> compared to SRP-TLS.  It's not that I dislike EAP-in-TLS, but it's
> not entirely fair to compare a real standard versus some theoretical
> construct, especially if you always give the latter the benefit of
> the doubt before it gets exposed to real design and engineering
> tradeoffs.  This EAP discussion is a non-starter until someone
> actually puts forth a specific SRP-EAP-TLS proposal.

Strictly speaking, there is a specific protocol. The EAP-SRP draft is  
expired, but still available (maybe someone should pick up this effort)
http://tools.ietf.org/id/draft-ietf-pppext-eap-srp-03.txt
and the EAP-in-TLS draft is still current (though we are going to  
publish a newer version soon)
http://www.ietf.org/internet-drafts/draft-nir-tee-pm-00.txt

I agree, though, that this hasn't had the security analysis that was  
given to SRP-TLS.

I really have two concerns with SRP-TLS:
 1. It's usually not a good idea to provide two ways of doing the  
same thing. In this case, if the TLS library maker should support  
both EAP-SRP and SRP-TLS that complicates the security analysis of  
the library. The websites would probably want to support both.
 2. Unlike certificates, which only require verification, passwords  
actually need to be stored in some form or another on the  
authenticating server. EAP provides a method of separating the  
authentication server from the TLS server, which is IMO a good thing,  
and also reflects the way most organizations store handle their  
passwords. From reading SRP-TLS, it looks like the server has to do  
all the verifications itself. Of course, there might be a backend  
server, but the protocol and trust relationship between the backend  
server and the TLS server is not specified. In EAP, this is specified.

You are right about the performance disadvantage of EAP-in-TLS as  
compared to SRP-TLS, but that is mitigated by the fact that half the  
server-side work is done on the AAA server. The extra roundtrips in  
the protocol are somewhat more worrying, because they cannot be  
solved by throwing extra resources at the server.


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