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

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 <mt@lowentropy.net> 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/
>> 
>> 
>> 
>

Received on Thursday, 9 January 2020 21:49:58 UTC