Re: [perpass] perens-perpass-appropriate-response-01

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 <nweaver@ICSI.Berkeley.EDU> wrote:
be 
> 
> On Dec 7, 2013, at 5:14 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> 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,
> nweaver@icsi.berkeley.edu                full of sound and fury,
> 510-666-2903                                 .signifying nothing
> PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc
> 
> 
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass