Subject: Re: [TLS] Straw poll on TLS SRP status

From: Tom Wu <[email-masked]>
Date: Sat, 2 Jun 2007 00:08:43 -0700 (PDT)

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.

Yoav Nir:

> I think SRP should not be a stand-alone extension, but rather that it should be introduced as part of EAP.

At the risk of being a bit blunt, if the EAP approach is so great, why has
more support grown around TLS-SRP instead?  I would also add that the two
parts of your statement are not mutually exclusive.  If you want to advance
EAP-SRP in TLS, great, but it is not a valid reason to slow down a standard
that is already in use and has seen a lot of scrutiny.

> I know SRP has the capability to do the whole key exchange, but why do we need it.

Perhaps we want the session to be secure against MITM attacks?

> The problem that both extensions are trying to solve is the problem of using passwords for authentication within TLS.
> TLS has a perfectly good way for keying already.

This is not necessarily directed at you in particular, since I've seen
several comments of this flavor in this discussion - there's this
assumption that transport security and password authentication are
separable and modular, but in the context of strong password protocols,
this assumption is false - in fact it is precisely this kind of
separation that would allow a MITM attack.  Password authentication
with low-entropy passwords is Harder Than You Think.  Little things
like which party sends which message first or whether one message
should only be sent after some other message has been received,
those can spell the difference between a secure password protocol
and an insecure one.  The TLS-SRP standard represents a great deal
of tweaking and analysis to make sure all the details are right.

Without a specific alternative password protocol to subject to
scrutiny, EAP or any other general proposal cannot really be
presented legitimately as an altenate "choice" to TLS-SRP at
this time since there is no way evaluate its security.  Just
saying it's SRP isn't enough without knowing how the transport
encryption/MAC keys are tied to the password-based key exchange.

Tom
-- 
Tom Wu
http://www-cs-students.stanford.edu/~tjw/

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Yoav Nir <[email-masked]>
Date: Sun, 3 Jun 2007 13:43:08 +0300

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

> Perhaps we want the session to be secure against MITM attacks?

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.

---

From: Tom Wu <[email-masked]>
Date: Mon, 4 Jun 2007 15:58:51 -0700 (PDT)

On Sun, 3 Jun 2007, Yoav Nir wrote:

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

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

Tom

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Jun 2007 08:59:54 +0300

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

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.

---

From: Tom Wu <[email-masked]>
Date: Mon, 4 Jun 2007 23:38:39 -0700 (PDT)

On Tue, 5 Jun 2007, Yoav Nir wrote:

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

Yup, and Stanford has issued a royalty-free license for SRP.  The only
remaining message to send is to competitors trying to do a denial-of-
service against it.  Making SRP-TLS Proposed would send the message
that this DoS attack doesn't work against the IETF, discouraging
"patent race" behavior.

> and the EAP-in-TLS draft is still current (though we are going to publish a 
> newer version soon)
> I agree, though, that this hasn't had the security analysis that was given to 
> 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.

I don't think the "complicates the security analysis" point is valid -
it is no more complicated than a TLS library that supports both client
certs and, say, PSK.  And as you point out yourself, there would be
many differences between the two that would make one or the other
preferable for a given server to support, so they're really not doing
the same thing.  In this case, there would be a clear tradeoff between
the advantages you cite for EAP versus the roundtrip, performance, and
possible security advantages of SRP-TLS.

Tom

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 05 Jun 2007 19:42:09 +1200

>for use of ECC in IKE and TLS.

Note however that the TLS license is booby-trapped: You can implement TLS, but
you can't do certs with it.  This makes the "royalty-free license" more or
less useless.

(I haven't looked at the IKE one, but I'm guessing it's the same thing there).

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Jun 2007 11:05:47 +0300

IIRC you can use certs, but the CA needs a license. In TLS it works  
pretty well, because usually a website gets a cert from someone on  
Explorer's list, so as long as they get a license, everyone is fine.

With IKE it's a little more booby-trapped, because lots of  
organizations issue their own certificates.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 05 Jun 2007 20:25:06 +1200

Yoav Nir <[email-masked]> writes:

>In TLS it works pretty well, because usually a website gets a cert from
>someone on Explorer's list, so as long as they get a license, everyone is
>fine.

According to a SecuritySpace survey from a few years ago (discussed in Simson
Garfinkel's thesis), 58% of all SSL server certs in use today are invalid for
some reason (unknown CA, self-signed, expired, whatever).  "Not issued by a
recognised CA" covers about 30% of all SSL server certs.  There aren't any
figures available for opportunistic-encryption facilities like STARTTLS et al,
but I'd imagine it's closer to 100% there since opportunistic encryption more
or less by definition doesn't care about officially-sanctioned crypto.  So
"issued by a recognised CA" only starts to address a small corner of the
market.

In any case even if you do want to go with a recognised CA, how many
recognised CAs will actually issue you an ECC cert?  No matter how you look at
it, the Certicom "license" doesn't work.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Jun 2007 11:34:21 +0300

It works well enough that the browsers have it now (at least IE), and  
also IKE implementations from several vendors including Microsoft.

When and if the likes of Verisign start issuing them remains to be  
seen, as well as when the rather ubiquitous Microsoft CA will begin  
to issue such certs.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 05 Jun 2007 20:48:02 +1200

Yoav Nir <[email-masked]> writes:

>It works well enough that the browsers have it now (at least IE), and also
>IKE implementations from several vendors including Microsoft.

It's irrelevant what the software has built in, if no-one's using it then it
may as well not be there (that's just a paraphrasing of the prime directive of
security UI, "If the user doesn't understand your feature, it doesn't exist").
Certicom issued their "royalty-free license" for ECC in TLS last year some
time, and I still haven't seen any use of it by anyone outside the USG and its
dependents as part of the Suite B mandate.  Although I can't speak for vendors
like Microsoft, I would imagine their only reason for putting it in IE was for
that particular market (I've talked to non-MS developers and they've told me
that's the sole reason why they added it to their product).

(Again, I don't know about the IKE situation).

Anyway, this is all going off on a bit of a tangent...

Peter.