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

Julian Reschke <julian.reschke@gmx.de> Thu, 20 October 2016 06:21 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 B37C012952E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 19 Oct 2016 23:21:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.332
X-Spam-Level:
X-Spam-Status: No, score=-7.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 2YdgpEdN7djS for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 19 Oct 2016 23:21:44 -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 2C20D129498 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 19 Oct 2016 23:21:44 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bx6fR-0001qC-ME for ietf-http-wg-dist@listhub.w3.org; Thu, 20 Oct 2016 06:17:29 +0000
Resent-Date: Thu, 20 Oct 2016 06:17:29 +0000
Resent-Message-Id: <E1bx6fR-0001qC-ME@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 <julian.reschke@gmx.de>) id 1bx6fL-0001pG-Jt for ietf-http-wg@listhub.w3.org; Thu, 20 Oct 2016 06:17:23 +0000
Received: from mout.gmx.net ([212.227.15.19]) by lisa.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <julian.reschke@gmx.de>) id 1bx6fJ-0006Cm-7J for ietf-http-wg@w3.org; Thu, 20 Oct 2016 06:17:23 +0000
Received: from [192.168.178.20] ([93.217.121.120]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M9Jss-1c5Kvk12g2-00Cf7B; Thu, 20 Oct 2016 08:16:42 +0200
To: Martin Thomson <martin.thomson@gmail.com>
References: <147607568231.30483.6721771001967558206.idtracker@ietfa.amsl.com> <06660B0E-6F8D-42DF-A909-C216B49FB590@mnot.net> <03fb16fd-35d4-e5d3-86d4-317b1016829e@gmx.de> <CABkgnnWKOTheZ9Gf9WLfVWAsQwNWi=EM6LhX=Za+UXnXQkf6AQ@mail.gmail.com> <90ee7958-5697-23ad-6f52-060f58800067@gmx.de> <7720.1476858421@critter.freebsd.dk> <7c879010-2145-fabc-9f97-d05de90e5147@gmx.de> <30011.1476886408@critter.freebsd.dk> <18d7f584-a303-f218-24ec-abf0c341f436@gmx.de> <CABkgnnWasq4=Y3uuw-Sccch8DMW9jTB474JnrJEuJa_gzDrKaA@mail.gmail.com>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, HTTP working group mailing list <ietf-http-wg@w3.org>, Patrick McManus <pmcmanus@mozilla.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <8e4d34d7-10fb-5715-bfca-28eca705ea08@gmx.de>
Date: Thu, 20 Oct 2016 08:16:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CABkgnnWasq4=Y3uuw-Sccch8DMW9jTB474JnrJEuJa_gzDrKaA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:eTevWKji3OPyGovAywYxUUMAA8nipjZToiuN4yJ2Yf/9gAzjrOK zzUZjghT4JJlSRYDZwrCOuWEcijj97NQvvOvf6Z5ViIPGJMJaE2OZWhQaClc9VVBvL9OwAY b7+E2Z7V98PuwESWBeV0P3VMcxGCBzQnkdrQFVB+9k5QH686FxXHhDMLo8P+jzGBhKmxxTw 3vpUJkWMeX8JWYE673YLg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:HYjNun4qjBo=:oyM0bb4TyGryzcsnM7XFBB A4b5KzWoql6Jdb27guaCEmmOVvPBtq7VGftZ8EfpTrf8jozl7Hs91R3rnAk6F/7NL/2yEi4SN KUlwA18sAsnKG1++1OQNkpu/Gd2q5xyFUAvaxgSEzlZs87IoDxLHAOfOm8Ffsrijkhr1eJP01 y+Z0ZORxuCDNfFeua1NIte8F8uYLJRj3zusvanqQ1kFI1y9BAhyv9Bg84c1q6M5AteJoAfgQl OH95yO446mbTDiKIvPoI3BFby7tn/8l9ScAZHhO+vbHrVaG4glprtkS6ZFqfHx9AsvS3NhK/m 5DAoL6ry6CYAQS/+GDP/6XmRhIeATqpFMmklNR0/Op8qH0Y18fTvf8lEIHMLgIs9NOjdcsEbT el3FexGr28xfySZo8vsJH5q2FCI2FeXjOoqHci7EPWXlBDn7WNG9bsbwzHpx4x4mcgQeCsE3P embZp3nSW9eFbjj8PyjDYGpk7eOqqzwub3N1v4kYwX1rSF22TaiZTWcEDZ0TxAL62LYhspXdd F2jLv3zKPti8A2CDF0q+45xh37ajrS5ceffv4y16hV3dLSJniR/8+95eJfvbtexZAeimYV6I2 jpfHbhW1TEvY16Y/4RdVf9QXbAZSuHxkmdDCdicDKux96AIgWos8CiNWmmaWjXyXTUYysB/Rh O/4+4hrYlUbqgsWAD1/a2zIWGAb24dWj+rcvId3cl/OkWI8V7zzdAhp+D7lTCoSnMd1m9AeKm yMISb0MgWFmiMW9tt2oWM3YvBQh11sR6ZBnh8fK12goj7cJSyjEg1l/fn735Je8mMUp44gRtg n1qT2sz
Received-SPF: pass client-ip=212.227.15.19; envelope-from=julian.reschke@gmx.de; helo=mout.gmx.net
X-W3C-Hub-Spam-Status: No, score=-8.2
X-W3C-Hub-Spam-Report: AWL=1.417, BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1bx6fJ-0006Cm-7J 76901e8324e53e5eb8f0bede8059e395
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/8e4d34d7-10fb-5715-bfca-28eca705ea08@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32649
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>

On 2016-10-20 04:14, Martin Thomson wrote:
> On 20 October 2016 at 01:46, Julian Reschke <julian.reschke@gmx.de> wrote:
>> But how would you handle the case describes above -- where the metadata
>> (content type, encryption material) is served from a server different from
>> the one having the (encrypted) payload?
>
> You know, I had the same thought as PHK after making that statement
> and I can't think of a reason he is wrong. What was relevant is that
> you need to *know* more stuff to get crypto right, but that's just the
> key.  You don't need to parameterize the content coding otherwise.
>
> If rs, salt and keyid were in the payload, I can't see how that would
> be a real problem.  They are public information and inline avoids a
> whole mess of issues.  Every secondary server would be serving the
> values, but that's not fatal.  You wouldn't be able to "compress" them
> by including one value across all potential secondaries (again, not a
> real problem, and potentially a feature if you wanted different
> encryptions across secondaries to avoid correlation).
>
> The best I could come up with is that random access always requires
> the first few octets.  But that's weak: it's either metadata or some
> of the payload.  And we already take on that burden in other places:
> it's actually a common restriction on resources that are acquired
> piecemeal.  Some media container formats require the end to make sense
> of the middle, which is much more tiresome.  Zip archives are also
> like that.

We may want to try to make the parameter segment fixed-size...

> Now, I don't know what to do about webpush, but if we are going to
> make breaking changes, I can maybe get some efficiency gains from them
> which should help there.  A new name should help avoid the worst parts
> of the churn.

Could you clarify this? Is this about a technical issue, or about when 
webpush can be finalized?

Best regards, Julian