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

Martin Thomson <> Thu, 20 October 2016 02:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD8BF129481 for <>; Wed, 19 Oct 2016 19:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.932
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lbMQ_BLe8xD1 for <>; Wed, 19 Oct 2016 19:19:30 -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 81425129401 for <>; Wed, 19 Oct 2016 19:19:30 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bx2si-0003t9-6L for; Thu, 20 Oct 2016 02:14:56 +0000
Resent-Date: Thu, 20 Oct 2016 02:14:56 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bx2sb-0003sO-Kw for; Thu, 20 Oct 2016 02:14:49 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bx2sY-0004fK-Ip for; Thu, 20 Oct 2016 02:14:47 +0000
Received: by with SMTP id z190so68402172qkc.2 for <>; Wed, 19 Oct 2016 19:14:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Zd21wbfdoHDZaxs+kNrXqqbh8MCOSwf2ZqpOzB8+ENM=; b=WIlqbjfEeV7Rrhf4QkBD8VB/aqlFYHFodM5axCrZ+M8lUCoSDs+A0/awg+HpqCu9Rb ZHCMYw+j7yAD+F/9bspevelI4cONRw2ELW9q7XV9OxA796ZBml1u/Vhi4FgUXkolYGSR lKJWimBRw/UV/tSWxTDT7StBoA2vJ8FSiO0YO/siuyys6jyPA9CJ0AfDVkWWb6gb2XzZ PyOC+3hhKAs/41X+Wuwdhz2sMNSs0L+7/BJK6GEjabbXKAuA3o1J5eHRJ0IE5sjzU/VU BXge4BgY0BwQA1UuYhBBu7X72W+A7gkkbjNozOIo3vDaK/bxmzlAcB3+v6mComPZ1MAw Pifg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Zd21wbfdoHDZaxs+kNrXqqbh8MCOSwf2ZqpOzB8+ENM=; b=NfjupsVOcLA8gVpA+7i7r4Csor/yCOdLdeOXnfa0KHogqFykUeZrTVlgA+gLJC6xra pngDR6WnYKd7Gk7HY9HLJ/uqEi+j9MY5NuID9gRWCVmDopVaV7jduP+pGRhuMfW26ghd tDf9bHDQ1w2gIxUWlopLsuCe1Urb9BQjsYE7XVU6ggOFMBTixV6iaRg5BZDzg2uNMUeo MM7EKdkqxYup7JVoDaP1yyfeABUoTHEVUWdySlT/MgbdHkXI6GaFuNdjQTbvYPvhJfXZ Hs2TypzqMJSeJt4fDoD3y58nSm/7vZBup3uRshJvxQ+joNcpNsDzQGFVmrOEKryKkeSE J6tw==
X-Gm-Message-State: AA6/9RnR8eHaDlS2UGputMHjp7lJPKaU3XqUpUy56+cY85c4CtpdFHNMOn00kAOFES5alzXITCumIx7BQeV/Ag==
X-Received: by with SMTP id d15mr8860042qke.115.1476929659976; Wed, 19 Oct 2016 19:14:19 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Oct 2016 19:14:19 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Martin Thomson <>
Date: Thu, 20 Oct 2016 13:14:19 +1100
Message-ID: <>
To: Julian Reschke <>
Cc: Poul-Henning Kamp <>, Mark Nottingham <>, HTTP working group mailing list <>, Patrick McManus <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: AWL=0.082, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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: 1bx2sY-0004fK-Ip f9c5a70334c4af75f63218610536acc8
Subject: Re: 2nd Working Group Last Call: draft-ietf-httpbis-encryption-encoding-03.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32647
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.

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.