W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 20 Oct 2016 08:16:42 +0200
To: Martin Thomson <martin.thomson@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>
Message-ID: <8e4d34d7-10fb-5715-bfca-28eca705ea08@gmx.de>
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
Received on Thursday, 20 October 2016 06:17:23 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 20 October 2016 06:17:27 UTC