Subject: WGLC comment on draft-ietf-httpbis-encryption-encoding-03, was: Encryption content coding simplification

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Oct 2016 09:23:25 +0200

On 2016-09-28 09:28, Martin Thomson wrote:
> I apologize for letting this email slip through the cracks.
>
> I see two requests here:
>
> 1. add a token to the header field syntax, i.e. go from:
>   Encryption = #encryption_params
> to:
>   Encryption = token #encryption_params
>
> 2. Fold the two header fields into one.
>
> For 1, adding the token doesn't, as you claim, gain you forward
> compatibility, due to the nature of content codings.  There's little
> point in the redundancy: if you don't understand the content coding,
> you don't get to decode/decrypt it, so order is sufficient to
> disambiguate which parameters go with which coding.  A receiver that
> decodes the content necessarily understands all of the content codings
> that it needs to acquire parameters for.
>
> For 2, while it seems like largely a matter of taste, a separable
> dictionary of keys is more flexible.  That flexibility enables the use
> of the header field in detached modes (some of the more advanced blind
> cache scenarios benefit from this).
>
> There might be a third request (use your strawman encoding), which I
> will respectfully decline.  At least until I've seen it, and maybe
> after we've had some more discussion.
> ...

While I agree with what Martin said here, I think I found another issue 
with the way Encryption is defined.

Here's a modified example:

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

The issue is that for aesgcm, the information in the Encryption header 
field is optional, it could be provided outside the HTTP message (such 
as when using the out-of-band encoding). In this case, for the message 
above, it's not clear to which of the two aescgm applications the 
parameters apply.

I believe this can be fixed by not introducing a placeholder syntax, for 
instance:

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

I also agree with PHK that if we add a new header field to specify 
content coding parameters, it should be applicable to any new encoding, 
not just Encryption codings (yes, that's just a naming issue).

With that, I actually end up with something similar to one of PHK's 
proposals:

	Content-Encoding: aesgcm, aesgcm
	CE-params: aesgcm;key="csPJEXBYA5U-Tal9EdJi-w";
		    salt="NfzOeuV5USPRA-n_9s1Lag",
                    aesgcm

...where the only difference is that any content coding that *can* have 
parameters MUST have an associated entry in CE-params.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 13 Oct 2016 07:39:35 +0000

--------
In message <[email-masked]>, Julian Reschke writes

>parameters MUST have an associated entry in CE-params.

I have a hard time dreaming up C-E's other than encryption which will
require parameters, but I'm all for taking the general approach up
front, rather than wait for my limited imagination to be exposed.

+1 from here

-- 
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: Mike Bishop <[email-masked]>
Date: Thu, 13 Oct 2016 17:46:07 +0000

Well, I can point at one, though it's not exactly a model of perfect HTTP C-E integration design....  Looking at https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-PCCRTP/[MS-PCCRTP].pdf, there are additional headers that carry the client's parameters (which the server will need if it chooses that coding) and then carry the server's selections back.

Most notable (and probably the worst choice :-) ) is that rather than defining a new C-E value for v2, the parameters include the client's min/max supported versions, and the server tells the client which version it used in a response header.

-----Original Message-----
From: Poul-Henning Kamp [mailto:[email-masked]] 
Sent: Thursday, October 13, 2016 12:40 AM
To: Julian Reschke <[email-masked]>
Cc: Martin Thomson <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: WGLC comment on draft-ietf-httpbis-encryption-encoding-03, was: Encryption content coding simplification

--------

>parameters MUST have an associated entry in CE-params.

I have a hard time dreaming up C-E's other than encryption which will require parameters, but I'm all for taking the general approach up front, rather than wait for my limited imagination to be exposed.

+1 from here

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Oct 2016 20:09:10 +0200

> Most notable (and probably the worst choice :-) ) is that rather than defining a new C-E value for v2, the parameters include the client's min/max supported versions, and the server tells the clien…

...and SDCH will also need a way to send compression related parameters, 
right?

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 14 Oct 2016 11:01:43 +1100

> ...and SDCH will also need a way to send compression related parameters,

...unless they are carried in the body.  Encryption is kinda weird in
the sense that the content is intentionally not able to be decoded by
every receiver.  Whereas most other content-encodings don't have that
constraint.  As a general notion, they benefit from being decoded
standalone.  (Yes, I believe that SDCH has header fields, but my
conjecture is that it shouldn't.)

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Oct 2016 07:23:17 +0200

> conjecture is that it shouldn't.)

Good point.

---

From: Kari Hurtta <[email-masked]>
Date: Sat, 15 Oct 2016 09:10:46 +0300 (EEST)

> parameters MUST have an associated entry in CE-params.

This looks like good idea and is unambiguous.

Also matches to "h1_common_structure" on 

3.  HTTP/1 serialization of HTTP header Common Structure
https://tools.ietf.org/html/draft-kamp-httpbis-structure-00#section-3

So that is "list of named dictionaries" as Poul-Henning Kamp 
wrote. ☺

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Sat, 15 Oct 2016 20:48:21 +1100

> This looks like good idea and is unambiguous.

I think that I will need to find a solution to this, and I think that
Julian's (originally phk's) suggestion to put the content encoding
label at the head of each value is a great one in light of this
feedback.  However, maybe we can dispense with the notion that there
is a generic need for content-encoding parameters (and thus avoid the
name change).

I will work on a proposal when it's not late, the weekend, etc...