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

[Julian Reschke <[e-mail]>]

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?

Editorial:

Abstract

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

References:

    [XMLENC]   Eastlake, D., Reagle, J., Imamura, T., Dillaway, B., and
               E. Simon, "XML Encryption Syntax and Processing", W3C
               REC , December 2002, <http://www.w3.org/TR/xmlenc-core/>.

Might be better to cite the slightly newer 
<https://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>. 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, 
<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/>."