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

Martin Thomson <martin.thomson@gmail.com> Wed, 19 October 2016 04:18 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0BA129466 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 18 Oct 2016 21:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.932
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKg8yxbvayoV for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 18 Oct 2016 21:18:29 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468CF12940D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 18 Oct 2016 21:18:28 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bwiGg-0003Tc-HI for ietf-http-wg-dist@listhub.w3.org; Wed, 19 Oct 2016 04:14:18 +0000
Resent-Date: Wed, 19 Oct 2016 04:14:18 +0000
Resent-Message-Id: <E1bwiGg-0003Tc-HI@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <martin.thomson@gmail.com>) id 1bwiGZ-0003SN-5E for ietf-http-wg@listhub.w3.org; Wed, 19 Oct 2016 04:14:11 +0000
Received: from mail-qk0-f176.google.com ([209.85.220.176]) by lisa.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <martin.thomson@gmail.com>) id 1bwiGR-0002ic-UR for ietf-http-wg@w3.org; Wed, 19 Oct 2016 04:14:10 +0000
Received: by mail-qk0-f176.google.com with SMTP id f128so17440211qkb.1 for <ietf-http-wg@w3.org>; Tue, 18 Oct 2016 21:13:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.55.99.17 with SMTP id x17mr3870892qkb.147.1476850417885; Tue, 18 Oct 2016 21:13:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Tue, 18 Oct 2016 21:13:37 -0700 (PDT)
In-Reply-To: <03fb16fd-35d4-e5d3-86d4-317b1016829e@gmx.de>
References: <147607568231.30483.6721771001967558206.idtracker@ietfa.amsl.com> <06660B0E-6F8D-42DF-A909-C216B49FB590@mnot.net> <03fb16fd-35d4-e5d3-86d4-317b1016829e@gmx.de>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 19 Oct 2016 15:13:37 +1100
Message-ID: <CABkgnnWKOTheZ9Gf9WLfVWAsQwNWi=EM6LhX=Za+UXnXQkf6AQ@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP working group mailing list <ietf-http-wg@w3.org>, Patrick McManus <pmcmanus@mozilla.com>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=209.85.220.176; envelope-from=martin.thomson@gmail.com; helo=mail-qk0-f176.google.com
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: lisa.w3.org 1bwiGR-0002ic-UR 0fef7a5e1762a3e2d03eb1819fdaf347
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 2nd Working Group Last Call: draft-ietf-httpbis-encryption-encoding-03.txt
Archived-At: <http://www.w3.org/mid/CABkgnnWKOTheZ9Gf9WLfVWAsQwNWi=EM6LhX=Za+UXnXQkf6AQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32625
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=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.

PR: https://github.com/httpwg/http-extensions/pull/249

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 <julian.reschke@gmx.de> 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
 size.
[ddf5f8e]

> 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...
[a0c51a2]

> (which reminds me that you can't have '_' in ABNF production names)
[1b376a8]

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

> 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?)
[bd0eef2]

>    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.
[4e510be]

> 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)
[63850db]

>       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.
[80225a4]

> maybe ...value *that* is produced...
[7f3a35c]

> ...*a* context...
[31c4bc4]

> 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:
[8ea4739]

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