Subject: [TLS] Straw poll on TLS SRP status

From: <[email-masked]>
Date: Thu, 24 May 2007 13:33:32 +0300

Folks,

The one remaining issue with TLS SRP is its intended status (Proposed
Standard, Informational, or Experimental). I and Eric think we need
more data to determine consensus here, so this message starts a
two-week straw poll on this issue. (Our apologies that this has 
taken so long; this poll should have been some time ago already.)

The question is: Do you support advancing draft-ietf-tls-srp as 
Proposed Standard? 

   [ ] Yes.
   [ ] I think Informational/Experimental is better.
   [ ] I don't care about the status, just get it published.
   [ ] Something else, please state:

You may reply either on the list, or privately to the chairs.

Some points you may wish to consider, summarizing some of the
arguments made earlier:

- The document describing SRP-3 (not exactly the same 
  algorithm as here), RFC 2945, is Proposed Standard.

- At least the following IPR disclosures may be relevant:

  https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=25
  https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=31
  https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=63

- Previously some WG members have argued that documents that 
  have IPR with non-royalty-free terms should go Informational
  or Experimental. We have at least one such IPR disclosure 
  (the last one listed above).

- There are several implementations of the draft: see e.g.
  http://www1.ietf.org/mail-archive/web/tls/current/msg01228.html

- Regardless of what status will be chosen, the RFC will 
  not be compatible with any of those implementations
  (since the TLS extension number will change).

Note that we need rough consensus to go for Proposed Standard; 
if there's significant disagreement, we go Informational or
Experimental.

Best regards,
Pasi & Eric

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

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 24 May 2007 23:19:41 +1200

<[email-masked]> writes:

>The question is: Do you support advancing draft-ietf-tls-srp as Proposed
>Standard?
>
>   [ ] Yes.
>   [X] I think Informational/Experimental is better.

I'll reply publicly in order to provide a rationale: Arguments against it
becoming a full standard are that this spec has been around for six years now
without any significant implementations appearing (apologies to the authors of
GnuTLS and TLS Lite :-).  Arguments for it being a full standard are that
given that we've got things like Camellia cipher suites (which have even less
mainstream support than SRP) moving forward as full standards, you can't
really count SRP out on that basis.  More to the point, the trend with WG
items seems to be to make everything a full standards rather than
experimental/informational.

So really the only deciding factor is the IP status.  The Lucent and
especially the Phoenix IPR statements will be, in my experience, sufficient to
scare off any commercial users (and by extension non-commercial users who have
to worry about lawyers).  So although it'd be nice to see SRP deployed, I
don't think the IP encumbrance will get it past Informational.  If it wasn't
for that, my vote would be "Just get it published".

Can we revisit this in 2012 (or 13, or whenever the patents expire)?

Peter.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 24 May 2007 13:28:35 +0200

>    [ ] Something else, please state:

[X] Something else: Get more information about the patent status of this
technology, possibly asking the patent owner to chime in.

I don't think we have enough information to decide right now.  While you

>   https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=63

If these would apply to this particular document, I would feel that we
shouldn't put this document on the standards track.  But those
disclosures aren't about this document.  And we have several free
software implementations out there and there haven't been any problems.
I think we must evaluate whether these patents are still relevant.

It would help if the patent owner could declare what they think about
people implementing TLS-SRP.  Do the owner consider TLS-SRP
infringement?  Is the owner willing to improve the patent license to
something that is more acceptable to the community?  [1] Further, what
guarantees do we have that the patent owner doesn't change their minds?

>   (since the TLS extension number will change).

I think that is a flaw with the TLS core specification that we should
fix.  It should be simple to get protocol numbers allocated to avoid
collisions.  I will maintain the old protocol numbers in GnuTLS for a
long while, and I suspect other implementers will do the same, to avoid
breaking backwards compatibility.

/Simon

[1] For hints on how to write a patent license that is more friendly
towards the free software community subset of the IETF community, see:
http://www.ietf.org/internet-drafts/draft-josefsson-free-standards-howto-00.txt

---

From: <[email-masked]>
Date: Thu, 24 May 2007 14:56:08 +0300

Simon Josefsson wrote:

> [X] Something else: Get more information about the patent status 
> of this technology, possibly asking the patent owner to chime in.

I believe several attempts have been made over the years to get 
more detailed IPR disclosures about SRP, but without much results.
In fact, this case is given as one example in RFC 3669.

<snip>

> If these would apply to this particular document, I would feel that
> we shouldn't put this document on the standards track.  But those
> software implementations out there and there haven't been any
> problems. I think we must evaluate whether these patents are still
> relevant.

One of the basic principles of IETF IPR is that "the IETF will 
make no determination about the validity of any particular IPR
claim" (see e.g. RFC 3979 and RFC 2026).

You, as an individual participant, are of course free to form opinions
about particular IPR claims (based on whatever evaluation you wish),
and express those opinions. But "we" as TLS WG will not make such a
determination.

In other words: we're not supposed to decide whether the IPRs
are valid or not; just whether this document is going Proposed
Standard or Informational/Experimental.

Best regards,
Pasi

---

From: badra <[email-masked]>
Date: Thu, 24 May 2007 14:15:44 +0200

> Standard or Informational/Experimental.

[X] Yes.

IMHO, it is better to don't argue on the patent itself since the current 
document is not the first and will not be the last IETF document to be 
published as Standard Track with the presence of a particular IPR claim.

Best regards,
Badra

-- 
Mohamad Badra
CNRS - LIMOS Laboratory

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 25 May 2007 01:16:44 +1200

<[email-masked]> writes:

>In other words: we're not supposed to decide whether the IPRs are valid or
>not; just whether this document is going Proposed Standard or
>Informational/Experimental.

I agree that it's not the WG's job to try and figure out the patent status.
It is up to us to consider what the effect of the IPRs on deployment will be
though, and the effect for any commercial user is that they'll run screaming.
Just because someone says they're only using it in free software won't help
either, look at what happened with GIF once Unisys started trying to enforce
their patent on LZW.

Peter.

---

From: Chris Newman <[email-masked]>
Date: Thu, 24 May 2007 09:06:45 -0700

It's my technical opinion that adding new user-level authentication mechanisms 
to the TLS layer is not a good idea in general.  TLS APIs are already quite 
complex and can be difficult to use.  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, however more 
traditional user-level authentication is a different beast.  As GSSAPI and SASL 
APIs have shown, designing general-purpose user-level authentication APIs is 
very difficult, by itself tends to create APIs most people can't understand, 
and it's not clear to me it's a good idea to add all that complexity to the 
existing TLS APIs.  I'd much rather keep user-level authentication as a 
separate subsystem and promote channel bindings on the standards track instead.

What do others on the list think about this issue?

                - Chris

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 24 May 2007 11:11:00 -0700

>    [ ] Something else, please state:

    [1] Yes.
    [2] I don't care about the status, just get it published.

Rationale for [1] -
    - Stanford IPR is royalty-free
    - SPEKE IPR is non-relevant
    - Dunno about Lucent EKE - AFAICT, their lawyers avoid making 
definite statements on principle (sigh).  But in the 9-year history of 
SRP they've never bothered anyone about it.  Also, the patent expires in 
3 years, so it will be a moot point soon enough.

Trevor

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 24 May 2007 15:58:42 -0400

On Thu, 24 May 2007 11:11:00 -0700
Trevor Perrin <[email-masked]> wrote:

> definite statements on principle (sigh).  But in the 9-year history
> of SRP they've never bothered anyone about it.  Also, the patent
> expires in 3 years, so it will be a moot point soon enough.
> 
Well, 4 years -- 20 years from the October 2, 1991 filing date, since
that's later than 17 years from the August 31, 1993 issue date.

Anyway -- you're never going to get a definitive "no" from Lucent.
There's absolutely no reason why they should bother -- if they say that
EKE doesn't apply to SRP, it gives them very little leverage to license
EKE.  If they say "yes", they have to do something about it, or no one
will take them seriously.  Besides, saying "yes" convincingly is a lot
of work; it would involve a fair amount of detailed study of the claims
in EKE and seeing how they match against what particular
implementations of SRP do.  This analysis includes understanding the
definitions in the (hard to understand) claims.  For example, claim 1
speaks of "forming an outgoing signal by encrypting at least a portion
of an excitation signal with a second symmetric key cryptosystem using
a key based on said authentication signal, said excitation signal being
based on a first signal, R.sub.A".  What is an "excitation signal"?
Coming up with suitable definitions is a major part of patent
litigation, and takes a significant amount of time and effort.  Why
should Lucent do that, if the FUD is working just as well?

