Subject: Fwd: New Version Notification for draft-thomson-http-encryption-00.txt

From: Martin Thomson <[email-masked]>
Date: Mon, 11 May 2015 13:32:32 -0700

Of potential interest.

This is a new version of draft-nottingham-http-encryption-encoding.
Mark asked that I look after this.

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 11 May 2015 at 13:26
Subject: New Version Notification for draft-thomson-http-encryption-00.txt
To: Martin Thomson <[email-masked]>

A new version of I-D, draft-thomson-http-encryption-00.txt
has been successfully submitted by Martin Thomson and posted to the
IETF repository.

Name:           draft-thomson-http-encryption
Revision:       00
Title:          Encrypted Content-Encoding for HTTP
Document date:  2015-05-11
Group:          Individual Submission
Pages:          17
URL:
https://www.ietf.org/internet-drafts/draft-thomson-http-encryption-00.txt
Status:         https://datatracker.ietf.org/doc/draft-thomson-http-encryption/
Htmlized:       https://tools.ietf.org/html/draft-thomson-http-encryption-00

Abstract:
   This memo introduces a content-coding for HTTP that allows message
   payloads to be encrypted.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 12 May 2015 11:18:34 +1200

>    payloads to be encrypted.

Thank you. This is indeed a document covering an area of some interest
to several members of the Squid community including myself.

I am more than a little surprised to find not one single mention of
proxy or cache middleware types or interoperability with them anywhere
within this document. Despite clear implications that it is intended for
use to secure data within CDN and other plain-text HTTP environments.

Section 4.1 is missing statements to the effect that encoding with the
key= parameter containing explicit keying material the message is
cacheable subject to other cacheability criteria.
 This implies the Vary:Accept-Encoding header is mandatory.
 This also implies Security Considerations regarding proxy caches (or
CDN) storing and sharing the message payload to multiple recipients.

Section 4.2 is missing statements to the effect that messages encoded
with the dh= parameter are not cacheable.
 This implies the "Vary: *" header and field-value are mandatory.
 This also implies that for compatibility with legacy implementations
the Cache-Control:no-store and/or Expires header should be recommended
to enforce correct behaviour.
 This method also requires a Security Considerations reinforcing
understanding that if the out-of-band parts of the encryption are lost
the data encoded is also lost. (common sense to us, but not to some
others in my experience).

Has any correlation check been done to see if there are any equivelent
mechanisms within protocols using MIME or mime-like headers? This is a
mechanism that could find a useful place in many of the other popular
protocols beyond HTTP. The Encryption* headers also fit the criteria
outlined in BCP 90 section 2.2.2 for Content-* prefixed MIME headers.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 May 2015 17:07:31 -0700

> use to secure data within CDN and other plain-text HTTP environments.

Cleartext HTTP use cases are actually not intended for this, though
I'm not opposed to adding any that make sense.

> CDN) storing and sharing the message payload to multiple recipients.

Indeed, caching (and Vary) implications do need to be addressed.
Tracking: https://github.com/martinthomson/http-encryption/issues/1

I'm less concerned about the proxy cache story.  Though perhaps we
could acknowledge the fact that this shifts the access control basis
from the content to the key (which also gets to your later point about
key loss).

> others in my experience).

Tracked: https://github.com/martinthomson/http-encryption/issues/2

> outlined in BCP 90 section 2.2.2 for Content-* prefixed MIME headers.

I've looked, but I know how poor I am at this searching business, so
will defer to others.  One thing that we decided was that decided to
generically design something for application to other protocols would
be a great way to kill it.

Obviously S/MIME (now CMS) is in this general space.  But the reasons
for not choosing that are articulated in the document.

Adding Content-* seemed like a waste.  We might just as well have
chosen to add 'Access-Control-Allow-*' to everything.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 12 May 2015 07:06:20 +0200

> I'm not opposed to adding any that make sense.

Well, you see, I've met people who designed and deployed their in-house
payload encryption mechanism in a banking environment where using plain
text for headers is mandatory to provide request routing capabilities
without giving the ability to decrypt data between the two extremities.
In fact many people use HTTP as a service-aware transport protocol on
top of TCP.

I can predict that you'll get requests for encrypting or at least signing
*some* header fields because these people had to do that when facing the
same use cases :-)

I hope to find some time to review your work, that sounds interesting and
useful.

Thanks,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 12 May 2015 17:30:05 +1000

My .02 - 

I'm somewhat wary of putting the requirements of every possible use case on the shoulders of one mechanism, as I see that as a recipe for boiling the ocean and subsequent failure. Arguably, this is what's been happening in Web authentication for quite some time now.

On the other hand, it would be good if we make sure we don't needlessly block reuse. E.g., it would be good if this were aligned with something like <https://tools.ietf.org/html/draft-cavage-http-signatures> (although we should be wary of what a minefield header signing has proven to be elsewhere). It might make sense to consider taking them on together.

Willy, Amos - how do you think this spec *should* talk about intermediaries? As specified, the HTTP caching model is still usable, and of course proxies are still capable of working with them. What else do you see as missing?

I can see is that it might be prudent to add Cache-Control: no-transform to the message, but then again an intermediary that transforms bodies with C-E that it doesn't understand kind of deserves what it gets, IMO…

Cheers,

> On 12 May 2015, at 3:06 pm, Willy Tarreau <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 12 May 2015 19:34:18 +1200

On 12/05/2015 5:06 p.m., Willy Tarreau wrote:
>> On 11 May 2015 at 16:18, Amos Jeffries wrote:

My take on that is that they should be able to use MIME syntax (or
equivalent) within the encrypted payload to transmit additional object
related headers.

The very act of encrypting any headers explicitly puts them out of scope
of the transfer protocol (HTTP). So we dont need to care and should
leave it undefined in this spec.

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 12 May 2015 10:06:12 +0200

> leave it undefined in this spec.

For encrypting, I agree, and I don't remember the exact use case (cookies
I believe though I'm not 100% certain). However signing headers will
certainly be used, but it doesn't require any specification if the
mechanism is agreed between two parties.

Willy

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 12 May 2015 20:11:30 +1200

On 12/05/2015 7:30 p.m., Mark Nottingham wrote:
> My .02 -
> 
> I'm somewhat wary of putting the requirements of every possible use
case on the shoulders of one mechanism, as I see that as a recipe for
boiling the ocean and subsequent failure. Arguably, this is what's been
happening in Web authentication for quite some time now.
> 
> On the other hand, it would be good if we make sure we don't
needlessly block reuse. E.g., it would be good if this were aligned with
something like
<https://tools.ietf.org/html/draft-cavage-http-signatures> (although we
should be wary of what a minefield header signing has proven to be
elsewhere). It might make sense to consider taking them on together.
> 
> Willy, Amos - how do you think this spec *should* talk about
intermediaries?

In the ways I outlined in my earlier mail. Stating clearly which
encrypted messages are safe to cache (or not) and what response headers
should be added to make it easier for compliant caches to do the right
thing will make implementers reading the spec aware that they are
relevant actors.

Perhapse explicitly calling out the types of third-party, including
proxy caches, which are expected to be handling these messages in the
Intro or some early section. Though I leave that to the editors.

Given that the purpose of this is to enable safe storage / caching of
objects by untrusted third parties. At least raising the topic of
middlewares is important.

> As specified, the HTTP caching model is still usable,
and of course proxies are still capable of working with them. What else
do you see as missing?

Yes, its still usable and relevant. But its currently not spelled out
how. Which will lead to mistaken interpretations and interoperability
failure IMO if left as per -00.

> 
> I can see is that it might be prudent to add Cache-Control:
no-transform to the message, but then again an intermediary that
transforms bodies with C-E that it doesn't understand kind of deserves
what it gets, IMO…

