Re: [TLS] Should TLS 1.3 use an augmented PAKE by default?

[Daniel Kahn Gillmor <[e-mail]>]

On 03/20/2014 04:51 AM, Yoav Nir wrote:

> The thing is, as long as the authentication happens in the application layer, none of the fancy crypto matters. If my bank implements a PAKE in the login screen using Javascript, a decent web designer can make a website that looks identical, only the passwords go in the clear to the phisher, and there is no fancy PAKE javascript. Good crypto in indistinguishable from bad crypto or no crypto at all.

This is the core of the issue for client authentication in a web
browser, i think.  Regardless of whether we're talking about PAKE or
client certs or some other mechanism, we have two choices:

Either:

A) We begin to establish a new norm for client-authentication UX that
relies on unspoofable and easily-recognizable browser chrome (with some
sort of browser-chrome logout mechanism as well), and start training
users to distrust <input type="password"/> (perhaps at first on a
site-by-site basis), taking some serious UX control away from web site
designers.

 or:

B) We continue to let web sites drive the full UX decisions, and leave
users vulnerable to phishing attacks.

option (A) is seriously hard, maybe impossible given the state of the
web.  option (B) is terrible.

TLS can help this effort by making clear recommendations for how
cryptographically strong authentication can be used, and tailoring some
of those specifications for browsers that might want to use them.

Already, we have discussions in httpbis about some additional HTTP
mechanism so that the browser can trigger cryptographic use for client
authentication in the TLS layer, and a proposed client-cert extension to
make use of them:

 https://tools.ietf.org/html/draft-thomson-tls-care
 https://tools.ietf.org/html/draft-thomson-httpbis-catch

This should provide a way for web sites to have full control over their
unauthenticated UI and have well-specified mechanism that browser chrome
can use when presenting client-authentication activity to the user.  But
Thomson's proposed scheme targets the use of client-side certs, not
PAKE.  If you really want PAKE to work as well in the HTTP context, it
seems likely to have to think through the same cases.

Perhaps the drafts above need to be modified to provide for SRP or some
other PAKE as well as client-certs so that the same communications-flow
can be used in a PAKE context at the TLS layer?  If so, why would that
be a better outcome than using PAKE directly at the HTTP layer (e.g.
https://tools.ietf.org/html/draft-ietf-httpauth-mutual) ?

	--dkg