Disclaimer: I'm one of the inventors of EKE.  But I haven't worked for
the patent owner since 1996, and back then they weren't interested in
my ideas about making it royalty-free for open source use, and charging
only for-profit users of the patent.  I have no idea if, when, to whom,
or how often Lucent has actually managed to license the patent.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 24 May 2007 14:05:52 -0700

[email-masked] wrote:
>    [x] Something else, please state:

I think the WG must be consistent about whether or not IPR (other than
royalty-free IPR) forces an RFC into Informational/Experimental status.
That decision should not be revisited for each and every RFC that may
encounter it.

RFC 4492, the ECC-in-TLS RFC, was forced into Informational because the
IPR status was uncertain to some WG members, even though there are two
major browsers that offer it (one open source), servers from several
vendors that offer it, and it is implemented in at least TWO different
open source TLS implementations.  I think that's sufficient precedent.

Note that I don't think that "Informational/Experimental is better."
but rather that it is what the WG has done in the past, and the WG
should remain consistent, or else the chairs should explain why they
insisted on it before and are now not doing so.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 25 May 2007 13:04:00 +0200

> insisted on it before and are now not doing so.

I agree with this.  I think it would be useful if the WG could develop
some simple criteria related to patents, i.e., when a specific
technology can and cannot go to the Standards Track.

There may be exceptional situations when such simple criteria aren't
applicable -- and, alas, one could argue that both TLS-SRP and TLS-ECC
are complex enough not to fit under simple guidelines -- but then the WG
can discuss per-case what the answer should be.  The WG criterias can be
updated after such incidents.

Having simple guidelines written down would make the procedures appear
more open and would encourage consistency.  Right now the process seems
arbitrary, and is open to hijacking by those who shout the strongest at
the moment, and further, can easily be FUDed by referencing patents
whose relevance have not been established.  I volunteer to help such an
effort or document.

/Simon

---

From: <[email-masked]>
Date: Fri, 25 May 2007 16:02:06 +0300

Nelson B Bolyard wrote:

> I think the WG must be consistent about whether or not IPR (other
> than royalty-free IPR) forces an RFC into Informational/Experimental
> status.  That decision should not be revisited for each and every
> RFC that may encounter it.

I actually think quite the opposite; that decision *should* be
revisited for each and every RFC. 

The decision cannot depend only on the existence of IPR claims.  
Not all IPR claims and license terms are equal.  And IPR claims 
anyway usually cover only IPR held by those contributing to the 
work; it's even likely that other IPR might be found later, 
after the document has been published.

But most importantly, not all documents are equal. There are some
things we probably want on standards track even though there is
other-than-royalty-free IPR (IPsec is one obvious example). Other
documents could be better off Informational/Experimental even in the
absence of any IPR.

<snip>

> insisted on it before and are now not doing so.

That decision was not made by the chairs (*): there was a straw poll,
the result of which was that there was no WG consensus to publish it
as PS, so it went Informational.

We're having a similar straw poll right now, so I think we are
being consistent -- the decisions are made by rough WG consensus,
not formal rules.

(*) Disclaimer: I wasn't chair back then, and I supported PS.

Best regards,
Pasi

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 25 May 2007 10:42:36 -0700

>insisted on it before and are now not doing so.

Fully agree. And I think it is appropriate to delay the decision on 
tls-srp until we have made that decision. Such a delay will not 
affect developers significantly.

FWIW, I'm fine with us saying "they can get on standards track just 
as well as if there were no IPR issues", but I'm equally fine with 
"they can only be published as Informational".

>after the document has been published.

If more than a small handful of TLS WG members think that a 
properly-published IPR claim is likely to be valid enough to be held 
against them, that is a high enough bar to put the proposal in the 
"IPR-affected" bucket.

>other-than-royalty-free IPR (IPsec is one obvious example).

This is irrelevant. We are talking about TLS extensions, not TLS itself.

>Other

This is also irrelevant.

--Paul Hoffman, Director
--VPN Consortium

---

