"James A. Donald" <jam...@echeque.com> writes:
[Incredibly complicated description of web scripting plumbing deleted]
Peter Gutmann wrote:
We seem to be talking about competely different things here. For a typical
application, say online banking, I connect to my bank at www.bank.com or
whatever, the browser requests my credential information, and the TLS-SRP or
TLS-PSK channel is established. That's all. There's no web application
framework and PHP and scripting and other stuff at all, in fact I can't even
see how you'd inject this into the process.
I cannot see how you could create a bank web page without a web
application framework (counting mod-php as a very primitive web
application framework) and scripting and a database, which scripting and
database has to know who it is is that logged in - which is indeed a
great deal of complicated plumbing to ensure that the script knows at
script execution time, *after* the connection has been made, which user,
which database primary key, is connected. The information about which
user, which database primary key is logged in, has to be passed up
through one layer after another and from one process to another. The
toe bone is connected to foot bone, the foot bone is connected to the
ankle bone, the ankle bone is connected ... The plumbing really is that
complicated.
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.
You only do it once when the TLS session is set up, it's exactly as for
standard TLS except that instead of PKI-based non-authentication you use
cryptographic mutual authentication. How do you get an SRP exchange for every
web page?
Because keep-alive usually fails for plumbing reasons, standard TLS
usually does the PKI-based non-authentication dance every page,
resulting in additional round trips, resulting in painfully bad
performance for SSL web sites such as
<https://www.cia.gov/library/publications/the-world-factbook/>
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
