From nobody Thu May  1 01:34:43 2014
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 9B8731A6EFF for <websec@ietfa.amsl.com>; Thu,  1 May 2014 01:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, 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 wsPnoclp-FUG for <websec@ietfa.amsl.com>; Thu,  1 May 2014 01:34:39 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 57B201A6EFA for <websec@ietf.org>; Thu,  1 May 2014 01:34:39 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id bs8so290602wib.12 for <websec@ietf.org>; Thu, 01 May 2014 01:34:37 -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 :content-transfer-encoding:message-id:references:to; bh=CHXlmdi0bv1ngnKjNSh4ka5rsxS/ZTUcFByw7qAZv/o=; b=FDBhd9NEoxpUP4naQFDKP9HvnahT2rffbPaAVTwTBN4MOEBYUgDGQVkvKrpG1lIGX3 GAC/KaluqeVsf4echEQ/WW3l87Y9Gxwz/SrLcR4ntve2qs/IxdiofFVYUlO0ARglD4oj A9y3YCI80wTvlqmdFJkuHlj2WV4zYx/HrSAiQYg0dfM/JvxPYq6s/myphg12YhSyhJvT h6/WXpGyeWzjWSIcd4qpruXlLQTB6if5qP5/ESjXDcJ7iwB5g3zTVee4YCqOUUzJIKlk O+OCkGhBTF4N6iI7qLthnY3Mr9uiB1v3DIt2yQ8h3ecp1ulmKjnC3VYdgqF6uQvEajeM Hyww==
X-Received: by 10.180.91.1 with SMTP id ca1mr1254904wib.32.1398933276958; Thu, 01 May 2014 01:34:36 -0700 (PDT)
Received: from [172.24.249.242] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id fo10sm2273988wib.12.2014.05.01.01.34.36 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 May 2014 01:34:36 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CAGZ8ZG2Fmd694piWonBn-J40Wj_AVMk1Df0iYzSXpbtpt7Wutg@mail.gmail.com>
Date: Thu, 1 May 2014 11:34:33 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <2FB9B161-A4DB-4905-A9EC-CF05D72EE7A3@gmail.com>
References: <20140428231041.12685.8218.idtracker@ietfa.amsl.com> <35B52561-A6B3-43F9-9291-81D46444D3D2@gmail.com> <CAGZ8ZG2Fmd694piWonBn-J40Wj_AVMk1Df0iYzSXpbtpt7Wutg@mail.gmail.com>
To: Trevor Perrin <trevp@trevp.net>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/dKsPW-eiCHWAnair7DEp-zzbhH4
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] I-D Action: draft-ietf-websec-key-pinning-12.txt
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: Thu, 01 May 2014 08:34:41 -0000

On May 1, 2014, at 12:41 AM, Trevor Perrin <trevp@trevp.net> wrote:

> On Mon, Apr 28, 2014 at 11:24 PM, Yoav Nir <ynir.ietf@gmail.com> =
wrote:
>>=20
>> Having reviewed this, I think this version addresses all the issues =
raised during WGLC.
>=20
> The added sentence in 2.7 on preloaded/dynamic pins doesn't match the
> rest of the text, which is written to mandate specific behavior.  If
> we're not going to discuss implementation alternatives, we should just
> delete most of 2.7 and let implementations do what they want.

Why? All the new sentence says is =93The Effective Pin Date of built-in =
pin lists is UA implementation-defined=94. Implementations are still =
required to treat the pre-loaded pins as though they have some effective =
date and determine precedence by whichever has a later date.  Suppose =
Chrome will have a pin list that is downloaded from Google every hour. =
What date is assigned to the pins in that list could be part of the =
format, or it could be assumed to be a week old, depending on how Google =
updates this file.

> The text in 2.3.2 on PKP-RO doesn't really match the rest of the doc.
> Most of the draft is written as if there is a single header, set of
> Pinning Metadata, and "Known Pinned Host" state.  But 2.3.2 doubles
> those things, which causes many minor ambiguities, e.g.:
>=20
> * 2.2.1 - "a Pinned Host SHOULD include in its response exactly one
> PKP header field"
>=20
> * 2.3.1 - "the UA MUST process only the first such header field"
>=20
> * 2.5 - Does a failed validation of a "report-only" pin count as an
> "error" that will inhibit noting of new pins in the connection? (or
> new "report-only" pins)?
>=20
> * 2.6 mandates "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".  It's unclear whether a "report-only"
> pin counts as a "Pinned Host" for the purpose of other TLS errors.
>=20
> The draft could use an editing/cleanup pass to clarify all this.
>=20
> Also, some of the issues I've been bringing up since July need to be =
addressed:
>=20
> * Interaction with cookies needs discussion, at least in security
> considerations.  Cookie scoping rules pose a serious problem for
> pinning, e.g. a pin at "example.com" could be undermined by a MITM
> inventing a "badguy.example.com" and using it to steal or force
> cookies.

While there are similar concerns, I don=92t see the interaction. If you =
are example.com, and badguy controls badguy.example.com, then they=92re =
going to get your example.com cookies unless you can block it with =
scoping.  HPKP doesn=92t help you there. You *can* block them with HPKP =
if their control on badguy.example.com relies on a mis-issued =
certificate and you restrict them with the includeSubdomains directive.

>=20
> * "Pinning Policy" and "Pinning Metadata" are synonyms?
> * 2.3.1 ... "or," ... "Otherwise" is confusing
> * 2.6 - is pin validation performed on resumed TLS connections?
> * 3 - can UAs provide additional JSON fields inside the report?
> * The term "validated certificate chain" is not defined
> * An IANA registry is needed for directives
> * The acknowledgement for "pin break codes" is ancient/irrelevant
>=20
>=20
> Trevor


From nobody Thu May  1 07:17:36 2014
Return-Path: <dkg@fifthhorseman.net>
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 D8DDC1A08DA for <websec@ietfa.amsl.com>; Thu,  1 May 2014 07:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 JxBklP8ysbYU for <websec@ietfa.amsl.com>; Thu,  1 May 2014 07:17:34 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id EFE611A08D4 for <websec@ietf.org>; Thu,  1 May 2014 07:17:33 -0700 (PDT)
Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 27750F984; Thu,  1 May 2014 10:17:31 -0400 (EDT)
Message-ID: <53625771.4050406@fifthhorseman.net>
Date: Thu, 01 May 2014 10:17:21 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0
MIME-Version: 1.0
To: Chris Palmer <palmer@google.com>
References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com>	<64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com>	<BLU0-SMTP1579CD1B2BD2455B6C4247EB1920@phx.gbl>	<CAOuvq22VH_MS8rA146zvBsXTejsqPASEJOXrnZzki0rvQ35c-w@mail.gmail.com>	<EFC44ED0-1679-4565-ACF0-3AD9849499D2@checkpoint.com>	<5307BDFD.7060009@gondrom.org>	<5308F126.7020308@fifthhorseman.net>	<CAOuvq22w3n_g2crOLkeDVTPKCFBXWrdMdt6UY1HRx-Js0tTOxQ@mail.gmail.com>	<5344CE2D.6050701@fifthhorseman.net> <CAOuvq23z0X6gRDnmn98waLExGvSGkoK5Kub6=zZ1TEYnLc6MJA@mail.gmail.com>
In-Reply-To: <CAOuvq23z0X6gRDnmn98waLExGvSGkoK5Kub6=zZ1TEYnLc6MJA@mail.gmail.com>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WoCkVCjdPRFNcJikq5FWi64nAx8Sr0BjJ"
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/YxJvdINciajOnOML6sg6yqk6jJk
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10
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: Thu, 01 May 2014 14:17:36 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--WoCkVCjdPRFNcJikq5FWi64nAx8Sr0BjJ
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 04/28/2014 07:04 PM, Chris Palmer wrote:
> Well, it's hard to draft text that reads well. There are a lot of hypot=
heticals:
>=20
> * A new version of this spec has been published that specifies BetterHa=
sh.
>=20
> * Separately, SHA256 becomes deemed unsafe.
>=20
> * Some site operators would rather be un-pinned than to pin with a
> hash function that is vulnerable to a preimage attack of complexity
> (pretend with me) 2**80.
>=20
> * Some UA that is fancy enough to support HPKP, but not fancy enough
> to also support BetterHash, exists in the wild for long enough that
> site operators actually face that weird choice.
>=20
> Honestly, I'd rather deal with this question in the future version of
> the spec that actually specifies the use of a second hash function. I
> am not real excited :) to specify how the UA should behave if a
> situation arises that the spec currently doesn't even allow for.

By that point, it's too late; there *will* be deployed key-pinning
clients that aren't updated from the initial deployment, if present
experience is any indication; if we don't suggest now what behavior we
expect in this case, then people who upgrade servers will face a range
of implementation choices in the clients that interact with them.

I think the changes to section 2.1 in draft -12 look like they cover
this.  Thanks for making them :)

>> if we treat the sha256 pin as identical to the sha3 pin, that we've ju=
st
>> reduced the strength of the pin to the weakest algorithm.  or am i
>> misunderstanding what you mean by "identical"?
>=20
> No, that is what I mean. It is true that there will be a window of
> vulnerability =E2=80=94 we can't just say, "Starting next Tuesday, you'=
re not
> pinned unless you're using SHA-3." There has to be a period of
> deprecation before we get rid of a thing completely.

yes, of course.

> Hopefully, when
> somebody publishes a research paper showing an improved attack on
> SHA-256 =E2=80=94 say, preimage at a cost of 2**128 (yikes!) =E2=80=94 =
we should
> immediately begin the deprecation process in anticipation of the
> attack improving to 2**80 soon. Conscientious site operators will
> observe the new spec, and update their headers, and will be ready for
> the time a year later when we say "...UAs MUST NOT honor SHA-256...".

But in the meantime, clients which have already implemented SHA-3 (or
whatever) should be able to be protected against breaks in SHA-256, no?

It takes us a long long while to get around to deprecating things that
we know are broken.  If both peers in a negotiation *can* handle
stronger mechanisms, they shouldn't have to wait for an official
deprecation of the weaker mechanism in order to get the benefit of the
stronger mechanism.

> Honestly, that is good enough for me. Of all the problems with web
> PKI, the hypothetical future weakness of SHA-256 in a feature that
> already greatly reduces the potential for mis-issuance just doesn't
> rate. We're talking about, after years of unprecedentedly awesome
> research by brilliant cryptanalysts, an attacker who can (a) get a
> mis-issued certificate; (b) can do the 2**80 work to get their cert to
> match the good pin; and (c) even after all that can only attack (d)
> sites using that key that didn't start pinning with SHA-3 yet.

