Subject: Re: [saag] Channel binding is great but not a silver bullet

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 10:00:36 -0600

On Thu, Feb 26, 2009 at 03:20:06PM -0500, Sam Hartman wrote:
> Nico, while I'm in favor of channel binding and believe your approach
> has a lot of value, please be careful to apply it only where applicable.

I'm mildly offended by your comment.  This is not channel binding as an
end -- it'd be silly to treat channel binding as end in itself, and if
you imply that that's what I'm doing then I categorically reject that.

This is channel binding as a means to an end, not as the end.  The end
is mutual authentication without a PKI but with [optional] federation.

> Phil is talking about the web browser PKI.  Channel binding to
> existing authentication solves some problems in that space, but
> definitely not all.  For example it is not useful for securing
> enrollment or certain classes of URI-only handoff.

My proposal does not solve enrolment, and though enrolment is the same
problem as the base problem, enrolment is also rare, therefore a simpler
problem.

There are two kinds of enrolment: those where the user is willing to use
a pre-existing business relationship, and those where the user is not.
For the former one could use SMS, much the way Google handles gmail
account creation, and, with somewhat less privacy, any ISP-mediated
federation will do as well -- heck, one could have coffee-house mediated
federation.  For the latter the existing weak PKI will just have to do,
but arguably if you're signing up for a hotmail or gmail account without
a pre-existing relationship then you get what you pay for, and anyways,
eventually you'll notice if you've enrolled through an MITM (because the
MITM won't always be able to be in the middle!).

> So, I think the web will continue to need a PKI.:-)

Yes, but if we solve the mutual authentication case then for the cases
where we don't need mutual authentication we can probably live with a
weak PKI.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 10:11:35 -0600

On Thu, Feb 26, 2009 at 06:23:59PM -0800, Eric Rescorla wrote:
> I don't want to get into an extensive argument about this on SAAG,
> but I don't think this direction is particularly promising, for
> reasons I've indicated before: namely that you're handwaving
> the difficult part of the problem, UI, which we have no real 
> idea how to solve. Sure, if we solved that, there are any
> number of things we could do, but absent that, the other things
> are fairly useless.

I'm not entirely handwaving the UI part.  There are two major UI
problems: a) the desire for full-screen apps, and, more generally, apps
that have full access to human interface I/O, b) the desire of web
application developers to have full control over credentials prompts.

(a) is practically insurmountable -- SAS helps, but I doubt users will
be happy to use SAS every time they are prompted for credentials.  My
knee-jerk reaction would be to reject full-screen apps.

In my scheme (b) is solved by letting apps prompt for identities,
but not any passwords -- and training users not to enter passwords into
non-secure dialogs (see SAS comment) -- and by having authentication
mechanisms where the relying party does not get to impersonate the
client just because the client authenticated itself (this, in turn,
creates another problem in that lots of web services need delegation).

In particular I think the solution to (b) needs to go hand-in-hand with
any solution to the mutual authentication problem.

> I think you're rather overselling here: this only works well for
> account-based systems. There are plenty of cases where I need to
> connect to someone where I only know their name but I don't yet have
> an account (e.g., https://www.amazon.com). The mechanism that you
> provide doesn't work at all in this case. Rather, you need some
> third-party verifiable mechanism. I suppose one could argue that certs
> aren't a good such mechanism, but they're the one that TLS supports
> and I suspect any replacement would smell a lot like certs.

I just addressed enrolment (I took "but I don't _yet_ have an account"
to refer to enrolment) in a reply to Sam.

For cases that are not enrolment and where you never need user
authentication, but do need server authentication, I can only think of
PKI, and today's weak PKI will just have to do.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 02 Mar 2009 09:21:35 -0800

At Mon, 2 Mar 2009 10:11:35 -0600,
> any solution to the mutual authentication problem.

I would characterize this as handwaving. 

As long as the user's credential provided to their client is a human
readable password (and I think that's pretty clearly an invariant in a
large number of cases), then you have to worry about the user being
conned into typing their password into a dialog box controlled by the
attacker. Seeing as the available evidence suggests that there is
almost no UI chrome that can stop them from doing so, even when the
attacker only controls the ordinary browser interface.

Sure, you can imagine training users not to do that, but since
there's no evidence that you can in fact do so, that seems fairly
speculative.

-Ekr

P.S. I don't see how SAS is at all relevant here. SAS depends on the existence
of a trusted channel to carry the SAS, and that's precisely what we don't
have.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Mar 2009 12:08:45 -0500

> where we don't need mutual authentication we can probably live with a

No, that is not true.  These days, people routinely establish new, real 
business relationships online.  Companies like Amazon and PayPal depend on 
this model, and so do smaller merchants who probably number in the 
millions.  In many cases, consumers engage in a single transaction with 
such a merchant and there is _never_ any enrollment.

Mutual authentication plus channel binding is a great model for some 
things, but expecting to use off-line enrollment for everything forever is 
a non-starter.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 11:11:22 -0600

> attacker only controls the ordinary browser interface.

It will be a long time before users can be trained not to type passwords
into attacker-controlled dialogs -- that is definitely true.  And we'll
also have passwords for a long time yet.  These are not reasons to throw
our hands up and give up.

Deploy mutual authentication schemes first, then train users; training
users first won't do since there's no way for the UI to distinguish
password dialogs for web applications, since there's no mechanism other
than sending the password in an HTML form.

DIGEST-MD5 exists, and I'd advocate its use, but currently that always
results in a browser-controlled dialog that app designers hate (or, if
you use XmlHttpRequest then the application can prompt for the password
in a form and then use DIGEST-MD5 without a browser dialog, but this is
still an attacker-controlled form).  The change that would make
DIGEST-MD5 and friends more acceptable is to let the app provide a form
where the user fills in a username, and then let the browser prompt for
the password if it doesn't already have it.

That's not handwaving -- there are specific details here.  That it will
take time to get there is not handwaving for that will be true of any
solutions.

> there's no evidence that you can in fact do so, that seems fairly

Any solution will require training, if nothing else because otherwise
everyone will continue doing what we all do today: typing passwords into
HTML forms, so that servers get cleartext passwords, and MITMs get all
our money.

> of a trusted channel to carry the SAS, and that's precisely what we don't

That's precisely what using a mutual authentication mechanism adds: a
trusted channel.  Now, mechanism strength will vary, and use of weak
passwords with mechanisms that don't do well when used with weak
passwords is a problem, but I'd much rather have that problem to worry
about than the current one.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 11:16:47 -0600

On Fri, Feb 27, 2009 at 07:56:12PM +1300, Peter Gutmann wrote:
> Nicolas Williams <[email-masked]> writes:
> 
> >What we need is something like DIGEST-MD5, but tied into browser apps in a
> >different way than DIGEST-MD5 is today (more on this below).  Given this we
> >can forego PKI -- just do channel binding to TLS (with or without server
> >certs, whether CA-issued or self-signed).
> 
> We already have this, and have had for some years, it's called TLS-PSK.

TLS-PSK is not sufficient by itself, and for two reasons:

a) As the RFC says: "[h]owever, this document is not intended for web
   password authentication, but rather for other uses of TLS."

   Thus there is nothing about how to derive PSKs from passwords.

   Now, we could have PSKs bootstrapped by passwords, but that requires
   an enrolment protocol, and the result is non-portable credentials
   (where portable credentials are ones that require no physical devices
   in order to carry, except, perhaps, pen and paper).

