MikeBishop / http2-certs

Enabling client certificate authentication in HTTP/2
3 stars 2 forks source link

relation to HTTP-Signature #14

Open bblfish opened 7 years ago

bblfish commented 7 years ago

Hi, there is a specification Signinging HTTP messages that can be used for authentication and that is very lightweight - I think it can be implemented nicely in a week - and that does not require any changes to TLS as it is now. This makes it very useful at least for dealing with the current transition where your spec is not finished, (and so browsers have not implemented it) keygen has been removed from most browsers with no replacement in sight that I know of, and TLS does not play nicely with HTTP/2.0 as your spec so very clearly explains. (Thanks for bringing so much clarity to this space!)

I have used HTTP-Signature in JS apps to authenticate an app to various servers, and am also implementing a standalone library for clients and servers for it too. That is clearly within my skill and time level, whereas implementing things at the TLS layer, would require a lot more effort and knowledge on my part.

I asked the question on their github repository and I ask it here, as to how the two specs complement each other, and what additional security this one brings. I ask so that I can understand the limitations of using only HTTP-Signatures, and to then also explain to people how both will be able to work together, and why people should support this work too - even though it is further off. Ie what are the limitations of the HTTP-Signatures method of authentication that I need to make people aware of, with the hope that this spec will fix that - understanding of course that no security technology is perfect, and so that all come with limitations.

MikeBishop commented 7 years ago

Without having closely examined the draft, I'd say the biggest difference is authentication of the channel. There's a difference between proving that the author of a message is X and proving that the person you're talking to is X. A signed message could be relayed or replayed at will.

This method gives you the converse -- you know who's sending you the message, but you don't actually have proof that they're the original author of what they're sending you. However, that seems less important, unless you're in a situation where you're expecting a third-party to relay and you want to authenticate both the relay and the original source.