IETF Logo Mail Archive

Re: [dispatch] [Secdispatch] HTTP Request Signing

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 04 November 2019 13:44 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0947120106; Mon, 4 Nov 2019 05:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCbxECciBEuB; Mon, 4 Nov 2019 05:44:34 -0800 (PST)
Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C13120154; Mon, 4 Nov 2019 05:44:34 -0800 (PST)
Received: by mail-oi1-f179.google.com 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; d=1e100.net; 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: <E53D0610-2A30-483E-9BF5-BC83E7BC2CBF@mit.edu> <AE0333E9-651F-4362-9BC2-5B24DDBB531A@mnot.net> <2AC5BD50-53E3-41CE-A2C3-C25D310A89ED@mit.edu>
In-Reply-To: <2AC5BD50-53E3-41CE-A2C3-C25D310A89ED@mit.edu>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 04 Nov 2019 08:44:22 -0500
Message-ID: <CAMm+Lwh95Ck4QVreC4hRriyxodvJ3JvkLgtc7a8M_ugrdJx4ow@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Mark Nottingham <mnot@mnot.net>, dispatch@ietf.org, IETF SecDispatch <secdispatch@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000009259f059685841f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/KoxyzfyIAT-5FhyuBgxAv6Wclxk>
Subject: Re: [dispatch] [Secdispatch] HTTP Request Signing
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2019 13:44:37 -0000

On Sat, Nov 2, 2019 at 6:39 PM Justin Richer <jricher@mit.edu> 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:

http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html

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
metadata...

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
ports.

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

v2.23.0 | Report a Bug | By Email