b) For any solution to scale that adds mutual authentication we'll need
   either the user to use the same password for all identities or
   federation.

   TLS-PSK does nothing about passwords (see (a)) and nothing about
   federation.

> Unfortunately the browser vendors' approach is to keep on waiting for PKI to
> start working, forever if necessary.  "PKI meurt, elle ne se rend pas!" [0].

Not surpringly given the lack of usable mechanisms for mutual
authentication.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 11:26:41 -0600

> things, but expecting to use off-line enrollment for everything forever is 

I addressed enrolment in separate posts.  I believe enrolment can be
bootstrapped securely in a great many ways.  For example:

 - via SMS (requires a phone)
 - via telephone (requires a phone)

 - at any network access point if you can authenticate the access point:

   Imagine a coffee house that posts a certificate fingerprint on a
   flyer by the cashier, then you can use the coffee house's
   infrastructure (an access point and a small service running on it) to
   enrol in any service federated with that coffee house.

   This method has anonymity.  It is a form of off-line enrolment in
   that it requires finding such a coffee house and going there, but we
   all pretty much do that -- we're physical beings after all and most
   of us go places (and even those that can't go places can still, with
   the help of others, do enrolment).

Note again that channel binding is but a means to an end -- if TLS were
to provide suitable mutual authentication mechanisms then we'd not need
channel binding as that would be but an internal detail of TLS.  Sadly
TLS does not (no, TLS-PSK is not a suitable mutual authentication
mechanism, for reasons I set out in a reply to Peter just now).

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 02 Mar 2009 10:11:43 -0800

