Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use tocreate integrity-assured metadata

> > 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@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls