Subject: [Secdispatch] HTTP Request Signing

From: Justin Richer <[email-masked]>
Date: Fri, 1 Nov 2019 17:59:50 -0400

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 <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

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 2 Nov 2019 15:26:01 +1100

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 <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/draft-cavage-http-signatures
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

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

---

From: Justin Richer <[email-masked]>
Date: Sat, 2 Nov 2019 18:38:56 -0400

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 <[email-masked]> wrote:
> 
> Hi Justin,
>

---

From: Jeffrey Yasskin <[email-masked]>
Date: Sat, 2 Nov 2019 20:18:15 -0700

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 <[email-masked]> 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
>
> > It's worth noting that there's a Working Group forming BoF, wpack, being
> held in Singapore about a draft with similar goals:
> >
> > 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,
> >
> >
> >> 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:
> >>
> >> 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.
> >>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 4 Nov 2019 09:28:08 +1100

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 <[email-masked]> 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
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 4 Nov 2019 08:44:22 -0500

> might seem on the surface, I think.

I think it is actually very different, not least because it is not yet
clear that WPACK is even proposing a new format or not. As it happens, I
developed a ZIP archive format while back-testing the DARE append only log
file spec:

http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html

If we were going to redo ZIP at this point it should be to use modern
cryptographic techniques. The signature should be a Merkle tree for a start
(see CT). And if you are going to sign/verify your archive with a single
operation, you should be able to encrypt/decrypt with one operation as well.

I have looked into signing HTTP headers many times beginning with Shen in
1993. I don't think it is actually very useful because of the way HTTP is
structured. If routing information had been separate from content
metadata...