At Mon, 2 Mar 2009 11:11:22 -0600,
> > As long as the user's credential provided to their client is a human
n> > readable password (and I think that's pretty clearly an invariant in a
> the password if it doesn't already have it.

And the attacker will just pop up a dialog that says "our cool new UI
system is broken. Type your password into the form for now." This is
quite clear from [SDO+07].

> take time to get there is not handwaving for that will be true of any

Except that you're handwaving about the UI, which is the critical
part that we have no idea how to solve. We already have plenty of
cryptographic protocols here. What we don't have is the UI. So,
no, I don't think it's particularly useful to put a new coat of paint
on the crypto.

> HTML forms, so that servers get cleartext passwords, and MITMs get all

"We must do something. This is something. We must do this."

> about than the current one.

Huh? If you already ahve mutual authentication, you don't need an SAS.
An SAS is about establishing a cryptographically trusted channel
from a low bandwidth non-cryptographic channel.

-Ekr

[SDO+07] S. Schechter, R. Dhajima, A. Ozment, I. Fischer, 
"The Emperor's New Security Indicators: An evaluation of website authentication
and the effect of role playing on usability studies", IEEE Oakland 2007.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 02 Mar 2009 18:57:32 +0100

Nicolas Williams wrote:
>    Imagine a coffee house

  ... doing anything but selling coffee.

  Nope, that's not going to work.  I work with/for global WiFi
operators, so I have some experience here.

  Take Starbucks, for example.  They have WiFi.  What do the employees
know about it?  Pretty much nothing.  What do the people who installed
it know about it?  Pretty much nothing.  What does the network operator
*running* the network know about it?  Pretty much nothing.

  You can't begin to believe how bad many of these networks are.

> that posts a certificate fingerprint on a

  This presumes that social engineering attacks, and/or re-printing
flyers is hard.  It's not.

  Alan DeKok.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Mar 2009 13:09:06 -0500

> *running* the network know about it?  Pretty much nothing.

Actually, I believe in the specific case of Starbucks, the network operator 
running the network is T-Mobile, and so probably actually _does_ know 
something about it.  At least, at the macro level.

But the point stands -- coffee houses are not network operators and they 
are not federated identity service providers.  They are purveyors of 
concentrated liquid evil, and the occasional cup of tea.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Mar 2009 13:19:13 -0500

--On Monday, March 02, 2009 11:11:22 AM -0600 Nicolas Williams 
<[email-masked]> wrote:

> into attacker-controlled dialogs -- that is definitely true.

No, no.  It's a long way down the road to the chemist's.  It will be 
_forever_ before users can be trained not to type passwords into 
attacker-controlled dialogs.  We've been trying for decades, and some of 
the users in question have _been here_ for decades, and the message still 
hasn't gotten through.

> And we'll
> also have passwords for a long time yet.

Again, probably forever.

> results in a browser-controlled dialog that app designers hate

To a certain extent, this is too bad.  For password dialogs to be safe, 
they _must_ be browser-controlled (or system-controlled) dialogs over which 
the app designers have no control.  Note that virtually all of the security 
problems the web has today result from app designers demanding and browser 
vendors granting more control over the client computer than the system was 
designed to give them.

Just for the record, the amount of control the system was designed to give 
app designers over the client computer is.... zero!  Every security, 
performance, and usability problem the Web has today can be traced to 
violations of that design principle.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 12:16:57 -0600

> quite clear from [SDO+07].

Clearly.  Eventually this would no longer be true -- but we'll never get
there if we don't provide any mechanisms that can overcome this.
Certificates won't do because passwords remain, and will remain the
lowest common denominator for a long time.

Unless small, portable devices with UIs (mobile phones!) become so
ubiquitous (they're getting there) that they are as portable and ever
present as passwords.  But I suspect the same will apply to that
alternative: it will be years before we stop relying on passwords.

> "We must do something. This is something. We must do this."

There are so many "this" we can do, and any one will take time.  Choose
an approach.  Requiring that everyone have bluetooth- and NFC-equipped
cell phones (and probably data rate service) and desktops and laptops
(terminals of any kind) will certainly do, provided that such a
requirement is reasonable -- we're getting closer to where it is.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 02 Mar 2009 11:00:55 -0800

At Mon, 2 Mar 2009 12:16:57 -0600,
> requirement is reasonable -- we're getting closer to where it is.

We're now in the discussion I told myself I didn't want to have.
Suffice to say that for the reasons I've alredy indicated I don't
think the technical direction you propose is at all promising.

-Ekr

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 12:25:47 -0600

> the users in question have _been here_ for decades, and the message still 

Mostly because the technology to move beyond application-controlled
dialogs has not been deployed or the technologies that have been have
been unsatisfactory.  All I see in your reply is surrender.

> >also have passwords for a long time yet.

Indeed, cell phones and all.

> vendors granting more control over the client computer than the system was 

Indeed.  I'm proposing an incremental approach to this problem.  Perhaps
I'm talking to the wrong crowd -- at SAAG we're mostly security
engineers, whereas any conversation about overcoming the above problem
must involve web application developers.

> violations of that design principle.

Agreed.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Mar 2009 13:45:58 -0500

--On Monday, March 02, 2009 12:25:47 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

>> > It will be a long time before users can be trained not to type
>> > passwords into attacker-controlled dialogs -- that is definitely true.
>>
>> the users in question have _been here_ for decades, and the message
>> still  hasn't gotten through.
>
> been unsatisfactory.

No, it has nothing to do with the technology.
As long as users have a password, they will give it to anyone or anything 
that asks for it.  You'll get through to some of them that they shouldn't 
give their password away, but not to most of them.

Really.  It's sad to say, but people in general do _not_ read directions 
and do _not_ follow procedures, even when they are carefully trained in 
procedures specifically designed to protect against particular threats, and 
even when the threat is to the user's life or safety.

How do you expect users to remember not to give away their passwords when 
they can't be bothered to remember to wash their hands or look both ways 
before crossing a street?

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 12:22:32 -0600

> concentrated liquid evil, and the occasional cup of tea.

Coffee houses most definitely sell Internet access (or just give it
away).  And the point wasn't specific to coffe houses.  Any access point
could provide an enrolment bootstrapping service via federation if the
market wanted that sort of service...

... but the market won't demand that because people will generally be
happy to use existing relationships, such as phone service, for
enrolment.  And those that don't will settle for using the existing
weak-PKI and will test for MITMs by trying to use their accounts from
many different places in the network.

I used coffee houses as an example of how anonymity could still be had
while solving the enrolment process without a PKI.  I didn't mean to
propose that as the primary form of enrolment.  Quite the contrary; in
practice using SMS should do quite well.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 12:43:39 -0600

> think the technical direction you propose is at all promising.

Fair enough.  I've made one proposal (mutual auth mechanisms, various
enrolment options) and mentioned an alternative (mobile devices
everywhere, all the time).  Your turn, when you feel like it.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 12:50:50 -0600

> before crossing a street?

I must say that the frequency with which I see others *not* wash their
hands at public restrooms is distressing.  To the degree that such
attitudes have negative externalities there's little that can be done
short of changing liability, and perhaps therein lies the trouble: it's
hard to establish, much less prove how online fraud happened, just as it
is hard to prove that someone's not washing their hands at the restroom
made you ill.  On the other hand, we do provide restrooms with sinks and
running water, and even soap.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 02 Mar 2009 20:28:26 +0100

Jeffrey Hutzelman wrote:
> 
> Actually, I believe in the specific case of Starbucks, the network
> operator running the network is T-Mobile,

  AT&T for at least a year:

http://wifinetnews.com/archives/2008/02/t-mobile_loses_starbucks_att_becomes_wi-fi_hotspot_giant.html

  Though the migration is taking time.

> and so probably actually
> _does_ know something about it.  At least, at the macro level.

  No offense to T-Mobile (or anyone else), but managing 1000's of
hotspots is hard.  When you add large companies who want to use that
network, it becomes nearly impossible.

  We have had a poor response rate from companies wanting to roll out a
global WiFi network.  "Authentication?  What's that?  Why can't we just
have every  WiFi network operator white-list our devices/users/traffic?"

  Really.  So all this talk about PKI && certs is "pie in the sky".  We
can't even convince major players to use *passwords*.

> concentrated liquid evil, and the occasional cup of tea.

  And their network providers are getting squeezed.  No matter what
T-Mobile does, their revenue from these locations is pretty low, and the
user and corporate demands are high.

  Alan DeKok.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 14:56:56 -0600

Perhaps the simplest fix, technologically speaking, would be to get a
real PKI -- no technical changes needed, just political ones.  But that
strikes me as politically infeasible.

A real PKI would imply:

 - trust anchor regulations
 - CA and DNS registrar regulations that work

Seems unlikely.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 02 Mar 2009 14:13:08 -0800

At Mon, 2 Mar 2009 11:16:47 -0600,
>    Thus there is nothing about how to derive PSKs from passwords.

That's because there are already well-known mechanisms for
deriving keys from passwords, as long as you're willing to
live with low entropy. See PKCS#5.

>    in order to carry, except, perhaps, pen and paper).

