Subject: authenticated unencrypted

From: Matthew Kerwin <[email-masked]>
Date: Wed, 18 Dec 2013 09:50:58 +1000

Hi, this question has been rattling around in my head for a couple of days
and I can't shake it, so I'll present it to the WG: is there any value in
offering an authenticated+unencrypted connection mode in HTTP?

It's completely aside from the everything-TLS debate (because if
everything's TLS it's already authenticated, and if authentication via
certs is expensive unenc-auth will be untenable for those people); but if
one of the opportunistic encryption proposals is encryption without
authentication, to prevent passive sniffing, would there be value in
authentication without encryption?

For example, I don't particularly need any of the CC-* content on my
website to be encrypted (it's free for everyone to read), however I'd
prefer it if a MITM couldn't modify my code snippets or misrepresent my
blog rants.  It's my understanding that decrypting the entire entity is
pretty expensive, but calculating a checksum/hash and decrypting that is
cheaper.  Is my understanding wrong?

Also, point in case, PGP-signed email messages to public(ly readable)
fora, such as this one.  Peter Saint-Andre just sent one.

Sorry if it's been covered before, I haven't found anything in the
archives.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Dec 2013 16:32:19 -0800

> offering an authenticated+unencrypted connection mode in HTTP?

I do believe that there is value.

Though I think that we'd have to answer the basic question about
priority, since I don't believe we have the focus necessary to do
that, plus all the stuff we have on our plate currently.  Nothing
stopping you (or anyone else) from going off and doing some work on
it, but I've found that working groups really don't do very well at
juggling multiple work items.

BTW, my current understanding is that the priority queue is stacked
like so:  http/1.1 docs (basically done), http/2.0, some sort of extra
TLS-ification, some sort of proxying stuff.  Maybe you can slot this
into the last item; I'm not sure.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 17 Dec 2013 20:25:11 -0500

On Tue, Dec 17, 2013 at 6:50 PM, Matthew Kerwin <[email-masked]>wrote:

> website to be encrypted (it's free for everyone to read),
>

The act of consuming public information requires different protection than
the information itself because it concerns both the information and the
consumer. The obvious argument is the public library - there are no secrets
in the stacks, but the transaction records of a patron's account are held
to a different standard.

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 18 Dec 2013 11:43:26 +1000

> in the stacks, but the transaction records of a patron's account are held

If people are that worried about Super Spies seeing that they requested X
documents from my website, including Y HTTP headers, from Z address, then
they don't _have_ to visit my site.  Or, if I'm offering TLS and they are
happy with the processing overhead of en/decrypting the entire
communication* then that's an option.**

* coming back to my understanding that decrypting the entire thing is
pretty expensive, but calculating a checksum/hash and decrypting that is
cheaper.  If that's an incorrect assumption then please correct me.

** currently my entire site is HTTP-only, because my hosts don't even offer
a TLS option unless I pay a somewhat exorbitant amount to upgrade to a "web
commerce" plan, because only "web commerce" people want HTTPS apparently.

Per Martin's suggestion I think I'll take this conversation off the list
now, so as not to add noise over the more important issues.  If I have any
further questions, or come up with a good proposal, I'll come back with it.

Cheers

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 18 Dec 2013 02:52:05 +0100

* Matthew Kerwin wrote:
>they don't _have_ to visit my site.

People are not given the choice as to which sites their browser visits.
A simple example is predictive loading of your site based on its place
in ranked search results in the background. This line of reasoning very
quickly ends with "then get off the Internet", I am afraid.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Yoav Nir <[email-masked]>
Date: Wed, 18 Dec 2013 17:50:26 +0200

On 18/12/13 3:43 AM, Matthew Kerwin wrote:
> On 18 December 2013 11:25, Patrick McManus <[email-masked] 
> <mailto:[email-masked]>>wrote:
>
>
>     On Tue, Dec 17, 2013 at 6:50 PM, Matthew Kerwin
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>         For example, I don't particularly need any of the CC-* content
>         on my website to be encrypted (it's free for everyone to read),
>
>
>     The act of consuming public information requires different
>     protection than the information itself because it concerns both
>     the information and the consumer. The obvious argument is the
>     public library - there are no secrets in the stacks, but the
>     transaction records of a patron's account are held to a different
>     standard.
>
>
> If people are that worried about Super Spies seeing that they 
> requested X documents from my website, including Y HTTP headers, from 
> Z address, then they don't _have_ to visit my site.  Or, if I'm 
> offering TLS and they are happy with the processing overhead of 
> en/decrypting the entire communication* then that's an option.**

I don't have to visit your site, and I don't have to read Wikipedia, 
although that's the first result you get on most search engine searches. 
The point is that looking for specific things on sites may indicate 
something about you. We don't even have to just to the obvious privacy 
and politics examples. If all of a sudden, 5 different computers (as 
evidenced by HTTP headers) from my company start getting RFCs and drafts 
from the CORE working group, this could indicate that we're thinking of 
introducing a product in the IoT area. That would be interesting 
information for competitors, and it's information that should be 
confidential until this fictional product is ready.
> pretty expensive, but calculating a checksum/hash and decrypting that 
> is cheaper.  If that's an incorrect assumption then please correct me.

These days, the difference is not so great. It used to be that AES-CBC 
took twice as long as HMAC-SHA1. With the newer Intel CPUs, AES-CBC 
takes half as long as HMAC-SHA1. With RC4, there's little difference, 
and when comparing AES-GCM and NULL-with-GHASH, the difference not 
great.  So you do save something by not encrypting, but the performance 
is more like  encryption+protection > protection >> unprotected

>
> ** currently my entire site is HTTP-only, because my hosts don't even 
> offer a TLS option unless I pay a somewhat exorbitant amount to 
> upgrade to a "web commerce" plan, because only "web commerce" people 
> want HTTPS apparently.

That's a problem that is common to hosts in many places, but they're 
getting better.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Dec 2013 09:26:11 -0800

On 17 December 2013 17:43, Matthew Kerwin <[email-masked]> wrote:
> * coming back to my understanding that decrypting the entire thing is pretty
> expensive, but calculating a checksum/hash and decrypting that is cheaper.
> If that's an incorrect assumption then please correct me.

That's not a perfect assumption.  It's certainly true for TLS modes
where encryption and authentication form different steps, such as with
AES CBC + HMAC modes.  On the other hand, AES-GCM doesn't require
running a hash over the entire message, the MAC is effectively just a
byproduct of encryption (not really, but you might consider it as
such), so in that case I believe it to be faster to encrypt and
authenticate than to just authenticate.  I'm told that with AES-NI
instructions on recent CPUs GCM is about as fast as memcpy, and it
runs the same order number of operations as HMAC.  I'm not aware of a
pure hash function that works as quickly, and one that is even close
to available in the same way.