Re: [websec] Pete Resnick's No Objection on draft-ietf-websec-key-pinning-19: (with COMMENT)
Ryan Sleevi <sleevi@google.com> Tue, 05 August 2014 19:14 UTC
Return-Path: <sleevi@google.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89111B2B21 for <websec@ietfa.amsl.com>; Tue, 5 Aug 2014 12:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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 9vM3XTqYiHuG for <websec@ietfa.amsl.com>; Tue, 5 Aug 2014 12:14:46 -0700 (PDT)
Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C2D1B2B24 for <websec@ietf.org>; Tue, 5 Aug 2014 12:14:21 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id la4so2373605vcb.19 for <websec@ietf.org>; Tue, 05 Aug 2014 12:14:20 -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=hfQ66eNp5qSnJQ5wUm+1frCvIPXMnoiHDuYBe80DSIA=; b=fIjqfX8F0AZGbI8yTpHNO+VSJkn0p4apmab9EiapPKxLIBC4MVL9+8+cXalTeuT3sL J3jqKNJHwF21Unc7AsBmDGah0rJuWvYvFma+mulWzpZz5WYMtfVKcx6UlRvqg2rvSzwx z5W3EpEv32GsD7MgBTcBp5DwWwTBEmASdc0+fK7lTH+UYOwyy9wgHfJut5ubHUzPyuze r3WmRm7CXaA0R0wd6hofnuXx8p0sv3YN/AUqENPo0bfaWrNC3y9fi2q/blduc+USK/gg j86DVKqWzT8ddeh28b0MES6YY14AjOnaFx5CdifVXc6y8Z09C7nO2gKGl95fdqSLx2X+ 7hbg==
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=hfQ66eNp5qSnJQ5wUm+1frCvIPXMnoiHDuYBe80DSIA=; b=YvB2dEGjPfjJGWcZFPMbR2GksKnWaZqJpGSQuaGRr+NXKJcSe1HgtqfzoKFsryKMOO x7EAUEA3ORm9D074WgoPXrX80y3swKMSqRjTK2UuW9jRZR+aYFuT/z+jNJPMXiH7gpMB 81y7thbBGJ224QzQabHM2IeN0d/qpYd9ExzCDo/XUe9rSrFE+cbpZcX+aLcY14DuQQiF kEL1x1e6JwZmLqJSjFEXTZWN9TXFwxqgogGUSbTQwW2+TYW37wzSnEZIQTa/E9im78Ux s4mYlpFDCtRrw5wmTP6LXHX2iYJx2CTbXl9H75BdY8E4r1F+p4lIicKzJhLymmjIP4nf 0qwA==
X-Gm-Message-State: ALoCoQkJZK8zITr+cOyZmYMpDICg9VLwU3BX/dBXPTYi7yycljtxyfblOInqB+IL+nEjgoe2rq1L
MIME-Version: 1.0
X-Received: by 10.220.5.1 with SMTP id 1mr3790361vct.73.1407266060423; Tue, 05 Aug 2014 12:14:20 -0700 (PDT)
Received: by 10.52.139.78 with HTTP; Tue, 5 Aug 2014 12:14:20 -0700 (PDT)
In-Reply-To: <20140805004950.9059.81409.idtracker@ietfa.amsl.com>
References: <20140805004950.9059.81409.idtracker@ietfa.amsl.com>
Date: Tue, 05 Aug 2014 12:14:20 -0700
Message-ID: <CACvaWvYVQk0U8KGBY2VkMHhyp=BZ6a4smRtv+JDtVRUVt-r2aw@mail.gmail.com>
From: Ryan Sleevi <sleevi@google.com>
To: Pete Resnick <presnick@qti.qualcomm.com>
Content-Type: multipart/alternative; boundary="001a11c3ec42a2ef8c04ffe6a921"
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/10ush-IZ-lX_D_J7KwoMBr94_wI
X-Mailman-Approved-At: Tue, 05 Aug 2014 13:23:59 -0700
Cc: draft-ietf-websec-key-pinning@tools.ietf.org, "<websec@ietf.org>" <websec@ietf.org>, The IESG <iesg@ietf.org>, websec-chairs@tools.ietf.org
Subject: Re: [websec] Pete Resnick's No Objection on draft-ietf-websec-key-pinning-19: (with COMMENT)
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, 05 Aug 2014 19:14:51 -0000
On Mon, Aug 4, 2014 at 5:49 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote: > Pete Resnick has entered the following ballot position for > draft-ietf-websec-key-pinning-19: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1: The first sentence is quite confusing. Might I suggest instead: > > This document defines a new HTTP header that enables user agents > (UAs) to determine which Subject Public Key Info (SPKI) structures > will be present in the web host's certificate chain in future TLS > [RFC5246] connections. > > 2.1: > > Public-Key-Directives = [ directive ] *( OWS ";" OWS [ directive ] ) > > Are you sure that's correct? First of all, it may be completely empty. > That seems like something you wouldn't want. Second of all, it allows for > semicolons without directives between them, which may or may not be what > you want. It's not clear to me why you made this semicolon-delimited > instead of comma-delimited, which would be much more in line with the > rest of HTTP. Then you'd simply get: > > Public-Key-Directives = 1#directive > Correct. Supporting the #rule directive is NOT desired, because intermediaries are allowed to perform coalescing of such headers, per RFC 7230 3.2.2 That is, as noted in http://tools.ietf.org/html/draft-ietf-websec-key-pinning-19#section-2.3.1 , third paragraph, only the first PKP header field or PKP-RO header field MUST be processed. The concern here is header injection (from hostile script on a host), and to provide a consistent declaration of directive processing. For example, if multiple instances of the Public-Key-Directives headers were processed, a hostile script (such as through obtaining code exploitation on the server) would be able to set additional pins to a certificate/set of certificates under the attacker's control. > > But if you insist on semicolons, you want either: > > Public-Key-Directives = directive *( OWS ";" OWS directive ) > > or if you want to allow for empty elements: > > Public-Key-Directives = *( ";" OWS ) directive *( OWS ";" [ OWS > directive ] ) > > If the following is acceptable: > > Public-Key-Directives: ;;;;; > > then your original is fine. > Correct. The ABNF here is the functionally same as Section 6.1 of RFC 6797. However, 6797 predates the HTTPBis work, in particular, the work in Section 7 of RFC 7230 to specify better semantics for #rule. Compared to 2616 (which allowed ",,," #rule combinations), 7230 Section 7 adopts language similar to what you've proposed. This would be a breaking change to existing implementations (in that headers previously declared valid would not be), but I think it would be good (for consistency with 7230). Before making this change, I think it would be good to get some feedback from the WG members to see if they also agree. > > s/hahs/hash > > 10.1: > > Update 4627 to 7159 > > I think W3C.REC-html401-19991224 is informative. This document says that > you MUST NOT do what's in that document. > > >
- [websec] Pete Resnick's No Objection on draft-iet… Pete Resnick
- Re: [websec] Pete Resnick's No Objection on draft… Ryan Sleevi