On 06/08/13 23:15, Joseph Bonneau wrote: > > 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.
<no hats> agree. +1 for going with http header and _not_ going with well-known URI at this point. Best regards, Tobias > > 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
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
