On Thu, Feb 27, 2014 at 12:15 PM, Ryan Sleevi <[email protected]>wrote:
> On Thu, February 27, 2014 9:52 am, Trevor Perrin wrote: > > On Thu, Feb 27, 2014 at 1:44 AM, Yoav Nir <[email protected]> wrote: > > > > > > > > > I (with no hats) am very much in favor of this change. It makes sense > > > for > > > the way I think this will be used. If I were administrating a web > server > > > and wanted to use PKP, I would generate the PKP string and install it > as > > > PKP-RO for a few days. If no reports came in, it would be ready for > > > production. > > > > > > Not necessarily. > > > > This type of PKP-RO would *NOT* detect whether all your subdomains or > > load-balancers / front-end machines are correctly configured with the > > right > > certs. > > > > If people do what you suggest, they could easily get a false impression > > that they're ready to go live ("no reports - it must be good!"), and > screw > > up their site. > > > > > > Trevor > > > > Do you have any alternatives you would like to suggest? That might save a > few feedback cycles. > The alternatives I see are: 1) PKP-RO implements the full PKP semantics (i.e. is stored for max-age, is applied to includeSubdomains), but only generates reports instead of hard fails. The browser would store PKP and PKP-RO pins in separate/parallel stores, for example setting max-age=0 for a PKP pin would not clear PKP-RO pins, and vice versa. 2) PKP-RO is removed from the spec. 3) Your suggestion - have PKP-RO implement a reduced set of PKP semantics (only check current connection). I'm not sure about the usefulness of that, and I worry site operators would be mislead by it. Trevor
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
