RE: [foaf-protocols] Discussion from W3C #idbrowser

I think the most fun part of webid , and its use of TLS, will come when the TLS messages are exchanged over HTTP posts as binary documents, vs TCP. Its long overdue that https goes connectionless, not just for SSLVPNs but for the web too.
 
This is the game changer, as all the arguments from the transport crowd go out the door. And, its not dependent on the browser vendors; being a matter for page designers communciating over websockets. Its not that hard for javascript to do a basic TCP protocl imeplemntnation too (folks did it in smartcards, years ago, over the serial line between card and reader!)
 
 
One of the chartered elements of webid work is to understand DTLS - which is the TLS message exchange (with suitable ciphersuites) over connectionless channels. HTTP Posts to restful endpoints are connectionless channels. It looks really interesting to take the very exciting work on javascript SSL client endpoints with javascript-implemented RSA and SHA-1 in the browser, and leverage THAT - to just get past the (never ending) transport arguments. Its obviously NO harder to insert an interceptor in a web server/farm for handling those messages than it is for the Shibboleth or the openid group to have similar interceptors be handling SAML XML-DSIG-signed IDP messages or the openid messages that define those protocols' sessions.
 
 
> From: henry.story@bblfish.net
> Date: Fri, 27 May 2011 01:27:12 +0200
> To: bhill@paypal-inc.com; foaf-protocols@lists.foaf-project.org; public-xg-webid@w3.org
> Subject: Re: [foaf-protocols] Discussion from W3C #idbrowser
> 
> Hi Brad,
> 
> Thanks for your input. I'll forward your e-mail to the WebID mailing list, as that is more formally about WebID.
> The foaf-protocols gave birth to WebID, but has many other interesting ideas up its sleeve :-)
> 
> On 26 May 2011, at 20:05, Hill, Brad wrote:
> 
> > I was recently introduced to the WebID proposal by Henry's video presentation for the W3C Conference on ID in the Browser. After a brief chat in that venue, I thought I should take my concerns here for further discussion.
> > 
> > While I conceptually like the idea, I fear it will face insurmountable obstacles to deployment in its current description. 
> > 
> > Primarily, I believe that interrupting the TLS handshake as part of the protocol is a complete non-starter for a variety of reasons.
> > 
> > The quick summary of my concerns is that:
> > 
> > 1. The existing install base of TLS terminators cannot support the protocol
> > 2. TLS terminators must communicate WebID context to apps
> > 3. Performance and scalability is terrible relative to server-auth-only TLS
> > 4. A major denial-of-service attack surface is introduced by the protocol
> > 
> > 
> > If you are ambitious to read more:
> > 
> > 1. Deployment obstacles with the existing infrastructure of TLS accelerator and terminators and appliances.
> > 
> > It is a reality of most large sites deploying HTTPS that TLS is not terminated at the web/application server where the application is hosted but instead in an accelerator card or network appliance. Changing the internals of the TLS handshake will be an extremely uphill battle given the enormous install base and reluctance of operations staff to modify these systems.
> > 
> > It is also not clear that many such appliances would be able to handle the proposed and envisioned protocol modifications, at least not without significant degradation of performance and scalability.
> > 
> > 2. Lack of standardized mechanism to pass WebID context from termination of TLS to where it will be applied.
> > 
> > Assuming that a termination device does participate in the protocol, it is safe to assume that it does not understand application, identity or authorization semantics. It must either call into application logic for such information (while still in the middle of the TLS handshake) if it is to return error conditions at the TLS layer, or must have a way to pass arbitrary (and potentially large) context information down to the application after completion of the handshake. This needs to be invented and is another change required of both limited devices as well as downstream consumers.
> > 
> > 3. Performance
> > 
> > Yes, this does matter, and yes this is a big deal. Witness the proliferation of accelerator appliances to reduce resource costs, and the interest in False Start, to reduce latency. While TLS is not a huge cost (and I have for years encouraged many major sites to go to full HTTPS) the additional cost of client certificate auth relative the baseline cost of TLS is significant, and this is even more true when the WebID modifications are added.
> > 
> > Consider the differences.
> > 
> > No client cert:
> > 
> > 3 round trips (or 2 with false start)
> > 1 asymmetric crypto operation
> > 
> > WebID client cert:
> > 
> > Initial connection:
> > 3 round trips (client can't use false start because it will have to renegotiate anyway, see below)
> > 1 asymmetric crypto operation (as part of key exchange)
> > 
> > Renegotiation is then required. The client certificate cannot be sent as part of the first handshake for privacy reasons - it is in the clear. The client and server must establish an encrypted channel and then renegotiate to send the client certificate if the user's expectation that the identity they are using at the site will be private to eavesdroppers is to be preserved, so now a new handshake begins including:
> > 
> > 3 round trips (or 2 with false start)
> > 3 asymmetric crypto operations (key exchange, plus client cert verify, plus CertificateVerify message)
> > Possible dereference of AIA information (multiple certs + CRL or OCSP) on client cert (1 or 2 round trips)
> > Additional 2 asymmetric crypto ops to verify cert and signature on CRL or OCSP
> > 
> > Now the server has to make an entire new TLS connection to pull the WebID metadata. (we will discount the cost of fetching and processing this for now), so 3 round trips (or 2 with false start), 2 additional asymmetric crypto operations, plus the cost of fetching, as a client, AIA information provided by the server. ( 1 or 2 round trips though this may likely be cached, plus 2 more asymmetric crypto ops) 
> > 
> > So normal case, we have 2-3 round trips and 1 asymmetric crypto operation for a typical TLS handshake vs. 11-13 round trips, 10 asymmetric crypto operations and 2 -4 resource downloads for a WebID-style client cert authentication. This is a 60-80% reduction in capacity, and a 4-5x increase in latency - hard to ignore no matter how cheap TLS is.
> > 
> > 4. Attack surface
> > 
> > This so far just assumes the "good" case. Perhaps the most troubling aspect of the system currently is that it allows an attacker to force a server to dereference arbitrary content in the middle of a TLS handshake. I can send a client certificate with AIA information pointing to a large set of large certificates that are expensive to verify (huge key sizes and large certificate sizes). I can then provide huge CRLs. I can force the download of this information to be very slow, tying up server resources. I can place these resources themselves at HTTPS URLs, forcing additional work. I can make my WebID information itself huge, slow to download and expensive to verify.
> > 
> > Caching is no help here, as the attacker gets to choose the resources to be retrieved and can pick ones which will not be cached. It is also important to consider, in general, that terminator appliances are not generally designed with caching in mind, as it is not a typical use case for server-auth-only TLS today.
> > 
> > 
> > Solutions?
> > 
> > As a first solution, I would suggest moving the retrieval and validation of WebID data out of band from completion of the TLS handshake. Always complete the handshake, pass the certificate data to the application, and let it complete the rest of the WebID protocol. This is much simpler for terminator appliances and they already have established methods for doing this. 
> > 
> > I would also suggest that wherever TLS handshakes are being performed, that all verification for client certs be turned off completely (AIA, CRL, OCSP, etc.) as this is all unnecessary in the WebID model and further reduces the attack surface.
> > 
> > This reduces the changes necessary and risk to terminator appliances, and places the responsibility for caching and mitigating attack surface in the application, where it can be most appropriately managed.
> > 
> > I think more work could be done on attack surface reduction, but this is already far too long for a first email.
> > 
> > -Brad Hill
> > _______________________________________________
> > foaf-protocols mailing list
> > foaf-protocols@lists.foaf-project.org
> > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> 
> Social Web Architect
> http://bblfish.net/
> 
>