Re: [Secdispatch] [dispatch] HTTP Request Signing

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/