Re: [Secdispatch] [dispatch] HTTP Request Signing

Jeffrey Yasskin <jyasskin@chromium.org> Sun, 03 November 2019 03:18 UTC

Return-Path: <jyasskin@google.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587DF120096 for <secdispatch@ietfa.amsl.com>; Sat, 2 Nov 2019 20:18:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.25
X-Spam-Level:
X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 lJvqufHaVdOJ for <secdispatch@ietfa.amsl.com>; Sat, 2 Nov 2019 20:18:28 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 9A6FA120046 for <secdispatch@ietf.org>; Sat, 2 Nov 2019 20:18:28 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id 15so14358246qkh.6 for <secdispatch@ietf.org>; Sat, 02 Nov 2019 20:18:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4nWYxApDoLqBFCEEkYDMhmNLPWLG6CoiGB51MDj1NYo=; b=Gu7Jgub+g1ZGwST5SgIqu39Yn2UoKxOeuu8RZlYCJpb0jMnHU0JygSOqVPDGsR0T5m LapOP94LBTwgU6LdCG3sig32AG+i9sFbFcmroojBZptOL/SGZslpQvXQZrqV/ZSx9AvO s6k/YkLiF5hoyL3QkYJ5icFxr884BZTmhZfBs=
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=4nWYxApDoLqBFCEEkYDMhmNLPWLG6CoiGB51MDj1NYo=; b=iQJQfFuGZwlF03nhes4CZpcGan4PO0i2xjSaruOzOyGmCGf2KSZJ+ygkCks9ACpgfz tYvBqcKDhsxqW8p/yytFWVKAD/8FPIiHg3Yuh9aQDHZvw+LI2qzv5KAxVuimj1tfF+ey V7eO2jACcxl+htiEDDsP3by3PDRuzfAA+wREBF/q6cdUrWBiEmySlNAYCksVhDRqnTmP BBZVQbs8ECanUmulAxPv3ZIo4sTHB3mhuP0hnwRO92uie9cG931uBu6vugYRwJSRMEi8 TY3nqInU5jN8vGqVHsr5J+UdXGqljweD3tKYBXOh5moIM/vBdjQGePnIx3QPFta1EcgO VrSg==
X-Gm-Message-State: APjAAAVW3Cjm5q0MYkhsl84ZeRwGuVxyEB7Kj1fWZYppVhraKiLFHzUq h9Xd5eyGeW5/+lFj3GoEvzZwj/5piwwlRP6Ggob1wg==
X-Google-Smtp-Source: APXvYqz3quswWeXhYY6OSwL1r3jBcPB3Vxa9/FEJiiL9Sk08khMm0P2gEgM4VoOpDGxV8MNgfOAz5TuNy+p891F9SHc=
X-Received: by 2002:a37:5f81:: with SMTP id t123mr11741589qkb.447.1572751106887; Sat, 02 Nov 2019 20:18:26 -0700 (PDT)
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: Jeffrey Yasskin <jyasskin@chromium.org>
Date: Sat, 2 Nov 2019 20:18:15 -0700
Message-ID: <CANh-dXnFQy+-s4LH6eL1fvEoFOVvhSY+jj-cAv2kuyx+JwC9_Q@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Mark Nottingham <mnot@mnot.net>, dispatch@ietf.org, secdispatch@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000c8a98059668a739"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/d13wmZdlxQlYdjxzWI1_aWwqOm4>
Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Nov 2019 03:18:30 -0000

That's roughly what I was going to say. :) I'd like to avoid the scope
creep of having WPACK take on request signing in addition to, effectively,
response signing. It's *possible* that we could define an HTTP header in a
general enough way that it would work for both purposes, and
https://tools.ietf.org/html/draft-cavage-http-signatures-12#section-4 attempts
to do that, but the problem spaces seem to be different enough that we
should have separate groups write down the requirements for each side's
signatures before deciding that a single header will work. It's not even
clear to me that WPACK is going to end up defining an HTTP header, even
though my draft currently does so.

I'll be sure to attend the request-signing sessions in case they
establish that I'm wrong about this.

Jeffrey

On Sat, Nov 2, 2019 at 3: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.
>
>  — Justin
>
> > On Nov 2, 2019, at 12:26 AM, Mark Nottingham <mnot@mnot.net> wrote:
> >
> > Hi Justin,
> >
> > It's worth noting that there's a Working Group forming BoF, wpack, being
> held in Singapore about a draft with similar goals:
> >
> https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-07
> >
> > In particular, both this draft and Jeffrey's propose the Signature HTTP
> header field, and seem to have at least partially overlapping use cases.
> >
> > If possible, it'd be good to avoid duplication of effort -- especially
> in terms of evaluating security properties and "fit" into HTTP by the
> security and HTTP communities, respectively. So, I'd suggest bringing it up
> there instead.
> >
> > Cheers,
> >
> >
> >> On 2 Nov 2019, at 8:59 am, Justin Richer <jricher@mit.edu> wrote:
> >>
> >> I would like to present and discuss HTTP Request signing at both the
> DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has
> been floating around for years now and has been adopted by a number of
> different external groups and efforts:
> >>
> >> https://tools.ietf.org/html/draft-cavage-http-signatures
> >>
> >> I’ve spoken with the authors of the draft and we’d like to find out how
> to bring this forward to publication within the IETF. I’m targeting both
> dispatch groups because this represents the intersection of both areas, and
> I think we’d get different perspectives from each side that we should
> consider.
> >>
> >> There have been a number of other drafts that have approached HTTP
> request signing as well (I’ve written two of them myself), but none has
> caught on to date and none have made it to RFC. Lately, though, I’ve been
> seeing a lot of renewed effort in different sectors, and in particular the
> financial sector and cloud services, to have a general purpose HTTP message
> signing capability. As such, I think it’s time to push something forward.
> >>
> >> I’ve reached out to the chairs for both DISPATCH and SECDISPATCH to
> request a presentation slot.
> >>
> >> Thank you, and I’ll see you all in Singapore!
> >> — Justin
> >> _______________________________________________
> >> dispatch mailing list
> >> dispatch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dispatch
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>