Huh?

At a high level, if what you want is an authentication mechanism
derived form a password, there are only two sets of technical
mechanisms:

- Symmetric-key based systems like TLS-PSK, CRAM-MD5, Digest, etc.
- ZKPP/PAKE systems such as SRP, EKE, etc.

All the protocols in the former class have dictionary attacks on
the password. The protocols in the latter class do not.
TLS-PSK does not explicitly provide for passwords because
we did not want to encourage the use of mechanisms which we
knew were subject to offline dictionary attacks. This is a policy
question, not a technical one. The technical problem is easily
solved by specifying a mechanism to derive a shared key from a
a password (e.g., PBKDF2). The credentials are quite portable.

-Ekr

---

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Mar 2009 17:02:13 -0500

>alternative: it will be years before we stop relying on passwords.

Not only does one need to carry a mobile phone everywhere to login, 
one also has to have an essentially free SMS service to avoid paying 
a phone service provider for authentication messages. The same 
requirement would apply to the sites that need to use SMS to send and 
receive these messages.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Mar 2009 19:22:31 -0500

Nico,

I'm unclear on the exact constraints you're trying to satisfy with 
the channle binding model, but here are some observations anyway.

Mutual authentication is certainly desirable for most communication 
contexts. But, in contexts where neither party has a relationship 
with the other a priori, I don't think there is any magic bullet.

The primary, large scale, global PKI to which PHB alluded is the only 
major example we have where a user can get a reasonable level of 
assurance for one-way authentication. That model enables a 
(conceptually simple) transition to two-way, cert-based 
authentication, where each web site can act as a CA for its users. 
However, the poor tools we have to manage a plethora of certs from 
these narrowly-scoped CAs makes it hard for users to buy into that 
model.

In other parts of the world (especially in Asia)) there are large 
PKIs that serve substantial user communities. Often governments take 
the lead in issuing certs to individuals in these PKIs, and in 
creating CAs or bridge CAs to certify government and private sector 
organizations.

But, none of this is free. Absent government subsidies, mandated use, 
or hidden taxes, one ought not surprised by business models that 
require users and/or web site owners to pay for certs.  After all, in 
most contexts, at best you get what you pay for :-).

The lack of a single credential that authenticates a user to 
everywhere is a good thing from a privacy perspective. Federated 
identity management schemes create lots of opportunities to link 
islands of authenticated users (and organizations), but they have 
sever drawbacks re security. I tend to think of such schemes as 
having all the charming features of Wikipedia :-).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Mar 2009 19:23:30 -0500

At 12:08 PM -0500 3/2/09, Jeffrey Hutzelman wrote:
>No, that is not true.  These days, people routinely establish new, 
>real business relationships online.  Companies like Amazon and 
>PayPal depend on this model, and so do smaller merchants who 
>probably number in the millions.  In many cases, consumers engage in 
>a single transaction with such a merchant and there is _never_ any 
>enrollment.
>
>things, but expecting to use off-line enrollment for everything 
>forever is a non-starter.
>
>-- Jeff

Jeff,

i think it is important to note the role of credit card companies in 
making these business relationships viable.  I am willing to do 
business with an unknown, online, merchant based in large part on my 
ability to decline payment if the merchant misbehaves.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Mar 2009 19:44:00 -0500

>  - CA and DNS registrar regulations that work

As I noted in the message I sent (which crossed in the ether) this is 
not uncommon in Asia.  For example, CAs have to be licensed by the 
government in India (and, I think, South Korea).

But in the EU and U.S.,  we have a laisse fare approach to CA 
regulation. That is a political issue.

Steve

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 18:45:36 -0600

> the channle binding model, but here are some observations anyway.

Again, channel binding is incidental.  I'll lay out the constraints
below.

> with the other a priori, I don't think there is any magic bullet.

This true, but there is a subtlety here: enrolment is rare, much rarer
than login events.  Enrolment still presents the same problem as typical
web app logins today.  But the fact that enrolment events are rare
helps.

I helps in several ways:

1) phishers would need to be luckier if all they could phish were
   enrolment attempts (just how much luckier than now depends on a
   variety of details, like how easy it is to poison every significant
   ISP's every DNS cache);

2) throw in federated authentication mechanisms and truly-initial
   enrolment events get rarer, which enhances effect #1 and,

3) allows one to leverage existing relationships for securing enrolment
   (at a cost in terms of anonymity, but then, this is optional).

> assurance for one-way authentication.

