Re: [websec] draft-ietf-websec-key-pinning

[Ryan Sleevi <[e-mail]>]

I wish you would have raised this during WGLC, which would have benefited
from the review and discussion now being paid.

I guess echoing Yoav's earlier remarks that:

"At this stage, we can make editorial changes, but we cannot make
> significant changes on our own. We can withdraw the request to publish, and
> take it back to the working group, but I think that would be inadvisable.
> I think we should proceed, making only editorial changes, and changes
> resulting from discussion with IESG members."


that it's probably not worth discussing much further.

If the WG feels strongly about this, we can certainly withdraw from
publication. If so, I think the Chris' and myself would need to recuse
ourselves from being able to edit this document any further, so the WG
would need to find a new set of editors to proceed with this draft.

Other than that, either we accept these as ERRATA, or we accept them as
being what they are.

That is, my understanding is that this is a bit like discovering a possible
issue after you've shipped your gold master to 100K stores. Yes, it's
awful, but either it's a recall or you fix it in post. My gut is that it's
for post. However, based on Yoav's remarks, I'm not sure that there's very
much we can do editorially to address these. It appears my proposed
suggestion does not address your concerns, so I will not be added it to the
next (and hopefully final) draft.



On Thu, Sep 4, 2014 at 4:53 PM, Trevor Perrin <[e-mail]> wrote:

> On Thu, Sep 4, 2014 at 4:09 PM, Ryan Sleevi <[e-mail]> wrote:
> >
> >
> >
> > On Thu, Sep 4, 2014 at 4:02 PM, Trevor Perrin <[e-mail]> wrote:
> >>
> >> I agree with Eric and Joe that the current definition of PKP-RO is not
> >> that useful and potentially surprising to deployers.
> >>
> >> Ryan argues that storing PKP-RO is dangerous because a TLS MITM who
> >> could set pins for a lot of clients for a lot of sites could flood a
> >> victim with reports.
> >>
> >>
> >> Couldn't the MITM also set PKP pins with report-uri, or set cached
> >> redirects or other cached resources to generate traffic toward a
> >> victim?
> >
> >
> > Yes, and that's a user visible effect, rather than transparent.
>
> Hmm, there's nothing clever that can be done with cached javascript or
> html to also generate silent traffic toward a victim?
>
>
> > It also
> > requires that a connection be validated first, whereas the very
> definition
> > of PKP-RO is that you send it when a connection is not validated.
>
> I'd expect stored PKP-RO to follow the same rules as PKP and be stored
> only if it meets the bullet points in 2.5 (error-free TLS connection,
> backup pins, etc.).
>
> It would make sense for any report-uri header (PKP or PKP-RO) that
> fails the 2.5 checks, or has some other invalid syntax (eg bad
> base64), to *also* generate a different sort of report and not be
> stored.
>
> Would it be reasonable to add a reporting message for 2.5 failure or
> syntax failure?  Otherwise, when asserting a report-uri pin you can't
> distinguish pin-not-stored errors from
> pin-stored-and-validation-successful.
>
>
> >> Ryan argues PKP-RO is worse because it's "conceptually and practically
> >> silent to the user".  But once the browser has sent junk traffic to a
> >> victim, I don't really see how seeing how displaying a pinning error
> >> makes things better.
> >
> >
> > First, the attacker can only mount the hostile attack after having first
> > established a good connection.
>
> Debateable per above.
>
>
> > PKP-RO allows an attacker to perpetually
> > mount a hostile attack.
> > Second, the presence of a pinning error is an inherently rate-limiting
> > factor to the user experience. You're not going to be able to trigger 100
> > reports if you're causing the user 100 error pages.
>
> Rate-limiting is already proposed:
> """
> UAs SHOULD limit the rate at which they send reports.  For example,
>    it is unnecessary to send the same report to the same report-uri more
>    than once per distinct set of declared Pins.
> """
>
> Wouldn't that take care of it?
>
>
> > Third, it seems like you're arguing for removing report-uri altogether,
> > given the privacy and DoS risks identified. That is, the more that  you
> > establish RO is similar to PKP in level of what an attacker can do, the
> more
> > it argues for removing report-URI entirely.
>
> Dunno.  I'm still trying to understand these risks, whether they're
> really different for PKP-RO vs PKP, and for HPKP versus other web
> technologies.
>
> Trevor
>