From: "tom.petch" <[email-masked]>
Date: Fri, 25 May 2007 12:03:22 +0200

----- Original Message -----
From: "Chris Newman" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, May 24, 2007 6:06 PM
Subject: Re: [TLS] Straw poll on TLS SRP status

> What do others on the list think about this issue?
I agree with you; we are making a complex technical situation (ignoring legal
issues such as IPR) yet more complex which leads me to

   [X] Something else, please state:

Do not publish this as an RFC.  If this is a single transferrable preference
system (I just love Irish general elections, voting was yesterday) then my
second preference is

   [X] I think Informational/Experimental is the next less bad

Tom Petch

---

From: Tom Wu <[email-masked]>
Date: Fri, 25 May 2007 11:09:52 -0700 (PDT)

> issues such as IPR) yet more complex which leads me to

Given that the SRP-TLS draft does a fairly good job of containing that
complexity, as evidenced by the success of its interoperating
implementations, it seems this concern would be more than
counterbalanced by the overall utility of having a handy solution
to the password authentication+transport security problem.

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

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 25 May 2007 12:16:34 -0700

> At 2:05 PM -0700 5/24/07, Nelson B Bolyard wrote:
[...]
> tls-srp until we have made that decision. Such a delay will not affect 
> developers significantly.

It will, since we'd like to get IANA numbers assigned soon.

I think the IPR situation is as clear as it's going to get, and the 
chairs are doing the best they can in polling the WG.

As Pasi say, these issues are complex and situtation-dependent.  It 
would be nice to have a clear, mechanical policy to apply, but I don't 
know of any WG or Standards Body with such a thing.

This draft has languished long enough, let's just get rough consensus 
and move on.

Trevor

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 26 May 2007 13:36:08 +1200

"Chris Newman" <[email-masked]> 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.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 27 May 2007 11:41:09 +0300

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

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.

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 27 May 2007 21:10:50 +1200

Yoav Nir <[email-masked]> writes:

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

Interesting draft [0]!  However, I'd never heard of this until now, and it's
not listed in the drafts on the TLS WG page either.

Peter.

[0] Disclaimer: I haven't read through it thoroughly yet, I'm sure I'll find
    something to gripe about presently :-).

---

From: <[email-masked]>
Date: Tue, 29 May 2007 11:05:45 +0300

> affect developers significantly.

While it's relatively easy to sort documents to "IPR-affected" and 
"no significant IPR issues known" buckets, do you have any suggestions
about what kinds of rules you would want for sorting documents 
to "Standards Track" and "Informational/Experimental" buckets?

In doing so, we have to follow RFC 2026 (which defines the different
maturity levels) -- but at least I cannot see how any mechanical rule
could be used to get that result, beyond asking WG members to exercise
their judgement (i.e. what we have done so far).

Best regards,
Pasi

---

From: Brian Minard <[email-masked]>
Date: Tue, 29 May 2007 11:28:03 -0400

>    [ ] Something else, please state:

     [X] I don't care about the status, just get it published.

WRT IPR concerns: the people who need to implement this need to
educate themselves on what IPR exists and deal with it. Let's move
the document forward.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 May 2007 09:02:53 -0700

>to "Standards Track" and "Informational/Experimental" buckets?

My preference is "IPR-affected" all go into the 
"Informational/Experimental" bucket. My main reasons for that are:

- It will stop this repetitive discussion

- The "lower" status of Informational or Experimental is irrelevant 
to users but seems relevant to some developers

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Rex <[email-masked]>
Date: Tue, 29 May 2007 18:53:50 +0200 (MEST)

Peter Gutmann wrote:
> 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.

We are happily using SSL with client certs for 30k+ users with a number
of different servers and we've been using it productively for 6 years
now (started using it 1999).

Initially there were a few bugs in MSIE, but they've been fixed
a few years ago.  Right now, the largest remaining issue for the
most commonly used platform is a Hotfix for WinHTTP that IIRC
is not yet available for public download.

One observation about SSL client certificate verification: you absolutely
do NOT want revocation checking or any kind of fancy path validation
(policy constraints and other bullshit) be done within the TLS stack.
Everything that involves communication to third parties or additional
computational processing will have to be done at a point where it
scales (i.e. in the backend server farm) or it will kill throughput
in a large server and ambitions for high availability.