No, my point is that if we don't make it clear that *all published
digests supported by the client must match*, then at least (c) isn't
necessary for the attacker.

I think this is not fixed in -12 yet.

I agree that we're talking about pretty intense hypotheticals here, but
i see no reason that we shouldn't specify the right thing in this draft
while we have the chance to provide this guidance.

> I owe you a beer (or your flavorite beverage) anyway, and if that ever
> happens, I'll get you a second one. :)

:)

	--dkg

PS orthographic nitpick: in -12, you've got "interpretting" where i
think you mean "interpreting"

PPS your link to [pin-break-codes] appears to be 404:
              Perrin, T., "Self-Asserted Key Pinning", September 2011,
              <http://trevp.net/SAKP/>.


--WoCkVCjdPRFNcJikq5FWi64nAx8Sr0BjJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQJ8BAEBCgBmBQJTYldxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpckZsP/1DTcm45Vxcv0hPHN+2RG1Ky
9oCaL16L8spvuw+bioiy4pulDgKnkwqWVPMBCfX275OSH6alN2wX21+44qRUH8Ve
jUvSMAlGwjjfSfVuQ+b/DnRiV3SJJQhnjvP5QLIE1+5LgMg1krNW0VIXeiIK760V
vVXvHN3/XGEj9bkcCGEqEcdJ3GV0GDjZa77N7c593UZPwCDkRvVG9VGCb0jw7BSV
3bnhlsueFjNgiKVis2nIdmyiMS4X1Cns8JsFnxhnT+8h4MqKuEypAiLFnHqAqZzr
pe2vZpIJXMysazGfxJNkQrkMCh7LK/0UA7yBt+s5ow1ft6CmMXDdmIQ8M8CXaIqp
eOGsQNErZx5n/no6GajvpBRJ64ATxAnHT/mdNTo1WmR5hy1CsJJp2WQQOfWH7Khl
gzF/JA4IUxQhv+Aw2v+VeEIc8ggAepQ2K7eppJ39e6m6Ua7JgwADjvwvyiQzCiRM
kRmdlp2rR2M7wVGKHNsJRCmxHPpNtGFsipShns1e1AuQmspIdSzAdtnZQ42Mermj
vczRPP3QgI3+Oeg8j70nl4Ih0BBlRrcanB8B61vh2s0ogmtNSDTgUI5MfujhCQZi
zTE3XS6vXs7OEvdLwIXtvwGmhF9IOPi2dAjuXaqXTSKZl0c2qH5XQzXNXbPxU6CT
gL1p9CFXb+jLqkYrGRxH
=iyfZ
-----END PGP SIGNATURE-----

--WoCkVCjdPRFNcJikq5FWi64nAx8Sr0BjJ--


From nobody Thu May  1 16:56:04 2014
Return-Path: <trevp@trevp.net>
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 314281A0958 for <websec@ietfa.amsl.com>; Thu,  1 May 2014 16:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 9Bk_cxvPCDzQ for <websec@ietfa.amsl.com>; Thu,  1 May 2014 16:56:02 -0700 (PDT)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id 18D731A066A for <websec@ietf.org>; Thu,  1 May 2014 16:56:01 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id cc10so1553403wib.4 for <websec@ietf.org>; Thu, 01 May 2014 16:55:59 -0700 (PDT)
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 :content-transfer-encoding; bh=mBKAK0R07DZ31PTrv004H/vJWG7oZxWQcXUvl89mpSI=; b=IadV0HjfDAt/nzVlqOJA8z91B4jEw9SsPWzkATZYUsAxNyghojq1ojYT8x+I8yaEOj 0/7F19Q1hV93Ts5HTpBe11YSramoyo49MfsHIYV8E9riBKXy3KxyApgL0dGZI0UmclmJ Qa0ZvDA6rhi4IXiwbvZfX/3kr+EvZ3lbDJwRLG21BXjwIzaOi7HugaOBQHSWQuZZv9EH NOxG5CVOdMwMd6zem1psl6J9wPL8YcOwjzIyI/QcqUTecZgGDGo/QZ+QazSRQnKtgAyM bmx7TACyjkwfHkKwnatoehjef1ag+pAfJUtdvlL72BTImvw9gJXzsp7cYpjvaq802bph nsZw==
X-Gm-Message-State: ALoCoQmV0qDLkpHBfG7LmZgF1VO5ebju4TjjjEOXJtDmV8IvQQz7E1/dti/IQSqaqYPYOmnCuu9u
MIME-Version: 1.0
X-Received: by 10.180.218.35 with SMTP id pd3mr328154wic.26.1398988559592; Thu, 01 May 2014 16:55:59 -0700 (PDT)
Received: by 10.216.155.7 with HTTP; Thu, 1 May 2014 16:55:59 -0700 (PDT)
X-Originating-IP: [50.204.254.254]
In-Reply-To: <2FB9B161-A4DB-4905-A9EC-CF05D72EE7A3@gmail.com>
References: <20140428231041.12685.8218.idtracker@ietfa.amsl.com> <35B52561-A6B3-43F9-9291-81D46444D3D2@gmail.com> <CAGZ8ZG2Fmd694piWonBn-J40Wj_AVMk1Df0iYzSXpbtpt7Wutg@mail.gmail.com> <2FB9B161-A4DB-4905-A9EC-CF05D72EE7A3@gmail.com>
Date: Thu, 1 May 2014 16:55:59 -0700
Message-ID: <CAGZ8ZG3sDu=T3HC9JDdpjJhCLzB3ctgOU52bBpULoxEx_LTWug@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/rvs5GPG5hWA1dYxAxB3I_vwXwPw
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] I-D Action: draft-ietf-websec-key-pinning-12.txt
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: Thu, 01 May 2014 23:56:04 -0000

On Thu, May 1, 2014 at 1:34 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>
> On May 1, 2014, at 12:41 AM, Trevor Perrin <trevp@trevp.net> wrote:
>
>> On Mon, Apr 28, 2014 at 11:24 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>>>
>>> Having reviewed this, I think this version addresses all the issues rai=
sed during WGLC.
>>
>> The added sentence in 2.7 on preloaded/dynamic pins doesn't match the
>> rest of the text, which is written to mandate specific behavior.  If
>> we're not going to discuss implementation alternatives, we should just
>> delete most of 2.7 and let implementations do what they want.
>
> Why? All the new sentence says is =E2=80=9CThe Effective Pin Date of buil=
t-in pin lists is UA implementation-defined=E2=80=9D. Implementations are s=
till required to treat the pre-loaded pins as though they have some effecti=
ve date and determine precedence by whichever has a later date.

That's a bad requirement, as it forces implementations to track the
Effective Pin Date for dynamic pins (the Effective Expiration Date is
not sufficient).

Also, we talked about and I thought agreed to allow implementations
freedom to decide how to handle preloaded/dynamic pin co-existence, as
long as they don't apply a pin that was never asserted.  For example,
I described a reasonable implementation which this text would
disallow:

http://www.ietf.org/mail-archive/web/websec/current/msg02016.html

I thought we had agreement to allow things like that:

Yoav:
"Yet a fourth way is to observer that none of this affects
interoperability in any way and leave it up to the UA vendor to choose
their way. The web site operator should only include valid pins in
their HPKP headers, and they should also enter only valid pins in
pre-loaded lists. They should also deal with the fact that don't
control usage patterns, so anytime they pin something for X seconds,
their website MUST conform to that pin for at least those X seconds or
bad things will happen."
http://www.ietf.org/mail-archive/web/websec/current/msg02019.html

Trevor:
"Your "fourth way" is well-put, and I agree - all of these seem valid
implementations which should be allowed."
http://www.ietf.org/mail-archive/web/websec/current/msg02020.html

Chris Palmer:
"I have been thinking that this 4th way is the way to go."
http://www.ietf.org/mail-archive/web/websec/current/msg02022.html

Dan Veditz:
"The pre-load list seems outside the mechanism covered by the spec. At
best the spec could mention it in a non-normative section as something
UAs can do to cover the first-visit gap, but there are several valid
ways such a list could be implemented."
http://www.ietf.org/mail-archive/web/websec/current/msg02028.html


You suggested a text modification which you maybe thought implemented
that, and which Tom, Tobias, and Chris seconded:
"Does anyone (and that includes the authors) object to relaxing the
requirements in section 2.7, so that the choice of when the static
pins are believed to have been observed is left to the implementer?
If not, we'll resolve it that way."
http://www.ietf.org/mail-archive/web/websec/current/msg02021.html

But that doesn't satisfy what I think people wanted, so I think we
should strip down 2.7 to something like your text above on the "fourth
way".


>> * Interaction with cookies needs discussion, at least in security
>> considerations.  Cookie scoping rules pose a serious problem for
>> pinning, e.g. a pin at "example.com" could be undermined by a MITM
>> inventing a "badguy.example.com" and using it to steal or force
>> cookies.
>
> While there are similar concerns, I don=E2=80=99t see the interaction. If=
 you are example.com, and badguy controls badguy.example.com, then they=E2=
=80=99re going to get your example.com cookies unless you can block it with=
 scoping.  HPKP doesn=E2=80=99t help you there. You *can* block them with H=
PKP if their control on badguy.example.com relies on a mis-issued certifica=
te and you restrict them with the includeSubdomains directive.