Agreed.  (But see (2) in conjunction with (3) above with regards to
"one-way authentication" (meaning that it's the server that gets
authenticated) in the context of enrolment.

Non-enrolment-related needs for one-way authentication are probably much
rarer than normal logins, and probably don't present as much of a
phishing target (but I admit I'm not sure of this last).

>                                       That model enables a 

Agreed.

> creating CAs or bridge CAs to certify government and private sector 

Even here, Stateside, the DoD has a huge PKI.

> most contexts, at best you get what you pay for :-).

Exactly.  I'm not, I should add, trying to cut out what Peter called
"nuissance fees."  If authentication federations took off it's very
likely that they'd have their own nuissance fees.

> everywhere is a good thing from a privacy perspective. Federated 

Indeed.  But users also want convenience and are willing to trade off
between the two.  Thus one might have 100 accounts with no federation,
or 10 with, using, say, one just for one's preferred dating site, etc...
-- most accounts in my home are related to shopping, where privacy is
somewhat less important, particularly considering the current online
payment system).

> having all the charming features of Wikipedia :-).

The ones that exist today, yes!  But that's partly because they are all
constrained to usign HTML forms for logins and redirects and all sorts
of funny business.

The constraints as I see them:

a) Must have mutual authentication.

b) Must use passwords (but need not necessarily be a DISGEST-MD5-like
   mechanism -- for example, Radia once proposed using SACRED to
   retrieve private keys and certs).

c) Corollary of (a): must not send passwords to the server (whether over
   TLS or not).

d) Must be acceptable to web application developers (they are the
   reason, after all, that DIGEST-MD5 is not used, they); specifically:

    - the user experience must be acceptable to web application
      developers.

e) Password-based mechanisms (as opposed to, e.g., Radia's proposal
   mentioned above) must be federatable, if only because of the need to
   reduce truly-initial enrolment events, but likely also because of
   (d).

   This in order to minimize the number of times a user must type in a
   password in a browser-controlled dialog, under the theory that web
   app developers hate those).

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 18:48:23 -0600

> regulation. That is a political issue.

Indeed.  As I said, I suspect it's a difficult political issue, but
then, perhaps it's not.  I'm not sure how to gauge the likelihood of
success of CA, registrart and browser trust anchor regulation, both as a
political proposal, and if implemented (once implemented we'll know
though :)

---

From: <[email-masked]>
Date: Tue, 3 Mar 2009 13:57:53 +0100

Phillip,

Would allowing a single certificate to be signed with multiple algorithms solve some of the problem?

Doing it in backwards-compatible way (=current browsers just use the SHA1 signature, and ignore the others) probably would involve violating some pristine ASN.1 style guidelines, though :-) (The "obvious" place to put the "other signatures" is a certificate extension, added after the "real" extensions.)

But would this significantly help solving the transition problem? (Perhaps something like this has been proposed before -- I haven't really thought about the potential pitfalls here.)

Best regards,
Pasi

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Hallam-Baker, Phillip
Sent: 26 February, 2009 17:33
To: Theodore Tso
Cc: der Mouse; [email-masked]
Subject: [saag] Deployment Deadlock

Ted,

Thanks for the comments.

I agree that this is really hard, but I do not think that tragedy of the commons is a good analogy. This is not a resource depletion issue. This is more like a prisoner's dilema issue in which following their own best short term interests causes everyone to end up with a worst-case result. Unlike the Axelrod prisoner's dilema, the problem does not go away when the game is played repeatedly. On the contrary the deadlock becomes tighter.

The reason that this is our problem is that the standards establish the set of options available to the parties and the values of the outcomes.

The good part is that if we can understand this issue and work out a systematic theory of how to address it we have a key that can unlock the deployment of other protocols - IPv6, ubiquitous IPSec, ubiquitous email encryption and so on.

We have encountered deployment deadlock in various forms in many different protocols. We have a lot of experience of deployment deadlock but no systematic theory. I think that we can develop an adequate theory for the purposes of protocol design by borrowing some ideas from the economists, in particular rational choice theory.

In rational choice theory we model the behavior of each party by *assuming* that they will follow their exclusive best interests.

I emphasize the word assume here as it is merely a modelling assumption and not a factual claim or a normative ethic. I do not want to get into a distraction about whether the Rat Choice modelling assumption is a normative truth. We are merely using it here as a modelling assumption, we do not need to enter into a politcal digression. While it is very clear that some people act from altruistic motives on some occasions, and we could model this, it is necessary to assume an improbable degree of altruism to affect the outcome.

What I did was to identify the parties:

1) Web browser providers
2) Certificate Authorities
3) Merchants

I am using merchants as a subset of certificate holders to simplify matters. While it may be argued that other certificate users will behave differently, the merchants are a large enough subset that their actions are sufficient to determine the behavior of the CAs.

Note that these parties are listed in a particular order. The IETF has the greatest ability to communicate with the Web browser providers, somewhat less contact with CAs and has negligible contact with the merchants. As a pragmatic matter it is much easier to change IETF specs than to mount an Al Gore publicity campaign telling folk to move to SHA-n. And in any case we have a very limited amount of jawboning bandwidth and we have to use that as a last resort. I would much rather have Vint Cerf jawboning carriers into support for IPv6.

>From a business perspective, the actions are determined in the reverse order. The CAs are driven by the demands of their customers. If any CA attempts to behave altruistically by refusing to supply a product demanded by the merchants they will lose business. In practice the actions of the Web browser providers are driven by the facts on the ground in the same way.

The facts on the ground in question are

1) The amount of business that merchants receive from browsers that do not support SHA-n
2) The number of merchants who deploy SHA-n certificates

