Client Certificate UI for Chrome?

[James A. Donald]

"James A. Donald" <jamesd at echeque.com> writes:
 > > [In order to implement strong password based
 > > encryption and authentication] on the server side,
 > > we need a request object in the script language that
 > > tells the script that this request comes from an
 > > entity that established a secure connection using
 > > shared secrets associated with such and such a
 > > database record entered in response to such and such
 > > a web page

Peter Gutmann wrote:
 > Ah, that is a good point, you now need the credential
 > information present at the TLS level rather than the
 > tunneled-protocol level (and a variation of this,
 > although I think one that way overcomplicates things
 > because it starts diverting into protocol redesign, is
 > the channel binding problem (see RFC 5056 and,
 > specific to TLS,
 > draft-altman-tls-channel-bindings-05.txt)).  On the
 > other hand is this really such an insurmountable
 > obstable?

Consider what would be involved in building the UI into
the Google browser, and also building the necessary
scripting support into Web2Py on Google App Engine.  It
is not a small job.

 > I don't really see why you'd need complex scripting
 > interfaces though, just "return the shared-secret
 > value associated with this ID" in response to a
 > request from the TLS layer.

This request is issued when the connection is being
established, before the URL is specified.  So it is
impossible to service that request from the script that
generates the web page.   So where are we servicing that
request?  Presumably, need to service it somewhere
within the Web Application Framework, for example within
Mod PHP or Web2Py.

Further, some applications, for example banks and share
registries, typically have several different ID tables
at a single domain, and several different kinds of
shared human memorable secret information associated
with each ID.

And, having established that association, then when the
URL is specified, and the script associated that URL is
finally invoked by the Web Application Framework, then
that script needs to be invoked with the relevant ID, or
better, the script then needs to be provided with a
database cursor pointing at the relevant ID.

Further, if we do the SRP dance every single page, it is
a huge performance hit, with many additional round
trips. One loses about 20 percent of one's market share
for each additional round trip.

So we only want to do the SRP dance on session
establishment, only want to do it once per human
session, once per logon, not once per TLS session.

Which means that the TLS layer has to cache the the
transient strong shared secret constructed from the weak
durable human memorable secret for the duration of the
Web Application Framework's logon and logoff and provide
the cached database cursor to the web page script at
every page request during a single logon session, which
requires a higher level of integration between TLS and
the Web Application Framework than either one was
originally designed for.

Which means a significant amount of work integrating
this stuff with any given web application framework.

Further, suppose, as is typical with banks, a given
domain name hosts multiple ID tables each with different
kinds of shared secret information.  In that case, we
can obtain multiple different kinds of SRP logons, each
relevant to certain web pages but not others, each with
different privilege levels, and the framework has to
enforce that, has to provide to each web page
information about the logon type, and ensure that
inappropriate web pages are never invoked at all, but
are 403ed when the user attempts to access a url through
a logon of inappropriate type.

We cannot rely on the server side web page script to 403
itself in response to inappropriate logon type, since
when a new kind of logon was introduced, no one would
ever go back and make sure that all the old web pages
correctly checked the logon type.  If the web page
script contains a line of code that says "If such and
such, then do a 403",

then sooner or later someone will delete that code and
say "Hey, it still works just fine.".

This is starting to sound depressingly like a great deal
of work rewriting lots of complex, bugridden stuff in
web application frameworks that are already designed to
handle logons in a quite different way.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com