Re: [websec] User interactivity requirements

[Yoav Nir <[e-mail]>]

On Aug 25, 2014, at 9:09 AM, Ryan Sleevi <[e-mail]> wrote:

> From someone who sent directly to the editors, and thus I've omitted their address/name on the assumption of privacy.
> 
> In section "2.6. Validating Pinned Connections" there is written:
>    When a UA connects to a Pinned Host, if the TLS connection has
>    errors, the UA MUST terminate the connection without allowing the
>    user to proceed anyway.  (This behavior is the same as that required
>    by [RFC6797].)
> I think that "(This behavior is the same as that required by [RFC6797].)" is misleading, because RFC6797 states that its section 12 (which contains "12.1. No User Recourse") is non-normative.
> http://tools.ietf.org/html/rfc6797#section-12
> 
> Indeed, this is an oversight, and one that's arguably in conceptual conflict with the paragraph that follows, which describes Pin Validation as a SHOULD.
> 
> That is, one can imagine that a TLS connection that is being actively MITM'd by a locally-installed trust anchor MAY induce other TLS errors. As the UA will not be performing pin validation, it's not clear that the UA should also be inheriting the requirement for non-procession.
> 
> That is, HSTS DOES have a normative requirement on termination (see http://tools.ietf.org/html/rfc6797#section-8.4 ), which HPKP should also have, but whether or not a user can proceed is non-normative and up to implementations (with a general recommendation that the user should not be permitted to proceed)

I don’t think they’re quite the same. 

HSTS does have to be enforced everywhere, because even if there’s a MitM with a locally-trusted anchor, it is going to give the client TLS, and not just any TLS, but TLS with a certificate that chains to a trusted anchor, which is all that HSTS requires.

HPKP requires the connection to have a specific public key. A MitM cannot use that public key. So if these are both enforced, a MitM connection will be OK for HSTS, but fail for HPKP.

So an implementation has no reason to have a “no HSTS enforced" mode, but it may have a reason to have a “no HPKP enforced” mode.  As long as you’re enforcing HPKP, it’s fine to require no user recourse. If you’re not enforcing HPKP, then of course you’re not going to terminate the connections.

I agree that there is a difference, that HSTS calls non-recourse non-normative, while we are making it a MUST requirement. I think that is fine, so in my opinion, we can either remove the parenthetical remark or just leave it as it is.

Yoav