We have some influence on the first factor but almost no influence on the second. At this point it is reasonably clear that the browser providers are either supporting SHA2 today or will do so in the very very near future. If not they risk public shame every time RSA and Crypto come round.

My problem is that based on my experience of the merchants, I cannot see any merchant voluntarily chosing a SHA-n certificate that provides only (100-x)% coverage while there is a SHA-1 certificate on offer that gives 100% for values of x greater than 2. No business is going to voluntarily sacrifice even 1% of sales for a security issue that only affects the credit card issuers.

And there is no way for the browser providers to withdraw support for SHA1 if 90% or more of merchants are using SHA1 certs. Not without proof-positive that an actual break has occured which by definition means that we are too late. And even then it will take several years for the SHA1 capable browsers to be withdrawn from service and those will still be vulnerable in the interim.

That is a deployment deadlock.

________________________________
From: Theodore Tso [mailto:[email-masked]]
Sent: Thu 2/26/2009 9:38 AM
To: Hallam-Baker, Phillip
Cc: David Harrington; der Mouse; [email-masked]
Subject: Re: [saag] SHA-1 to SHA-n transition

On Wed, Feb 25, 2009 at 05:35:04PM -0800, Hallam-Baker, Phillip wrote:
>
> If people really think that Amazon.com is going to say 'I know that
> only 95% of browsers support SHA1, but I am going to get an SHA2
> cert and lose that 5% of sales so that our transactions are as
> secure as possible' because someone finds a practical attack on
> SHA1, then let them say that. So far nobody has challenged the
> analysis directly, they have merely described themselves as
> unconvinced that there is a problem.
>

OK, so let's get real here.  The reality is that transitioning between
crypto algorithms is *hard*, and that the tragedy of the commons is
hitting us hard.  We can try to create technical solutions (such as
the Svengali-style suicide note which causes browsers to break
intranets), but their have shortcomings because this is fundamentally
a social problem.

There are couple of things we need to do in order to successfully
carry off a migration:

(1) We need to get browsers to add support for the new crypto algorithm
(2) We need to get users to upgrade to the new browsers with support
        for the new crypto algorithm
(3) Once (1) and (2) are done, we need to get secure commerce sites to
        upgrade to use certificates that utilize the new crypto algorithm.
        (In practice this will be the crypto checksum; but the same thing
        applies if we ever need to get nervous about replacing the PK
        algorithm.)

This normally takes time --- years, but it is possible to speed things
up.  For example, an interested body, perhaps funded by far-sighted
merchants and other concerned citizens, could track which browsers
have added the new algorithms, and jawbone (and perhaps in the later
part of the effort, publically shame) entities distributing browsers
to implement the new algorithm.

For (2), sites who were interested in being "good citizens" could test
to see if the browser supports the new crypto algorithm, and display a
"nag screen" if the browser apparently doesn't support the new crypto
algorithm.  Said nag message could be gentle at first, but could get
increasingly strident; a lot of this would be up to the web site(s)
involved, of course.

So it's possible to encourage the ecosystem to move in a particular
way, but it all requires effort and coordination, and the tragedy of
the commons is that until the emergency comes up, it's unlikely that
such an effort will get funding and support.

But again, this is all nothing new, and I suspect one of the reasons
why we're thrashing a little in this discussion is because it really
is much more of a social problem than a technical problem, which means
it's a bit outside of the IETF's core competency.

                                        - Ted

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Mar 2009 05:35:52 -0800

That is another option. But the cost is that every cert now has to carry 512 bytes of extra baggage per algorithm. And this scheme is not so responsive as any change has a lead time of the lifetime of the longest certs - 2 or 3 years. That scheme works a lot better if you have ECC crypto available.

There are many ways that this can be addressed. But all of the ones I have thought of so far are somewhat yukky. That is why I wanted to focus on the fact that we have a problem before we jumped to solutions.

So far I do not see anyone giving a substantive argument that the deployment deadlock effect will not be a problem. I do see statements to the effect that this is a problem that some people would like not to have to think about or rule out of scope. And we go through these arguments every single time someone suggests even thinking about real world deployment constraints in a specification no matter how they are put.

We have the same problem in the DKIM spec. Take a look at how deployed verifiers will react when a zone contains a key for an algorithm that the verifier is unable to process. It is impossible for a verifier to react correctly in that situation without additional information. Publishing one unsupported key effectively negates the effect of the policy. So nobody can deploy new keys without a new policy language. But nobody in the group wants to think about that issue because it is the product of an interaction between policy and signature and the group wanted to keep them in two separate little boxes and hope they did not affect each other.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tue 3/3/2009 7:57 AM
To: Hallam-Baker, Phillip
Cc: [email-masked]
Subject: RE: Deployment Deadlock
 
Phillip,

 
 
Best regards,
Pasi

	Ted,
	 
	Thanks for the comments.

	 

	 

	1) Web browser providers

	 

	 

	

	

	
	
	                                        - Ted

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Mar 2009 06:25:17 -0800

A PKI does not grow of its own accord. The SSL PKI only exists because there was a clear business driver that drove its deployment.

That is not to say that it is impossible to deploy an alternative design. Only that it is necessary to model and understand the real world deployment constraints and design for deployment.

And the biggest mistake most designers make is to over-estimate the extent to which security is actually desired. As far as actual end users are concerned the SHA-n transition issue is irrelevant, it is even irrelevant as far as the banks and so on are concerned. Everyone else in the system expects 'the boffins' to come up with a fix that won't require them to do too much. In particular, they don't want a solution that might require them to actually think.

The only way that an imminent crisis can lead to large scale concerted action is if (1) the underlying technical issue is simple enough for anyone to grasp and (2) those required to act have other motives for action. The reason that the Y2K scam was so successful was because it enabled a clique of mediocre corporate VPs to engage in empire building. After a short while the scam became self-perpetuating because the first act of a Y2K vampire was to send out letters to every supplier demanding proof of Y2K certification - and so the infection was spread.

