oriented to the response and distribution of content signed by third parties
developed mostly by Google, will be implemented in Chrome
supports multiple authority signatures
mutual security strategies from TLS1.3 and other specifications
uses the new draft of the HTTP working group Structured Headers that allows to specify binary data and strings delimiting with * data encoded in base64
` Example-DictHeader: en = "Applepie", from = * w4ZibGV0w6ZydGUK = * `
We are discussing these specifications in workgroups so that:
1- become a basis for implementing non-repudiable exchanges;
2- find a summary on the Signature header;
3- improve draft-cavage security eg # 35 and # 36
I’ve been asked by @Roberto_Polli to have a look into this thread to see if I can bring any opinion on the matter.
Quick introduction so I can brag myself: My name is Vincenzo Chianese, I live in Madrid and I work for (https://stoplight.io) — a platform for designing/building/testing APIs; for the last 4 years I’ve been working for API Companies (https://apiary.io). I also maintain an open source API Gateway written in JavaScript (https://express-gateway.io)
First Foreword: I do APIs (badly), and I am even worse with security. What I’m saying here could be completely non-sense.
Second Foreword: I haven’t really looked into the first proposal. The draft is in expired state and apparently you’ve done a first round analysis which led you towards the direction of neglecting/discarding it. I’m going to cope with that.
TL, DR
Use mutual TLS, and you get what you need.
Long story
I’ve been looking to the RFC and I have the following considerations:
Not all the HTTP headers are signed by default. They must be explicitly set using another header. Albeit this is not a showstopper, I think this might be a problem in case of an intermediary server adding/modifying/removing a header on the way.
The use case that is leading this proposal is not really about non-repudiation. The reason of the whole toy here (or at least, the main use case) is to serve a content from an Origin — that’s in turn fetched from another Origin. Having a look at the author of the proposals (Google) I do see the motivations. This seems interesting for CDNs providers and, in my opinion, an attempt to fix AMP.
The whole RFC, to me, is simply reimplementing at the HTTP level what mutual TLS has been doing for a very long time (the reason are in the point 2); I’d be way more inclined to leverage the existing technology rather than trying to adapt another one for this specific purpose. Moreover, although today HTTP is the thing, tomorrow it might not be the case anymore.
I understand that XMLHttpRequest was meant do to something really different and then it turned out to be the driver for Ajax and all the stuff around, but
I consider that an exception rather than the rule.
With security you might want to avoid technology adaption
That said, regardless of the technology (HTTP Signed Messages, mutual TLS), there’s the big problem of authenticating the current user, which can be done with confidentiality exclusively through a certificate issued by a CA (the government, in this case, and ultimately there is more to ponder on issuing, revoking and securely deliver such certificate to the client (the citizen, I guess).
Hi @vncz and thanks for your comment! I’ll shed more light on that. The post assumes some background that instead I gave for granted: your comment is very useful even for integrating it.
a) on mutualTLS: Though it’s not clear from my post (I have to find a way to explicit that), this is on top of mutualTLS; TLS provides security only while the exchange is happening. Once the connection is closed, the ony evidences that data was sent via TLS are connection logs, which may be tampered. That’s the reason why only mutualTLS is not enough;
1- if intermediary servers alter the resource representation and the related headers content-type, content-encoding, ... the representation has been tampered and it’s fine to have a problem. If you need non-repudiation, the resource representation should be preserved and you shouldn’t accept an altered one.
2- the proposal goal, as you said, is about AMP. It contains many of the building blocks for implementing a request/response signature.
3- see a) the problem with mutualTLS is that it’s ephemeral and you may need a proof of your exchanges. I understand that’s subject is quite regulatory. Your comment on XMLHttpRequest is very interesting tough.
Once the connection is closed, the ony evidences that data was sent via TLS are connection logs, which may be tampered.
I might be missing something then. How would signed exchanges solve this problem?
You would have to save/store the traffic somewhere regardless of signatures or not in case you want to display/replay it as proof of non repudiation, isn’t it?
In case of Mutual TLS, you can save the whole TLS stream and open it on the spot in case you need to. I think this is a non-issue.
this is on top of mutualTLS
Hmm, this is weird to me.
In mutual TLS (where both client and server have a certificate) you already have all the guarantees you need. I struggle to see the value of re-encrypting (most likely with the exact same set of keys) the whole traffic.
In case you’d go with HTTP Signatures, I think you can ditch mutual TLS entirely for Server-Only TLS
the problem with mutualTLS is that it’s ephemeral
I believe it is not. You can store the stream and reopen it in case you need to check out what happened in that particular exchange.
Again, I might be missing some context here, to feel free to fill in in case it’s needed.
Message-Signatures is a specification derived from draft-cavage and has recently been adopted by the IETF http workgroup. It is more similar to Signed-exchanges now and:
