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

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Sat, 07 December 2013 15:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D5D231AE388 for <>; Sat, 7 Dec 2013 07:48:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HSN8BRIl1xPr for <>; Sat, 7 Dec 2013 07:48:08 -0800 (PST)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id A70441AE050 for <>; Sat, 7 Dec 2013 07:48:08 -0800 (PST)
Received: from localhost (localhost.localdomain []) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id D34FD2C4033; Sat, 7 Dec 2013 07:48:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([]) by localhost (maihub.ICSI.Berkeley.EDU []) (amavisd-new, port 10024) with LMTP id iLrBVGY0lX-y; Sat, 7 Dec 2013 07:48:03 -0800 (PST)
Received: from [] ( []) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id A5C7A2C4004; Sat, 7 Dec 2013 07:48:03 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_3E15BCB3-7E1E-4F5D-B1A3-5BE9D2B4C9AE"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
In-Reply-To: <>
Date: Sat, 7 Dec 2013 07:48:02 -0800
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.1510)
Cc:, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>, Bruce Perens <>
Subject: Re: [perpass] perens-perpass-appropriate-response-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 07 Dec 2013 15:48:11 -0000

On Dec 7, 2013, at 5:14 AM, Stephen Farrell <> 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,                full of sound and fury,
510-666-2903                                 .signifying nothing