On Mon, Sep 22, 2014 at 5:56 AM, Henri Sivonen <[email protected]> wrote:
>> -- HTTP Strict Transport Security > > Yes, but I think this requirement shouldn't apply to subresources for > the page to qualify, since top-level HSTS together with the "No mixed > content" requirement mean that there's no sslstrip risk for embedded > resources even if they are served from a non-HSTS CDN. These days we're blocking loads of active mixed content, but passive mixed content is still a concern to me. E.g. an attacker can mangle a web app's UI pretty badly, including to perform attacks, if the app gets its icons and buttons via SSLstrip-able sources. >> -- HTTP Public Key Pinning > > I'm a bit worried about this one. I'd like the bar for this indicator > to be such that it can motivate anyone with nginx to configure it > right. This way, the new indicator could have a broad impact beyond > just the largest sites. It's not clear to me if HPKP is practical for > sites without Google/Twitter-level ops teams. HPKP is indeed dangerous. I don't anticipate any additional UI for it, let alone additional UI that would motivate a not-ready-yet ops team to turn it on. > It seems to me that it's at least currently impractical for small > sites to get CAs to commit to issue future certs from a particular > root or intermediate, so it seems to me that especially pinning an > intermediate is hazardous unless you are big enough a customer of a CA > to get commitments regarding future issuance practices. Intermediates move slowly, and roots even more slowly. It's fairly safe to assume that, for the lifetime if your end-entity cert, the CA will still be operating, and if that they can and will cross-sign in cases where they re-key heavily-used issuing certs. But, yeah, have a backup pin, and pin at various places in the certificate chain. I'd advise people to look at net/http/transport_security_state_static.json and consider what Dropbox, Google, Twitter, and Tor have done, and why. > It's unclear to me if HPKP makes it safe and practical to use without > actually forming a business relationship with two CAs in advance > (which would be impractical for many small sites). It seems to me that > HPKP makes it possible to generate a backup end-entity key pair in > advance of having it certified. However, the spec itself discourages > end-entity pinning altogether and it's pretty scary to pin a key > before you know for sure you can get it certified by a CA later. I wouldn't say we discourage EE pinning; but I would discourage pinning EEs *exclusively*. > (In some way, it seems like HPKP is the simplest thing that makes > sense for Google, which has its own intermediate, but for the rest of > us, being able to maintain a TACK-style signing key *to the side of* > the CA-rooted chain would be better. What's the outlook of us > supporting TACK or some other mechanism that allows pinning a > site-specific signing key that's not part of the CA-rooted chain?) I consider a backup pin to be enough like an "on the side" pin. But, however, you may not. >> -- Certificate Transparency > > Are we planning to support CT now? (I'm not stating an opinion for or > against. I'm merely surprised to see CT mentioned as if it was > something we'd support, since I don't recall seeing previous > indications that we'd support it.) I devoutly hope Mozilla does support CT. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
