Subject: Encryption simplification

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Oct 2016 21:22:26 +1100

After discussion about content codings, I've made something of a
drastic change to the encryption draft.  A preview is here:
    http://httpwg.org/http-extensions/encryption-preview.html

The pull request is here:
    https://github.com/httpwg/http-extensions/pull/252

This is a huge simplification in many ways, so I think that's a fair
improvement.

The main assertion that this assumes is this: content codings should
be self-descriptive.

Obviously, this isn't a strong assertion given that this content
coding requires a key, and SDCH relies on having an external
dictionary, but the point is that the contents of the message can be
decoded without reading additional header fields.  This is consistent
with the observation that James Manger made about the MICE content
coding previously [1].

To that end, I've removed the Encryption header field and packed the
critical data into the content itself.  This is more efficient and
avoids strange cross-header-field correlation between Encryption and
Content-Encoding.  It retains Crypto-Key and key identifiers, but
that's necessary since they generally travel separately.

I realize that we're close to the draft submission deadline, so I'm
planning to publish the draft with these modifications.  We can
continue to have this discussion.  Thanks to the magic of revision
control systems, it's easy to revert this change if needed.

(Yes, this messes with webpush, I still need to talk to people about
what to do there.)

[1] https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun/0242.html

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Oct 2016 11:35:01 +0100

> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun/0242.html

+1 in general.

That said, doesn't have Crypto-Key a similar problem (in that you might 
not now what applied encryption content codings it applies to)?

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 30 Oct 2016 18:18:50 +0000

--------
In message <[email-masked]>, Martin Thoms

>The main assertion that this assumes is this: content codings should

I think this is the right way to go.  When we discussed this, I had
to twist my brain silly to come up with examples, and they were all
clearly strawmen.

I wish we had a pool of "HTTP design principles" somewhere we could
add decisions like this to, for future reference.

-- 
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: Kari Hurtta <[email-masked]>
Date: Sun, 30 Oct 2016 20:26:03 +0200 (EET)

> not now what applied encryption content codings it applies to)?

http://httpwg.org/http-extensions/encryption-preview.html#crypto-key

| keyid:
|     The “keyid” parameter corresponds to the “keyid” parameter in the content 
|     coding.
| aes128gcm:
|     The “aes128gcm” parameter contains the base64url-encoded octets [RFC7515] of 
|     the input keying material for the “aes128gcm” content coding.

So there is keyid and it is also on

http://httpwg.org/http-extensions/encryption-preview.html#header

| +-----------+--------+-----------+------------+
| | salt (16) | rs (4) | idlen (1) | id (idlen) |
| +-----------+--------+-----------+------------+

I guess that this "id" is keyid:

| keyid:
|     The “keyid” parameter can be used to identify the keying material that is 
|     used. When the Crypto-Key header field is used, the “keyid” identifies a 
|     matching value in that field. The “keyid” parameter MUST be used if keying 
|     material included in an Crypto-Key header field is needed to derive the 
|     content encryption key. The “keyid” parameter can also be used to identify 
|     keys in an application-specific fashion.

This

| rs:
|     The “rs” or record size parameter contains an unsigned 32-bit integer in 
|    network byte order that describes the record size in octets. Note that it is 
|    therefore impossible to exceed the 2^36-1 limit on plaintext input to 
|    AEAD_AES_128_GCM. Values smaller than 3 are invalid.

Is that 2^36-1 same than  2^36-31  here:

http://httpwg.org/http-extensions/encryption-preview.html#limits

|   There are limits to the data that AEAD_AES_128_GCM can encipher. The maximum 
|   record size is 2^36-31 [RFC5116].

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Oct 2016 10:55:31 +1100

> I guess that this "id" is keyid:

Yes, thanks for noticing.  Fixed.

> Is that 2^36-1 same than  2^36-31  here:

Again, a typo.  Thanks.

---

From: Costin Manolache <[email-masked]>
Date: Mon, 31 Oct 2016 06:13:02 +0000

1. Why not add the Crypto-Key to the binary header ? If we have to deal
with binary encoding, we can at
least avoid parsing more text headers - and it doesn't have to be b64.

2. For webpush - if the actual encryption is the same ( and I haven't
compared with the previous version ) - I
don't expect it to be a big problem to accept both formats for a while in
existing servers.
Having all keys in the binary payload has benefits - less parsing/confusion
on the headers, b64 encoding/decoding.
+1

Costin

On Sun, Oct 30, 2016 at 5:01 PM Martin Thomson <[email-masked]>
wrote:

Again, a typo.  Thanks.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 31 Oct 2016 07:51:10 +0100

Hi Martin,

> that's necessary since they generally travel separately.

I like it. I think it is well designed and even suspect that if it
succeeds we'll see an update later to move some payload-specific
metadata which currently stand in headers into the encrypted block
(I don't have good examples right now but have faced this need in
the past -- we may for example think about the content's title and
author or the location where a photo was taken). But for now I think
it efficiently covers what it aims to.

Good job!
Willy

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Oct 2016 21:03:24 +1100

On 31 October 2016 at 17:13, Costin Manolache <[email-masked]> wrote:
> 1. Why not add the Crypto-Key to the binary header ? If we have to deal with
> binary encoding, we can at

I considered doing this, but - other than webpush, more on that below
- the key usually has to travel independently of the encrypted
payload.  Otherwise we're reduced to providing an elaborate checksum.

> don't expect it to be a big problem to accept both formats for a while in

I have an update for the webpush document that follows this.
Unfortunately, the format and crypto is incompatible.  That's
unavoidable.  I took the opportunity to simplify things further.

We've managed this in the past by switching on the content-encoding
header field value, and I plan to do the same.  I consider that sort
of extra complexity the cost of trying to implement a standard that
isn't completely done.

For the DH public key, I did consider packing it into the keyid field
rather than relying on Crypto-Key.  That seemed wrong, but I could be
convinced that it's worth doing.

I'll follow up on the webpush list and we can hash out that side of
things there.

---

From: Kari Hurtta <[email-masked]>
Date: Mon, 31 Oct 2016 18:54:11 +0200 (EET)

Costin Manolache <[email-masked]>: (Mon Oct 31 08:13:02 2016)

This

http://httpwg.org/http-extensions/encryption-preview.html#introduction

| For example, it might be necessary to store a file on a server without exposing its contents 
| to that server. Furthermore, that same file could be replicated to other servers (to make it 
| more resistant to server or network failure), downloaded by clients (to make it available 
| offline), etc. without exposing its contents.

does not mention it, but I think that there was hidden 
(for this draft) motivation where reponse headers was 
served from originin server via https (that include 
Crypto-Key) but actual payload is served from another 
server. That content-encryption provides encryption
for that payload. Another Content-Encoding (Out-Of-Band)
moves payload to other server.

https://greenbytes.de/tech/webdav/draft-reschke-http-oob-encoding-08.html#rfc.section.3.5.3

was mentioned.

/ Kari Hurtta

---

From: Costin Manolache <[email-masked]>
Date: Mon, 31 Oct 2016 17:50:18 +0000

I'm not sure I understand - if symmetric keys are used:
1. They should not be sent along with the content
2. If they are for some reason, it doesn't make a difference if it's in
header or body
3. The server storing the encrypted content would need to have access
somehow to the key, if it is to be send to the user
4. If they do have access - it doesn't matter if they send it in a header
or prepend it to the body

IMHO it's very confusing to have examples of symmetric encryption where the
key is sent along -
sending a public key along with the message is fine. Not clear from the doc
is if the public-key case
 is no longer supported - but if that is the case, there would be no need
to send any key with
the message, so the Crypto-Key will not be needed ?

Again - I may miss something obvious here, is the value in the header just
a reference to a pre-shared
secret and not the actual secret ? But in this case - there is already the
id in the binary header.

Costin

---

From: Kari Hurtta <[email-masked]>
Date: Mon, 31 Oct 2016 20:11:26 +0200 (EET)

Costin Manolache <[email-masked]>: (Mon Oct 31 19:50:18 2016)
> 2. If they are for some reason, it doesn't make a difference if it's in

It makes difference with Out-Of-Band

> > https://greenbytes.de/tech/webdav/draft-reschke-http-oob-encoding-08.html#rfc.section.3.5.3

gives:

-------------------------------------------------
HTTP/1.1 200 OK
Date: Thu, 14 May 2015 18:52:00 GMT
Content-Encoding: aesgcm, out-of-band
Content-Type: text/plain
Encryption: keyid="a1"; salt="vr0o6Uq3w_KDWeatc27mUg"
Crypto-Key: keyid="a1"; aesgcm="csPJEXBYA5U-Tal9EdJi-w"
Content-Length: 101
Vary: Accept-Encoding

{
  "sr": [
    { "r" :
      "http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"}
  ]
}
-------------------------------------------------

Note that actual body, which was encrypted, is on
http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00

That is different server than from where these headers
(and out-of-band -pointer on body) was got.

Story is that combination

    Content-Encoding: aesgcm, out-of-band

First encrypt body: aesgcm
Then move body out from response: out-of-band

/ Kari Hurtta

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Nov 2016 10:14:02 +1100

You can log an issue here:
  https://github.com/httpwg/http11bis/issues
to remind us to say something about it in the next revision.

Cheers,

> On 31 Oct. 2016, at 5:18 am, Poul-Henning Kamp <[email-masked]> wrote:
> 
> --------

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