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

Martin Thomson <> Wed, 19 October 2016 04:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE0BA129466 for <>; Tue, 18 Oct 2016 21:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.932
X-Spam-Status: No, score=-6.932 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_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.431, 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 aKg8yxbvayoV for <>; Tue, 18 Oct 2016 21:18: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 468CF12940D for <>; Tue, 18 Oct 2016 21:18:28 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bwiGg-0003Tc-HI for; Wed, 19 Oct 2016 04:14:18 +0000
Resent-Date: Wed, 19 Oct 2016 04:14:18 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bwiGZ-0003SN-5E for; Wed, 19 Oct 2016 04:14:11 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bwiGR-0002ic-UR for; Wed, 19 Oct 2016 04:14:10 +0000
Received: by with SMTP id f128so17440211qkb.1 for <>; Tue, 18 Oct 2016 21:13:43 -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=JBNv22A7vgMZ/qqPL6LMGrtRTOKflcGvPeykgJtxoOE=; b=QCQFp3nD3H9fyLHDy0c9PXTXtbpVwTOGARuPl24s7WuRP+K4UXef9PgTfXYMzZjzR9 isHzVK2CbfPXR02Bc7wcHHCfR0xvYAilsG8s6gZhlcPZUny9PAFktR6Wx75/tibRMqV0 S/mq4YOcwYVMuhSwgYWqxhmWN7S5zd6/3P7F21IoBM5ExezcayxFMaNJ1YQeI3JJnJiw +aEe1Ka+TjKeoceB1sxiXg83AC68v4jMey0BtA8KKkrdBSNrUhMUTr/VLEIq8o7wojb/ zhAw2quDlozwa5bQvVKBq/OQjyfyrlMjymhU/8I40UVClq1K4yowWFDWI0O5xhryxs/n 00/Q==
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=JBNv22A7vgMZ/qqPL6LMGrtRTOKflcGvPeykgJtxoOE=; b=L6mvSwAB4TGzwB8sDgtZ3Ov7RoLe+FUtUKdRvE3rKn5AZ5jEYh1vq08COxVIGeiS3F j7OgEgtozPhlE3k59l9LgaQgH2RH33EMRXb7UWqVQVJFmocvMljLXKH/owxABx3VRj8K TpKU7J5gnJVG/y1JQdeiERKAQ/NxL8jVDrFztk2ZCquIhy2Hmb4us67npYWMBSBlvObU eAnYM8CvlGFNmyc8F6fINSTKYaQTGLrjlNGE/AFzdp2upVKwTS0d0O9K3STgUPt/awav prXoOVXQNEAVGPBAIChA8NySEaGeQtlnrtbaACaDF0tYRKgaQjcN2IuzI+0S9hksBlxP onuQ==
X-Gm-Message-State: AA6/9RkGUIg4ZkVxXGdLTEQDNX4tMafr+56PMi7L1ReUInLoemXQyk+daYe4BwhUSN3R+/SqvwqfPqz7AvfD+A==
X-Received: by with SMTP id x17mr3870892qkb.147.1476850417885; Tue, 18 Oct 2016 21:13:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 18 Oct 2016 21:13:37 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Martin Thomson <>
Date: Wed, 19 Oct 2016 15:13:37 +1100
Message-ID: <>
To: Julian Reschke <>
Cc: Mark Nottingham <>, HTTP working group mailing list <>, Patrick McManus <>
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: 1bwiGR-0002ic-UR 0fef7a5e1762a3e2d03eb1819fdaf347
Subject: Re: 2nd Working Group Last Call: draft-ietf-httpbis-encryption-encoding-03.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32625
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.