The interaction is that the security you were hoping HPKP would give
you for example.com will be largely ineffective if a badguy can forge
a cert for badguy.example.com and you don't defend this with either
(a) includeSubdomains or (b) cookie-scoping to the domain (which
doesn't work on IE).

So this is a security consideration deployers of pinning need to be aware o=
f.

Anyways, below is the text from TACK's security consideration which
isn't perfect, but something like this should be added:

   HTTP cookies [RFC6265] set by a pinned host can be stolen by a
   network attacker who can forge web and DNS responses so as to cause a
   client to send the cookies to a phony subdomain of the pinned host.
   To prevent this, TACK HTTPS servers SHOULD set the "secure" attribute
   and omit the "domain" attribute on all security-sensitive cookies,
   such as session cookies.  These settings tell the browser that the
   cookie should only be presented back to the originating host (not its
   subdomains), and should only be sent over HTTPS (not HTTP) [RFC6265].


Trevor


From nobody Tue May 13 13:25:57 2014
Return-Path: <palmer@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 930201A0204 for <websec@ietfa.amsl.com>; Tue, 13 May 2014 13:25:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level: 
X-Spam-Status: No, score=-2.03 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, RP_MATCHES_RCVD=-0.651, 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 FjlpRLl85iln for <websec@ietfa.amsl.com>; Tue, 13 May 2014 13:25:49 -0700 (PDT)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id BBE691A01DC for <websec@ietf.org>; Tue, 13 May 2014 13:25:48 -0700 (PDT)
Received: by mail-ig0-f176.google.com with SMTP id hl10so5687215igb.3 for <websec@ietf.org>; Tue, 13 May 2014 13:25:42 -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=vhczT9ngL6T6PyaKmPuYjqRwIyrwDH7w/k/hLOZ+BO0=; b=WNw64OIZqx4AI/a++xs7c7i4D0iTvz38wHiEcmTceadCZYnZMsxJEHMnLDLfcRxzsb hWEB5XKb0Q5fDc1KB3Ocq7UMU1VbIcLto5sCNN5KzuwCUCkRQ4lX221pQw33EL7rUyBu A8q8ieclTQQjMl1BPMAJ6ss+Bi0yaRg0Hxd7ANlSWnuK2Nm4ssxr5Pr8Ybam8uGBlNyk wh2OpK5Q1FeR+ivB9hPZkfJVrlLfR8lfdsO2aq5zJwt8PZG45WyikJ/NbGDelBOxhC3B gWXPjfPJRTMCV6PE960lPEtpFp6t2LWZTBlrm+i6RLBXPUWgu2Ps3Phbhh6O7sfLsQP/ 0ahQ==
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=vhczT9ngL6T6PyaKmPuYjqRwIyrwDH7w/k/hLOZ+BO0=; b=bZ0IZ+J7lwaG8+sHHD+emrc8PxSpbtnXPps/pSH2QJOCFwCYDRPJ+vrCzlYzIvSbHZ 1pGIieXLosaZftDZVbdl8ww9gXsNJkYNTKkNHhN0lONt7zSP2+UD6Vlchnxlpg8EMikI JzHJGXSw3Zx+2RYhO8DlAEBOXFZv/aUNwVBKRsfQsHhgue9m7HBRjhxiZ3A87VpG8fPG awHJyl97/f+d1slIqyqhjaylA45pZfiYLiljknU8sYMSwjkieDj1idZ47V/9XNeKHUk1 T0TpZzdknVBFR9jMbqbPOGOPj0bpiMZ9BlNveP2LtVzuymDlTa39D295BXYuqa5BL9AR he/g==
X-Gm-Message-State: ALoCoQkH8QtynBRer0Wxu066guCXx2PfW0ZsyUisYQMAhS5eCg19ra1ce8IgA4m1rpqobZC+Ci5C
MIME-Version: 1.0
X-Received: by 10.50.83.6 with SMTP id m6mr115236igy.30.1400012742304; Tue, 13 May 2014 13:25:42 -0700 (PDT)
Received: by 10.64.165.2 with HTTP; Tue, 13 May 2014 13:25:42 -0700 (PDT)
In-Reply-To: <CA+cU71mno6gnrUeP2Zh+xP5ku5n4NPrNEApsGQaat-cccsN3kA@mail.gmail.com>
References: <CA+cU71m+MR9NkskHcpujzLS4tDGypuEUP10JPkNF0u7oJPFdCw@mail.gmail.com> <CAOuvq20G6E9YKN4ksm1XQczB4kXbZ9FPyqQ_SHpcBFkRVwv0LQ@mail.gmail.com> <CA+cU71mno6gnrUeP2Zh+xP5ku5n4NPrNEApsGQaat-cccsN3kA@mail.gmail.com>
Date: Tue, 13 May 2014 13:25:42 -0700
Message-ID: <CAOuvq21g-isvf0dq4vhZUR86AfQZ8kLFXxW0mQG2MpKmXVy8vA@mail.gmail.com>
From: Chris Palmer <palmer@google.com>
To: Tom Ritter <tom@ritter.vg>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/z35s-k6hTZvohlexZLdQq80MgtA
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] First Connection Active Attack in HPKP
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: Tue, 13 May 2014 20:25:53 -0000

On Tue, Apr 29, 2014 at 4:28 AM, Tom Ritter <tom@ritter.vg> wrote:

>> I see your point... is the attack so marginal that it doesn't matter
>> either way? I'm not sure I feel strongly any more on this topic.
>
> I would call the difference marginal only if the we never envision the
> report having anything done with it except immediate sending.  If it's
> stored for later, logged, a browser extension collects them all and
> sends them out through Tor or some other mechanism... then I would say
> it's not marginal.  And since those are possibilities, I would say it
> would be better to remove the paragraph and not have different
> behavior. It would also probably make the code simpler, too.

OK, reverted the dubious paragraph.

https://code.google.com/p/key-pinning-draft/source/detail?r=25d5bae1373def833a0d1091654ae5e712d32d40


From nobody Tue May 13 13:38:18 2014
Return-Path: <palmer@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 3732C1A01FB for <websec@ietfa.amsl.com>; Tue, 13 May 2014 13:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level: 
X-Spam-Status: No, score=-2.03 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, RP_MATCHES_RCVD=-0.651, 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 bL_4TLhlqx67 for <websec@ietfa.amsl.com>; Tue, 13 May 2014 13:38:11 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D24FE1A01E6 for <websec@ietf.org>; Tue, 13 May 2014 13:38:11 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id y20so920374ier.34 for <websec@ietf.org>; Tue, 13 May 2014 13:38:05 -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:content-transfer-encoding; bh=Xqtp+nmsfZRVOYzRd07f7ZdstTTvb5r+dU5hHRBugn4=; b=JEc52Kfa8mDD8O8Wp9YrOYqPRScAETxddmr9BNg5yh8NDH1pp7fDgduPDEmgp7ec/5 yhyd1U+G9w2N4wI8zMOLirD1OZxfqNS0ijCk0keybRr2tI1kIB+KHO6dGM2TU8LonTFq GTbzB6Pa6HhUwV5Vov/AAM1vNT++Obh8RCGefhnyzH4DMv72WgYUoan/PmVvo13CkvN/ Koc5ARZ4e3/hMV2mrwVb5wfD1vKJujXdAp6r8zr05TPfcnJ9WctkAg0V36FxZ2YDCLUg JjYNGKj0OjGMQLPaZntK1HmkJkselE2vPz8vkxVl+1dhHCiyih3pF4zbjGA7yNWQb9Zr k4yA==
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 :content-transfer-encoding; bh=Xqtp+nmsfZRVOYzRd07f7ZdstTTvb5r+dU5hHRBugn4=; b=h5NjTeVDASPlAMuQu3MflgLpfraFHTQWVhGw9qga5DeQG1Pe+AgOkkiitP4fx59fjL NEKvX1ABsJgkoVFimMA0t+mliv8dpfc98MnFt7PuN5cDX+kbUcAApD7YHavPT4KZlxlL cqNNjTJlAgOucp4y0MiaW+wIGm7RlkX7EkYz20u8P+TU3Us9vTUICz5HxyHjTNajZNfd hRO133zQLGuQflBJKnTP3BiI/1YSiR/U0n05IZ5zB5hPlm4Xcj3TbCQMcKEZ0v7YmjlY tRBALp4mc+rM+nqrWh38RUHzP5PmABn3KxYLlQG3nEXDqgRlWJHDFUZCIotBZTEREYQV s/8g==
X-Gm-Message-State: ALoCoQkouj1Zfw99MlHs6HQgb00viloY92ryoY0Oigo8lwGV+I9EXa7zb3LexPOAEu4NcPl1iCJR
MIME-Version: 1.0
X-Received: by 10.50.22.37 with SMTP id a5mr60723627igf.30.1400013485332; Tue, 13 May 2014 13:38:05 -0700 (PDT)
Received: by 10.64.165.2 with HTTP; Tue, 13 May 2014 13:38:05 -0700 (PDT)
In-Reply-To: <53625771.4050406@fifthhorseman.net>
References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> <BLU0-SMTP1579CD1B2BD2455B6C4247EB1920@phx.gbl> <CAOuvq22VH_MS8rA146zvBsXTejsqPASEJOXrnZzki0rvQ35c-w@mail.gmail.com> <EFC44ED0-1679-4565-ACF0-3AD9849499D2@checkpoint.com> <5307BDFD.7060009@gondrom.org> <5308F126.7020308@fifthhorseman.net> <CAOuvq22w3n_g2crOLkeDVTPKCFBXWrdMdt6UY1HRx-Js0tTOxQ@mail.gmail.com> <5344CE2D.6050701@fifthhorseman.net> <CAOuvq23z0X6gRDnmn98waLExGvSGkoK5Kub6=zZ1TEYnLc6MJA@mail.gmail.com> <53625771.4050406@fifthhorseman.net>
Date: Tue, 13 May 2014 13:38:05 -0700
Message-ID: <CAOuvq22ESVJmqCVR5FZXYf2MfUaoM=LsTTj-+yiiZdXynRL-=g@mail.gmail.com>
From: Chris Palmer <palmer@google.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/owt95njL1XUCpkp-hWWq-uiiq1g
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10
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: Tue, 13 May 2014 20:38:14 -0000

On Thu, May 1, 2014 at 7:17 AM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:

>> Hopefully, when
>> somebody publishes a research paper showing an improved attack on
>> SHA-256 =E2=80=94 say, preimage at a cost of 2**128 (yikes!) =E2=80=94 w=
e should
>> immediately begin the deprecation process in anticipation of the
>> attack improving to 2**80 soon. Conscientious site operators will
>> observe the new spec, and update their headers, and will be ready for
>> the time a year later when we say "...UAs MUST NOT honor SHA-256...".
>
> But in the meantime, clients which have already implemented SHA-3 (or
> whatever) should be able to be protected against breaks in SHA-256, no?

2**128 is so expensive, and would be such an incredible improvement
over the current cost of second-preimage attack (2**256) that frankly
I'm willing to take the risk to keep the I-D from getting any more
complicated. Second-preimage attack against SHA-256 is so much not our
biggest problem right now =E2=80=94 many other things are much more likely =
to
go wrong.

> It takes us a long long while to get around to deprecating things that
> we know are broken.  If both peers in a negotiation *can* handle
> stronger mechanisms, they shouldn't have to wait for an official
> deprecation of the weaker mechanism in order to get the benefit of the
> stronger mechanism.

First, we have to get any peers at all using HPKP. And we've been
sluggish long enough (blame me first and foremost, of course).

> I agree that we're talking about pretty intense hypotheticals here, but
> i see no reason that we shouldn't specify the right thing in this draft
> while we have the chance to provide this guidance.

I'm a Worse Is Better believer, rather than a Right Thingist;
especially when as far as anyone publicly knows, SHA-256 is very
strong against second-preimage. We already moved to get rid of SHA-1
as a concession to the Right Thing (and, code simplification).

