> 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?
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
