Re: [Secdispatch] [dispatch] HTTP Request Signing

Phillip Hallam-Baker <> Mon, 04 November 2019 13:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0947120106; Mon, 4 Nov 2019 05:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UCbxECciBEuB; Mon, 4 Nov 2019 05:44:34 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52C13120154; Mon, 4 Nov 2019 05:44:34 -0800 (PST)
Received: by with SMTP id s71so14079907oih.11; Mon, 04 Nov 2019 05:44:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jtA5X1tmx5/aInP0/x9ZjyagOIrGZ/LUM8Su1f7iioA=; b=Erput7vEqzesJXaonQjgTAedzNX3q9mxq8fELD1iGtZ8sF0j095xUmN6iY1VuoMofc Kh2081KF6avBaYKT810xZ5ygIIRwtDcHyBacSip275bCP+ku0DKuIFCSCqmubL1YXAO+ smXypwukgx11dacQU3GCi/sZRVifq+Z3tZ/M5MFXyPyPL8kupDXwPlHQwi0qAfLB9rbu GoEb39JPjgkHpzi7RTxrqHK0Q2cZkpTg8C2ZtN3Wf18LTJattR743pfgg2BSAKkb7NED 4txSf7JcXsEJ4R/pBWN4eosiRrfwbV/8MfzvR1C4beLOwUtandjakaph2/A4J1P9IWsx DgOw==
X-Gm-Message-State: APjAAAVfDd3/35dnUVcOBQ7CtrGGoGDg+VayTUaSlKsbBi6k8sU4AlGq Oh/zid1pCz2gpGJtoq6+Sd6sCLaMwQDYw2RVXuA=
X-Google-Smtp-Source: APXvYqzQVneB0N+x2tI/nLYr3PqqWcRRwvpHGYr+0PL23oqwAUlLkk/xJDf3pDQv6mIReLcagM3XHTuhBUDMQmNIKBs=
X-Received: by 2002:a54:4499:: with SMTP id v25mr234932oiv.17.1572875073560; Mon, 04 Nov 2019 05:44:33 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Mon, 4 Nov 2019 08:44:22 -0500
Message-ID: <>
To: Justin Richer <>
Cc: Mark Nottingham <>,, IETF SecDispatch <>
Content-Type: multipart/alternative; boundary="00000000000009259f059685841f"
Archived-At: <>
Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Nov 2019 13:44:37 -0000

On Sat, Nov 2, 2019 at 6:39 PM Justin Richer <> wrote:

> Thanks for the pointer to the BoF, I hadn’t seen that one. I am familiar
> with the draft you linked though: The main difference is that the draft in
> question is for a signed response, whereas the draft(s) I’ve pointed at are
> for a signed request. Yes, they ought to be aligned, but the WG in question
> seems to be much more focused on packaging responses together than dealing
> with requests. If that new group also wants to take on request signing,
> then by all means let’s do it there. But it’s not as clean a match as it
> might seem on the surface, I think.

I think it is actually very different, not least because it is not yet
clear that WPACK is even proposing a new format or not. As it happens, I
developed a ZIP archive format while back-testing the DARE append only log
file spec:

If we were going to redo ZIP at this point it should be to use modern
cryptographic techniques. The signature should be a Merkle tree for a start
(see CT). And if you are going to sign/verify your archive with a single
operation, you should be able to encrypt/decrypt with one operation as well.

I have looked into signing HTTP headers many times beginning with Shen in
1993. I don't think it is actually very useful because of the way HTTP is
structured. If routing information had been separate from content

I don't yet have running code to support it, but my plan for authenticating
Mesh Service requests and responses is to wrap them in a cryptographic
envelope (I am using DARE but you could do the same thing in PKCS#7/CMS).

The envelope is always authenticated but the mode of the authentication can
be a signature, a MAC/AEM via a mutually authenticated key exchange or a
MAC/AEM under a ticket.

At this stage, the only part of HTTP I am actually using for my 'Web
Service' is the stem section of the URI which provides me with additional

There is also a BOF on MATHMESH in Singapore. DARE is a part of the Mesh.