> PS orthographic nitpick: in -12, you've got "interpretting" where i
> think you mean "interpreting"

Fixed, thanks.

> PPS your link to [pin-break-codes] appears to be 404:
>               Perrin, T., "Self-Asserted Key Pinning", September 2011,
>               <http://trevp.net/SAKP/>.

Oh yes, I believe Trevor mentioned this too. Got rid of it.

https://code.google.com/p/key-pinning-draft/source/detail?r=3D9c118381b2b6e=
49384f2ea22e13247ea1c992fb9


From nobody Tue May 13 14:09:46 2014
Return-Path: <palmer@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 D990C1A01B6 for <websec@ietfa.amsl.com>; Tue, 13 May 2014 14:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level: 
X-Spam-Status: No, score=-2.03 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, RP_MATCHES_RCVD=-0.651, 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 Wts4pJDDX7-q for <websec@ietfa.amsl.com>; Tue, 13 May 2014 14:09:41 -0700 (PDT)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 81BDE1A019C for <websec@ietf.org>; Tue, 13 May 2014 14:09:41 -0700 (PDT)
Received: by mail-ie0-f181.google.com with SMTP id rl12so898637iec.26 for <websec@ietf.org>; Tue, 13 May 2014 14:09:35 -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:content-transfer-encoding; bh=JDIYpps0q0Ez6l99zNyuMb+yQM0C59l6JuZefcz9MZM=; b=h+jjGCvJWZST+Yri5ox5e+cxe6cckBts+H6A/7tBSsQU1nNCbBE1BtoYP0vfEz8PEX TKYjyVdizHYhky+XO8AKJvCRf3Ux6IbZueDbxY/ZSuoki5NGbyWWiHe65PgOoxKplyFr /3wcCTezDyVeLVkmmCU9VA2tpOBUJtuw6VSdaR8T4s9kN6/aY3HhMpTLyL2iMx7E9Vhi JTBd2iRc2tuGSKiiv2DGAZLGmO11ZRtkiK4Zg4SrmUg1SBpG5G7LD9cfjyDysPVO8pNd 0EzkzlpvExnJjroP+fMkXOn8Dj3D7DsUQxPPsjQly6Ov38WN+nG8ZwYVkUfpuJQ1Q8E8 h9XA==
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 :content-transfer-encoding; bh=JDIYpps0q0Ez6l99zNyuMb+yQM0C59l6JuZefcz9MZM=; b=AdAK4qHhfF6DqAEoqs3RHhre57RrqJvENGedAL44ooZ/LQJcsiqElH1QtE/X15lySp KwZ8Z9urXkVxyfcdAxPr2t0lvCGKwF5ggu/IBhsAJhrCXCmdJbVuhXuMm5RvByDbS9NR 5Wq0Z1e8Gar2wp9sKIIuL4puvjYA6gxXAuRaTfVSMZlmrABgGIR/C05MNHvfbGDMUMQ8 y2phsKbWa7ONYdMqKQ2NzSHW3Ub8fDgLl+XzdNkns88A6k9MdyE5aPdZCs9Tbd7VaTnj 21ZuAYmVArvEXmhGqPvKPTjAHKMgzAXwuSxvFjo3II5r1CY4+eqtcdUqUbR/4JNcNPi0 rk8A==
X-Gm-Message-State: ALoCoQmnFJTigeZEIV2e0ydkiigGnygYhV2foVcQzoWnkaXM4qTPIgEm3zYzjvJ1GbpMCCbKjBkW
MIME-Version: 1.0
X-Received: by 10.50.23.52 with SMTP id j20mr242417igf.13.1400015374936; Tue, 13 May 2014 14:09:34 -0700 (PDT)
Received: by 10.64.165.2 with HTTP; Tue, 13 May 2014 14:09:34 -0700 (PDT)
In-Reply-To: <CAGZ8ZG3sDu=T3HC9JDdpjJhCLzB3ctgOU52bBpULoxEx_LTWug@mail.gmail.com>
References: <20140428231041.12685.8218.idtracker@ietfa.amsl.com> <35B52561-A6B3-43F9-9291-81D46444D3D2@gmail.com> <CAGZ8ZG2Fmd694piWonBn-J40Wj_AVMk1Df0iYzSXpbtpt7Wutg@mail.gmail.com> <2FB9B161-A4DB-4905-A9EC-CF05D72EE7A3@gmail.com> <CAGZ8ZG3sDu=T3HC9JDdpjJhCLzB3ctgOU52bBpULoxEx_LTWug@mail.gmail.com>
Date: Tue, 13 May 2014 14:09:34 -0700
Message-ID: <CAOuvq20Br0_8=uaWbZK+hvC=dGcbVAzXo3WL9oFbnFr0rRhuUg@mail.gmail.com>
From: Chris Palmer <palmer@google.com>
To: Trevor Perrin <trevp@trevp.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/RIPQPSl0qFqs6Qwo_s62hd4GZqg
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] I-D Action: draft-ietf-websec-key-pinning-12.txt
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: Tue, 13 May 2014 21:09:45 -0000

For your consideration:

PKP vs. PKP-RO:
https://code.google.com/p/key-pinning-draft/source/detail?r=3D994a00dc31bf2=
cca6f3edea29871a6a4f18090f9

Interactions with built-in pins:
https://code.google.com/p/key-pinning-draft/source/detail?r=3Dbbf42b1e5e9b4=
9a8cdf193f9c7fe230d0d290543

Cookie security considerations:
https://code.google.com/p/key-pinning-draft/source/detail?r=3D7b4474e7d3666=
f1aebb3f1bcde69bf552aa65d78


On Thu, May 1, 2014 at 4:55 PM, Trevor Perrin <trevp@trevp.net> wrote:
> On Thu, May 1, 2014 at 1:34 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>>
>> On May 1, 2014, at 12:41 AM, Trevor Perrin <trevp@trevp.net> wrote:
>>
>>> On Mon, Apr 28, 2014 at 11:24 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>>>>
>>>> Having reviewed this, I think this version addresses all the issues ra=
ised during WGLC.
>>>
>>> The added sentence in 2.7 on preloaded/dynamic pins doesn't match the
>>> rest of the text, which is written to mandate specific behavior.  If
>>> we're not going to discuss implementation alternatives, we should just
>>> delete most of 2.7 and let implementations do what they want.
>>
>> Why? All the new sentence says is =E2=80=9CThe Effective Pin Date of bui=
lt-in pin lists is UA implementation-defined=E2=80=9D. Implementations are =
still required to treat the pre-loaded pins as though they have some effect=
ive date and determine precedence by whichever has a later date.
>
> That's a bad requirement, as it forces implementations to track the
> Effective Pin Date for dynamic pins (the Effective Expiration Date is
> not sufficient).
>
> Also, we talked about and I thought agreed to allow implementations
> freedom to decide how to handle preloaded/dynamic pin co-existence, as
> long as they don't apply a pin that was never asserted.  For example,
> I described a reasonable implementation which this text would
> disallow:
>
> http://www.ietf.org/mail-archive/web/websec/current/msg02016.html
>
> I thought we had agreement to allow things like that:
>
> Yoav:
> "Yet a fourth way is to observer that none of this affects
> interoperability in any way and leave it up to the UA vendor to choose
> their way. The web site operator should only include valid pins in
> their HPKP headers, and they should also enter only valid pins in
> pre-loaded lists. They should also deal with the fact that don't
> control usage patterns, so anytime they pin something for X seconds,
> their website MUST conform to that pin for at least those X seconds or
> bad things will happen."
> http://www.ietf.org/mail-archive/web/websec/current/msg02019.html
>
> Trevor:
> "Your "fourth way" is well-put, and I agree - all of these seem valid
> implementations which should be allowed."
> http://www.ietf.org/mail-archive/web/websec/current/msg02020.html
>
> Chris Palmer:
> "I have been thinking that this 4th way is the way to go."
> http://www.ietf.org/mail-archive/web/websec/current/msg02022.html
>
> Dan Veditz:
> "The pre-load list seems outside the mechanism covered by the spec. At
> best the spec could mention it in a non-normative section as something
> UAs can do to cover the first-visit gap, but there are several valid
> ways such a list could be implemented."
> http://www.ietf.org/mail-archive/web/websec/current/msg02028.html
>
>
> You suggested a text modification which you maybe thought implemented
> that, and which Tom, Tobias, and Chris seconded:
> "Does anyone (and that includes the authors) object to relaxing the
> requirements in section 2.7, so that the choice of when the static
> pins are believed to have been observed is left to the implementer?
> If not, we'll resolve it that way."
> http://www.ietf.org/mail-archive/web/websec/current/msg02021.html
>
> But that doesn't satisfy what I think people wanted, so I think we
> should strip down 2.7 to something like your text above on the "fourth
> way".
>
>
>>> * Interaction with cookies needs discussion, at least in security
>>> considerations.  Cookie scoping rules pose a serious problem for
>>> pinning, e.g. a pin at "example.com" could be undermined by a MITM
>>> inventing a "badguy.example.com" and using it to steal or force
>>> cookies.
>>
>> While there are similar concerns, I don=E2=80=99t see the interaction. I=
f you are example.com, and badguy controls badguy.example.com, then they=E2=
=80=99re going to get your example.com cookies unless you can block it with=
 scoping.  HPKP doesn=E2=80=99t help you there. You *can* block them with H=
