Re: [websec] User interactivity requirements

Ryan Sleevi <sleevi@google.com> Mon, 25 August 2014 09:00 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBCF1A89E8 for <websec@ietfa.amsl.com>; Mon, 25 Aug 2014 02:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJjF9iHCAqVt for <websec@ietfa.amsl.com>; Mon, 25 Aug 2014 02:00:29 -0700 (PDT)
Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED581A8A14 for <websec@ietf.org>; Mon, 25 Aug 2014 02:00:28 -0700 (PDT)
Received: by mail-vc0-f171.google.com with SMTP id hq11so14954107vcb.30 for <websec@ietf.org>; Mon, 25 Aug 2014 02:00:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B91M7WZzrDPSmpJsHl2wE2+t3qxJvTAxUfmXDFmr9og=; b=i6yACZk4HrekXODiqqmFiGQxT9bIfYI5OaDfIZttPPSw6OmtYoSKEduF5deEwyDDom lAdBLAWq2OkpQ7spPQdgghffTZK8iniXpUJP9tULlYO/qlmNNjH384gzUGigmAtM9sU5 dXSlC1/RKchIxZVCd1734bsQRUOMH+DIlLlPqzrl0/dV1qVk+dk5k8McF/rfGCWuYBD0 A0pJn3QvQ7TxjHWoz1aKktVlP4Gs4ZSVpdVdaF1MnfDL84A1nsu1ctdearJKpLcQIumD J6jxTD9JFpCkqTMiSaBNHbWamvk+0O+sWtklNTORTQADEJmud04e11wPC0n66dypN69Y wNZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=B91M7WZzrDPSmpJsHl2wE2+t3qxJvTAxUfmXDFmr9og=; b=XePQyiUlg1WQJA0A+JLLI8/3Dq+6R5KiQaFqq5oElF+ZC/u+qOEXtvt4nKUWsk+x9o GlHM3algiI/JvQzdzlBsioi58a1FZ8oGywUZcOgJ5dBpKt/1uhXIsKoP3SoVjPoRjpiO Btwmcq0cEw2isAqZZrBmSmZdOStr0g5h17vIV5TiTdfduHR05xb7xid+DiR5QO/WqP4a N2ynqHpw9s4HNQrwi3quFnnad3bkTemTIPx2NYYNo3xWRcTZgjtpox1gqJjg1GvqkxhT I66xMsmY3HyNvsVWCL3a2gQfOxTL3Mhr7yXgX21r/ghW2NlRqkKYGnP8+hpDtQZ4LNLi TXug==
X-Gm-Message-State: ALoCoQlaaPz+GZWV3QBKLUc3rBzODzq4z+nrfYGDkv+rYsWtiL/f6CYuza0Hv+BoVh9/lpt265fP
MIME-Version: 1.0
X-Received: by 10.220.30.8 with SMTP id s8mr4452112vcc.58.1408957227934; Mon, 25 Aug 2014 02:00:27 -0700 (PDT)
Received: by 10.52.119.178 with HTTP; Mon, 25 Aug 2014 02:00:27 -0700 (PDT)
Received: by 10.52.119.178 with HTTP; Mon, 25 Aug 2014 02:00:27 -0700 (PDT)
In-Reply-To: <E3421423-FA5A-42E2-BCB2-714FCD1D3573@gmail.com>
References: <CACvaWvawc2YTi0RxEr7POdx2r8WQgwBG5b4h-N8Xd6pcd9EMdA@mail.gmail.com> <E3421423-FA5A-42E2-BCB2-714FCD1D3573@gmail.com>
Date: Mon, 25 Aug 2014 02:00:27 -0700
Message-ID: <CACvaWvZDQzcSWWjC8VhCMFWvrDhEXDo2b4q4CXOiwg4Bww3=Ew@mail.gmail.com>
From: Ryan Sleevi <sleevi@google.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="001a11c2d0561343860501706b31"
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/NDfNyiIG0HDiItPtWVlfmcZxtBo
X-Mailman-Approved-At: Mon, 25 Aug 2014 02:18:47 -0700
Cc: "<websec@ietf.org>" <websec@ietf.org>
Subject: Re: [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 09:00:32 -0000

On Aug 25, 2014 1:52 AM, "Yoav Nir" <ynir.ietf@gmail.com> wrote:
>
>
> On Aug 25, 2014, at 9:09 AM, Ryan Sleevi <sleevi@google.com> 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
>
>

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.