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

[Nicholas Weaver <[e-mail]>]

On Dec 7, 2013, at 5:14 AM, Stephen Farrell <[e-mail]> 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,
[e-mail]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc