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.
- I-D Action: draft-ietf-httpbis-encryption-encodin… internet-drafts
- Re: I-D Action: draft-ietf-httpbis-encryption-enc… Martin Thomson
- Re: I-D Action: draft-ietf-httpbis-encryption-enc… Poul-Henning Kamp
- Re: I-D Action: draft-ietf-httpbis-encryption-enc… Martin Thomson
- Re: I-D Action: draft-ietf-httpbis-encryption-enc… Mark Nottingham
- 2nd Working Group Last Call: draft-ietf-httpbis-e… Mark Nottingham
- Re: I-D Action: draft-ietf-httpbis-encryption-enc… Poul-Henning Kamp
- Re: 2nd Working Group Last Call: draft-ietf-httpb… Julian Reschke
- Common structure | Re: I-D Action: draft-ietf-htt… Kari Hurtta
- Re: Common structure | Re: I-D Action: draft-ietf… Poul-Henning Kamp
- Re: 2nd Working Group Last Call: draft-ietf-httpb… Martin Thomson
- Re: 2nd Working Group Last Call: draft-ietf-httpb… Julian Reschke
- Re: 2nd Working Group Last Call: draft-ietf-httpb… Poul-Henning Kamp
- Re: 2nd Working Group Last Call: draft-ietf-httpb… Julian Reschke
- Re: 2nd Working Group Last Call: draft-ietf-httpb… Poul-Henning Kamp
- Re: 2nd Working Group Last Call: draft-ietf-httpb… Julian Reschke
- Re: 2nd Working Group Last Call: draft-ietf-httpb… Poul-Henning Kamp
- Re: 2nd Working Group Last Call: draft-ietf-httpb… Kari Hurtta
- Re: 2nd Working Group Last Call: draft-ietf-httpb… Martin Thomson
- Re: 2nd Working Group Last Call: draft-ietf-httpb… Julian Reschke
- Re: 2nd Working Group Last Call: draft-ietf-httpb… Martin Thomson
- Re: I-D Action: draft-ietf-httpbis-encryption-enc… Julian Reschke