Subject: [websec] User interactivity requirements

From: Ryan Sleevi <[email-masked]>
Date: Sun, 24 Aug 2014 23:09:35 -0700

>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)

---

From: Yoav Nir <[email-masked]>
Date: Mon, 25 Aug 2014 11:52:24 +0300

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

> From someone who sent directly to the editors, and thus I've omitted their address/name on the assumption of privacy.
> 
> 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.
> 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

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 25 Aug 2014 02:00:27 -0700

On Aug 25, 2014 1:52 AM, "Yoav Nir" <[email-masked]> wrote:
>> From someone who sent directly to the editors, and thus I've omitted
their address/name on the assumption of privacy.
>>> 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.
> 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

Yoav,

UAs today already have "no HSTS enforced" modes. While generally (and
intentionally) not documented, they do exist.

The nature of what is a TLS error here is a broad category, and may include
elements that are policy specific. Most importantly, however, I think it
does not make any sense that if you're talking to a known pinned host, but
for policy reasons disable enforcement of HPKP, that it would suggest a
normative MUST fail. That doesn't seem to jive with the language
recognizing policy exceptions exist.