Yes, well. I disagree (slightly) on that - in the general case. The spec
does state that encryption may be layered with multiple keying. I see it
reasonable then that a proxy could add/remove one or more of those
encryption layers as the message transits in or out of sites security zones.

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 12 May 2015 10:25:24 +0200

Hi Mark,

On Tue, May 12, 2015 at 05:30:05PM +1000, Mark Nottingham wrote:
> My .02 - 
> 
> I'm somewhat wary of putting the requirements of every possible use case on
> the shoulders of one mechanism, as I see that as a recipe for boiling the
> ocean and subsequent failure. Arguably, this is what's been happening in Web
> authentication for quite some time now.

Yes, over-designing is the first step to massive failure.

> On the other hand, it would be good if we make sure we don't needlessly block
> reuse. E.g., it would be good if this were aligned with something like
> Willy, Amos - how do you think this spec *should* talk about intermediaries?
> As specified, the HTTP caching model is still usable, and of course proxies
> are still capable of working with them. What else do you see as missing?

>From my point of view, HTTP gateways must continue to work normally, and I'm
no seeing significant risks by encrypting a payload since gateways generally
do not even "see" this payload. Maybe we should be careful about those which
can compress contents however. First, compression should be discouraged in
such a case as it will be useless (or the encryption has a serious flaw),
and second it could hurt the recipient's ability to extract the data. Note
that if a client supporting an encrypted response payload sets gzip in
Accept-Encoding, it probably means it's willing to decompress *after*
decryption, so the content-encoding in the response will reflect the
series of transformations and a compressing intermediary will not be
tempted to compress again. Some might be tempted to recompress better and
might skip unknown tokens in content-encoding. It would be prudent to remind
the reader that an intermediary must not touch certain header fields (eg:
content-encoding again), and/or be precise in the way the recipient must
understand the fields if they come as a list because an intermediary has
appended another level of transformation. But that's normally covered by
the HTTP spec.

> I can see is that it might be prudent to add Cache-Control: no-transform to
> the message, but then again an intermediary that transforms bodies with C-E
> that it doesn't understand kind of deserves what it gets, IMO???

Yes very likely since this covers the intended use case. I think that
intermediaries located between two agents encrypting a payload over clear
text are generally well under control (eg: load balancers) and that the
purposes for which they would have to modify a content-encoding are
limited and configurable.

When it comes to caches, I don't know if anything must be done, it could
even be useful to cache such contents if multiple clients use the same
key. Maybe pass a vary: referencing the encryption key then, but I could
be wrong, I'd rather let the experts talk.

Cheers,
Willy

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 May 2015 13:33:30 +0100

On 12/05/15 08:30, Mark Nottingham wrote:
> needlessly block reuse. E.g., it would be good if this were aligned
> with something like
> <https://tools.ietf.org/html/draft-cavage-http-signatures> (although
> we should be wary of what a minefield header signing has proven to be

Just a suggestion, and possibly a dumb one at that...

In other contexts, we've seen that people talk about use-cases
for signing and even deploy signing, but verification can lag
significantly behind, which can make the whole effort somewhat
pointless.

So it might be a useful thing here to only try attempt the
general signed header field thing if there are use-cases that
are compelling where someone really treats the request or
response differently in a well defined way when a signature
that includes a header field is bad or cannot be verified.

By the "general signed header field thing" I mean something
that's like a DKIM-Signature or Dave Crocker's DOSETA proposal
or the Cavage draft above.

Note that DKIM didn't have to pass the test I'm suggesting
here, which was correct in that case. And again, the above
is a possibly dumb idea so please take it with salt:-)

Cheers,
S.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 12 May 2015 12:56:16 +0000

--------

>significantly behind, which can make the whole effort somewhat

Agree, there are plenty of wrecks in the road-side, but the other
side of that problem is that people end up rolling their own because
there is no standard.

I personally think this is the privacy area we should have focused
on, rather than the blunt weapon of "SSL-everywhere", because
this does not conflict with laws and disable caching to the same
degree.