PKP if their control on badguy.example.com relies on a mis-issued certifica=
te and you restrict them with the includeSubdomains directive.
>
> The interaction is that the security you were hoping HPKP would give
> you for example.com will be largely ineffective if a badguy can forge
> a cert for badguy.example.com and you don't defend this with either
> (a) includeSubdomains or (b) cookie-scoping to the domain (which
> doesn't work on IE).
>
> So this is a security consideration deployers of pinning need to be aware=
 of.
>
> Anyways, below is the text from TACK's security consideration which
> isn't perfect, but something like this should be added:
>
>    HTTP cookies [RFC6265] set by a pinned host can be stolen by a
>    network attacker who can forge web and DNS responses so as to cause a
>    client to send the cookies to a phony subdomain of the pinned host.
>    To prevent this, TACK HTTPS servers SHOULD set the "secure" attribute
>    and omit the "domain" attribute on all security-sensitive cookies,
>    such as session cookies.  These settings tell the browser that the
>    cookie should only be presented back to the originating host (not its
>    subdomains), and should only be sent over HTTPS (not HTTP) [RFC6265].
>
>
> Trevor
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec


From nobody Tue May 13 14:15:00 2014
Return-Path: <internet-drafts@ietf.org>
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 B72BD1A01A5; Tue, 13 May 2014 14:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 CxlX12Ib4kgp; Tue, 13 May 2014 14:14:55 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9581A0207; Tue, 13 May 2014 14:14:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.4.2.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140513211452.16805.6108.idtracker@ietfa.amsl.com>
Date: Tue, 13 May 2014 14:14:52 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/PGUVMLVcuJugTCw60Dt3zrpBYGQ
Cc: websec@ietf.org
Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-13.txt
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 13 May 2014 21:14:57 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Security Working Group of the IETF.

        Title           : Public Key Pinning Extension for HTTP
        Authors         : Chris Evans
                          Chris Palmer
                          Ryan Sleevi
	Filename        : draft-ietf-websec-key-pinning-13.txt
	Pages           : 25
	Date            : 2014-05-13

Abstract:
   This memo describes an extension to the HTTP protocol allowing web
   host operators to instruct user agents (UAs) to remember ("pin") the
   hosts' cryptographic identities for a given period of time.  During
   that time, UAs will require that the host present a certificate chain
   including at least one Subject Public Key Info structure whose
   fingerprint matches one of the pinned fingerprints for that host.  By
   effectively reducing the number of authorities who can authenticate
   the domain during the lifetime of the pin, pinning may reduce the
   incidence of man-in-the-middle attacks due to compromised
   Certification Authorities.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-13

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed May 14 15:17:38 2014
Return-Path: <Jeff.Hodges@kingsmountain.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 8436F1A0306 for <websec@ietfa.amsl.com>; Wed, 14 May 2014 15:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.803
X-Spam-Level: *
X-Spam-Status: No, score=1.803 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
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 6XCAs-9FpcI1 for <websec@ietfa.amsl.com>; Wed, 14 May 2014 15:17:36 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 81CD51A02FA for <websec@ietf.org>; Wed, 14 May 2014 15:17:36 -0700 (PDT)
Received: (qmail 22466 invoked by uid 0); 14 May 2014 22:17:29 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 14 May 2014 22:17:29 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with  id 1yHQ1o0132UhLwi01yHTZb; Wed, 14 May 2014 16:17:29 -0600
X-Authority-Analysis: v=2.1 cv=XPOjF2RE c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=4eyjf-e663kA:10 a=xojvF6Qnh0oA:10 a=3NT3xRclEPMA:10 a=N659UExz7-8A:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=vS7MmSmxvPQA:10 a=pE7ifguLAAAA:8 a=1XWaLZrsAAAA:8 a=3vSUqmUqjfIkEuI9opIA:9 a=pILNOxqGKmIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=JqEYdk2rMmSHXuhweeTY63LqJt9wc/gev2XxQAr2gtQ=;  b=upTASXk3Qu3QkGWEIwt2D7Red3lT9D3+1DaKMyrGuhTyMIkIvRugELIK7gVXfCta7/sapctbEgWZnrxXSTmjXwL6/t+w+hKZg5iCbU+j3VE+eDcExc7L0Z21/2ZYR/uy;
Received: from [216.113.168.128] (port=64068 helo=[10.244.137.220]) by box514.bluehost.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1WkhUK-0003Jt-Q6 for websec@ietf.org; Wed, 14 May 2014 16:17:24 -0600
Message-ID: <5373EB71.9010303@KingsMountain.com>
Date: Wed, 14 May 2014 15:17:21 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5
MIME-Version: 1.0
To: IETF WebSec WG <websec@ietf.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/PrpRGIHawcSFlvr1o1r8K_6BZZQ
Subject: [websec] fyi: Analyzing Forged SSL Certificates in the Wild
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: Wed, 14 May 2014 22:17:37 -0000

Analyzing Forged SSL Certificates in the Wild
Lin-Shung Huang=03, Alex Ricey, Erling Ellingseny, Collin Jackson

Abstract=97The SSL man-in-the-middle attack uses forged SSL
certificates to intercept encrypted connections between clients
and servers. However, due to a lack of reliable indicators, it is
still unclear how commonplace these attacks occur in the wild. In
this work, we have designed and implemented a method to detect
the occurrence of SSL man-in-the-middle attack on a top global
website, Facebook. Over 3 million real-world SSL connections
to this website were analyzed. Our results indicate that 0.2%
of the SSL connections analyzed were tampered with forged
SSL certificates, most of them related to antivirus software and
corporate-scale content filters. We have also identified some SSL
connections intercepted by malware. Limitations of the method
and possible defenses to such attacks are also discussed.

https://www.linshunghuang.com/papers/mitm.pdf


news coverage..

https://news.google.com/news?ncl=3DdCtyuKtyM9cSNPM9nzTnp15Wfnh4M&q=3DIopF=
ailZeroAccessCreate&lr=3DEnglish&hl=3Den&sa=3DX





From nobody Mon May 19 23:28:25 2014
Return-Path: <trevp@trevp.net>
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 E27E21A028C for <websec@ietfa.amsl.com>; Mon, 19 May 2014 23:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 lTLeBcT57ofD for <websec@ietfa.amsl.com>; Mon, 19 May 2014 23:28:22 -0700 (PDT)
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045841A028F for <websec@ietf.org>; Mon, 19 May 2014 23:28:21 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id cc10so2677638wib.4 for <websec@ietf.org>; Mon, 19 May 2014 23:28:20 -0700 (PDT)
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=UfsH3ttiCoByUmJnrMIS11hoozp4Zjw3t5Dh2K9ddAo=; b=m/R4DwHj0GWGzWJa7adxDvJgiiyoxuPjFvurmmg2E00nsW72jCqu6Q9ZzdvBs2f8h8 s4ZxgSwbub8MJy2aZqgIftt8ptjdID2E+ZZtqC5+r4qBRduvL6hT9nbUQBrC3hx9V4He GOcjLGZqG++mrqUo5bpqqiZkSgCr5jGXMpYy+gZHCvnrZN9GXSsIli+ZfV8TU6jUr7vY wVARD3Kk/bBtcgIggfWcVK65o/b9VUf1eQhOyh5jQd3J4vO4dGLrGj9FfmzAjE7viH29 1XZ/N63Fl5sGFQdMoR4CY4orljJq10kDBFs8kfr8+OEcOXe69H693jXWj5nxjSdpkf0D N4AQ==
X-Gm-Message-State: ALoCoQk3Yiv1RRVLLFzx4Vs5kn1Tf9fvbypMGhgHl4S/6/QleijNxdA1cE32VvLl3kondpEILfY5
MIME-Version: 1.0
X-Received: by 10.194.243.104 with SMTP id wx8mr34678050wjc.32.1400567300509;  Mon, 19 May 2014 23:28:20 -0700 (PDT)
Received: by 10.216.155.7 with HTTP; Mon, 19 May 2014 23:28:20 -0700 (PDT)
X-Originating-IP: [70.36.227.134]
In-Reply-To: <CAOuvq20Br0_8=uaWbZK+hvC=dGcbVAzXo3WL9oFbnFr0rRhuUg@mail.gmail.com>
References: <20140428231041.12685.8218.idtracker@ietfa.amsl.com> <35B52561-A6B3-43F9-9291-81D46444D3D2@gmail.com> <CAGZ8ZG2Fmd694piWonBn-J40Wj_AVMk1Df0iYzSXpbtpt7Wutg@mail.gmail.com> <2FB9B161-A4DB-4905-A9EC-CF05D72EE7A3@gmail.com> <CAGZ8ZG3sDu=T3HC9JDdpjJhCLzB3ctgOU52bBpULoxEx_LTWug@mail.gmail.com> <CAOuvq20Br0_8=uaWbZK+hvC=dGcbVAzXo3WL9oFbnFr0rRhuUg@mail.gmail.com>
Date: Mon, 19 May 2014 23:28:20 -0700
Message-ID: <CAGZ8ZG2EE5KjESiLmPN+_-pDLAN_Wg-5rbyYo+8oOMOcLpkd_g@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Chris Palmer <palmer@google.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/OPzlqfJdwUTpKnf0nLa_yUvZQcA
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] I-D Action: draft-ietf-websec-key-pinning-12.txt
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: Tue, 20 May 2014 06:28:24 -0000

On Tue, May 13, 2014 at 2:09 PM, Chris Palmer <palmer@google.com> wrote:
>
> PKP vs. PKP-RO:
> https://code.google.com/p/key-pinning-draft/source/detail?r=994a00dc31bf2cca6f3edea29871a6a4f18090f9

The new text about PKP-RO in 2.5 (quoted below) seems to say that a
PKP-RO header is only evaluated against the current connection, not
stored as a pin.  I thought we decided the opposite (which is what I
think 2.3.2 is saying):

2.3.2 (existing text):
  If a Host sets both the Public-Key-Pins header and the Public-Key-
   Pins-Report-Only header, the UA MUST note and enforce Pin Validation
   as specified by the Public-Key-Pins header, and SHOULD note the Pins
   and directives given in the Public-Key-Pins-Report-Only header.

2.5 (new text):
    The UA SHOULD NOT note any pins or other policy expressed in the PKP-
    RO response header field.


> Interactions with built-in pins:
> https://code.google.com/p/key-pinning-draft/source/detail?r=bbf42b1e5e9b49a8cdf193f9c7fe230d0d290543
>
> Cookie security considerations:
> https://code.google.com/p/key-pinning-draft/source/detail?r=7b4474e7d3666f1aebb3f1bcde69bf552aa65d78

Those look OK to me.

Trevor