You do not need to be an economist or apply fancy algebra to understand the effects of economic processes. If we are not prepared to try to understand the economists, why should the economists attempt to understand us?

-----Original Message-----
From: [email-masked] on behalf of Nicolas Williams
Sent: Mon 3/2/2009 3:56 PM
To: Jeffrey Hutzelman
Cc: der Mouse; [email-masked]
Subject: [saag] Or grow a real PKI (Re:  SHA-1 to SHA-n transition)

A real PKI would imply:

Seems unlikely.
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 04 Mar 2009 04:40:15 +1300

>   password authentication, but rather for other uses of TLS."

That was added as a sop to the "<whine>we already have PKI in all its infinite
perfection and splendor, why provide an alternative?</whine>" crowd.

>Thus there is nothing about how to derive PSKs from passwords.

Yeah, my fault, I've had an RFC draft prepared but not quite posted yet for
ages.

>either the user to use the same password for all identities or federation.

Huh?  Where did this requirement come from?  You need neither of those two.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 04 Mar 2009 04:46:42 +1300

>"We must do something. This is something. We must do this."

So you've got the choice between the Polician's Fallacy (the above) and
psychosis ("PKI has been failing for 30 years [0], let's try more of it in the
hope that it suddenly works this time").

I think we need psychiatrists for this more than we need security geeks.

(I don't know the answer either, but admitting you have a problem with your
current approach is always the first step to recovery).

Peter.

[0] Or 20 years if you measure your epoch from X.509 rather than Kohnfelder.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Mar 2009 10:00:07 -0600

> hope that it suddenly works this time").

Well, no, there's also the choice of making PKIs work -- that requires
more political work than technical, and may be as infeasible as a good
unregulated PKI has been.

Also, I'm not sure that well-regulated PKI will necessarily be a good
thing -- I can already imagine the complaints about how red tape slows
everything down, doesn't scale, blah, blah, blah.  But if the consensus
here was that that is what we need, and if politicians told us it's
feasible then it'd be worth trying.

> current approach is always the first step to recovery).

How long has the consensus been that web security is broke?  Admitting
you have a problem is the first step, but it is not sufficient.

Nico
--

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 04 Mar 2009 05:26:47 +1300

>you have a problem is the first step, but it is not sufficient.

By "current approach" I meant PKI as a means of addressing web security
problems.  The response to 20 (or 30, see before) years of PKI failure as
recently as a year ago has been EV certs, i.e. more of what we already know
doesn't work.  It looks like we're nowhere near admitting that we have a
problem yet if the response to the failure of PKI is PKI-me-harder.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 04 Mar 2009 05:34:15 +1300

>before crossing a street?

 site_password = HMAC( user_password || 128-bit salt, site_URL );

(or assorted variations thereof, there are a pile of password-fortification 
techniques around, and all manner of free and low-cost commercial products 
that implement them).  That way even if they hand their password over a 
phisher, it won't do the phisher much good.

At this point I expect the peanut gallery to jump in with the usual million or
so corner cases where this won't work, but the important point is that the
above would help most of the people most of the time, and in particular it'd
help the demographic who are most likely to fall into phisher traps, i.e. non-
technical people for whom the standard "the salt isn't portable across my
eight computers and three laptops and therefore your scheme isn't worth
trying" objection doesn't apply.

Peter.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Mar 2009 10:30:02 -0600

On Tue, Mar 03, 2009 at 06:25:17AM -0800, Hallam-Baker, Phillip wrote:
> The only way that an imminent crisis can lead to large scale concerted
> action is if [...]

... it happens.

> You do not need to be an economist or apply fancy algebra to
> understand the effects of economic processes. If we are not prepared
> to try to understand the economists, why should the economists attempt
> to understand us?

As I said, a real PKI is a political problem.  Is it really necessary in
this day and age to point out that economists take a back seat to
politicians?  It seems there's nothing that government can't do now, so
why not a PKI?  :^/

Stephen pointed to regulated PKIs in Asia, proving the point, though if
those PKIs are lousy, then it was a lousy point, but at least we might
be able to gather data on what the impact of a real PKI might be.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Mar 2009 10:40:31 -0600

>  site_password = HMAC( user_password || 128-bit salt, site_URL );

I've had sundry such browser plugins installed and I still don't use
them.  I tried, but I stopped when I noticed that using such passwords
in my cell phone was a royal PITA.

Thanks, you've managed to depress me :)

You've also disproved my point and proved EKR's.  The clarity is welcomed.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Mar 2009 09:04:39 -0800

Governments can regulate PKIs to be employed for government purposes.

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]]
Sent: Tue 3/3/2009 11:30 AM
To: Hallam-Baker, Phillip
Cc: [email-masked]
Subject: Re: [saag] Or grow a real PKI (Re:  SHA-1 to SHA-n transition)

... it happens.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Mar 2009 12:26:46 -0500

> Governments can regulate PKIs to be employed for government purposes.

I think you misunderstand the nature of a government's power.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 03 Mar 2009 09:57:24 -0800

At Wed, 04 Mar 2009 05:34:15 +1300,
> trying" objection doesn't apply.

Peter,

While I think this general class of solutions has some utility, but
the difficulty is that it requires some UI mechanism to stop the
phisher from convincing the user to type their password
into a dialog which goes directly to the phisher rather
than being hashed. I'm unaware of any general solution to that
problem, and this is not really a corner case but rather the
main case.

-Ekr

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Mar 2009 09:54:06 -0800