However, it is not obvious to me that it is a good idea to involve
the Content-Encoding at all, whereas I see several downsides.

For instance we cannot Vary: on just the aesgcm-128 part of the C-E
header, and since the Encryption: header is just noise without the
qualifying C-E element, varying on just Encryption: is not a good
idea.

Leaving C-E entirely out of the picture will make no difference in
any scenario I can come up with (Please enlighten me if such scenarios
exist).

I think it would make much more sense to concentrate all the relevant
information in a single new header (Content-Encryption ?) which would
make Vary "just work".

This would also make the obvious "Accept-Encryption" negotiation
header possible.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 12 May 2015 13:07:58 +0000

--------
In message <[email-masked]>, Willy Tarreau writes:

>Note that if a client supporting an encrypted response payload sets gzip in
>decryption, [...]

That be an information leak.  We shouldn't say anything which tells
anybody anything about what the encrypted data means.

I thinke the order has to be encryption before gzip, and if that
means that people pointlessly gzip AES output, then there is no
more (or less) harm than them gzip'ing JPEGS.

>be wrong, I'd rather let the experts talk.

I can see a lot of use cases for that scenairo.  (See also my previous
email about why C-E shouldn't be involved.)

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 12 May 2015 15:14:05 +0200

Hi Poul-Henning,

> information in a single new header (Content-Encryption ?) which would

Interesting. But it would make it harder for a recipient to identify
in what order to apply transformations then if both content-encoding
and content-encryption are set. Imagine two servers communicating
together over encrypting gateways, which would apply their own algo
to be safe on their local networks, and the gateways would apply a
stronger one on to of this over the WAN, after base64-ing the contents.

I know this is totally made up and highly stupid, but it's just to give
an idea. If the protocol is successful, and we encourage to work well
with intermediaries, then we could expect to see adoption at several
levels in some institutions where encryption keys are assigned to
different internal business units, leading to encapsulation. In this
case I think that content-encoding alone would remove any confusion.

Not that I'm encouraging to do dirty practices, but rather that we
manage to make the thing robust against such practices.

> This would also make the obvious "Accept-Encryption" negotiation

That could be a good point.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 12 May 2015 15:21:06 +0200

> anybody anything about what the encrypted data means.

Good point, which brings back the header fields encryption. Thus maybe
as was suggested, if any header is to be encrypted it should be moved
to the payload part (mime or so). That said, a correct encryption
algorithm would not be weakened by knowing that the first 3 bytes are
expected to be 0x1f8b08.

> more (or less) harm than them gzip'ing JPEGS.

It depends. What I remember about was SSL contents deciphered on the SSL
gateway and encrypted in the payload only. If these contents were gzipped,
they remain in gzip format but encrypted.

> email about why C-E shouldn't be involved.)

I do as well which is why I think we must be careful to predict them before
it's misused because the use cases were understimated :-)

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 12 May 2015 13:28:04 +0000

--------
In message <[email-masked]>, Willy Tarreau writes:

>and content-encryption are set.

Encryption first.

If you allow a client to retrieve get both a encrypt(plaintext) and
encrypt(gzip(plaintext)) at their choice, you have revealed information
about the payload which should be secret.

If you waste CPU cycles gzip'ing the ciphertext you only harm your
CO2 footprint.

If people want to save bandwidth with compression, they have to compress
before the encryption, and include the bit which says "compressed" in
the plaintext passed to the encryption algorithm.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 12 May 2015 13:48:17 +0000

--------
In message <[email-masked]>, Willy Tarreau writes:

>to the payload part (mime or so).

It's very simple:  You have an envelope everybody can see (the headers)
and you have the content (the body).

Anything you want to keep secret goes in the body.

>That said, a correct encryption algorithm would not be weakened
>by knowing that the first 3 bytes are expected to be 0x1f8b08.

Which is why really good crypt always has initial and trailing non-sense.

And you non-sense had better be good:

	http://en.wikipedia.org/wiki/The_world_wonders

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 12 May 2015 09:52:02 -0400

Hi Stephen,

> is a possibly dumb idea so please take it with salt:-)

