[websec] User interactivity requirements

Ryan Sleevi <sleevi@google.com> Mon, 25 August 2014 06:09 UTC

Return-Path: <sleevi@google.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2E4B01A6FC0 for <websec@ietfa.amsl.com>; Sun, 24 Aug 2014 23:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xP3dq8mWe7U8 for <websec@ietfa.amsl.com>; Sun, 24 Aug 2014 23:09:36 -0700 (PDT)
Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7BB1A8A69 for <websec@ietf.org>; Sun, 24 Aug 2014 23:09:36 -0700 (PDT)
Received: by mail-vc0-f177.google.com with SMTP id hy4so14613269vcb.36 for <websec@ietf.org>; Sun, 24 Aug 2014 23:09:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SNm6zii+diEpimmNzAJB5KR4n6O/IdAkjDmxpBxmMi0=; b=In8ryNhIOIPHgQzeHC0sv+Ki75Sr4EJTauyRlpSHA35j7pSKk5uCxnFIVnP3uDiN8L U8/80BtZsq7E4cP7RwxNe9w1N5QK7jeNZfKruBj/XUeg5+NbWKVaPaw0PBtH90oFtf5j EFkLPHa/XR+FgVjoZ4hsLMgh5pwc5hWIKEs0WdoNZLZnXmvdd9e/k0jvJ4KroFkUdXHS 6Jztn9R9uNss9buabfaIxByYWoNCSg+SDqSzHlEKJ99stAbK/E5drcOpMmzo3UL6OJ/5 tuF8V3jngq7cJSO4h8cvzX6+psLuENBjDH744ma3mDxltatyZfMqKN3nQtLSfNvpFwSZ HlQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=SNm6zii+diEpimmNzAJB5KR4n6O/IdAkjDmxpBxmMi0=; b=lyYPzjNnFRJOaCsEbEM86Ri5VNtG1PxdJaKuHxmFSr99agnEhWTDX/Yl1R1PtuGdjM OKT886G/SAuGCrwELbnR4zgfI0SN13H2U3eAt8WZCJzUicfSLJuMORzN3KuufVxaB+zB FhSWRtOXmtQYf5yWm15lCNfWGuzeHfmbJkq16kHxPMd8ZZ9fP5LgOPY8pcHtT6jXTkma 0b/+oq5bvQFxVMRBbY3pqlwiJFqaC37MHBq8Qh6wXjosjoyL7n8Ijl67b8DwnmBx+dLH HiW00swkTNizNC6sIqe092r1Z38EYB74x3M/zBZA39W1IimRtR/qZlfJv3K8HKj1J5Sm jv3g==
X-Gm-Message-State: ALoCoQkSTJGqjfbdOHGTXY5ogNngOh2+tzIBuM6fkXbyehMuaa9FhVW652QGWT4RiUhDxIiIUPCo
MIME-Version: 1.0
X-Received: by with SMTP id o16mr3278555vdj.58.1408946975415; Sun, 24 Aug 2014 23:09:35 -0700 (PDT)
Received: by with HTTP; Sun, 24 Aug 2014 23:09:35 -0700 (PDT)
Date: Sun, 24 Aug 2014 23:09:35 -0700
Message-ID: <CACvaWvawc2YTi0RxEr7POdx2r8WQgwBG5b4h-N8Xd6pcd9EMdA@mail.gmail.com>
From: Ryan Sleevi <sleevi@google.com>
To: "<websec@ietf.org>" <websec@ietf.org>
Content-Type: multipart/alternative; boundary="20cf307c9f10fa3fde05016e0712"
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/27dwUQJk_SrQ1E4ZonEfCjwwLWo
X-Mailman-Approved-At: Mon, 25 Aug 2014 01:24:12 -0700
Subject: [websec] User interactivity requirements
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec/>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Aug 2014 06:09:38 -0000

>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

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)