Re: Encryption content coding simplification

Martin Thomson <> Wed, 28 September 2016 07:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D79C12B08D for <>; Wed, 28 Sep 2016 00:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.837
X-Spam-Status: No, score=-8.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q5QmvpAArPgv for <>; Wed, 28 Sep 2016 00:33:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1AE4912B076 for <>; Wed, 28 Sep 2016 00:33:57 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bp9JM-0008CA-Jd for; Wed, 28 Sep 2016 07:29:48 +0000
Resent-Date: Wed, 28 Sep 2016 07:29:48 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bp9J0-00083T-Li for; Wed, 28 Sep 2016 07:29:26 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bp9Ix-0002zl-Ib for; Wed, 28 Sep 2016 07:29:25 +0000
Received: by with SMTP id j129so31409288qkd.1 for <>; Wed, 28 Sep 2016 00:29:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UQRclXqUPcKYlhTgQUK72df9LYYu6pVeyQqmCk125w8=; b=Fxp+dlpCe/LYXdDEN01zFJ7L87wC6jWIVL4w/BfAntpBoQ3RfEBVB6JPZgR6uI3iB2 FzpKgDESAe4eQNRLACe4/wvjPYNQTp75nc7A8TSTmBOZMO9H59B6Lh9hTM4hgxWxZ3XZ l+XCfPRcbGPwoVCMa5iW/sJGK9LWmSBtaMfuLc3mbqxymWbMSSGIjvTptPzJerBKlCcb 6k1JNEsATvmWxcnz/MWDzKR54eM4KxAUkUWPh1tdNl2xcxK3yBGHSMil1gncVfh3TKjL Wl3Qh7YeeoNrxLZ0esDoZ2Fp4HC/bbC3LpAMYBQcLEZmnrCrkm0h1o+F+2FcIYzdJ8Al ysFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UQRclXqUPcKYlhTgQUK72df9LYYu6pVeyQqmCk125w8=; b=SffV8+a3rLMYs9iygzlDbbak1nFnWYVxkDtspijo/70hZ3C2Dlp5gUZ38CK6LC6FER G8NVgrMMY+KV+Ezu/37sLGgGQ/XyxTkMjJqiVmqls17t7u5naU75ghuyo13A8dx54MhT XQe/elGc4g71VrLLBrSQCzkvLL0cs2VbU6QR/qrqW+uWvBL/etpqGiBHk2fXvMMG45/I FnYplo7gLFiY3+3UL1v7Kle/OZV2bq1SjfJi2ZBTH35ImgfHaxzDuxkB1t0j4ujzkvPy 1XMxU9Zn9vGEl9N7ncpeBNZPrbBBtEp4nqkCZhRlrPPHjIBF0zepbadCxRRwdVoI0766 G1zA==
X-Gm-Message-State: AA6/9Rng8BsNikaf2tQ3W+RjxUn2eUaGluPeF65S96RrmWaJFxE0+Hfy38uvg77HR64fB8NGuprT6tDzz0BMnw==
X-Received: by with SMTP id m188mr30857092qkc.55.1475047737659; Wed, 28 Sep 2016 00:28:57 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 28 Sep 2016 00:28:57 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Martin Thomson <>
Date: Wed, 28 Sep 2016 17:28:57 +1000
Message-ID: <>
To: Poul-Henning Kamp <>
Cc: HTTP Working Group <>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.8
X-W3C-Hub-Spam-Report: AWL=-0.268, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bp9Ix-0002zl-Ib 2554a3136588d60335435459eda8ce21
Subject: Re: Encryption content coding simplification
Archived-At: <>
X-Mailing-List: <> archive/latest/32425
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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
  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 <> wrote:
> --------
> In message <>om>, 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:
> 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="";
>                     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="";
>                     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="";
>                     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="";
>                     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="";
>                     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.