First step would be to try to understand the business issues that cause people to avoid deployment.

If we are going to get anywhere we have to recognize that these issues are not only in IETF scope, they are the most important issues for the IETF to consider if the IETF is going to have the real-world relevance that we all hope for.

We have to face the fact that deployment of new protocols has often been a failure and that changes to deployed protocols have failed with even greater frequency.

-----Original Message-----
From: [email-masked] on behalf of Peter Gutmann
Sent: Tue 3/3/2009 10:46 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [saag] SHA-1 to SHA-n transition

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 04 Mar 2009 07:19:30 +1300

Eric Rescorla <[email-masked]> writes:

>While I think this general class of solutions has some utility, but the
>difficulty is that it requires some UI mechanism to stop the phisher from
>convincing the user to type their password into a dialog which goes directly
>to the phisher rather than being hashed.

Uhh, read my original message again, it doesn't matter if the phisher gets the
password or not (obviously it'd be better if they didn't, but if they do then
it's not serious because they still need to get the 128-bit salt, and the only
way to get that is via malware on the victim's PC at which point any measure
at all is going to fail).  That's the beauty of it, as Jeff pointed out you're
never going to stop users from giving out their password to anything that asks
for it so the solution is to create a mechanism where this isn't an issue any
more.  OTPs are one example of this, but that one's a lot more work than a
simple password diversifier.

(There's a whole pile of other problems that this addresses as well, for
example the user only has to remember a single password, recovery can be
handled via standard backup mechanisms like the Windows password reset disk
(PRD) via DPAPI, and so on.  The full run-down gets quite complicated because
there's a pile of carry-on effects that address a lot of other problems with
password-based authentication).

Peter.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Mar 2009 13:28:51 -0500

--On Wednesday, March 04, 2009 07:19:30 AM +1300 Peter Gutmann 
<[email-masked]> wrote:

>> convincing the user to type their password into a dialog which goes
>> directly to the phisher rather than being hashed.
>
> Uhh, read my original message again, it doesn't matter if the phisher
> gets the password or not (obviously it'd be better if they didn't, but if
> they do then it's not serious because they still need to get the 128-bit
> salt, and the only way to get that is via malware on the victim's PC at
> which point any measure at all is going to fail).  That's the beauty of
> it, as Jeff pointed out you're never going to stop users from giving out
> their password to anything that asks for it so the solution is to create
> a mechanism where this isn't an issue any more.  OTPs are one example of
> this, but that one's a lot more work than a simple password diversifier.
>
> handled via standard backup mechanisms like the Windows password reset
> disk (PRD) via DPAPI, and so on.  The full run-down gets quite
> complicated because there's a pile of carry-on effects that address a lot
> of other problems with password-based authentication).

Unfortunately, it also creates a fairly signficant set of problems, in that 
the credentials are no longer portable -- besides needing to know your 
password, you need a salt that's hidden somewhere in your browser's 
long-term state.  That makes it hard to use multple browsers on multiple 
machines, and guarantees that if you lose your disk, you also lose the 
ability to log in to anything and everything.

-- Jeff

---

From: Stephen Kent <[email-masked]>
Date: Tue, 3 Mar 2009 13:53:05 -0500

At 9:04 AM -0800 3/3/09, Hallam-Baker, Phillip wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>	boundary="----_=_NextPart_001_01C99C22.4DD0C516"
>

A government can regulate CAs that operate in its country, for ANY 
purpose, if so desires.

But, I already noted that this outcome is likely in the U.S. or the EU.

Steve

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Mar 2009 11:12:46 -0800

We already went through that phase. Early in the life of PKI there was a whole slew of state regulation. At one point there was an entire wall in the practices group covered in certification and accreditation plaques.

None of it had any real effect.

These are hard problems that governments have difficulty with as well. It was a government inquiry that started my thinking on this topic.

Regulation is a government tool, it is rarely a government objective in its own right.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Tue 3/3/2009 1:53 PM
To: Hallam-Baker, Phillip
Cc: Nicolas Williams; [email-masked]
Subject: Re: [saag] Or grow a real PKI (Re:  SHA-1 to SHA-n transition)

Steve

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 04 Mar 2009 08:22:45 +1300

Jeffrey Hutzelman <[email-masked]> writes:

>password, you need a salt that's hidden somewhere in your browser's long-term
>state.

Yes, I know, and I also knew that every time anyone mentions something like
this someone immediately raises the point you've just made, which is why I
addressed it in my original message.

Peter.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Mar 2009 14:33:57 -0500

--On Wednesday, March 04, 2009 08:22:45 AM +1300 Peter Gutmann 
<[email-masked]> wrote:

>> Unfortunately, it also creates a fairly signficant set of problems, in
>> that the credentials are no longer portable -- besides needing to know
>> your password, you need a salt that's hidden somewhere in your browser's
>> long-term state.
>
> Yes, I know, and I also knew that every time anyone mentions something
> like this someone immediately raises the point you've just made, which is
> why I addressed it in my original message.

You seem to imply that only weird technical people have or use more than 
one computer.  This is certainly not true; many people have a computer at 
home and one at work, and many of those are quite non-technical.  Computers 
have become commonplace desktop items both in the home and in the office.

Also, telling people "if the disk on your home PC dies, your life is over" 
is a good way to get them _not_ to use a scheme like this.  Saying the 
solution is to always have backups is just going to get you laughed at.

-- Jeff

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 03 Mar 2009 20:38:18 -0800

At Tue, 03 Mar 2009 14:33:57 -0500,
> solution is to always have backups is just going to get you laughed at.

Indeed. You're of course free to feel that this issue is out of
scope, but I assure you that when you explain this to nontechnical
people, they take it seriously.

-Ekr