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

Julian Reschke <> Thu, 20 October 2016 06:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B37C012952E for <>; Wed, 19 Oct 2016 23:21:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.332
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2YdgpEdN7djS for <>; Wed, 19 Oct 2016 23:21:44 -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 2C20D129498 for <>; Wed, 19 Oct 2016 23:21:44 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bx6fR-0001qC-ME for; Thu, 20 Oct 2016 06:17:29 +0000
Resent-Date: Thu, 20 Oct 2016 06:17:29 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bx6fL-0001pG-Jt for; Thu, 20 Oct 2016 06:17:23 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1bx6fJ-0006Cm-7J for; Thu, 20 Oct 2016 06:17:23 +0000
Received: from [] ([]) by (mrgmx002) with ESMTPSA (Nemesis) id 0M9Jss-1c5Kvk12g2-00Cf7B; Thu, 20 Oct 2016 08:16:42 +0200
To: Martin Thomson <>
References: <> <> <> <> <> <> <> <> <> <>
Cc: Poul-Henning Kamp <>, Mark Nottingham <>, HTTP working group mailing list <>, Patrick McManus <>
From: Julian Reschke <>
Message-ID: <>
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: <>
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=;;
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: 1bx6fJ-0006Cm-7J 76901e8324e53e5eb8f0bede8059e395
Subject: Re: 2nd Working Group Last Call: draft-ietf-httpbis-encryption-encoding-03.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32649
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 2016-10-20 04:14, Martin Thomson wrote:
> On 20 October 2016 at 01:46, Julian Reschke <> 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