From nobody Tue May 20 22:16:11 2014
Return-Path: <igor@mir2.org>
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 713F51A0493 for <websec@ietfa.amsl.com>; Tue, 20 May 2014 22:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 ht7miwTUOChf for <websec@ietfa.amsl.com>; Tue, 20 May 2014 22:16:08 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40A71A0684 for <websec@ietf.org>; Tue, 20 May 2014 22:16:07 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id a1so1442376wgh.3 for <websec@ietf.org>; Tue, 20 May 2014 22:16:05 -0700 (PDT)
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=KbP6zXZqrehYFpNMTrRw8X9+gRgjJPRsF3Njl5MRZbQ=; b=F6l/AWem45P0HG1EYgdE3qCbOED83gBxo5wFvkwJR7Kgs4ZFmSUBecqytPueTgS5aC 8ugtmJ6GmZVyGhJgJXRO4Y3Zr7eXR7cGpPgPze4QBiXA0pAQvyvXexXYi+xIM/tu7IQb Of0duhIZF1gmS1Ayd+QzzjpUgIEBvFO1U9v1p4//byBWKNIJuToZ15UUB3cYhUzJg1wO OPVT4mzPx4y2VCAKselB8vEdhHqafbsHxVluAxITbzuhP0vXv6fs/a4oT1KjaEjwhFZc l0MiX5BpAi3+oHmQBnLZwXo546mZd0k8aXaKJEiuqgkGGmBSdf2FMcJVRBXjy6yq3Pbc Xbdg==
X-Gm-Message-State: ALoCoQmbOo+jpuAIFV+s5nyYk8IqRHY8EQmTICEgCMYIcJDQ2S/dXqyTB+xWlvwhomm44sw/N6la
MIME-Version: 1.0
X-Received: by 10.194.71.71 with SMTP id s7mr20972581wju.48.1400649365616; Tue, 20 May 2014 22:16:05 -0700 (PDT)
Received: by 10.180.88.136 with HTTP; Tue, 20 May 2014 22:16:05 -0700 (PDT)
Date: Wed, 21 May 2014 07:16:05 +0200
Message-ID: <CADd11yWjK=5Ns0xAQzJZgGiaicpX-FpFMBNb6hW3Av4ipBjz5g@mail.gmail.com>
From: Igor Bukanov <igor@mir2.org>
To: websec@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/1XTDEO1yWaeW7ImlKLfGnBkH_iI
Subject: [websec] key-pinning overrides and reporting
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: Wed, 21 May 2014 05:16:09 -0000

It is not clear from draft-ietf-websec-key-pinning how reporting
interacts with a user-defined policy or with a disabled pin
validation.

For example, if UA allows to proceed for connections with a locally
installed certificate on a pin mismatch, should the report still be
generated?


From nobody Thu May 22 00:49:21 2014
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 685A11A0137 for <websec@ietfa.amsl.com>; Thu, 22 May 2014 00:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, 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 1gpxsVcA9IBP for <websec@ietfa.amsl.com>; Thu, 22 May 2014 00:49:19 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063F11A0125 for <websec@ietf.org>; Thu, 22 May 2014 00:49:18 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id n15so3910084wiw.8 for <websec@ietf.org>; Thu, 22 May 2014 00:49:16 -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 :content-transfer-encoding:message-id:references:to; bh=OA0IJx+UHim0aawuXN4Lwjm4hxvOUcyUlCbA2gVP9j0=; b=etw5NmcyHrPdaJq7oCbQQJl7sPvf88oAelaP6sUIsBI3E7dw/6tlRcA3amiXQdqbn6 DKymFksSXh1hbzEGoAIIdPEvo6kYRERkxiT5ElvqfUT1z0AZI1VXnG03Q9Lf5K9ZrmpF QyTINvMTCIihZC1dUw9a6r0qKr1RjhSlOzDPL9aEIofrJKrVFvT5CFBbILSA3b50F3Ka FVd2biMuC9LhOxrjde3ypRDrFCLc83vrwKYasYoYYN8z5RPmjnetJSyRh3hMKHGFMQa2 po3E0sqJdPugdRfajBNnvsJS4c7ZdCAaqrOcnfdiyhjFvTjXIv4ryDRxxE/Uu1VSRPQ8 rnyw==
X-Received: by 10.194.92.228 with SMTP id cp4mr35360240wjb.28.1400744956692; Thu, 22 May 2014 00:49:16 -0700 (PDT)
Received: from [172.24.249.169] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id h19sm6524863wiw.17.2014.05.22.00.49.15 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 00:49:15 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CADd11yWjK=5Ns0xAQzJZgGiaicpX-FpFMBNb6hW3Av4ipBjz5g@mail.gmail.com>
Date: Thu, 22 May 2014 10:49:13 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <F769F129-5A72-40FE-87CF-48BB1AE5C991@gmail.com>
References: <CADd11yWjK=5Ns0xAQzJZgGiaicpX-FpFMBNb6hW3Av4ipBjz5g@mail.gmail.com>
To: Igor Bukanov <igor@mir2.org>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/dky5ugYRqP3knbC7p6iFXQt700I
Cc: websec@ietf.org
Subject: Re: [websec] key-pinning overrides and reporting
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: Thu, 22 May 2014 07:49:20 -0000

Interesting question. IMO (no hats) the answer should be no. If the UA =
has disabled pin validation (as section 2.6 says it may) then it should =
not send reports either.

Yoav

On May 21, 2014, at 8:16 AM, Igor Bukanov <igor@mir2.org> wrote:

> It is not clear from draft-ietf-websec-key-pinning how reporting
> interacts with a user-defined policy or with a disabled pin
> validation.
>=20
> For example, if UA allows to proceed for connections with a locally
> installed certificate on a pin mismatch, should the report still be
> generated?
>=20
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec


From nobody Sun May 25 13:46:13 2014
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 E6C731A0249 for <websec@ietfa.amsl.com>; Sun, 25 May 2014 13:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 D-Ea_8ZuKk54 for <websec@ietfa.amsl.com>; Sun, 25 May 2014 13:46:09 -0700 (PDT)
Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47ED71A0224 for <websec@ietf.org>; Sun, 25 May 2014 13:46:09 -0700 (PDT)
Received: by mail-wg0-f45.google.com with SMTP id m15so6962611wgh.28 for <websec@ietf.org>; Sun, 25 May 2014 13:46:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=qm4SZ38w5J7zvj1i2K1gPLSS+zYcYZ2ZagIAR2mzGzk=; b=jbTz1Ewj+4ji26Y9nazZmSdyqeceV3G7xp30RTCQaffROVxKE2gnGnvjDPulCndvWN WLuaFyGQnGM/sedEICzmFEdnuiu0tPaq0+FGwvGbAeB29MXQUUh4GowoKv4WpTqRNl9G kJxslmX+tMLjG8YHoFZ4B2G42WCX5VOxi/6siVxlgWnWn1EpQRtqWGD+RxSFNRmvfVD3 jdfZ+wS+CuRtWLdsiStiABVTQvfHBapWxORayZqDl4UuhoH5AgXX2AVkUFsPjEZ08BDC pWAeQ1Xa6Gr1sM5yFgVPOIbdQDLPaZOPlLmvqhr65aHgGhHIDzIx0r/eDn99nXMSlB3v xeiA==
X-Received: by 10.194.58.79 with SMTP id o15mr22649021wjq.62.1401050765570; Sun, 25 May 2014 13:46:05 -0700 (PDT)
Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id kr6sm21226543wjb.16.2014.05.25.13.46.04 for <websec@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 May 2014 13:46:04 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <9346B38F-5532-4B84-ADBB-96B53C9EAF0F@gmail.com>
Date: Sun, 25 May 2014 23:45:59 +0300
To: IETF WebSec WG <websec@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/10Nm7tiWpRYaZlO_akwh6ReC7bE
Subject: [websec] Shooting yourself in the foot with HSTS and HPKP
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: Sun, 25 May 2014 20:46:11 -0000

Hi

We=92ve had a few threads ([1]) on this list about administrators =
needing to be careful when activating HSTS and/or HPKP, because a common =
mistake like forgetting to replace the certificate in time can brick =
your site. The usual conclusion was that companies and organizations =
without the proper technical capacity to maintain a valid certificate =
should not use these features ([2])

So today we got a real live demo how this can happen even to big, =
well-funded companies ([3]). HSTS and HPKP were not involved - this was =
not a browser, but a client that was programmed to hard-fail when =
receiving an expired certificate. It is the equivalent of a site with =
HSTS, and if it can happen to them, it could happen to anybody.

I=92m not saying we should revisit our previous decisions. Obviously =
Apple can fix this now in minutes (probably already has), and all the =
consequences are some bad press. I just think it is illuminating that =
even at large companies there is no guarantee that an action that needs =
to be performed once a year will be done correctly.

Yoav

[1] http://www.ietf.org/mail-archive/web/websec/current/msg01119.html =
(just an example - there were many threads)
[2] http://www.ietf.org/mail-archive/web/websec/current/msg01213.html
[3] http://www.macrumors.com/2014/05/25/apple-software-update-invalid/=


From nobody Sun May 25 23:06:25 2014
Return-Path: <igor@mir2.org>
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 60A3F1A048E for <websec@ietfa.amsl.com>; Sun, 25 May 2014 23:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 Dwp66ZskcR6R for <websec@ietfa.amsl.com>; Sun, 25 May 2014 23:06:22 -0700 (PDT)
Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3981A048A for <websec@ietf.org>; Sun, 25 May 2014 23:06:21 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id z12so7535736wgg.24 for <websec@ietf.org>; Sun, 25 May 2014 23:06:18 -0700 (PDT)
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 :content-transfer-encoding; bh=/Jmj52u9wLsXDhMUPwpKRd9cRMUVHojnbU32f7+HpSY=; b=iSgGB+pnuQXF40vwGHBdzWZuoIPlJis0lhOHoj6Q45GT/XNj5r+ekcEk6YOdRMkwGP WJSUXimpg+2utmnT7H2mNTW31aBpT/qo/7MHeMIVyWkkLoKfgDJuonSWrVuaH51nB40V uWwuCWysNBTkU2lb0VhDUGtSwNGPaDZfZ6/ah7Ns5NJC+lEG9rWeCFCp3sTOHDeBjT+W +iPOfBEh/RGd5NE7TM5yFy0WWQi3LoaTMXuv9CucDdjsykJWg5YqXTrn1cd5nkbj7jzS y9Ac4ppep1YSMLtKo6yJOFp47pFxwSijqpl/R2D6NKthfMLHmTi1cAkHtqK0+kB7zkGk Msog==
X-Gm-Message-State: ALoCoQlqbXbyKrfvghKSzSk64Yt0JkUfFaoqS2+DMfTI9uf4as8/KbUFi6LjkkT9oZIK0zuQVJ9d
MIME-Version: 1.0
X-Received: by 10.194.93.202 with SMTP id cw10mr1083069wjb.95.1401084377944; Sun, 25 May 2014 23:06:17 -0700 (PDT)
Received: by 10.180.82.72 with HTTP; Sun, 25 May 2014 23:06:17 -0700 (PDT)
In-Reply-To: <9346B38F-5532-4B84-ADBB-96B53C9EAF0F@gmail.com>
References: <9346B38F-5532-4B84-ADBB-96B53C9EAF0F@gmail.com>
Date: Mon, 26 May 2014 08:06:17 +0200
Message-ID: <CADd11yXpL8H0J4fuZYt3siK1kcYCChK2bwtbEScweBFrk6vA-Q@mail.gmail.com>
From: Igor Bukanov <igor@mir2.org>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/BsGqpe7GwkMrUP7NGLFRfMJyltU
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Shooting yourself in the foot with HSTS and HPKP
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, 26 May 2014 06:06:24 -0000