> providing substrate for phishing attacks.

I agree that for User-level (or more precisely app-level) authentication is
the preferable approach for pretty much all scenarios that are not
(or not yet) native SSL/TLS, including passwords and GSS-API authentication
(e.g. rfc-4559).  It scales much better and it is much easier to adapt
to custom requirements (of legacy authentication systems).

Having to mess with the _entire_ middleware (SSL/TLS and backend
communication layers directly above it) each time an additional
authentication scheme (or additional attribute of an existing scheme)
needs to be supported is the nightmare scenario for software maintenance,
especially if there are thrid-party components (like SSL Accellerators
or reverse proxies) are involved.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 29 May 2007 13:23:51 -0400

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:[email-masked]] 
Sent: Friday, May 25, 2007 9:36 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Straw poll on TLS SRP status

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.

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

---

From: Martin Rex <[email-masked]>
Date: Tue, 29 May 2007 19:27:02 +0200 (MEST)

> to users but seems relevant to some developers

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

Even Lucent could come up with an IPR statement describing under
what terms they will be licensing their patent(s) should they
ever come to the conclusion that their any of their patent(s) apply,
and that they have not made any such determination so far.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 29 May 2007 13:57:38 -0400

> From: Martin Rex [mailto:[email-masked]]
> 
> We are happily using SSL with client certs for 30k+ users with
> a number of different servers and we've been using it productively
> for 6 years now (started using it 1999).

Ditto, for 4.3 million users.  Ditto for the implementation concerns
surrounding revocation, which for certs can be addressed in a scalable
manner.

I have doubts that password-based SSO schemes can achieve a similar
level of scalability.

---

From: Martin Rex <[email-masked]>
Date: Tue, 29 May 2007 20:09:49 +0200 (MEST)

> is a huge community of users with certs who use it every day.

I'm not very familiar with the various kinds of support for crypto hardware
that is out there, or those that you're thinking of.

The one that I know (available for the OEM software that we ship)
performs only the secret key operations in hardware (on the smartcard)
because its primary function is to not reveal the private key.

Even if there were smartcards able to hold arbirarily large and complex
lists of trust anchors and able to independently build certificate
chains and perform path validations -- as long as the security critical
action is performed in regular software, that software can be trojaned
(skipping the PKI checks or ignore the results).

I see one area where an improvement might be useful (at least for those
platforms where users do not always work with full privileges, and
where we believe that there exists some level of effective privilege
seperation): have the private-key operations performed by a
privileged system service rather than entirely within the
process space of the user application, sort-of a software-smartcard.

> a PBE subsystem and binding interface could be implemented with equal

Just that we currently don't have suitable channel bindings in
the installed base of SSL/TLS that will work transparently accross
all deployed scenarios (some of which are using seperate consecutive
but independently protected communication links).  A re-encrypting
reverse proxy (including SSL Accellerators) is probably the most
common multi-hop scenario.

But if the nature of SSL/TLS channel bindings is defined and nailed
down, then the existing deployments may be adopting means to
transfer them in multi-hop scenarios in similar fashions how they
make SSL client-cert authentication work in multi-hop scenarios,
and that work must only be done once.

-Martin

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 30 May 2007 22:16:34 +1200

>We are happily using SSL with client certs for 30k+ users with a number of
>different servers and we've been using it productively for 6 years now
>(started using it 1999).

The reason I made the comment about TLS client auth being an abject failure is
that every time anyone mentions the possibility of providing any other way of
authenticating clients and servers, it's practically guaranteed that someone
will pop out of the woodwork and state that we already have the perfect
solution to authentication in the form of client certs (see e.g. the comments
made during the TLS-PSK last call), and here's a special-case stovepipe
deployment with a captive audience as incontrovertible proof that client certs
are perfectly workable in the real world.  In the meantime we have a multi-
billion doller phishing industry as proof that if certificate-based
authentication is working then it's a very peculiar interpretation of the term
"working".

At the moment for 99.9% of users if they want to do authentication to Amazon,
to Hotmail, to Flickr, to almost anything out there (in other words the very
situation where client-cert-auth was supposed to be used) then the state-of-
the-art solution that TLS provides is to connect to the server and hand over a
static password in plaintext form (over the TLS channel), circa 1965.  The
ultimate indictment of TLS certificate-based auth has to be the fact that when
I want to authenticate myself for the NIST PKI Workshop (the premier PKI get-
together AFAIK), I have to use a static password.

