Re: [websec] #60: Well Known URIs vs Response Headers

[Joseph Bonneau <[e-mail]>]

> In our mind, one of the biggest factors has been "What are the hurdles to
> practical deployment?". While there is admittedly complexity from the
> header approach, it's our view that it's not greater than the inherent
> complexity of effective pinning, as enumerated in the existing
> considerations. The complexity of an efficient and reasonable
> implementation of well-known URIs, or of a practical deployment of server
> extensions, seems to greatly outweigh both, and the benefits are not as
> seemingly significant.


I am in agreement that a TLS extension seems like far too much to ask of
deploying sites. I'm also appreciating more and more from this thread the
difficulty of a well-known URI and though I think it's a cleaner approach
in the long-term I can see the argument that it's too much to do right now.

I'm fully on-board with headers if we can address two issues that I think
are real impediments to servers deploying HPKP and doing so correctly: (a)
header bloat (600 bytes of for a site requiring 10 pins) (b) inadvertent
HPKP hole-punching when resources are accidentally served without headers
set. Other issues (e.g. discoverability by crawlers) seem secondary.

I think we can address (b) by not interpreting a missing HPKP header as a
max-age=0, and I was hoping we could deal with (a) by clients sending a
hash or policy serial number to avoid repeatedly sending the header. Does
this approach add too much complexity given the level of concern about
header bloat, which doesn't seem huge?