FYI folks in the CalDAV/Calendaring community have had success adopting 
DKIM for use with HTTP for a server-to-server scheduling protocol 
(<https://tools.ietf.org/html/draft-desruisseaux-ischedule-05> - draft 
expired but still a work in progress). In our case we provided a much 
stricter verification requirement than typically used in email (i.e., we 
stated that requests must be rejected if the signature fails). The re-use 
of DKIM in HTTP provided a quick and easy route to implementation and

-- 
Cyrus Daboo

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 13 May 2015 04:35:11 +1200

On 13/05/2015 1:28 a.m., Poul-Henning Kamp wrote:
> Willy Tarreau writes:

No, they may be applied by different layers at different times. A dumb
legacy intermediary may arbitrarily gzip everything going through it.

I agree with Willy here for the reasons he stated and the below as well.

I checked over the Vary situation earlier and do not find a huge problem.

* The Diffi-Helmen / dh= keying (section 4.2 form) requires Vary:*
because the key material is out of band. But so would gzip encoding with
an out-of-band dictionary to seed it.

* The explicit key= material (section 4.1 form) response can use
Vary:Accept-Encoding. Since the IKM is part of the response variant
headers it does not matter which client you send the pair to - all
clients will be able to decode using that key or not be able to with any
key (IKM provided was the *senders* part).

As you can see it does work if you get the cases right. But needs to be
stated in the spec so we and others dont have to individually figure it
out - making various mistakes along the way.

> about the payload which should be secret.

I note that it was your proposal to add Content/Accept-Encryption
separately from *-Encoding which allows this flaw you are now pointing
out. The -00 draft lacks this flaw.

When the two are using Accept-Encoding the Vary header will only contain
Vary:Accept-Encoding. Which is agnostic to compression vs encryption and
does not permit the client to control the gzip+aesgcm-128 case. The
server gets to choose to emit only gzip(plaintext) vs
encrypted(plaintext) for any variant.

Vary:Accept-Encoding,Accept-Encryption is the format which allows client
the most control of selection between encrypt(gzip(plaintext)) vs
encrypt(plaintext) by requiring the server to deal with permutations of
the cases.
 * it is also more verbose in both number of variants in play for
caching, and in bandwidth bytes used by headers.

> If you waste CPU cycles gzip'ing the ciphertext you only harm your

Having two headers implicitly encourages using both. Having one header
and having to deal with these problems encourages getting it right
without forcing a particular viewpoint on everyone.

> the plaintext passed to the encryption algorithm.

True. That is something that probably also should be mentioned. Its a
good incentive and reason for implementers to make the right choice.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 May 2015 09:40:15 -0700

> key (IKM provided was the *senders* part).

If you use different keys for different users, then you have to add
Vary: Encryption.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 13 May 2015 04:49:15 +1200

> algorithm would not be weakened by knowing that the first 3 bytes are

Actually that would be octets 2-4. The first octet defines the padding size.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 13 May 2015 04:52:10 +1200

On 13/05/2015 4:40 a.m., Martin Thomson wrote:
> On 12 May 2015 at 09:35, Amos Jeffries wrote:

Encryption is defined as a response header.
Vary lists request headers.

You cannot be both cacheable and use per-client keys (or payload for
that matter).

Amos

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 12 May 2015 17:17:53 +0000

--------

>Encryption is defined as a response header.

Why would it be limited to responses ?

>Vary lists request headers.

Which is why we should think about "Accept-Encryption"

