Sorry to be second guessing you Chris, but wanted to ask about this change: https://code.google.com/p/key-pinning-draft/source/detail?r=5810662a42e56938272d9db4b2e5373914b266f4
Let's say an active attacker does MITM on a client. (That's the scenario you reference, right?) The client can have pins for the server or not. If the client does have pins, the active attack fails and generates a report event. The attacker knows the attack fails because a) perhaps they observe metadata about the report event being sent right away but more concretely b) because their attack fails. If the client doesn't have pins, the active attack succeeds. The attacker knows the attack succeeded and that the pinning wasn't effective because... it succeeded. Whether or not a report event is generated the attacker knows it succeeded. Furthermore, if an attacker is attacking the client and wants to learn if it supports pinning or not, it can look at the User Agent header, TLS handshake fingerprinting, or active javascript injection. If the attack succeeds, and the attack already knows about it succeeding, I don't understand the harm in generating a report event. Maybe the attack will block it (and know it was generated), but maybe they won't and it will get out. Maybe the report will be held for some time and sent later. -tom
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
