On Wed, February 26, 2014 9:20 am, Trevor Perrin wrote: > On Wed, Feb 26, 2014 at 8:30 AM, Yoav Nir <[email protected]> wrote: > > > Hi > > > > I think all the issues raised during this WGLC have been (I think) > > addressed (and correct me on another thread if I've missed something), > > with > > the exception of some issues with the Report-Only header. > > > > I don't know whether the recently-discussed issues are addressed, as we > haven't seen a new draft. > > Many of the issues I raised in July and November are still outstanding: > > http://www.ietf.org/mail-archive/web/websec/current/msg02011.html > http://www.ietf.org/mail-archive/web/websec/current/msg01956.html > http://www.ietf.org/mail-archive/web/websec/current/msg01692.html > > I'll bring them up again once there's a new draft.
If there are outstanding issues, we definitely want to be tracking them in the issue tracker. The threads you link to include several issues that should be resolved now. While I appreciate you linking to them, it would be helpful to make sure what you feel is outstanding is properly noted. > > > > > First issue was the interaction between PKP and PKPRO if both are > > present. > > Current text ([1]) says "If a Host sets both the Public-Key-Pins header > > and > > the Public-Key-Pins-Report-Only header, the UA MUST NOT enforce Pin > > Validation". This was objected to by some ([2[), as it doesn't follow > > the > > CSP model. Chris suggested alternative text that allows them both ([3]), > > where PKP is enforced, and PKPRO is only noted and reported. There were > > no > > objections to this, except that Tom corrected a typo. Can we consider > > this > > resolved? > > > > No, because this is linked to the question about how PKP-RO works, which > we > don't have an answer to: > > http://www.ietf.org/mail-archive/web/websec/current/msg02030.html > > > > > Then Trevor brought up another issue ([4]). He asked whether the UA > > actually notes PKPRO pins or just reports on them. Nobody has responded > > yet, but I think that's a good point. Is there any value to noting PKPRO > > for, say, a month, and then reporting after two weeks that the current > > certificates do not match? When I imagine how someone would use PKPRO, > > I > > guess they generate a pins string, issue them as PKPRO, and if no > > reports > > arrive for, say, 7 days, they are moved into "production", which is the > > regular PKP. Suppose the pins in PKPRO do generate reports, I guess the > > administrator checks the reports, fixes whatever is wrong, and posts the > > good pins as PKPRO again. Does it make sense to keep receiving reports > > for > > the old pins? OTOH if we accept the non-noting idea, then the max-age > > directive makes no sense and should be omitted. As there has been no > > discussion yet, we need to consider this a bit. > > > > The issue is not just old pins, it's whether the browser is expected to > the > apply the PKP-RO check to other connections besides the current one, and > if > so, how these two different types of pins co-exist, whether they overwrite > each other, etc. In attempt to resolve your outstanding issue(s) with PKP-RO, I want to first ensure that this proposal makes sense. If we're in agreement, we can work on adding it to the next draft. PKP - Persistently recorded - Expires based on max-age - Causes all subsequent connections since 'noting' fails - Note that this is somewhat ambiguous within a UA that has multiple simultaneous connections, and for which header parsing may happen at any arbitrary time. - _HOWEVER_, I think this is best left up to implementations, since the external effects are consistent with how the server/service sets up resource fetching. PKP-RO - Not persistent - Applies only to the _single_ transport connection - Because HTTP connections MAY be kept-alive or re-used, to further qualify - Is evaluated upon receipt of the header, for the response it's included in. This means that if an HTTPS server sends PKP-RO header, then performs a TLS renegotiation that changes certificates in a way that violates the -RO, _NO_ report is sent. If the connection is used for another HTTP request, and -RO is sent, then the policy IS re-evaluated and a report is sent. Clarify that PKP-RO does _not_ affect the overall security state of the resource fetch. Specifically, it does NOT cause the connection to be closed with error. UAs MAY choose to also notify the user on -RO failures, or MAY NOT - it's up to the implementation. Example of "notification" may include something as simple as logging to the developer console. Cheers, Ryan _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
