Nick, I agree that there is a cost threshold for signature/MAC. It is something I uncovered in my PKI research: for PKI-enabled micropayments it is, arguably, not worth signing the public key involved, if the number of disputed payments is at normal levels... because normal levels, for most micropayment applications, are low. It's more cost-effective to simply refund the tiny minority of disputed payments.
That said, I think what we learned from IETF88 was that the strategy most likely to succeed against pervasive, unaccountable state interception is to make it more costly for the net reception to take place. (Essentially, forcing accountability by forcing expenditure). We have also seen evidence of large-scale MITM attacks, made easier by the weakness of integrity mechanisms in session establishment and key exchange. If that's the new context in which we find ourselves architecting systems, then it may change the calculation that says "Integrity checks aren't worth paying for". NB - I am not saying that this necessarily justifies breaking all web traffic down to frames and applying MACs/DSigs at the element level; all I'm saying is that the events of 2013 change the cost structure of integrity mechanisms, and we should adjust our architectural principles accordingly. Yrs., Robin Robin Wilton Technical Outreach Director - Identity and Privacy On 7 Dec 2013, at 15:48, Nicholas Weaver <[email protected]> wrote: be > > On Dec 7, 2013, at 5:14 AM, Stephen Farrell <[email protected]> wrote: >> Today, there's no such solution for how to load JS with >> integrity but without TLS after an https:// "landing page" >> load. I've thought about ways to do it with RFC 6920, but >> so far without finding a way that could scale or would be >> likely to get adopted - apparently the JS code gets >> updated too often for a 6920 based approach to help very >> much. > > We do actually have a system for data integrity without confidentiality. Its > called DNSSEC. And the lack of confidentiality is a deliberate design > decision due to its focus around offline signature generation and a structure > composed of various proven untrustworthy intermediaries. > > So if you really actually WANTED data integrity on elements (and it has to be > all HTML, CSS, JS, flash, etc.. since all of those are directly executable > content, so you might as well do ALL elements. After all, there have been > image rendering vulnerabilities too..), how about storing them and just > fetching them through DNSSEC... > > Indeed, thats a very silly and downright stupid idea. Nobody will do it. > > > > Why? Because our model for HTTP is that content is often generated > dynamically, so each dynamic element would need to be signed dynamically, so > instead our focus on HTTP is on channel security: create a secure channel and > then keep using it. > > There is effectively zero call for "MAC w/o ENCRYPT", which is whats > necessary to answer "authentication problem rather than a confidentiality > one." in terms of channel security. We don't do it. Why? Because its > stupid. You'd still need to go through all the public key certificate > efforts, key exchange, server side computation, and all the other crap needed > for a TLS handshake or similar to generate a MAC key. Adding in encryption > is a practical no-op by this point. > > > And without doing a key exchange for a MAC and instead doing signatures for > integrity, signature verification happens at the END of a communication. > Signatures are expensive to generate and validate (and verification w/o a key > exchange requires a lot more of them anyway), so you'd hash all the data and > then sign/verify, so you coludn't take advantage of incremental rendering, > lest you render an iframe at the start that shouldn't be there. > > Yes, you could use some block-hash structure where at the start you get a > signature over a bunch of block hashes, but that instead requires that the > sender know in advance the WHOLE message. Its a silly thought, since the > server in many cases does NOT know what the full .html document will be when > it starts sending it over a TLS channel. > > > So the idea of "authentication problem rather than a confidentiality one" is > a red herring: We have a solution that solves the authentication problem for > HTTP. Its called TLS. We MUST use it everywhere, if only to protect US > citizens from the French and Chinese, and Russians, and Brazilians, and > Israelis... > > And a solution which solves authentication w/o confidentiality may be silly, > but if you want it anyway, the best solution that gives authentication w/o > confidentiality for HTTP is, indeed, a browser button that says: > > "F-confidentiality: broadcast my encryption key (but not the MAC key) in the > clear if the server consents". > > -- > Nicholas Weaver it is a tale, told by an idiot, > [email protected] full of sound and fury, > 510-666-2903 .signifying nothing > PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc > > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
