Return-Path: <ynir.ietf@gmail.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 E52A21A702C
 for <websec@ietfa.amsl.com>; Mon, 25 Aug 2014 01:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
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 mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 4b13fs2tbWAy for <websec@ietfa.amsl.com>;
 Mon, 25 Aug 2014 01:52:30 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com
 [IPv6:2a00:1450:400c:c00::229])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id D75121A86F4
 for <websec@ietf.org>; Mon, 25 Aug 2014 01:52:29 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id z12so12685877wgg.0
 for <websec@ietf.org>; Mon, 25 Aug 2014 01:52:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.180.99.4 with SMTP id em4mr14001059wib.8.1408956748564;
 Mon, 25 Aug 2014 01:52:28 -0700 (PDT)
Received: from [172.24.248.61] (dyn32-131.checkpoint.com. [194.29.32.131])
 by mx.google.com with ESMTPSA id ck5sm68484170wjb.24.2014.08.25.01.52.27
 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 <ynir.ietf@gmail.com>
In-Reply-To: <CACvaWvawc2YTi0RxEr7POdx2r8WQgwBG5b4h-N8Xd6pcd9EMdA@mail.gmail.com>
Date: Mon, 25 Aug 2014 11:52:24 +0300
Message-Id: <E3421423-FA5A-42E2-BCB2-714FCD1D3573@gmail.com>
References: <CACvaWvawc2YTi0RxEr7POdx2r8WQgwBG5b4h-N8Xd6pcd9EMdA@mail.gmail.com>
To: Ryan Sleevi <sleevi@google.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/FPuQVhN4ji26dQfINbu4W0fRCQo
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 08:52:32 -0000


--Apple-Mail=_968DAD25-200F-43D1-93C2-6BE97616E43A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Aug 25, 2014, at 9:09 AM, Ryan Sleevi <sleevi@google.com> wrote:

> =46rom someone who sent directly to the editors, and thus I've omitted =
their address/name on the assumption of privacy.
>=20
> 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
>=20
> 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.
>=20
> 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.
>=20
> 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=92t think they=92re quite the same.=20

HSTS does have to be enforced everywhere, because even if there=92s 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 =93no HSTS enforced" mode, =
but it may have a reason to have a =93no HPKP enforced=94 mode.  As long =
as you=92re enforcing HPKP, it=92s fine to require no user recourse. If =
you=92re not enforcing HPKP, then of course you=92re 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



--Apple-Mail=_968DAD25-200F-43D1-93C2-6BE97616E43A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Aug 25, 2014, at 9:09 AM, Ryan =
Sleevi &lt;<a href=3D"mailto:sleevi@google.com">sleevi@google.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr"><div =
style=3D"font-family:arial,sans-serif;font-size:13px"><div>=46rom =
someone who sent directly to the editors, and thus I've omitted their =
address/name on the assumption of =
privacy.</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">
In section "2.6. Validating Pinned Connections" there is =
written:<br>&nbsp;&nbsp; When a UA connects to a Pinned Host, if the TLS =
connection has<br>&nbsp;&nbsp; errors, the UA MUST terminate the =
connection without allowing the<br>&nbsp;&nbsp; user to proceed =
anyway.&nbsp; (This behavior is the same as that required<br>
&nbsp;&nbsp; by [RFC6797].)<br>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.<br>
<a href=3D"http://tools.ietf.org/html/rfc6797#section-12" =
target=3D"_blank">http://tools.ietf.org/html/rfc6797#section-12</a></block=
quote><div><br></div>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.</div>
<div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div><div =
style=3D"font-family:arial,sans-serif;font-size:13px">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.</div>
<div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div><div =
style=3D"font-family:arial,sans-serif;font-size:13px">That is, HSTS DOES =
have a normative requirement on termination (see&nbsp;<a =
href=3D"http://tools.ietf.org/html/rfc6797#section-8.4">http://tools.ietf.=
org/html/rfc6797#section-8.4</a> ), 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)</div>
</div></blockquote><br></div><div>I don=92t think they=92re quite the =
same.&nbsp;</div><div><br></div><div>HSTS does have to be enforced =
everywhere, because even if there=92s 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.</div><div><br></div><div>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.</div><div><br></div><div>So an implementation =
has no reason to have a =93no HSTS enforced" mode, but it may have a =
reason to have a =93no HPKP enforced=94 mode. &nbsp;As long as you=92re =
enforcing HPKP, it=92s fine to require no user recourse. If you=92re not =
enforcing HPKP, then of course you=92re not going to terminate the =
connections.</div><div><br></div><div>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.</div><div><br></div><div>Yoav</div><div><br></div><br></body></html>=

--Apple-Mail=_968DAD25-200F-43D1-93C2-6BE97616E43A--