Anyway, my point is that the No.1 threat (by a long shot) to TLS users today
is phishing, and it works because (as stated above) the best way that we have
of handling authentication is by handing over the password.  So we urgently
need to come up with some alternative (Authz, EAP, whatever) that at least
provides the tools to combat phishing.  I'm somewhat biased towards EAP
because it provides (at least in theory :-) a universal mechanism that would
allow companies to leverage their existing authentication infrastructure.

Peter.

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 May 2007 21:14:20 +0200 (MEST)

Peter Gutmann wrote:
> 
> The reason I made the comment about TLS client auth being an abject failure
> is that every time anyone mentions the possibility of providing any other
> way of authenticating clients and servers, it's practically guaranteed
> that someone will pop out of the woodwork and state that we already have
> the perfect solution to authentication in the form of client certs

The main reason why I brought it up is because most the installed base
is able to cope with SSL clients certs.  But it did take a few years
to get there.  It is far from perfect, especially in mixed scenarios
for the cert-less users because, depending on the browser, they
might get constantly annoyed with a certificate selection popup.

I would not want to see additional password-based authentication schemes
to be promoted that require significant changes to then entire
infrastructure/middleware, because this will only add new problems,
and not really solve any of the existing problems.

The reason for people still using passwords are (a) legacy password-based
authentication systems and (b) the necessity to be able to walk up
to any network-connected PC and "login" from there by entering
a memorized password.  And the latter is often a phishing-enabling
requirement.

The operational costs of password-based authentication is likely much
lower than the use of strong cryptographic credentials, which require
either a hardware token (e.g. USB-key, smartcard) or a software
credential that is distributed through the network protected
by a traditional password, and which must be at least temporarily
persisted on the PC where it is being used.

Dealing with forgotten passwords is usually much easier for a
helpdesk/callcenter than dealing with a forgotten or lost or
defective hardware token, especially if when you're travelling.

OTP might be seen as one approach to thwart phishing attacks, but
it is also seen as a major inconvenience.   More and more often
you find Single Sign-On (SSO) and in addition to that, credentials
management tools (not just Browsers) aggressively try to persuade
users to memorize and auto-supply credentials (The credentials
manager on my new notebook was a serious nuisance and real security
problem, so I uninstalled it).

The problem with SSO is that it allows attackers to perform all sorts
of MITM attacks through active content, trojans and CSRF
(Cross-site request forgery).

The approach taken by online banking to limit the damage from such
attacks is to accept SSO only for reading information, not for
requesting transaction.  Here in Germany, most banks use an OTP-style
approach (TAN) for authenticating transactions.  I think this is
a fairly reasonable and usable compromise, but it requires careful
application design (clearly seperate more dangerous and less dangerous
actions and exclude the more dangerous actions from Single Sign-On)
and I don't currently see how the two different authentication
schemes (Single Sign-On and per-transaction authentication) should
both be provided by TLS without significant architectural changes
to the middleware (session management).

The other thing I feel uncomfortable with is the skewed threat model.
On the one hand there is the attitude that one cannot prevent the
credential from being stolen, so one tries to limit the damage that
can be done to the server (in a cover-your-ass fashion).  On the other
hand there is ignorance about the problem that an attacker that is
able to steal my credentials from my machine can probably just as
easily subvert my browser to perform the fraudulent transaction
itself and therefore bypassing all channel-bindings and
password-concealing efforts that are being proposed.

At the same time the victim Joe User will be in a much worse position
trying to repudiate a fraudulent transaction compared to the majority
of unsophisticated phishing attacks today.  Service providers will
like this because Joe User will have to cover most of the damages
and the attacker will like it because they're less like to get
caught.  As security engineers we can hardly claim tomorrow that
we could not anticipate such a shift in attack methods when tweaking
the technology to thwart the large amounts of low-tech phishing attacks
and cutting into the attackers ROI without adding real security.

If we think that passwords are fundamentally flawed in this
environment, we should not significantly prolong and promote
their continued use by applying band aids.

:-|

-Martin