Subject: [TLS] Another [Well-deserved] attack on TLS CCA

From: Anders Rundgren <[email-masked]>
Date: Tue, 18 Jun 2013 20:30:58 +0200

https://sites.google.com/site/oauthgoog/gnubby

Luckily for all users Google didn't select TLS CCA (Client Certificate
Authentication) for their coming U2F system; only a moron would base a
future consumer authentication system on a scheme that is only suited
for VPN tunnels and invisible authentications like as ChannelID.

What's missing you may wonder?  Well, how about

- Compatibility with web sessions including timeout and logout
- A working credential filtering system

Anders

---

From: Adam Langley <[email-masked]>
Date: Tue, 18 Jun 2013 14:39:04 -0400

> for VPN tunnels and invisible authentications like as ChannelID.

The U2F system originally did use client-side certificates. We changed
it to ChannelID, but not for the reasons you suggested, but rather as
explained in https://tools.ietf.org/html/draft-balfanz-tls-channelid-00#section-2

Cheers

AGL

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 18 Jun 2013 20:46:19 +0200

> explained in https://tools.ietf.org/html/draft-balfanz-tls-channelid-00#section-2

Not exactly; U2F builds on JSON objects and ChannelID is an optional
element in the login protocol.

Cheers
Anders

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Jun 2013 15:35:59 -0500

BrowserID uses its certificates at the application-layer, not in TLS.
I think that's the correct approach.

(That still leaves the use of TLS server certs for authenticating
servers; that's not going to go away.  Ideally mechanisms like
BrowserID can do channel binding so that the dependence on the TLS
server PKI can be mitigated / eventually removed.)

Nico
--

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 18 Jun 2013 22:44:53 +0200

> I think that's the correct approach.

Yes, so does all usable consumer-auth solutions including Google's U2F.

Anders

---

From: Geoffrey Keating <[email-masked]>
Date: 18 Jun 2013 14:39:58 -0700

> - Compatibility with web sessions including timeout and logout

Logout is a client-side function, and occurs (typically) when the user
logs out of their local session and/or quits their web browser.
Timeout occurs when the TLS connection is closed due to inactivity
(typically 60 seconds) and the session resumption token is expired,
which is up to the server; or, looking at it another way, when the
user's screen lock triggers due to inactivity.

> - A working credential filtering system

I think this is mostly due to lack of demand.  I wouldn't say it isn't
"working", just that as commonly implemented, it isn't very good.

I wouldn't list these as the biggest problems when trying to use
client certificate auth, they can be solved with minor fixes.  The
first major obstacle you'll hit is trying to get users enrolled.  Then
there are:

- Enrolling multiple devices
- Key rollover
- Lost devices
- Shared devices
- Public access terminals

and all the other things that people don't think about immediately
when they say "let's replace passwords!"

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 19 Jun 2013 00:17:37 +0200

> user's screen lock triggers due to inactivity.

Yes, but this is not how most web apps work today for good or for worse.

> "working", just that as commonly implemented, it isn't very good.

There is a perceived little demand because many organizations who are big
users of consumer-PKI have no voice in the IETF.  I believe these guys
would be slaughtered by the IETF bunch since they don't have exactly the
same "lingo" and probably don't know very much about inner life of TLS.

> client certificate auth, they can be solved with minor fixes. 

Minor fixes?  I doubt that given the fact that you probably must
do something in both ends.

> The first major obstacle you'll hit is trying to get users enrolled.

Indeed.  Which is why Google made it a part of the U2F plot while the
rest of the industry has nothing to offer except insanely useless crap
like Mozilla's <keygen> and Microsoft's CertEnroll.

> Then there are:

This can be addressed in due time when you have an enrollment solution.
Before that nothing can happen.

> when they say "let's replace passwords!"

Google may very well be the only party on the planet who have a chance
making this in reach for the masses.  Microsoft, Banks, Governments
and last but not least, the Card industry, have showed that they cannot.

Anders

---

From: Geoffrey Keating <[email-masked]>
Date: 18 Jun 2013 16:40:17 -0700

> Yes, but this is not how most web apps work today for good or for worse.

That's because most web apps require the user to type a password, but
you can't require the user to type a password on every click, so they
only ask the user to enter the password once, and then they have to
maintain authentication status information using cookies (or similar).
Client certificates avoid this entirely; you don't need cookies, you
can authenticate on every request.  This can dramatically simplify the
design of a web app.

At least, that's one way to do it.  If you're doing two-factor, you
can combine this with a password: you still have a session, with
login, logout and timeout, but you also require that every connection be tied
to the client certificate.

> same "lingo" and probably don't know very much about inner life of TLS.

Asking at the IETF is definitely the wrong place to start this.  At
present there's no consensus that any protocol changes are required
let alone what these changes might be.  These organizations need to
ask the OS and/or browser vendors for better support, explaining in
detail what they need and why, and those vendors can work with them
and then if necessary do any protocol design under the IETF umbrella.

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 19 Jun 2013 06:56:08 +0200

> to the client certificate.

A fly in the soup is that few if any of the web-server application frameworks
out there like Java Servlets have any information or control over the TLS session.
You'd probably have to program at "MOD-SSL" level or something like that :-)

> and then if necessary do any protocol design under the IETF umbrella.

Today VISA and MasterCard authorize credit-card transactions on the
Internet with a "User ID" (card number + other details) together
with a "Password" (CCV) printed in clear (!) on the back of the card.

It is pretty obvious that there is a total disconnect between the
different parties so we are essentially at the mercy of tech giants
like Google who "can think for everybody else".  Google have (with U2F)
indirectly declared TLS CCA as not useful for consumer-auth and that's
about it.

Anders