>You cannot be both cacheable and use per-client keys (or payload for

"per-client" can trivially mean "per-group-of-clients" -- particularly
so since this does not at all address or limit key-management.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 May 2015 10:23:12 -0700

> Anything you want to keep secret goes in the body.

Yes.

This is the design we propose. If headers need protection, they can go
inside the encrypted body using application/http content type. That
probably needs to be accompanied by rules regarding composition of
headers for presentation after decryption.

Julian suggested offline that the representation header fields [1] are
easy: the encrypted form takes precedence.  It might be that the other
header fields are just writing on the envelope that can be discarded.

[1] https://tools.ietf.org/html/rfc7231#section-3.1

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 May 2015 10:25:30 -0700

> Vary lists request headers.

Of course.  As long as Encryption is seen by the cache, that's not a
problem.  Well, as long as the key identifier changes.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 May 2015 10:35:58 -0700

> Which is why we should think about "Accept-Encryption"

I think that the problem you are concerned with is why the Key draft [1] exists.

In this context, I don't see responses actually varying based on the
Accept-Encoding header field.  Servers will encrypt based on their
needs more so than in reaction to clients claiming support.

In fact, if we were to rely solely on Accept-Encoding (or create
Accept-Encryption), then we create the potential for a downgrade
attack if we ever need to define an alternative encryption encoding to
address flaws in this one.

[1] https://tools.ietf.org/html/draft-fielding-http-key

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 12 May 2015 17:44:04 +0000

--------

>legacy intermediary may arbitrarily gzip everything going through it.

So this is one of the reasons I think overloading C-E is a bad idea.

It adds a cryptographic weakness if

	C-E: aesbla, gzip

and

	C-E: gzip, aesbla

mean different things.

In the transmitted headers, an attacker is welcome to be able to
tell the difference between

	aesbla(plaintext)

and 

	gzip(aesbla(plaintext))

since that doesn't reveal anything about the plaintext.  (Never
mind that this is waste of CPU cycles, same thing goes for JPEG).

But the attacker should not be able to tell the difference between:

	aesbla(plaintext)

and

	aesbla(gzip(plaintext))

since that would leak information, and she should *absolutely not*
be able to force this distinction herself by sending an
Accept-Encoding header.

Therefore I think we should leave the Content-Encoding header alone
and add a new Content-Encryption header, so that the order is not
defined in what you find in the headers, but by what headers you
find.

Notice that Range is not in C-E for the very same reason:  By pulling
it out of C-E its exact placement in the pipeline gets nailed down.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 May 2015 10:50:12 -0700

> be able to force this distinction herself by sending an

The current consensus is that applying compression before encryption
is not generically safe anyway.

  C-E: aesbla, gzip

is not equivalent to:

  C-E: gzip, aesbla

because order matters for C-E.  It describes the order of application
of the transforms.  That order is at the sole discretion of the
server.  I believe that A-E is not ordered in the same way, so
coercion doesn't seem to be an option.

I'm trying to understand what attack scenario you are describing (and failing).

I do appreciate the idea that a separate header field would allow us
to pin when encryption happens and avoid the footgun.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 12 May 2015 17:50:08 +0000

--------
In message <CABkgnnXMjTueG1LXXUQkd-UTdyEsNBuw2wdrzEzxuUGzo=[email-masked]>
>needs more so than in reaction to clients claiming support.

Think Internet-Of-Junk.  Not everybody may support the same crypto
algorithms, for reason of size, cpu-power, electrical power or laws.

Being able to tell the server what the client can (and is allowed
to) cope with, the server can better pick the right algo.

>address flaws in this one.

It's still the servers responsibility to enforce the overall policy
of encryption and laugh at such attacks.  (One logical reaction:
reply "use SSL instead then")

Also:  Without Accept-Encryption (of some kind), we have no way to
phase in new and stronger crypto later on.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 May 2015 10:56:20 -0700

> reply "use SSL instead then")

That's a fair point, but the general view is that there might be
clients that want to guarantee that upgrade when it is possible.  That
is, the mutually agreed best option is chosen, even when an attacker
is present.

For instance, many TLS clients still support TLS 1.0, but TLS provides
us with ways to avoid cases where servers choose TLS 1.0 even when
both client and server support the newer and better TLS 1.2.

Accept-Encoding does not provide that property.  Accept-Encryption
might, if we were prepared to design something new.

> phase in new and stronger crypto later on.

Yes, that's the challenge.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 12 May 2015 18:01:56 +0000

--------
In message <[email-masked]>
>is not generically safe anyway.

The operative word there being "generically":  The application knows
what is being encrypted, and can therefore take appropriate
countermeasures (padding, filling, selectors, decoys etc.)

This is why we should never allow

	encrypt(gzip(who_knows_what_kind_of_data))

And therefore, "C-E: gzip" must always happen after encryption,
because we are always dealing with who_knows_what_kind_of_data.

And therefore "C-E: gzip" does not make any sense if you have
encryption (unless somebody invents an encryption where the
ciphertext is base64 or similar) but it is just a harmless waste
of electricity, it is not a security-hole.

>coercion doesn't seem to be an option.

If A-E allows you to pick and choose if you want
	aesbla(plaintext)
or
	aesbla(gzip(plaintext))

I'm not sure I would call it "Coercion", but I'm sure my card-carrying
cryptographer friends would call it "utterly broken".

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 12 May 2015 20:16:51 +0200

> it out of C-E its exact placement in the pipeline gets nailed down.

Well, thinking about it, C-E, C-T, range, etc are the body's meta-data
so they should be hidden from the clear-text headers and encrypted with
the body.

Regarding the fact that the transported contents must not be compressed,
I disagree here. If we encrypt, it's in order to protect the transported
data, regardless of that data. We will never decide what type of data a
server sends, and if you want to send a tar.gz or a PNG with different
compression levels, you must be allowed to do so. However I agree that
you don't want to reveal a single bit about what's inside.

So I tend to think now that moving all entity headers to the body (including
C-E) and using a separate header to indicate what's being compressed makes
sense.  You ask for a blob, you get a blob and until you decipher it, you
cannot tell how it was made nor what it contains.

At this point, reusing Content-Encoding to indicate the envelope's format
doesn't seem problematic at all to me since any previous occurrence of it
would have moved inside the body.

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 12 May 2015 18:21:36 +0000

--------
In message <CABkgnnUfFJHXv6CLTu2MDWOmEihB=[email-masked]>
>is, the mutually agreed best option is chosen, even when an attacker

I don't think that is a guarantee you can give, unless you reinvent
the entire SSL/TLS mess.

You'd have to have the server first send an encrypted response
saying "I saw you asking for these crypto parameters, does that
match what you sent ?" and you'd need to sign those messages
to ensure they're not forged etc.

There may be applications where that is worth the effort, but
if so it is way above our abstraction level (and crypto-skill).

For our purposes this is will have to be controlled by the guy
in uniform and his "crypto must be this tall to ride" sign on
the server.

So to summ up, this is what I think we should do:

   Accept-Encryption
	I can do these kinds of encryption
	For instance:  "rot13, aes128bla, aes256bla, keyid=ask_mom"

   We can explicitly make A-E advisory, so it is clear that the
   sender can try something stronger at the risk of failure.

   Content-Encryption
	This message is encrypted with these parameters
	For instance:  "aes128bla, keyid=ask_mom"

   And we should make it symmetric, so it can be used both for
   requests and responses.

   Vary: should match if the clients A-E contains all the fields of
   the responses C-E (but possibly ignoring salt= fields ?)

   Making Vary work this way would allow caching of pay-per-view video,
   and there are people who want that and who are hacking up stuff
   themselves for it these days.

PS: I fear that the double-encryption example will be misunderstood
as parallel encryption rather than serial encryption.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 12 May 2015 18:35:06 +0000

--------

>cannot tell how it was made nor what it contains.

Exactly.  This is why I say that encryption goes first: The moment
you perform the encryption, all metadata except for the encryption
parameters disappear, and you get an entirely new message.

We have to decide precisly how far that goes however, does an plaintext
403 response arrive as an encrypted 200 response which only reveal its
true colors on decryption ?

It follows from this that if you receive a message with both
(Content-)Encryption and Range it means:

	Range(encryption(plaintext))

