RFC 7569 – Public Key Pinning Extension for HTTP | Hacker News Reader

RFC 7569 – Public Key Pinning Extension for HTTP

tools.ietf.org

49 pointsch0wn9 comments

This is very important and can increase security on the internet a lot. As far as I know Google is already doing this in Chrome with it's own servers.

There's more to the Internet than HTTP, though. I'd be a lot happier if this effort were being invested in improving DNS so that other services could benefit.

It seems like DANE would benefit from extra backing instead of this approach

Surely they two approaches are complementary? This could be a good second-best approach for those unable to sign their domain for some reason.

The web browser should treat a pin identically, regardless if it was hardcoded or sourced from HTTP or DNS. Or are there obvious problems with that approach?

There is currently very close to zero deployment of DNSSEC on clients and it's unlikely to change any time soon.

I'm somewhat baffled that every time CA problems are discussed someone comes up with DANE. This has been tried for years and the result is that it does almost nothing at all today to protect anyone.

HPKP is not perfect, but it's a vast improvement over the state of the art - and it works today, in real browsers. And I think there is a reason for it: DNSSEC is far too complicated and involves too many parties. For HPKP you need a browser and a webpage to support it, that's relatively simple. For DANE/DNSSEC you need the root zone, the TLD, the registrar, the dns server operator and somehow also the client to do something useful at all.

Security is complex. I didn't say "we don't need this, we have DANE".

I said that I wish the effort and weight put behind this solution, was put behind something like DANE, which is protocol agnostic - so it helps you protect connections to your HTTPS login form just the same as it helps me protect connections to my XMPP server or IMAP server or whatever else I have that operates over SSL/TLS.

Yes, DNSSEC has not had the best rollout - even though basic support is mandatory now for registrars, some (I'm looking at you fuckers, Hover/Tucows) use ridiculous subsidiary setups to get around providing support for it.

That to me though, is just further evidence that it (DANE) needs all the support it can get - if we didn't do things that were slightly complicated, we wouldn't encrypt anything at all, or hash passwords or even have the internet.

In theory I agree that any improvements are good.

In practice, this results in organisations saying "we support/use HPKP so we/our customers are safe"

Better support for DANE would mean a marked increase in security for all services offered over SSL/TLS.

There's the "equivalent" of HPKP in TLS in the form of TACK (http://tack.io/). I find TACK even cleaner because it keeps layer properly separated (whereas HPKP mixes HTTP and TLS). Also, being at the TLS layer makes it beneficial for every other protocol.

Is it just me or is the text size on that RFC a lot larger than on others?

Reply on news.ycombinator.com