I don't yet have running code to support it, but my plan for authenticating
Mesh Service requests and responses is to wrap them in a cryptographic
envelope (I am using DARE but you could do the same thing in PKCS#7/CMS).

The envelope is always authenticated but the mode of the authentication can
be a signature, a MAC/AEM via a mutually authenticated key exchange or a
MAC/AEM under a ticket.

At this stage, the only part of HTTP I am actually using for my 'Web
Service' is the stem section of the URI which provides me with additional
ports.

There is also a BOF on MATHMESH in Singapore. DARE is a part of the Mesh.

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 4 Nov 2019 11:20:17 -0700

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:
> 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 
> 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.
>
> On Sat, Nov 2, 2019 at 3:39 PM Justin Richer <[email-masked] 
> <mailto:[email-masked]>> 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 <[email-masked]
>     <mailto:[email-masked]>> 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:
>     >
>     > 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 <[email-masked]
>     <mailto:[email-masked]>> 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:
>     >>
>     >> 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.
>     >>
>     >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Nov 2019 10:33:04 -0800

Speaking as one of the authors of 2660, if we want to attack these
problems, I don't think it is really a suitable starting point, though
perhaps there are ideas we could steal.

-Ekr

On Mon, Nov 4, 2019 at 10:20 AM Dr. Pala <[email-masked]> wrote:

> Is the proposal to update / replace the RFC or do you see it as something
> completely different ?
>
> Cheers,
> Max
>
>> > It's worth noting that there's a Working Group forming BoF, wpack,
>> being held in Singapore about a draft with similar goals:
>> >
>> >> 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.
>> >>
> Secdispatch mailing [email-masked]://www.ietf.org/mailman/listinfo/secdispatch
>
> --
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director

---

From: Mary Barnes <[email-masked]>
Date: Mon, 4 Nov 2019 14:02:47 -0600

Personally, I'd rather not have the presentation twice, recognizing of
course, that not everyone would be able to attend one or the other. But, we
will have recordings and as is oft stated, ultimately decisions happen on
mailing lists.  And, I appreciate and agree with Jeffrey not wanting
feature creep in WPACK.  One objective of DISPATCH has been to ensure that
work that is chartered is discrete enough to finish in a timely manner.

You mention other communities that are interested in this.  Will they be
participating or have they participated in IETF?    It's hard for chairs to
judge consensus to work on something when the communities interested in the
work are not participating in IETF.  Mailing list participation is
sufficient.

DISPATCH agenda is pretty full right now, so this would have to fall into
AOB at this juncture if ADs and my WG co-chair agree that we should discuss
in DISPATCH.  And, perhaps whether it gets a few minutes in SECdispatch
might be informed on how it goes in DISPATCH, if we have a chance to
discuss it, since you need the agreement that this is a problem IETF should
solve from both areas.

Regards,
Mary
DISPATCH WG co-chair

On Fri, Nov 1, 2019 at 5:00 PM Justin Richer <[email-masked]> wrote:

> 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
> 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

---

From: Justin Richer <[email-masked]>
Date: Tue, 5 Nov 2019 11:55:54 -0500

A number of the people involved with implementing the drafts that I’d like to present are involved in IETF in different places, but none for pushing this draft to date. If this work finds a home, I think we’d be able to get a lot of that external community to participate in whatever list ends up hosting the work. 

I’m fine with presenting at only one of DISPATCH or SECDISPATCH instead of both, but since this sits squarely at the intersection of the two communities it might make sense for me to just introduce the concept (~1 min) at whatever meeting I’m not giving a full presentation at. 

 — Justin

> On Nov 4, 2019, at 3:02 PM, Mary Barnes <[email-masked]> wrote:
> 
> Personally, I'd rather not have the presentation twice, recognizing of course, that not everyone would be able to attend one or the other. But, we will have recordings and as is oft stated, ultimately decisions happen on mailing lists.  And, I appreciate and agree with Jeffrey not wanting feature creep in WPACK.  One objective of DISPATCH has been to ensure that work that is chartered is discrete enough to finish in a timely manner.   
> 
> You mention other communities that are interested in this.  Will they be participating or have they participated in IETF?    It's hard for chairs to judge consensus to work on something when the communities interested in the work are not participating in IETF.  Mailing list participation is sufficient.  
> 
> DISPATCH agenda is pretty full right now, so this would have to fall into AOB at this juncture if ADs and my WG co-chair agree that we should discuss in DISPATCH.  And, perhaps whether it gets a few minutes in SECdispatch might be informed on how it goes in DISPATCH, if we have a chance to discuss it, since you need the agreement that this is a problem IETF should solve from both areas.
> 
> Regards,
> Mary
> DISPATCH WG co-chair
> 
> 
> On Fri, Nov 1, 2019 at 5:00 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 5 Nov 2019 11:59:15 -0500

We have the time at SecDispatch, so should I just add it
considering DISPATCH has a full agenda?

Best regards,
Kathleen

On Tue, Nov 5, 2019 at 11:56 AM Justin Richer <[email-masked]> wrote:

> A number of the people involved with implementing the drafts that I’d like
> to present are involved in IETF in different places, but none for pushing
> this draft to date. If this work finds a home, I think we’d be able to get
> a lot of that external community to participate in whatever list ends up
> hosting the work.
>
> I’m fine with presenting at only one of DISPATCH or SECDISPATCH instead of
> both, but since this sits squarely at the intersection of the two
> communities it might make sense for me to just introduce the concept (~1
> min) at whatever meeting I’m not giving a full presentation at.
>
>  — Justin
>
>

-- 

Best regards,
Kathleen

---

From: Justin Richer <[email-masked]>
Date: Tue, 5 Nov 2019 12:06:41 -0500

That sounds great to me, I will plan to present at SECDISPATCH. If the chairs of DISPATCH would be willing to give me a quick moment to just point people to this other work during the meeting, in case they aren’t paying attention to this list. Considering that DISPATCH is first it’d mostly be pointing people to the SECDISPATCH meeting for the discussion if they’re interested.

 — Justin

> On Nov 5, 2019, at 11:59 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> We have the time at SecDispatch, so should I just add it considering DISPATCH has a full agenda?
> 
> Best regards,
> Kathleen
> 
> On Tue, Nov 5, 2019 at 11:56 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Nov 4, 2019, at 3:02 PM, Mary Barnes <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/secdispatch <https://www.ietf.org/mailman/listinfo/secdispatch>
> 
> 
> -- 
> 
> Best regards,
> Kathleen

---

From: Adam Roach <[email-masked]>
Date: Tue, 5 Nov 2019 13:43:00 -0600

Given that DISPATCH meets in the first Monday morning slot, I think this 
plan makes the most sense. Justin (or the DISPATCH chairs) can give a 
very short description of the purpose of the proposed mechanism, and let 
interested parties know that the discussion will take place in SECDISPATCH.

/a

On 11/5/19 10:59 AM, Kathleen Moriarty wrote:
>     A number of the people involved with implementing the drafts that
>     I’d like to present are involved in IETF in different places, but
>     none for pushing this draft to date. If this work finds a home, I
>     think we’d be able to get a lot of that external community to
>     participate in whatever list ends up hosting the work.
>
>     I’m fine with presenting at only one of DISPATCH or SECDISPATCH
>     instead of both, but since this sits squarely at the intersection
>     of the two communities it might make sense for me to just
>     introduce the concept (~1 min) at whatever meeting I’m not giving
>     a full presentation at.
>
>      — Justin
>
>
>>     On Nov 4, 2019, at 3:02 PM, Mary Barnes
>>     <[email-masked] <mailto:[email-masked]>>
>>     wrote:
>>
>>     Personally, I'd rather not have the presentation twice,
>>     recognizing of course, that not everyone would be able to attend
>>     one or the other. But, we will have recordings and as is oft
>>     stated, ultimately decisions happen on mailing lists.  And, I
>>     appreciate and agree with Jeffrey not wanting feature creep in
>>     WPACK.  One objective of DISPATCH has been to ensure that work
>>     that is chartered is discrete enough to finish in a timely manner.
>>
>>     You mention other communities that are interested in this.  Will
>>     they be participating or have they participated in IETF?    It's
>>     hard for chairs to judge consensus to work on something when the
>>     communities interested in the work are not participating in
>>     IETF.  Mailing list participation is sufficient.
>>
>>     DISPATCH agenda is pretty full right now, so this would have to
>>     fall into AOB at this juncture if ADs and my WG co-chair agree
>>     that we should discuss in DISPATCH.  And, perhaps whether it gets
>>     a few minutes in SECdispatch might be informed on how it goes in
>>     DISPATCH, if we have a chance to discuss it, since you need the
>>     agreement that this is a problem IETF should solve from both areas.
>>
>>     Regards,
>>     Mary
>>     DISPATCH WG co-chair
>>
>>
>>         Singapore. This I-D has been floating around for years now
>>         and has been adopted by a number of different external groups
>>         and efforts:
>>
>>         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.
>>
>>         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.
>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 5 Nov 2019 14:45:54 -0500

OK, it's on the posted agenda.

Best regards,
Kathleen

On Tue, Nov 5, 2019 at 2:43 PM Adam Roach <[email-masked]> wrote:

> plan makes the most sense. Justin (or the DISPATCH chairs) can give a very
> short description of the purpose of the proposed mechanism, and let
>> A number of the people involved with implementing the drafts that I’d
>> like to present are involved in IETF in different places, but none for
>> pushing this draft to date. If this work finds a home, I think we’d be able
>> to get a lot of that external community to participate in whatever list
>> ends up hosting the work.
>>
>> I’m fine with presenting at only one of DISPATCH or SECDISPATCH instead
>> of both, but since this sits squarely at the intersection of the two
> dispatch mailing [email-masked]://www.ietf.org/mailman/listinfo/dispatch
>
>
>

-- 

Best regards,
Kathleen

---

From: Justin Richer <[email-masked]>
Date: Wed, 6 Nov 2019 11:36:06 -0500

Thank you, everyone, and I’ll see you in Singapore!

 — Justin

> On Nov 5, 2019, at 2:45 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> On Tue, Nov 5, 2019 at 2:43 PM Adam Roach <[email-masked] <mailto:[email-masked]>> wrote:
> Given that DISPATCH meets in the first Monday morning slot, I think this plan makes the most sense. Justin (or the DISPATCH chairs) can give a very short description of the purpose of the proposed mechanism, and let interested parties know that the discussion will take place in SECDISPATCH.
> 
> /a
>