Subject: Encryption content coding simplification

From: Martin Thomson <[email-masked]>
Date: Thu, 4 Aug 2016 11:54:42 +1000

Based on the review from ekr and the discussion at the last meeting,
I've put together a pull request on the encrypted content coding spec
that proposes to remove a bunch of the complexity from the spec. I
think that it's a lot simpler:

https://github.com/httpwg/http-extensions/pull/218

I have a uploaded preview of the resulting spec here:
http://httpwg.org/http-extensions/simple_base/draft-ietf-httpbis-encryption-encoding.html

I have a corresponding change on the webpush spec to take the parts of
what was removed that they rely on.

This is a fairly big change.  I think that it's prudent to run WGLC
again after this change.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 04 Aug 2016 10:09:53 +0000

--------
>https://github.com/httpwg/http-extensions/pull/218

It certainly is.

But relative to the discussion about how many specialized parsers
we have forced people to write, this draft seems to add yet another
for the new headers.

I think we should try to, and easily can avoid that.

	Content-Encoding: aesgcm, aesgcm
	Encryption: keyid="mailto:[email-masked]";
		    salt="NfzOeuV5USPRA-n_9s1Lag",
		    keyid="bob/keys/123";
		    salt="bDMSGoc2uobK_IhavSHsHA"; rs=1200

Keyid, salt and rs are parameters to the Content-Encoding,
so in a perfect world, we would send this as:

	Content-Encoding:
		aesgcm;keyid="mailto:[email-masked]";
		    salt="NfzOeuV5USPRA-n_9s1Lag",
		aesgcm;keyid="bob/keys/123";
		    salt="bDMSGoc2uobK_IhavSHsHA";
		    rs=1200

That is a non-trivial extension of RFC7231's "content-coding", which
may or may not cause existing implementations to needlessly reject
these transactions.

I suggest we run a few tests to see what happens in the real world.

If extending C-E is impractical, we should put the Encryption header
on "common structure" form, by having it reference its corresponding
token from the C-E header explicitly:

	Content-Encoding: aesgcm, aesgcm
	Encryption: aesgcm;keyid="mailto:[email-masked]";
		    salt="NfzOeuV5USPRA-n_9s1Lag",
		    aesgcm;keyid="bob/keys/123";
		    salt="bDMSGoc2uobK_IhavSHsHA"; rs=1200

That has the added advantage of being a clean extension point
past aesgcm down the road:

	Content-Encoding: aesgcm, caesar
	Encryption: aesgcm;keyid="mailto:[email-masked]";
		    salt="NfzOeuV5USPRA-n_9s1Lag",
		    caesar;shift=52

But if we've come all this way, we might as well generalize
"Encryption" to a "CE-params", that can carry parameters for any
C-E:

	Content-Encoding: aesgcm, caesar, supercompress
	CE-params: aesgcm;keyid="mailto:[email-masked]";
		    salt="NfzOeuV5USPRA-n_9s1Lag",
		    caesar;shift=5,
		    supercompress;dictionary=11

With this approach the new Crypto-Key header surplus to
requirements: The key is simply another parameter, and
we avoid having to match the key-id from two different
headers with each other, and all the corner-cases that
brings:

	Content-Encoding: aesgcm, caesar, supercompress
	CE-params: aesgcm;key="csPJEXBYA5U-Tal9EdJi-w";
		    salt="NfzOeuV5USPRA-n_9s1Lag",
		    caesar;shift=5,
		    supercompress;dictionary=11

And finally, we want a "binary blob" type in the common structure,
the two we have here would be marked as such, for instance with
the "\#" I proposed in my strawman:

	Content-Encoding: aesgcm, caesar, supercompress
	CE-params: aesgcm;key="\#csPJEXBYA5U-Tal9EdJi-w";
		    salt="\#NfzOeuV5USPRA-n_9s1Lag",
		    caesar;shift=5,
		    supercompress;dictionary=11

Please ?

-- 
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.