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

[Rob Sayre <[e-mail]>]

Hi,

I support this work.

Martin raised the issue of "à la carte selection of what to sign" as well
as related concerns around intermediaries:

"The interaction between signing and intermediation is a topic that
requires some attention... For instance, what if an intermediary adds a
cache-control directive when that header field was signed previously?"

That is the strength of proposals along these lines. The endpoints decide
which fields to sign, and the amount of intermediary mangling to be
tolerated. In some cases, they will sign everything and tolerate no
mangling or additions. Another example: a strict and complete signing
approach would not tolerate an edge server adding an "X-Forwarded-For"
header, but this proposal allows for it.

thanks,
Rob


On Thu, Jan 9, 2020 at 5:50 PM Martin Thomson <[e-mail]> wrote:

> Thanks Annabelle,
>
> I want to acknowledge how much this is engaging with the process with the
> right intentions.  Having existing deployments when you enter a process
> like this is always a mixed bag; you get great experience to draw from, but
> also suffer from some inertia.  We'll just have to work that out as we go.
>
> I'd say that addressing the question of flexibility is my first concern as
> much of the rest of this is driven by that.  We'll need to lean on your
> experience and contacts with real deployments for that.
>
> On Fri, Jan 10, 2020, at 12:40, Richard Backman, Annabelle wrote:
> > (Full disclosure: I am the editor of the proposed draft)
> >
> > Martin raises several important points that will need to be addressed.
> > In my opinion, this should happen within the HTTP working group, so
> > that the right people can be involved in the conversation, and
> > consensus-driven decisions can be made with full understanding of the
> > greater context of HTTP's past, present, and future. It is true that a
> > variety of groups are attempting to solve message signing and adjacent
> > problems within particular contexts, but I think a general purpose
> > solution from this working group would help drive consistency rather
> > than simply be the N+1'th standard.
> >
> > One quick note on scope/intent: this document is intended to provide a
> > general purpose mechanism that can be leveraged and profiled by other
> > specifications, developed here or in other working groups, or even
> > outside the IETF (e.g., the OpenID Foundation or W3C). It does not
> > describe how to use signatures for X or Y purpose, how to negotiate,
> > distribute, or identify keys, or how to indicate what information from
> > the request the sender must sign in order to be "secure." The answers
> > to these questions vary from use case to use case, and are therefore
> > left to profiling documents to define, as appropriate for their context.
> >
> > –
> > Annabelle Richard Backman
> > AWS Identity
> >
> >
> > On 1/9/20, 1:53 PM, "Justin Richer" <[e-mail]> wrote:
> >
> >     Thank you for all of your points below, they’re thoughtful and
> > well-considered. Just a couple points that I would like to respond too.
> >
> >     To be clear, changing syntax and breaking with existing deployments
> > of the Cavage series is absolutely on the table. Communicating with the
> > existing implementation community and providing guidance forward from
> > the Cavage series to this new work is something that the editors are
> > keenly aware of. If that means using structured headers or something
> > like that, then that’s something we need to decide in the WG. This is
> > where the expertise for that is.
> >
> >     The editors are also deeply familiar with JOSE and the differences
> > from that are, and will continue to be, in our minds going forward. We
> > have some ideas about how we can re-use the JWS algorithms (and maybe
> > even its registry), and we intend to involve many members of the SEC
> > area in this work. That said, I really think the canonicalization of
> > the HTTP request is going to be far and away the hardest part of this
> > work, and that was the general thought at the SECDISPATCH talk with a
> > room full of security experts. JWS made life easy by not doing any
> > canonicalization at all, but that comes at the cost of message rigidity
> > that can’t be counted on at the HTTP layer.
> >
> >      — Justin
> >
> >     > On Jan 9, 2020, at 1:13 AM, Martin Thomson <[e-mail]>
> > wrote:
> >     >
> >     > I think that if we were going to do this we would need to find a
> > way to better scope the work.  The draft you suggest we adopt does a
> > lot and some of that overlaps with existing work from other IETF groups
> > that are probably better suited to the definition.
> >     >
> >     > I see here canonicalization of (subsets of) HTTP messages,
> > something that probably belongs here.  We might also want to engage
> > with the question of what is signed.  More on both these subjects below.
> >     >
> >     > But this also defines a bespoke signing format, something the
> > IETF has done many times before.  I would prefer that we lean on JWS,
> > COSE, or even CMS when it comes to defining signatures.  In a brief
> > review of the document, I wasn't able to convince myself that the
> > current draft was free from some very simple problems in signature
> > construction.  An analysis of this is a surprisingly difficult thing to
> > do well and we would do well to rely on the work of others here to the
> > greatest extent possible.
> >     >
> >     > Yes, that might change the syntax in ways that are incompatible
> > with deployments, but I don't think that we should take this work on if
> > we aren't allowing for that possibility.  To give a simpler example,
> > using structured headers would be a breaking change, but also a very
> > worthwhile one in my view.
> >     >
> >     > I remain unconvinced that à la carte selection of what to sign is
> > a good strategy in general.  In two ways.  Firstly, an endpoint that
> > validates a signature needs to be careful not to consume unsigned
> > information.  There are likely strategies that can minimize exposure to
> > that risk, but anything we develop would need to consider that.
> > Secondly, this loose sort of definition means that the format is only
> > ever reliably available in very narrow application domains where it is
> > feasible to perform the necessary analysis on what can and cannot be
> > signed.  For application domains like that, specific profiles with
> > little or no flexibility are possible.  Profiles are likely to be more
> > secure as a result of being able to perform a more bounded and thorough
> > analysis.  Profiles are also more concise.
> >     >
> >     > Similarly, this takes an attitude toward canonicalization for
> > signing that differs from that taken in JWS (and web packaging, for
> > something closer to home).  I suspect that we can't avoid
> > canonicalization here due to the nature of the protocol, but it is a
> > significant complicating factor.  For instance, the draft here doesn't
> > really address the potential for character encoding issues.
> >     >
> >     > The interaction between signing and intermediation is a topic
> > that requires some attention.  This was very much an afterthought in
> > the token binding work and it produced a bunch of problems.  For
> > instance, what if an intermediary adds a cache-control directive when
> > that header field was signed previously?  Or what if endpoints and
> > intermediaries disagree about what can or cannot be modified?
> >     >
> >     > ACME takes a very different approach to signing.  Lessons from
> > that work are probably worth considering, such as the way that the
> > protocol adds anti-replay mechanisms independent of, but interlocking
> > with, the signature mechanism.  Understanding if anti-replay is in
> > scope would be good.
> >     >
> >     > In the end, I concede that there are people out there with a need
> > in this area and that we should probably do this work, but it is a
> > non-trivial enterprise.
> >     >
> >     > Yes, you can read this as me preferring a different approach,
> > maybe one closer to what ACME ended up with, but it shouldn't mean that
> > we shouldn't take on this work.  I acknowledge that the existence of a
> > willing constituency of customers for this greatly outweighs many of
> > these concerns.  I am willing to review the work and hope that the
> > above is construed as constructive input to future iterations.
> >     >
> >     > Procedural question: If we do this, what would we say about the
> > interactions with the web packaging work?  That also aims to sign HTTP
> > $somethings using a bespoke format, but the proposals there take a very
> > different approach.  I would rather avoid another XKCD 927 here.
> >     >
> >     > On Thu, Jan 9, 2020, at 15:33, Mark Nottingham 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/
> >     >>
> >     >>
> >     >>
> >     >
> >
> >
> >
> >
> >
>
>