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

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