Re: [Secdispatch] [dispatch] HTTP Request Signing

Mark Nottingham <mnot@mnot.net> Sun, 03 November 2019 22:28 UTC

Return-Path: <mnot@mnot.net>
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 9C70B120043; Sun, 3 Nov 2019 14:28:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=W7HH+A3h; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oyhuSap/
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 L8n4QV_ieQIY; Sun, 3 Nov 2019 14:28:21 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648E612000F; Sun, 3 Nov 2019 14:28:21 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 52C60213CA; Sun, 3 Nov 2019 17:28:19 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 03 Nov 2019 17:28:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=n W0SkntqlbpA2HkAY1i1TK+OxCWg75rW0nGT9HT++Ko=; b=W7HH+A3hjqUDXjQqp lkAmLw4sqJ/LDbPJ6jOWgTXfuGYag1mT8PA2OqpZ7UYTC8a46LEZ0Z//JXNaxT9E qGNC52rwTkNdlsXoB46dMilz1SvYaOZwEzDWwVgEf9hTnQTzeCZzgqHHIOR47s66 vgskeMdmAcD4DZLnW7/bUVJtJoP8gYzTTJm1qGwPQ+PCNI0oxR6SOHlZDyYHX0iP VuAxTAWlhQ7iFaKPGhabs2rEpjkfOmUsn8WzG4aAPTSlHEIS1xVZESXiV61OlLor R0q+b23Szb0zZb5/HFtXiV4HxMU7OS9UpeLGLMOd/lULFqze127rhSCjI/Pn4S4t BC4OA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=nW0SkntqlbpA2HkAY1i1TK+OxCWg75rW0nGT9HT++ Ko=; b=oyhuSap/DZxI2sefPgdezR6aSGr/A6J+qgDDvQLCFGpo+rP8C8BdTP4NX 2cm+nWN3R//YYVn/WIJ3ziCdWRmM+G4Py+mPuXqac9r7bmudbFheUwejn8CzHon/ EgJC8dkHATT/dtekbPW2DXchcP+nBswS0RE7XNm8UhOfQY55v6ta8PTEhbs6Akgk YQ1aCE6sTNDQ+oP5MRK3zs6f1HFWBNXGVfdkSEGMyhqq4GnAvdAOpQRRNOZ/4qF7 VM7+JPWFvMG8TM3dCVaHp0ts+JWar4VjTrtHbSMlBMareiK3SYvl9u3xpAfSAnR4 dJRkmR2jkPc3Dvbn+XPulqdiQqsvg==
X-ME-Sender: <xms:glS_XYnOEFeZgkNy_MX-uItx43cAFmOKJE8ePqygH10cXMp47uGNUg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduuddgudeihecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrih hnpehhthhtphgtohhmmhhunhhithhivghsrhgvshhpvggtthhivhgvlhihrdhsohdphhht thhpmhgvshhsrghgvghsihhgnhhinhhgtggrphgrsghilhhithihrdgrshdpihgvthhfrd horhhgpdhmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedunecurfgr rhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrh fuihiivgeptd
X-ME-Proxy: <xmx:glS_XTawOm4ITgsGjLWL4VJaKttJ1skaMvDmn5s1diWN4efu56UykQ> <xmx:glS_Xd7U5CPFr5vnPpt1lmmYSxGh_R6Htdu9-0Fdt26MhFQJfU0EVg> <xmx:glS_Xc9ZKvAHfVMhEAgdFANRp-LS2_d5FtSi2Mk2hTDLtb4Q6wFOgg> <xmx:g1S_XSnWihiPkkrWBrCEB5dIJM--0r5qpnTKTfQGwIeurVQBf5jGxQ>
Received: from macbook-pro.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id DCDD980059; Sun, 3 Nov 2019 17:28:12 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CANh-dXnFQy+-s4LH6eL1fvEoFOVvhSY+jj-cAv2kuyx+JwC9_Q@mail.gmail.com>
Date: Mon, 4 Nov 2019 09:28:08 +1100
Cc: Justin Richer <jricher@mit.edu>, dispatch@ietf.org, secdispatch@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D279E705-19DD-444D-A819-8C4F5249AFF3@mnot.net>
References: <E53D0610-2A30-483E-9BF5-BC83E7BC2CBF@mit.edu> <AE0333E9-651F-4362-9BC2-5B24DDBB531A@mnot.net> <2AC5BD50-53E3-41CE-A2C3-C25D310A89ED@mit.edu> <CANh-dXnFQy+-s4LH6eL1fvEoFOVvhSY+jj-cAv2kuyx+JwC9_Q@mail.gmail.com>
To: Jeffrey Yasskin <jyasskin@chromium.org>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/6_MtyyramZ_ReKXJshpk8ecUtsI>
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 22:28:24 -0000

I understand -- I just want to make sure the discussions are coordinated, not had in isolation.

Cheers,


> On 3 Nov 2019, at 2:18 pm, Jeffrey Yasskin <jyasskin@chromium.org> wrote:
> 
> 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

--
Mark Nottingham   https://www.mnot.net/