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

Thanks for the review Julian.

Thanks for making your comments actionable.  And sorry it took so
long, illness and other work conspired against me.


I've just responded with commit IDs below if I agreed with your
comment and thought that it needed no discussion.

On 13 October 2016 at 20:54, Julian Reschke <> wrote:
>    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?

How about:
 The "aesgcm" content coding uses a fixed record size.  The resulting
encoding is
 any number of fixed-size records - which could be zero records - followed by a
 single partial record.  The partial record MUST be shorter than the
fixed record

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

I think that I have some text that will help.  I think that the answer is:

Content codings that use the Encryption header field MUST always include a
value for the header field when the content coding has been applied.  If no
parameters are needed, then a dummy value is necessary to avoid confusion about
which set of parameters applies to which content coding.  This requirement
applies to uses of the `aesgcm` content coding, which does not need a dummy
value because the `salt` parameter is mandatory.
[97b3c12] and [67b65df]

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

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

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

Yes, and it says that just above: "the salt parameter MUST be unique
each time".  The "SHOULD" here is advice (good advice I believe).

> Maybe [the abstract] should mention that it also adds a mechanism to parametrize
> content codings in general?

I don't believe that it does, or should.  See earlier email about
crypto being special (though we might argue that point if you like).

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

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

Maybe I can just explain it.  || is more compact.

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

> ...*a* context...

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

Interesting thing I learned from this: there are rules for "fixing"
non-ASCII names in xml2rfc.

Received on Wednesday, 19 October 2016 04:14:11 UTC