I second that concern. I know at least one organization that is not
going to consider implementing key pining precisely for that reason.
They may consider a report-only mode, but as they were badly bitten by
browser bugs in the report-only mode implementation of
Content-Security-Policy that effectively changed report-only into
enforcing, they would wait with that until the implementation matures.

I think it would be easier to convince them if they could implement
key pinning themselves in incremental steps. For example, a browser
can provide JS API to access certificate chain and a possibility to
"pin" a particular JS source so it would be always executed from the
local cache.

On 25 May 2014 22:45, Yoav Nir <ynir.ietf@gmail.com> wrote:
> Hi
>
> We=E2=80=99ve had a few threads ([1]) on this list about administrators n=
eeding to be careful when activating HSTS and/or HPKP, because a common mis=
take like forgetting to replace the certificate in time can brick your site=
. The usual conclusion was that companies and organizations without the pro=
per technical capacity to maintain a valid certificate should not use these=
 features ([2])
>
> So today we got a real live demo how this can happen even to big, well-fu=
nded companies ([3]). HSTS and HPKP were not involved - this was not a brow=
ser, but a client that was programmed to hard-fail when receiving an expire=
d certificate. It is the equivalent of a site with HSTS, and if it can happ=
en to them, it could happen to anybody.
>
> I=E2=80=99m not saying we should revisit our previous decisions. Obviousl=
y Apple can fix this now in minutes (probably already has), and all the con=
sequences are some bad press. I just think it is illuminating that even at =
large companies there is no guarantee that an action that needs to be perfo=
rmed once a year will be done correctly.
>
> Yoav
>
> [1] http://www.ietf.org/mail-archive/web/websec/current/msg01119.html (ju=
st an example - there were many threads)
> [2] http://www.ietf.org/mail-archive/web/websec/current/msg01213.html
> [3] http://www.macrumors.com/2014/05/25/apple-software-update-invalid/
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec


From nobody Mon May 26 07:14:49 2014
Return-Path: <noloader@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 AB8C31A0157 for <websec@ietfa.amsl.com>; Mon, 26 May 2014 07:14:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, 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 tHfKatEtmF7g for <websec@ietfa.amsl.com>; Mon, 26 May 2014 07:14:46 -0700 (PDT)
Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC071A0173 for <websec@ietf.org>; Mon, 26 May 2014 07:14:46 -0700 (PDT)
Received: by mail-vc0-f179.google.com with SMTP id im17so9240501vcb.38 for <websec@ietf.org>; Mon, 26 May 2014 07:14:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ONW9z0Zs3rgC/Hn6wT0rz8Jznk/BMpU4nmWgJHK1WaM=; b=d31+CV1CWUu/kEvMGACEted/CiPVG02zrI1LFSDhARXezsWyQQBG3nCaqnHGZzA+fo bzreJ/KX0VMzuw5VSO6gAnCFgK7zWbxqc04XRuVrI0mW8d/tBXy4iDmx3pVgfwNsjJ89 qeqjMmJcfN+d3WkaLo3J6wa4xzUDdAoghsXNSSpEWKTpNPXeuxQtGirx1OPRwLIWgV3k QCHXHbeBiPhPhfNNFBz9G7pKp8IR+cAd2L2MtMY/qYzDbH0AcZvi2LeZglO9N7dznDpZ vHVW/bgbLY6pjB0d/GFVk8ncsfXPI0H/GfGUPojXjFEjiuSGRHq616WsSTSpA1yBJXaI nmRA==
MIME-Version: 1.0
X-Received: by 10.58.112.8 with SMTP id im8mr7925453veb.35.1401113683413; Mon, 26 May 2014 07:14:43 -0700 (PDT)
Received: by 10.220.58.71 with HTTP; Mon, 26 May 2014 07:14:43 -0700 (PDT)
In-Reply-To: <CADd11yXpL8H0J4fuZYt3siK1kcYCChK2bwtbEScweBFrk6vA-Q@mail.gmail.com>
References: <9346B38F-5532-4B84-ADBB-96B53C9EAF0F@gmail.com> <CADd11yXpL8H0J4fuZYt3siK1kcYCChK2bwtbEScweBFrk6vA-Q@mail.gmail.com>
Date: Mon, 26 May 2014 10:14:43 -0400
Message-ID: <CAH8yC8mvAdBdCprN-0bHhQ=RyygZRckYOKXfqtVHQk+_U0s0TQ@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Igor Bukanov <igor@mir2.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/w1WAbwyquDaApn5pEi1Q4hDmhw4
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Shooting yourself in the foot with HSTS and HPKP
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
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, 26 May 2014 14:14:47 -0000

On Mon, May 26, 2014 at 2:06 AM, Igor Bukanov <igor@mir2.org> wrote:
> ... For example, a browser
> can provide JS API to access certificate chain ...
+1. I've been looking for it for years (and WebSockets, too). If
anyone knows where to find it, please let me know.

Jeff


From nobody Mon May 26 07:25:24 2014
Return-Path: <nico@cryptonector.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 8ED091A0170 for <websec@ietfa.amsl.com>; Mon, 26 May 2014 07:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.043
X-Spam-Level: 
X-Spam-Status: No, score=-1.043 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 dqJKbjZQqr91 for <websec@ietfa.amsl.com>; Mon, 26 May 2014 07:25:22 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id F17FB1A0160 for <websec@ietf.org>; Mon, 26 May 2014 07:25:21 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 54DF4B8058 for <websec@ietf.org>; Mon, 26 May 2014 07:25:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=KqrgTanOkUMiWxhLXmE6 0uiC5rQ=; b=VxPcSa+TzkfHyU4W6uc/jPHhotTlBhHhMA7kceEKKcpJQH2xUAH4 IWYTTdOJp7SFe+wzA2Cy5jAXObloTt8ThPO5VXu1FAnFnrC8iduEr6NfoX1bqRmD H9ktafYpnxPHOKlAWAaPL8JZrKW92EK/OKYpC9RhMTiA69KIhDedgEY=
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 09650B8057 for <websec@ietf.org>; Mon, 26 May 2014 07:25:18 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id k48so8164029wev.19 for <websec@ietf.org>; Mon, 26 May 2014 07:25:17 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.12.135 with SMTP id y7mr28587637wib.39.1401114317668; Mon, 26 May 2014 07:25:17 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Mon, 26 May 2014 07:25:17 -0700 (PDT)
In-Reply-To: <9346B38F-5532-4B84-ADBB-96B53C9EAF0F@gmail.com>
References: <9346B38F-5532-4B84-ADBB-96B53C9EAF0F@gmail.com>
Date: Mon, 26 May 2014 09:25:17 -0500
Message-ID: <CAK3OfOhjEZ_c5MwpTfXF6RA4QEQuSYx2zXkTyCKaU5cqKGAkeg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2ab3431cd1b04fa4e5969
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/mrWE56AnQOeWMCiGwW453dCQDHk
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Shooting yourself in the foot with HSTS and HPKP
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, 26 May 2014 14:25:22 -0000

--001a11c2ab3431cd1b04fa4e5969
Content-Type: text/plain; charset=UTF-8

I've seen many corporate failures to ensure fthe availability of unexpired
certificates.  I's a big problem.  Without an online certification
protocol, it is organizationally difficult to keep certificates valid!

DANE, of course, doesn't have validity periods, just TTLs, so it shouldn't
suffer from this.  But DANE with pinning still would.  And rebuilding a
host without preserving its private keys would still cause failures.  But
at least organizationally, DANE is much, much easier to handle than PKIX.

(Kerberos has validity periods, but does much better because it has online
infrastructure, at the increased risk of downtime if that infrastructure
becomes unavailable.)

Nico
--

--001a11c2ab3431cd1b04fa4e5969
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>I&#39;ve seen many corporate failures to ensure fthe availability of u=
nexpired certificates. =C2=A0I&#39;s a big problem. =C2=A0Without an online=
 certification protocol, it is organizationally difficult to=C2=A0keep cert=
ificates valid!<br>
</div><div><br></div>DANE, of course, doesn&#39;t have validity periods, ju=
st TTLs, so it shouldn&#39;t suffer from this. =C2=A0But DANE with pinning =
still would. =C2=A0And rebuilding a host without preserving its private key=
s would still cause failures. =C2=A0But at least organizationally, DANE is =
much, much easier to handle than PKIX.<div>
<br></div><div>(Kerberos has validity periods, but does much better because=
 it has online infrastructure, at the increased risk of downtime if that in=
frastructure becomes unavailable.)<br><div><br></div><div>Nico</div><div>
--=C2=A0<br><br></div></div>

--001a11c2ab3431cd1b04fa4e5969--


From nobody Mon May 26 10:42:30 2014
Return-Path: <igor@mir2.org>
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 0C1451A01EB for <websec@ietfa.amsl.com>; Mon, 26 May 2014 10:42:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 PCI7TTTf2sz4 for <websec@ietfa.amsl.com>; Mon, 26 May 2014 10:42:27 -0700 (PDT)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333A31A01DE for <websec@ietf.org>; Mon, 26 May 2014 10:42:26 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id bs8so367907wib.0 for <websec@ietf.org>; Mon, 26 May 2014 10:42:23 -0700 (PDT)
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=eEBpWEIk+BwGD1cuu/yClLY4Khl5T+3kavlUpiYKzKQ=; b=XzYihh18stQNrEUUxC3oWLmjgIKplXxRhVzJ6IWdFEchcPKJzCP9JGDJLLVgt7isvY EHE17sSsR0mdCKwXxQpc86AsD5+6rS9gf1SeXlAoN0x+FO0z6lVoobs38sb1HQEljwzm plet7e0Irm/6Hjb5CcXyHb5bHVgN6DAKsYnpcPoDImbffIE8iX2nW3sn5R5Z6a8nQEjR vfsOgspRl4/FqPz66ARQtUvvD0Og0zOV6Mu7jHPTo4cezDT5sDKmOp0Zwfyi1MBsenwy gs1Z2CsUggwL3nuJkCFH56Qf+A5nj+WudVvBEmQLp5zXJyPlPqbzC6qq1eHReyfJSusf sJag==
X-Gm-Message-State: ALoCoQkiENeAjtn2ZLj3i0+0dW8LGVXcjS+HBDrMWFkJVMkLfRsdBOmRQfMdy36ze9VipGcJqDr6
MIME-Version: 1.0
X-Received: by 10.194.221.4 with SMTP id qa4mr32978098wjc.38.1401126143141; Mon, 26 May 2014 10:42:23 -0700 (PDT)
Received: by 10.180.82.72 with HTTP; Mon, 26 May 2014 10:42:23 -0700 (PDT)
In-Reply-To: <CAH8yC8mvAdBdCprN-0bHhQ=RyygZRckYOKXfqtVHQk+_U0s0TQ@mail.gmail.com>
References: <9346B38F-5532-4B84-ADBB-96B53C9EAF0F@gmail.com> <CADd11yXpL8H0J4fuZYt3siK1kcYCChK2bwtbEScweBFrk6vA-Q@mail.gmail.com> <CAH8yC8mvAdBdCprN-0bHhQ=RyygZRckYOKXfqtVHQk+_U0s0TQ@mail.gmail.com>
Date: Mon, 26 May 2014 19:42:23 +0200
Message-ID: <CADd11yVSQCQ26KsqhdOAkEbHe2=FP8h1P0N=f=CmcML9x9u+yg@mail.gmail.com>
From: Igor Bukanov <igor@mir2.org>
To: noloader@gmail.com
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/sCHrTfqKKbv7uw7hOoGbDTj6qes
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Shooting yourself in the foot with HSTS and HPKP
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, 26 May 2014 17:42:29 -0000

