Re: Call for Adoption: draft-richanna-http-message-signatures

Thanks for the feedback, Eric! While I obviously don’t agree with your conclusions, you bring up an important point:

…we should have a coherent threat model and architecture that helps understand where each technical piece fits in and how they fit together. I appreciate that we have a bunch of individual energy for specific pieces and that the enthusiasts for those pieces don't want to be delayed by a bigger project, but part of the purpose of standardization is to look to the bigger picture.

This is precisely why I think it’s important to bring this work into the working group at this time. The Cavage draft has been kicking around as an individual draft for almost 7 years now. Meanwhile, various other initiatives have started up and tread over a lot of the same ground, reinventing incompatible approaches to the same problems. No one knows what work has been done, because it’s all tied up in individual drafts – here it’s worth noting that along with this draft, two of the other three documents you referred to as examples of our failure to coordinate are individual drafts themselves. Individual drafts are, it turns out, a really bad mechanism for coordination on “the bigger picture.”

This is where the HTTP Working Group can and should come in. Working groups provide the structure, process, and diversity of knowledge and experience needed to drive consensus and bring competing/conflicting efforts into alignment. I think it is unlikely that the coordination you’re looking for will happen outside of that context. I also think this adoption and development of this draft would be a good first step towards establishing that coordination. Many on-going efforts (including Signed Exchanges) depend on signing mechanisms of some kind, and a standard general purpose signing mechanism would provide a foundation that these efforts could build off of.

And for what it’s worth, I will go on record as the editor of this spec that I do not care what form the signing mechanism takes, as long as it meets the technical requirements and is capable of achieving broad adoption. I am happy to rewrite this thing to use CBOR, or JWS, or whatever, if that’s what it takes to start bringing things into alignment. But I want the decision to do so to derive from public discussion and working group consensus, not because I decided in my “infinite wisdom” (:P) that it was the right decision.

–
Annabelle Richard Backman
AWS Identity


From: Eric Rescorla <ekr@rtfm.com>
Date: Sunday, February 2, 2020 at 8:49 AM
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Tommy Pauly <tpauly@apple.com>
Subject: Re: Call for Adoption: draft-richanna-http-message-signatures
Resent-From: <ietf-http-wg@w3.org>
Resent-Date: Sunday, February 2, 2020 at 8:45 AM

Hi folks,

I do not believe we should initiate work in HTTP on HTTP Request
signatures starting with draft-richanna-http-message-signatures.

My high order concern is that we seem to be starting to build a
piecemeal object security system for HTTP without any kind of
coordination or common architecture. So far, we have standardized or
proposals to standardize:

- Encrypted Content-Encoding (RFC 8188)
- Martin Thomson's expired draft on HTTP signatures
  (draft-thomson-http-content-signature)
- Signatures for responses (Signed Exchanges)
- Signatures for requests (this draft)

Plus a bunch of others I'm surely forgetting.

I'm certainly not going to argue that it wouldn't be useful to have
some kind of message security system for HTTP (and I agree that RFC
2660 isn't it), but if we're going to do that, we should have a
coherent threat model and architecture that helps understand where
each technical piece fits in and how they fit together. I appreciate
that we have a bunch of individual energy for specific pieces and that
the enthusiasts for those pieces don't want to be delayed by a bigger
project, but part of the purpose of standardization is to look to the
bigger picture.

To take just one example of this: while the intended semantics of
Signed Exchanges and of this draft are obviously very different, they
both attempt to perform the same basic task, namely signing an HTTP
message, they make a variety of different wire format choices (CBOR
versus ad hoc [0], different header inclusion treatment, etc.) I note
that they also both attempt to register the Signature header, but with
different formats, which obviously won't work.


Aside from this architectural point, I think the evidence from HTTP
Encryption (which was conceptually much simpler) is that this work
shouldn't be in HTTP, which just doesn't have the appropriate level of
security engagement to ensure solid review. If the IETF wishes to work
in this area, it should form an "HTTP Message Security" working group
that can work through all the use cases and will have the right level
of security engagement rather than just adopt individual specs into HTTP.


I also have some technical comments about the document, but they're
kind of beside the point here.


-Ekr

[0] Incidentally, it's frustrating that neither of these seems to use
COSE, JOSE, etc.

On Wed, Jan 8, 2020 at 8:36 PM Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:
Hello everyone,

We've discussed mechanisms for signing HTTP messages for some time. At IETF106, this draft was presented in the SECDISPATCH Working Group:
  https://tools.ietf.org/html/draft-richanna-http-message-signatures-00


See also the presentation given there:
  https://datatracker.ietf.org/meeting/106/materials/slides-106-secdispatch-http-signing


In discussion there (and with the relevant ADs), it was felt that the most obvious place for this work to land in the IETF would be in this WG. So, while this specific draft has not been discussed extensively here, we have expressed interest in this topic for quite some time, and it seems appropriate to see if we're willing to take it on.

To that end, this is a Call for Adoption of draft-richanna-http-message-signatures-00. Since there hasn't been extensive discussion yet, we're looking for more confirmation than just absence of objection; we'd like folks to read the document and state explicitly whether they support it as a starting point for a work item.

As with all of our drafts, it will only be a starting point; we're not looking for consensus to publish this draft as-is, just confirmation that this is an area we want to start work in.

In particular, if folks could state whether they're willing to contribute to discussion and review drafts, that would be helpful.

To give time to read and consider the draft, this CfA will be for a longer than usual period; we'll make a decision no earlier than 31 January.

Cheers,

P.S. As a reminder, this isn't a call to start discussing specific issues in the draft; we'll have plenty of time for that later.

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