Re: [websec] User interactivity requirements

Yoav Nir <> Mon, 25 August 2014 08:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E52A21A702C for <>; Mon, 25 Aug 2014 01:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4b13fs2tbWAy for <>; Mon, 25 Aug 2014 01:52:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D75121A86F4 for <>; Mon, 25 Aug 2014 01:52:29 -0700 (PDT)
Received: by with SMTP id z12so12685877wgg.0 for <>; Mon, 25 Aug 2014 01:52:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5M+C/OkssjqKg6gu/Yl6amLbJ9Drwy8XLRu7FOgopVc=; b=uPOC3oxl1H4L+NbVAlnMF1GZng5pRTi/eG7af111O4Ip20Ox55kB737md6dXLB0Gco 8qWAcZoli+C5qgRSjC3VT/T2fJknDxqVWej8eQc+5LC1WGEprZ/sWN/EoTpv9JmbLHIQ EMcS2zvAMiIRyqkroisL3PCCqK0Fe5VUdzFTOXRpjB18VXPqS3ZTNyG7RwILIWWo6N6O r6ML4yx6cP9/SSsq08G3Z1mHEuTWp+7/pn/61W8Z+FmOifoVKeQ35snsOMP+Au+6XEni J9UtP4pV2LEEcUgNu71UyMbXgFf80jQfgDffGl4w4wnbW+A67r0212MlYV+uU/0L7qU0 F3ww==
X-Received: by with SMTP id em4mr14001059wib.8.1408956748564; Mon, 25 Aug 2014 01:52:28 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id ck5sm68484170wjb.24.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Aug 2014 01:52:28 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_968DAD25-200F-43D1-93C2-6BE97616E43A"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Mon, 25 Aug 2014 11:52:24 +0300
Message-Id: <>
References: <>
To: Ryan Sleevi <>
X-Mailer: Apple Mail (2.1878.6)
Cc: "<>" <>
Subject: Re: [websec] User interactivity requirements
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Aug 2014 08:52:32 -0000

On Aug 25, 2014, at 9:09 AM, Ryan Sleevi <> 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.
> 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 ), 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.