Re: Encryption content coding simplification

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.

On 4 August 2016 at 20:09, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> --------
> In message <CABkgnnXCMFRthQRCgvSXVjaMwE8BPTdfUYZHCa2tEwhDQ3RUpA@mail.gmail.com>, Martin Thomson writes:
>>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
>
> 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:me@example.com";
>                     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:me@example.com";
>                     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:me@example.com";
>                     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:me@example.com";
>                     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:me@example.com";
>                     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
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.

Received on Wednesday, 28 September 2016 07:29:26 UTC