[Secdispatch] Updating/Replacing RFC 2660 ? (was Re: [dispatch] HTTP Request Signing)

"Dr. Pala" <madwolf@openca.org> Mon, 04 November 2019 18:20 UTC

Return-Path: <madwolf@openca.org>
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 51025120115 for <secdispatch@ietfa.amsl.com>; Mon, 4 Nov 2019 10:20:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 u1q3QTdu6EK1 for <secdispatch@ietfa.amsl.com>; Mon, 4 Nov 2019 10:20:19 -0800 (PST)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 9A17712011F for <secdispatch@ietf.org>; Mon, 4 Nov 2019 10:20:19 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 5A44D3741098 for <secdispatch@ietf.org>; Mon, 4 Nov 2019 18:20:19 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pLj4G7s8q-M0 for <secdispatch@ietf.org>; Mon, 4 Nov 2019 13:20:18 -0500 (EST)
Received: from Maxs-MBP-2.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id E09F737408CB for <secdispatch@ietf.org>; Mon, 4 Nov 2019 13:20:17 -0500 (EST)
To: secdispatch@ietf.org
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>
From: "Dr. Pala" <madwolf@openca.org>
Message-ID: <400abd10-3bbc-2288-b357-f36ad721cebf@openca.org>
Date: Mon, 4 Nov 2019 11:20:17 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.1
MIME-Version: 1.0
In-Reply-To: <CANh-dXnFQy+-s4LH6eL1fvEoFOVvhSY+jj-cAv2kuyx+JwC9_Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------CB8D6AC057F463EC38642290"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/yu9RR2DdSpUZEWuR1ajS61kvWDQ>
Subject: [Secdispatch] Updating/Replacing RFC 2660 ? (was Re: [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: Mon, 04 Nov 2019 18:20:24 -0000

Hi Jeffrey, Justin, Mark, all,

I have not had the time to read the proposals, but are you familiar with 
RFC 2660 ?

Would that provide the authentication you are talking about for both 
requests and responses ?

Is the proposal to update / replace the RFC or do you see it as 
something completely different ?

Cheers,
Max

On 11/2/19 9:18 PM, Jeffrey Yasskin 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 
> <mailto: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
>     <mailto: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
>     <mailto: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 <mailto:dispatch@ietf.org>
>     >> https://www.ietf.org/mailman/listinfo/dispatch
>     >
>     > --
>     > Mark Nottingham https://www.mnot.net/
>     >
>
>     _______________________________________________
>     dispatch mailing list
>     dispatch@ietf.org <mailto:dispatch@ietf.org>
>     https://www.ietf.org/mailman/listinfo/dispatch
>
>
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo