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

["Dr. Pala" <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>> 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
>     >> [e-mail] <mailto:[e-mail]>
>     >> https://www.ietf.org/mailman/listinfo/dispatch
>     >
>     > --
>     > Mark Nottingham https://www.mnot.net/
>     >
>
>     _______________________________________________
>     dispatch mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/dispatch
>
>
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo