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 B144C1A6F8F
 for <websec@ietfa.amsl.com>; Thu, 28 Aug 2014 07:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001,
 SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id hu5i2Vl0Wkp3 for <websec@ietfa.amsl.com>;
 Thu, 28 Aug 2014 07:32:30 -0700 (PDT)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com
 [IPv6:2a00:1450:4010:c03::22f])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 4888B1A6F8A
 for <websec@ietf.org>; Thu, 28 Aug 2014 07:32:29 -0700 (PDT)
Received: by mail-la0-f47.google.com with SMTP id s18so1069819lam.34
 for <websec@ietf.org>; Thu, 28 Aug 2014 07:32:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 
 h=content-type:mime-version:subject:from:in-reply-to:date:cc
 :message-id:references:to;
 bh=c+J0MS/dbFODtl/jyi94pz5DVB36waY02SVcf11fkBs=;
 b=YoMTdlRYyssaFHbOGOzP2w4j6SXZb/jp2+7XT9nhGde28DJbTdcS5zOs7PfFn7XZrN
 m/SrRhNThKNS16u0DCqmxRs24pAVfq4/erN7vXZ4iXX6f7rEm5l++qdGlmhVDzn0jRPX
 Wbq77MNViMcF+JHFRv5Ik49SCMjQlOYYUAe9y7KxQcBrtGKjazAjVOjuSEPmFE8nfkTP
 5VTM3gncs27Dr/u49JJdbA+G5bhLnzAekZibKsDSu20ULFO5sBCZ7yHCeycY5k/TWMIU
 QHxxYVZQfApU9L9I/Z2bSrXEbTogI5FZop5NL8Qcrw2dvhYZEyHw65E2h3zgVrBOzmBF
 UTXg==
X-Received: by 10.152.44.162 with SMTP id f2mr4741798lam.84.1409236346612;
 Thu, 28 Aug 2014 07:32:26 -0700 (PDT)
Received: from [172.24.249.230] (dyn32-131.checkpoint.com. [194.29.32.131])
 by mx.google.com with ESMTPSA id i5sm6222902lbd.27.2014.08.28.07.32.25
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Thu, 28 Aug 2014 07:32:26 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_E1B49EE1-E1DF-4CB2-BD1A-B984832991CA"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <53FF2333.9080804@gmx.de>
Date: Thu, 28 Aug 2014 17:32:23 +0300
Message-Id: <26265CC4-6C48-4518-A177-DD56CC1AC414@gmail.com>
References: <6CAA88AE-1A98-4FF1-B994-A43A0AD3930D@gmail.com>
 <53FEC72A.7010605@greenbytes.de>
 <6CA0E2AF-C758-4EFF-9506-E2E545FB4EBA@gmail.com> <53FF2333.9080804@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/WzYkvmFvvm24Em99MJO4wJIx3zY
Cc: Barry Leiba <barryleiba@computer.org>,
 "<websec@ietf.org>" <websec@ietf.org>
Subject: Re: [websec] Re-litigating Key-Pinning
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, 28 Aug 2014 14:32:35 -0000


--Apple-Mail=_E1B49EE1-E1DF-4CB2-BD1A-B984832991CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Aug 28, 2014, at 3:40 PM, Julian Reschke <julian.reschke@gmx.de> =
wrote:

> On 2014-08-28 10:01, Yoav Nir wrote:
>>=20
>> On Aug 28, 2014, at 9:07 AM, Julian Reschke =
<julian.reschke@greenbytes.de> wrote:
>>=20
>>> On 2014-08-27 07:44, Yoav Nir wrote:
>>>> ...
>>>> Fixing editorial issues like Julians=92 comments about references =
is fine, and could even be done *after* IESG review. ...
>>>> ...
>>>=20
>>> FWIW, I believe the ABNF issues (which are *not* editorial) =
absolutely need to be fixed as well.
>>>=20
>>=20
>> Hi, Julian
>>=20
>> I don=92t want to nit-pick the meaning of the word =93editorial=94. =
But anyone who=92s read the draft knows what a PKP header looks like. I =
don=92t think there=92s any controversy about what is and is not a valid =
PKP header. So changing the ABNF to reflect this existing understanding, =
is something that I don=92t think requires polling the group.
>> ...
>=20
> The issue is that the ABNF is ambiguous about whether
>=20
>     Public-Key-Pins: max-age=3D3000;
>       pin-xyz=3Dabc;
>=20
> is syntactically valid or not. I believe it should be, because =
otherwise parsers would need to special-case the "pin-*" parameters when =
parsing.
>=20
> Best regards, Julian

Well, this might lead to me being proven wrong in my statement that =
everyone agrees what a valid PKP header is, but I also think this should =
be syntactically valid. However, clients that only support *this* =
document (and not =93xyz and its use in key pinning=94) would not pin =
anything based on this header.

Yoav



--Apple-Mail=_E1B49EE1-E1DF-4CB2-BD1A-B984832991CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Aug 28, 2014, at 3:40 PM, Julian =
Reschke &lt;<a =
href=3D"mailto:julian.reschke@gmx.de">julian.reschke@gmx.de</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div style=3D"font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;">On 2014-08-28 10:01, Yoav Nir =
wrote:<br><blockquote type=3D"cite"><br>On Aug 28, 2014, at 9:07 AM, =
Julian Reschke &lt;<a =
href=3D"mailto:julian.reschke@greenbytes.de">julian.reschke@greenbytes.de<=
/a>&gt; wrote:<br><br><blockquote type=3D"cite">On 2014-08-27 07:44, =
Yoav Nir wrote:<br><blockquote type=3D"cite">...<br>Fixing editorial =
issues like Julians=92 comments about references is fine, and could even =
be done *after* IESG review. ...<br>...<br></blockquote><br>FWIW, I =
believe the ABNF issues (which are *not* editorial) absolutely need to =
be fixed as well.<br><br></blockquote><br>Hi, Julian<br><br>I don=92t =
want to nit-pick the meaning of the word =93editorial=94. But anyone =
who=92s read the draft knows what a PKP header looks like. I don=92t =
think there=92s any controversy about what is and is not a valid PKP =
header. So changing the ABNF to reflect this existing understanding, is =
something that I don=92t think requires polling the =
group.<br>...<br></blockquote><br>The issue is that the ABNF is =
ambiguous about whether<br><br>&nbsp;&nbsp;&nbsp;&nbsp;Public-Key-Pins: =
max-age=3D3000;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;pin-xyz=3Dabc;<br><=
br>is syntactically valid or not. I believe it should be, because =
otherwise parsers would need to special-case the "pin-*" parameters when =
parsing.<br><br>Best regards, =
Julian</div></blockquote><br></div><div>Well, this might lead to me =
being proven wrong in my statement that everyone agrees what a valid PKP =
header is, but I also think this should be syntactically valid. However, =
clients that only support *this* document (and not =93xyz and its use in =
key pinning=94) would not pin anything based on this =
header.</div><div><br></div><div>Yoav</div><div><br></div><br></body></htm=
l>=

--Apple-Mail=_E1B49EE1-E1DF-4CB2-BD1A-B984832991CA--