Re: 2nd Working Group Last Call: draft-ietf-httpbis-encryption-encoding-03.txt

Julian Reschke <> Thu, 13 October 2016 09:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B135012970F for <>; Thu, 13 Oct 2016 02:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.917
X-Spam-Status: No, score=-9.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T5jR0IISezsc for <>; Thu, 13 Oct 2016 02:59:29 -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 00D2E129711 for <>; Thu, 13 Oct 2016 02:59:28 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bucjU-00047D-UJ for; Thu, 13 Oct 2016 09:55:24 +0000
Resent-Date: Thu, 13 Oct 2016 09:55:24 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bucjP-00046R-GG for; Thu, 13 Oct 2016 09:55:19 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1bucjB-0001cx-Nr for; Thu, 13 Oct 2016 09:55:18 +0000
Received: from [] ([]) by (mrgmx003) with ESMTPSA (Nemesis) id 0MZCQ8-1bZeSP1oEe-00KxGa; Thu, 13 Oct 2016 11:54:29 +0200
To: Mark Nottingham <>, HTTP working group mailing list <>
References: <> <>
Cc: Patrick McManus <>
From: Julian Reschke <>
Message-ID: <>
Date: Thu, 13 Oct 2016 11:54:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:3JiQtkgpaCkzD6x06M74KNTg/EiureuRa5PzPFE4X3WhywijZyX WNFESRpg4m6np4lLh0jTxgClqvFbGooERtisPZn4tfRxeKghCVDbvDSsKAmVuZKh5U2hCtw d9ZpEPNGwMGVCFfK0a8cWguHKA/TnB5ThU9tFFCnMz5etmO11Ii0TKJxdRbUPoy9FCQUBlH 5DyXi1AtcIR/vowjrGV6g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:+5MZRM2vUUw=:sEJldqq8UmFeynKn0n5X0q y+eINllRR8bK3lcbsnorsBq/tfawauLJd7q2w/HaU6SUvph8NXc0c6W8jji34CkWQ9jb95i88 jfw65CEsEjJwy7KhyuXS/6buF/cjg6XGdbCJsRQjxdANNgNhwDCy5UxV+uKsdbhENxI4OwR9M JWj3Y5htwStA7VW6CQFv/KOWl/3aLsjMAJhns9X21zVuI34PQWk12dWxUmLUkW+S2Fy2u+JU5 RkAxx6A++X0SdHUicnRWUgPJgslZ5T5CgZltU09vN5/U1FE/AWyGM9V0nOS9PlTUHWX3o6QNZ Hp94bgLjPWCfngrrSboQ3UPEPT+bGB+cwWNxW4EsXGBXBHiXNtnzfLHi7r2rE+fCgn3t+WAQB vV3RXjuq31fB9nG9m4E9GUwnysmu/w247wZ/b7FA7NjFSwaJKab4hP4yz7xAifAcWzmNV3W4c hcfUjgJ5g0OxB/OjYhaTRXWN4WAmgc/rwon00299CHKngmvDS2a4IrB/pAzh/eIwohpp3x8+6 9IzNmxpD0nNDQDA1AXZbCrC4NedPNQzvOT0zrW5gDlgDKA53V+4SHNKNN7y8RzmbHw5ZP3hrs eamBymsL+xzEc5KKKWY8I9kI5eVBTkndGFt5ikaK3Y8yVgpho26lScgy6HtyfCfuOT43GgZyB 2iFNSrllbFO28eAQ3/10yZLZpVHHQam1hdSh6qWJytj/fuTIW8zTLrMPC/de/HufIuHWKLqrT HYE+mYhp+o+IEKtW9UttUkweZ3c4d+lxjhiwSQcvCPFPzMMOWuwnBh8lxJpDyBtj3NL1rO3JP xxsbysa
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.2
X-W3C-Hub-Spam-Report: AWL=1.422, BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1bucjB-0001cx-Nr 64a0a8e089dc02ad8663a2bb741e3551
Subject: Re: 2nd Working Group Last Call: draft-ietf-httpbis-encryption-encoding-03.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32574
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi there,

below are my first comments, mainly focusing on the non-crypto parts.

(I might try to implement at least the receiving part, in which case 
I'll have certainly more comments...)

Best regards, Julian

2.  The "aesgcm" HTTP Content Coding


    The "aesgcm" content coding uses a fixed record size.  The resulting
    encoding is either a single record, or a series of fixed-size
    records.  The final record, or a lone record, MUST be shorter than
    the fixed record size.

That seems incorrect. If it's "either a single record or a series of 
fix-sized records", how then can then last record be shorter?

3.  The Encryption HTTP Header Field

    If the payload is encrypted more than once (as reflected by having
    multiple content codings that imply encryption), each application of
    the content coding is reflected in a separate Encryption header field
    value in the order in which they were applied.

I believe we need to clarify the precise interaction between new content 
codings and this header field. I'll assume any new content coding needs 
to opt-in to use this field value as well, so it's clear how to remove 
entries when unwrapping codings.

In particular: what if the parameters are optional? (and, nitpicking: is 
this mechanism really only applicable to encryption codings?)

    Encryption header field values with multiple instances of the same
    parameter name are invalid.

...of the same parameter name in a single encryption_params production...

(which reminds me that you can't have '_' in ABNF production names)

4.  Crypto-Key Header Field

    Crypto-Key header field values with multiple instances of the same
    parameter name are invalid.

(see above)

5.1.  Encryption of a Response

    Here, a successful HTTP GET response has been encrypted using input
    keying material that is identified by a URI.

by a URI? (leftover from earlier versions?)

    Note that the media type has been changed to "application/octet-
    stream" to avoid exposing information about the content.

Maybe mention the alternative of not sending it at all.

6.1.  Key and Nonce Reuse


    If a content encryption key is reused - that is, if input keying
    material and salt are reused - this could expose the plaintext and
    the authentication key, nullifying the protection offered by
    encryption.  Thus, if the same input keying material is reused, then
    the salt parameter MUST be unique each time.  This ensures that the
    content encryption key is not reused.  An implementation SHOULD
    generate a random salt parameter for every message; a counter could
    achieve the same result.

So maybe the requirement is uniqueness, not randomness?



    This memo introduces a content coding for HTTP that allows message
    payloads to be encrypted.

Maybe this should mention that it also adds a mechanism to parametrize 
content codings in general?

3.1.  Encryption Header Field Parameters

   salt:  The "salt" parameter contains a base64url-encoded octets
       [RFC7515] that is used as salt in deriving a unique content
       encryption key (see Section 3.2).  ...

As "base64url" is defined upfront, citing here RFC7515 is a bit 
confusing (as when you follow the reference, you end up with a spec that 
happens to include that definition, but it largely about something else) 

3.2.  Content Encryption Key Derivation

    The info parameter to HKDF is set to the ASCII-encoded string
    "Content-Encoding: aesgcm", a single zero octet and an optional
    context string:

       cek_info = "Content-Encoding: aesgcm" || 0x00 || context

I was a bit confused by this until I realized that it's pseudo-code, not 
ABNF. Maybe "concat(....)" would be clearer than "||" (which, in the 
languages I use, definitively does not mean concatenation).

3.3.  Nonce Derivation

    The nonce input to AEAD_AES_128_GCM is constructed for each record.
    The nonce for each record is a 12 octet (96 bit) value is produced
    from the record sequence number and a value derived from the input
    keying material.

maybe ...value *that* is produced...

    The length (L) parameter is 12 octets.  The info parameter for the
    nonce is the ASCII-encoded string "Content-Encoding: nonce", a single
    zero octet and an context:

...*a* context...


    [XMLENC]   Eastlake, D., Reagle, J., Imamura, T., Dillaway, B., and
               E. Simon, "XML Encryption Syntax and Processing", W3C
               REC , December 2002, <>.

Might be better to cite the slightly newer 
<>. In any case, 
please add the W3C short name to the series element, such as in:

"Eastlake, D. and J. Reagle, “XML Encryption Syntax and Processing”, W3C 
Recommendation REC-xmlenc-core-20021210, December 2002,