According to [1] the only realistic way to access the certificate
chain on the present web is to use Flash or Java applets,
https://www.linshunghuang.com/papers/mitm.pdf

[1] - https://www.linshunghuang.com/papers/mitm.pdf

On 26 May 2014 16:14, Jeffrey Walton <noloader@gmail.com> wrote:
> On Mon, May 26, 2014 at 2:06 AM, Igor Bukanov <igor@mir2.org> wrote:
>> ... For example, a browser
>> can provide JS API to access certificate chain ...
> +1. I've been looking for it for years (and WebSockets, too). If
> anyone knows where to find it, please let me know.
>
> Jeff


From nobody Tue May 27 11:28:46 2014
Return-Path: <palmer@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 D1C071A0644 for <websec@ietfa.amsl.com>; Tue, 27 May 2014 11:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level: 
X-Spam-Status: No, score=-2.03 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, RP_MATCHES_RCVD=-0.651, 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 ohh0eDHFD-YA for <websec@ietfa.amsl.com>; Tue, 27 May 2014 11:28:35 -0700 (PDT)
Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E441A01F6 for <websec@ietf.org>; Tue, 27 May 2014 11:28:34 -0700 (PDT)
Received: by mail-ig0-f181.google.com with SMTP id h3so1456045igd.2 for <websec@ietf.org>; Tue, 27 May 2014 11:28:31 -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=FqSHhTZOBwCM5rEctc5T5cK5Wrho08OzXYOGQApebWU=; b=Q+9zGeB3X4G5tHGTu4wMlI3k+D7rMilvlNQA73yEaf8oUHGx9btEUTh2pyfsi4pa31 Nsj28tO9Ftrozjk59fduKH+MBnma1A03LWprpCb6cB7OSglLjPxsDNq0BKhHl+hKjd89 YgxFY3VsEA26Zmr9sigh3LH71MGOptIJbJE4Ae33qi2eZwN5YJdvlUwcXQeTKrheJ9ME HF8BhhDOMKV/EzvY4dT/clbvaNYOlo99c9uCqbZ0WbrW9/+CXDtcuJFyLbnpB5yLWt1a qdhVskVhTbGRzpDbmZug8YHO4AMlAFXo6XueuJykCd86ghtEz24l9Q8VGifNTO1eSLKP T7yw==
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=FqSHhTZOBwCM5rEctc5T5cK5Wrho08OzXYOGQApebWU=; b=WK31to7y+CsL6d+2aQpyagJx2ymMHHe6bmgbY04UOd44Nq9hK4EvmrD2bFYKggSao4 lWbA1Cd8cdTPtUBnyNPwVr4kuOTN2gm0awC8y9WC/LkFenastJDAc7JYbDWkHMvkOSax SZjK/3r1gOoi7ju/MFe6417dUiiRG6CiEiLtyWPvu9onNzo+z4462sFxrh5F31zTxObi Zq6dJ4SgRorxYZW7TyGjRDn8Px6bstI3IxPPYpP/6i1YV9Woq8c4MxH+ljiUfja2MEAZ 0IakAaNMWOXJPamxUmnJMg93DG5ktkZDYYLUiUkjALKD+auGGTIuXxSspGEOKkbGgEoY cbCg==
X-Gm-Message-State: ALoCoQlxcDL01+6SdKsZlD3WSZS9Tzm9cRRWmg2kui4fTOFxC38ons1+TkuN6yP7Nl1YJQ/Kv2LM
MIME-Version: 1.0
X-Received: by 10.50.1.5 with SMTP id 5mr36587958igi.13.1401215311235; Tue, 27 May 2014 11:28:31 -0700 (PDT)
Received: by 10.64.137.40 with HTTP; Tue, 27 May 2014 11:28:31 -0700 (PDT)
In-Reply-To: <F769F129-5A72-40FE-87CF-48BB1AE5C991@gmail.com>
References: <CADd11yWjK=5Ns0xAQzJZgGiaicpX-FpFMBNb6hW3Av4ipBjz5g@mail.gmail.com> <F769F129-5A72-40FE-87CF-48BB1AE5C991@gmail.com>
Date: Tue, 27 May 2014 11:28:31 -0700
Message-ID: <CAOuvq22Y_ZbdUj=v7tcO2u_DLn5_a2n2iL=sxi93cMo_TBHj1w@mail.gmail.com>
From: Chris Palmer <palmer@google.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/tCn9NKFsXvbDyY3ESiILoLLq9VA
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] key-pinning overrides and reporting
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: Tue, 27 May 2014 18:28:39 -0000

On Thu, May 22, 2014 at 12:49 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

> Interesting question. IMO (no hats) the answer should be no. If the UA has disabled pin validation (as section 2.6 says it may) then it should not send reports either.

Thanks for raising the question, Igor. I am inclined to agree with
Yoav. Anyone else have thoughts?

Is section 2.6 a good place to put a note about this issue? Proposed text:

"""
If Pin Validation is not in effect (e.g. because the user has elected
to disable it, or because a presented certificate chain chains up to a
locally-installed anchor), and if the server has set a report-uri in a
PKP or PKP-RO header, the UA SHOULD NOT send any reports to the
report-uri for the given certificate chain.
"""


From nobody Tue May 27 23:03:20 2014
Return-Path: <igor@mir2.org>
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 713271A0359 for <websec@ietfa.amsl.com>; Tue, 27 May 2014 23:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 Rlg1v5pp9Dft for <websec@ietfa.amsl.com>; Tue, 27 May 2014 23:03:16 -0700 (PDT)
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F78F1A0358 for <websec@ietf.org>; Tue, 27 May 2014 23:03:16 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id cc10so3031371wib.10 for <websec@ietf.org>; Tue, 27 May 2014 23:03:11 -0700 (PDT)
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=HyEw2SmIsaUrawwlSX3uo/WjWzvgf3rv7XL/Oc3SIjQ=; b=VUPaWNPWrUNky94G+rXdX8atAK3mHEQMga6iuvxhP9aQqWT7ZZEg4st+85usmVit5z r6shbFAeytHO/Lqq3ZUX5MBCImP5zCs8888t/9U7/QeGO47cB17ZjsAZj6gYYbnh8OfP VvUP0gUbs0faLsvKQRkHkbORH69A/vygcPzj1WGSA+k2Qor9AM1wW3RhbIJuH6YnmCDr Z5RtJXT2A/krxyr00t3vFEpnWV5K3Tbc0+YQEhcYUDDxvFzDEYxar5BX90ZjXE7+hFoZ nezefjVeTyVMfVGXMMMgZVP2HHBQ3qsTZs010aFkou2O18JFCi96Pb0ysQQC6h6HpegK 926g==
X-Gm-Message-State: ALoCoQmJnFEw4UQGGCjSd9hHafCfAhliNntobMWQO6M4oFzGLPjMQ8ISWlvdvy4EidTktC1+JVSl
MIME-Version: 1.0
X-Received: by 10.180.75.102 with SMTP id b6mr44901619wiw.26.1401256991449; Tue, 27 May 2014 23:03:11 -0700 (PDT)
Received: by 10.180.82.72 with HTTP; Tue, 27 May 2014 23:03:11 -0700 (PDT)
In-Reply-To: <CAOuvq22Y_ZbdUj=v7tcO2u_DLn5_a2n2iL=sxi93cMo_TBHj1w@mail.gmail.com>
References: <CADd11yWjK=5Ns0xAQzJZgGiaicpX-FpFMBNb6hW3Av4ipBjz5g@mail.gmail.com> <F769F129-5A72-40FE-87CF-48BB1AE5C991@gmail.com> <CAOuvq22Y_ZbdUj=v7tcO2u_DLn5_a2n2iL=sxi93cMo_TBHj1w@mail.gmail.com>
Date: Wed, 28 May 2014 08:03:11 +0200
Message-ID: <CADd11yXGorO+HX7n0EGH+sKrC1MRBg95Nrj5yCQP+AUADnSifA@mail.gmail.com>
From: Igor Bukanov <igor@mir2.org>
To: Chris Palmer <palmer@google.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/OGw-hIzLaurnG7ufcwtkug7Zvro
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] key-pinning overrides and reporting
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: Wed, 28 May 2014 06:03:18 -0000

This is somewhat related to the question if a website in general
should be allowed to know if the user uses non-approved certificate
that is installed on her device. This is important if one considers a
possibility of using social engineering to trick the user to install a
new certificate authority that allows to perform MTM attacks. I know
banks worry about that.

However, allowing such knowledge to websites has a privacy
implications. Besides social engineering arguments are weak as a user
can be just as well tricked to install a special browser that skips
any ssl checks. So the proposed text change is good.

On 27 May 2014 20:28, Chris Palmer <palmer@google.com> wrote:
> On Thu, May 22, 2014 at 12:49 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>
>> Interesting question. IMO (no hats) the answer should be no. If the UA has disabled pin validation (as section 2.6 says it may) then it should not send reports either.
>
> Thanks for raising the question, Igor. I am inclined to agree with
> Yoav. Anyone else have thoughts?
>
> Is section 2.6 a good place to put a note about this issue? Proposed text:
>
> """
> If Pin Validation is not in effect (e.g. because the user has elected
> to disable it, or because a presented certificate chain chains up to a
> locally-installed anchor), and if the server has set a report-uri in a
> PKP or PKP-RO header, the UA SHOULD NOT send any reports to the
> report-uri for the given certificate chain.
> """