and if you get Encryption, Range and C-E: gzip it means

	Range(gzip(encryption(plaintext))

so as to not reveal anything about the plaintext.

>would have moved inside the body.

It is problematic if "gzip, aesbla" and "aesbla, gzip" means different
things.

C-E is defined today as giving them different meanings, so either
we have to add veribiage which mandates that "aesbla" always must
be first in the C-E, or (better) avoid the issue by not involving C-E.

The fact that encryption needs to care about metadata means that it
is not really a "Content-Encoding" but rather a "Message-Encoding".

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 12 May 2015 20:46:35 +0200

> parameters disappear, and you get an entirely new message.

OK it was a matter of wording/understanding then, let's say
interoperability between the sender and the receiver :-)

> true colors on decryption ?

I'd rather not start to play with status nor hop-by-hop headers. But on
the other hand, if some headers have to be encrypted even when there's no
contents, you don't want to return a 204/304 implying that content-length
can be ignored and return data after it :-/

And a 304 in response to a HEAD request must not reveal the plaintext
headers that would have been encrypted in response to the equivalent
GET request if it is assumed that these ones can reveal sensitive info.

I'm sorry I haven't read the proposal yet so maybe I'm talking about things
that are already covered, thus I'll rather stop speculating.

> so as to not reveal anything about the plaintext.

Good point.

> It is problematic if "gzip, aesbla" and "aesbla, gzip" means different

Except that "gzip, aesbla" cannot happen since whatever appears before
"aesbla" would have been moved into the encrypted body. Thus "aesbla, gzip"
means that gzip has been applied after aesbla. Whether or not the client
can decode it before decrypting is another story, of course.

> be first in the C-E,

It will if the previous C-E moves to the body during the encryption
process.

> or (better) avoid the issue by not involving C-E.

Since it's clearly a change in the representation I still do find this
field appropriate for this use-case. There's no difference between
"aesbla" and "gzip" in terms of operations except that one uses some
extra parameters.

> is not really a "Content-Encoding" but rather a "Message-Encoding".

That's a possibility as well, though I'm not convinced that it brings
anything beyond C-E above.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 12 May 2015 18:50:10 +0000

--------

>that are already covered, thus I'll rather stop speculating.

They are not.

>"aesbla" would have been moved into the encrypted body.

s/would/SHOULD/

There's no guarantee against people doing stupid things.

>anything beyond C-E above.

I think it would bring clarity.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 May 2015 12:07:03 -0700

> because we are always dealing with who_knows_what_kind_of_data.

I think that's a reasonable conclusion.

> of electricity, it is not a security-hole.

Not that this is practically relevant, but you can actually compress
encrypted data.  There's a paper proving that it's possible from about
10 years back.  It's certainly not gzip though.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 May 2015 12:16:11 -0700

> I don't think that is a guarantee you can give, unless you reinvent

It's actually relatively easy to design something, but there is a cost
in fragility and flexibility.

Say you make key derivation dependent on the value of the client's
advertised capabilities.  Then content fails to decrypt (and
authenticate) if an attacker tampers with the advertisement.  It
doesn't work for requests as well (CICE might be forced into service,
but see above regarding fragility).

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 12 May 2015 21:25:56 +0200

> 10 years back.  It's certainly not gzip though.

For sure you can, the best demonstration is that by chaining the decryption
to a generic compression algo, you'll get the same compression ratio as
before encrypting. So *at least* one operation exists that way. But others
certainly do as well, as encryption doesn't add entropy, it just makes it
much harder to recognize the original data. I would not be surprized if
people who invent crypto algorithms would also be able to invent filters
for their algorithms that help to compress the data (or invent the two at
once in order to satisfy both purposes).

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 12 May 2015 19:29:23 +0000

--------
In message <[email-masked]>, Willy Tarreau writes:

>I would not be surprized if

There have been crypto algorithms which used key-bits to influence a
pre-compression, but I think the consensus was that it was better
to use a good (general) compression and a good (general) encryption.