> Consumer-to-provider authentication (as opposed to > consumer-to-provider's-TLS-accelerator) is needed, > has both benefits and the abuse potential you are > worried about, and is happening regardless of whether > TLS is extended.
[David] I got it from Page 12 of the I-D:
For example, a client
may request access to a resource provided by the
server,
provide sufficient authentication and authorization
information
grounds to convince the server to grant the
requested access,
and receive an affirmative response from the
server. A record
of TLS Handshake protocol messages representing
this example
may provide a sufficient record of the intent of
both the
client and the server.
Wow. you got a lot more out of that paragraph than I did!
Obviously the words must have much more loaded meanings that
I realized (sufficient, convince, grant, affirm, record,
intent). I thought it meant: (i) do a conventional client
auth (and accept the TLS evidence extensions), and (ii) a
signature comes back saying "you just authenticated to
website URI x; we agree that use of this URI is subject to
the terms and conditions attached in the signer's cert").
But. Ive clearly learned this is actually all about: 1 intent 2 SSL offloading.
Your 1 point does clearly indicate out that the designers are FURTHERMORE making very specific (legalistic) claims about facilitating the signaling (and acceptance of?) intent. Perhaps this is too strong: its an issue that they are focused on, and intend their design to address its nature. IETF would be adopting that as a work item, if TLS Evidence becomes a work item.
on point 2: I like the general analytical model your developing tho ...and the problem definition that IETF can certainly address, if it wants. Your essentially asserting that the signature may come from the website, rather than the loadbalancer that is doing SSL offloading, in an increasing number of IDCs. And, the semantics of the signature would involve reliance on a (signing) cert for the app-server - whose X>509 extensions express which Ts&Cs are now binding for that URI, located way back in the server farm. This is all good, and was stock VeriSign design work early on, that never went far, pending adoption of digital signatures for e-commerce.
Again, the authors need to cater for grade C students (like me), not only grade A students. It has to be a "bit more" spelled out (e.g. loadbalancer, SSL offloading, consumer-to-provider-vs-loadbalancer). Its ever more interesting, tho., assuming the protocol's hashing of handshakes can be designed not to auto-fall foul of regulations affecting 450 million of the Internet's users.
_______________________________________________ TLS mailing list TLS@xxxxxxxxxxxxxx https://www1.ietf.org/mailman/listinfo/tls