From nobody Thu Jul 3 20:52:34 2014 Return-Path: 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 4434F1B2B50 for ; Thu, 3 Jul 2014 20:52:32 -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 u1tqgUZtG_Z3 for ; Thu, 3 Jul 2014 20:52:29 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA2E1B2A40 for ; Thu, 3 Jul 2014 20:52:29 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id w7so1069908qcr.35 for ; Thu, 03 Jul 2014 20:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bj4KRqp7tIBBgXmze21r87o6+faqOoBTFlRKNt0waNs=; b=SR7Ri9CAmsTitNPntJxPvve/8tpcEB9CqyPc0myDXas6MItUso2o0C5ju5exzZr2hO W0ASA4WWKVfK6E9e12VXBgoihZwoLJzOUuSwLgkcEXzZQLBuV1C9XxkE9QPJtMD+rIYa srS98h10IK42ZosKyHMS5+tTA9VTpXfz1xsqX/RtdMKCURCoh3JtMLi+obBS+eBrIJtK wYzic4GzoEUaIHeZ92tGDuogf/fIzthaDbvwuhgTNjEBAPJeMGQEDWfLBE+XCc/heDXF YTkOrhx8oQ2uLCCnsdL3q+wr3wos4t1aQjlJxXH0u0YYvn91RQusZX/wcYkdizAndPTw MrHg== 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=bj4KRqp7tIBBgXmze21r87o6+faqOoBTFlRKNt0waNs=; b=T6cWL3VYMZfImJGpt3dFobnA8JB8L5jaqgtI7buiATFSOiY76Zv21Ieu6FxO9LebiS HEQG3plyaxwyHJmoY3T2NAJpzsAc+zz2pDCKf5Lwg75y5AA7UtxHwWO2W6WPbOP2nqsw 7Cu+YWFbc/JH7I125Shl5RBS7igZvQ9i6KP5c6gHEEyZC+wFLyrfdlO2sEpkOeo+c0V7 q2Om6oDPjBIrcGoeaQxeDOSAukoo1kwhvT6S8bHsVpD998hz2Ra3UChwoQAjyDBx7YDc uZxlM3N3+R6EO7vwWaJ2ML9MLKnBcn1bDaM2PKlp2xb7OV0HoD9FdvKIiMK6gUeryEBX 97Ww== X-Gm-Message-State: ALoCoQky8+yfErKuLTwASsFo4DNMFM9WGgNlq5daOpmhfl3IX9GnhVFCcribV4/OzLOcZ58gNUQz MIME-Version: 1.0 X-Received: by 10.140.32.166 with SMTP id h35mr13437608qgh.114.1404445948237; Thu, 03 Jul 2014 20:52:28 -0700 (PDT) Received: by 10.229.162.3 with HTTP; Thu, 3 Jul 2014 20:52:28 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Jul 2014 20:52:28 -0700 Message-ID: From: Chris Palmer To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/websec/FSG2yI4_peM-uDsy84Egp9wgOc0 Cc: draft-ietf-websec-key-pinning.all@tools.ietf.org, "websec@ietf.org" Subject: Re: [websec] AD review of draft-ietf-websec-key-pinning-17 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 03:52:32 -0000 Thanks Barry, for your many excellent contributions. I've incorporated most everything you and Yoav suggested. Some additional discussion below: On Thu, Jun 26, 2014 at 4:00 AM, Barry Leiba wrot= e: > NEW > When a connection passes Pin Validation using the UA's noted pins > for the Host at the time, the Host becomes a Known Pinned Host. > > According to rule 5, above, the UA MUST ignore pin-directives with > tokens naming hash algorithms it does not recognize. If the set of > remaining effective pin-directives is empty, and if the Host is a > Known Pinned Host, the UA MUST cease to consider the Host as a Known > Pinned Host (the UA should fail open). The UA SHOULD indicate to > users that the Host is no longer a Known Pinned Host. > END > > On the last sentence, though, I'm really unsure: are we really giving > UI advice in a protocol document? Is that a good idea? Do w have any > sense that my mother will have the first idea what you're talking > about when you indicate this to her? We feel that the minimal UI currently implemented in Chrome is necessary for at least developers, operators, and organizational IT staff to debug and generally cope with pinning. (In Chrome, visit https://pinningtest.appspot.com/ and chrome://net-internals/#hsts.) By "users" we mean not only non-technical people, but technical people also. It is indeed likely to be the case that non-technical users will never see any of this UI or care about pinning, but site operators certainly will. Additionally, we want to leave open the possibility that pinning status could be exposed to users in some way. For example, we expose Certificate Transparency status in Chrome: Click on the Lock icon to bring up what we call the Page Info Bubble, then click the Connection tab. The phrase "...does [not] have public audit records" is our CT UI. Obviously, this is more "technical user-facing", but that such indicators may be important for pinning as they are for CT. That said, I am open to softening the language further. > -- Section 2.1.3 -- > What does it mean to use POST on a URI that isn't http or https? What > do you do with a wss URI, for example? I don't think we've considered that. Perhaps we should simply specify HTTP or HTTPS. > The UA MUST ignore all > expired Known Pinned Hosts from its cache if, at any time, an expired > Known Pinned Host exists in the cache. > > Eh? I don't understand what this is trying to say. Do you mean "MUST > *remove* them from its cache? What's with the "at any time" bit? > Please try rephrasing this -- I don't understand it well enough to > try. I gave it a bit of a rewrite, see what you think. > Although the UA has previously received Pins at the HTTP layer, it > can and MUST perform Pin Validation at the TLS layer, before > beginning an HTTP conversation over the TLS channel. The TLS layer > thus evaluates TLS connections with pinning information the UA > received previously, regardless of mechanism: statically preloaded, > via HTTP header, or some other means (possibly in the TLS layer > itself). > > Can you re-word this? It seems very strained, and I don't understand > it. There's no background for telling me what the UA has previously > received. I thought Pins *only* happened with TLS, so how can they > have been received without it? And please avoid phrasing such as "can > and MUST"; it if MUST, it clearly can, or else the MUST is > meaningless. I also re-worded this a bit. > -- Section 2.7 -- > In the first sentence, again, you're giving UI advice, and advice that > I find questionable. This is an option that will *only* be applicable > to expert users, and that won't be understood, much less used, by > 99.999% of UA users (certainly not by my mother). I can't imagine how > such advice, well intentioned though it may be, merits a SHOULD. As above, this might mean something like "your company's IT staff set up pre-loaded pins for your internal mail servers" or "your company's IT staff doesn't want to use the pre-loaded pins that come with Foo Browser." Only the IT people are likely to noodle around in an interface as rudimentary as chrome://net-internals/#hsts, and that is OK. Control of policy should rest in the hands of the device owner, not the UA vendor =E2=80=94 hence the SHOULD. > Because having a backup key pair is so important to recovery, UAs > MUST require that hosts set a Backup Pin. (See Section 2.5.) > > Unless I misunderstand, this requirement means that if my server > doesn't send a backup pin, my server doesn't benefit from key pinning > (it's as though I never included the header in the first place). If > that's not true, then Section 2.5 needs to be fixed to make it clear > that failure to include a backup pin constitutes a validation failure. > > If that is true, then you're trading off recovery for security, and I > expect the Security ADs to question that. To head that off, it might > be good to acknowledge that here, and perhaps to say a few more words > about it. Correct. We discussed this at length during the drafting of the specification, and I'm happy with where we ended up. We are trading off availability vs. extra-bonus-strong authentication. For pinning to be viable in the topsy-turvy world of the internet, we have to do something to help site operators from inadvertantly DoSing themselves. The Backup Pin requirement gives us that, and also serves as a way for the UA (which knows very little) to make some minimal run-time determination of site operator maturity. Publishing the new version of the draft momentarily... From nobody Thu Jul 3 20:52:59 2014 Return-Path: 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 45D061B2B82; Thu, 3 Jul 2014 20:52:52 -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 5sjj3kqXjk6P; Thu, 3 Jul 2014 20:52:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEBF1B2BB3; Thu, 3 Jul 2014 20:52:41 -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.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704035241.4179.31777.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 20:52:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/n9fSkRdKPCeRHt4cdMKGcgIvql4 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-18.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 03:52:52 -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-18.txt Pages : 26 Date : 2014-07-03 Abstract: This document describes an extension to the HTTP protocol allowing web host operators to instruct user agents 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-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-18 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 Fri Jul 4 06:46:31 2014 Return-Path: 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 083C31B2937 for ; Fri, 4 Jul 2014 06:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 wpPrhdeSvNiI for ; Fri, 4 Jul 2014 06:46:27 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520931B27B0 for ; Fri, 4 Jul 2014 06:46:27 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id hr17so1188055lab.4 for ; Fri, 04 Jul 2014 06:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NKA6zKnTdmAsvjpwebfk8+g+rsTOyPDbbLvJBkBFkP0=; b=sWwZyuPO4o/nnLUA6TLrlRh0O9EF4dc/Lwh3n/dkkf2AWNgg1DYc1Fvy0LVXN00rbw PXUxaruRzGVFzrOGv4CmUeclPJmzwXdlagsbiV/f9+G2kndLxVlD3eyGjyAAx+sM3Boc 6IcFQXbuydwW1WVKPyo5rLA/d1q9YAEWosW7IF3hEexYxU31eYsKj1Di96NXDptDvmNB oRESQiaPKkB0zoHuk5ANicdVHnHBdzDpTE/Cp7UGIJ3yb9mx58SK+gX01HzhmNqbhzZC 8ups/2JZkvytw4OUZxrcqKK02b2MjWcUJb9mc5Fp6thfJwRRDbvwwllTjmm9rjSnYsWU Yn8A== MIME-Version: 1.0 X-Received: by 10.112.134.97 with SMTP id pj1mr8089760lbb.9.1404481585615; Fri, 04 Jul 2014 06:46:25 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Fri, 4 Jul 2014 06:46:25 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Jul 2014 09:46:25 -0400 X-Google-Sender-Auth: DE802j95Y7ypi64DViCwgnlLqAk Message-ID: From: Barry Leiba To: Chris Palmer Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/zBtvSa2eiwGKfdz0MmVL-izWuvQ Cc: draft-ietf-websec-key-pinning.all@tools.ietf.org, "websec@ietf.org" Subject: Re: [websec] AD review of draft-ietf-websec-key-pinning-17 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 13:46:29 -0000 Hey, Chris. Thanks for all the changes, and after I send this message I'll request last call. I think I'll make it a four-week last call, because there won't be a telechat we can put it on until after that anyway, so we might as well give people time during and after the IETF meeting to comment. The only thing we still have in contention is the UI advice, and I'm not going to let that hold anything up at this point. Further comments: >> The UA SHOULD indicate to >> users that the Host is no longer a Known Pinned Host. >> >> On the last sentence, though, I'm really unsure: are we really giving >> UI advice in a protocol document? Is that a good idea? Do w have any >> sense that my mother will have the first idea what you're talking >> about when you indicate this to her? > > We feel that the minimal UI currently implemented in Chrome is > necessary for at least developers, operators, and organizational IT > staff to debug and generally cope with pinning. (In Chrome, visit > https://pinningtest.appspot.com/ and chrome://net-internals/#hsts.) By > "users" we mean not only non-technical people, but technical people > also. It is indeed likely to be the case that non-technical users will > never see any of this UI or care about pinning, but site operators > certainly will. > > Additionally, we want to leave open the possibility that pinning > status could be exposed to users in some way. For example, we expose > Certificate Transparency status in Chrome: Click on the Lock icon to > bring up what we call the Page Info Bubble, then click the Connection > tab. The phrase "...does [not] have public audit records" is our CT > UI. Obviously, this is more "technical user-facing", but that such > indicators may be important for pinning as they are for CT. > > That said, I am open to softening the language further. On this, as well as the other points of UI advice (Section 2.7, at least; I don't remember whether any others remain), I still think it's not a good idea for the protocol spec to give UI advice, but I'm OK with leaving it in if we don't use 2119 language for it. 2119 is specifically for protocol interoperability issues. So let's make the SHOULDs be "should"s, and then see if anyone else raises an issue with that. >> -- Section 2.1.3 -- >> What does it mean to use POST on a URI that isn't http or https? What >> do you do with a wss URI, for example? > > I don't think we've considered that. Perhaps we should simply specify > HTTP or HTTPS. That's probably best, if we're not sure of the answer. You can say that extensions to this can specify how key pinning is used with other protocols. >> Because having a backup key pair is so important to recovery, UAs >> MUST require that hosts set a Backup Pin. (See Section 2.5.) >> >> Unless I misunderstand, this requirement means that if my server >> doesn't send a backup pin, my server doesn't benefit from key pinning >> (it's as though I never included the header in the first place). If >> that's not true, then Section 2.5 needs to be fixed to make it clear >> that failure to include a backup pin constitutes a validation failure. >> >> If that is true, then you're trading off recovery for security, and I >> expect the Security ADs to question that. To head that off, it might >> be good to acknowledge that here, and perhaps to say a few more words >> about it. > > Correct. We discussed this at length during the drafting of the > specification, and I'm happy with where we ended up. We are trading > off availability vs. extra-bonus-strong authentication. For pinning to > be viable in the topsy-turvy world of the internet, we have to do > something to help site operators from inadvertantly DoSing themselves. > The Backup Pin requirement gives us that, and also serves as a way for > the UA (which knows very little) to make some minimal run-time > determination of site operator maturity. OK. Enough said on this, then -- leave it as it is. So: I'll wait a couple of hours to give you time to post one more revision, if you want to make the changes above. Whether or not you do, I'll request the last call then. (Please don't post a revision after you see the last call requested... we can save the changes for later, at that point.) Again, thanks for all the work on this! Barry From nobody Fri Jul 4 10:46:55 2014 Return-Path: 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 610131A03D8 for ; Fri, 4 Jul 2014 10:46:52 -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 qyuGgKSJ1-Kt for ; Fri, 4 Jul 2014 10:46:50 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51511A0021 for ; Fri, 4 Jul 2014 10:46:50 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id f51so1640252qge.25 for ; Fri, 04 Jul 2014 10:46:49 -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=bBjFwE3haxDz5jSbhv2Zj6IgfeFg90X23+vDnOSO4y4=; b=U4O2VE7Yz6k32UtTkfkA5uTYbE5q9D4VVWzHahJovAB5/tnGfE52xy+YCfs/EI3zJp ysi9SnGcGb86HLFOLjWmzmHs2k4qv3wFkHM4gzLv/22ThF3t/OBZJlnHsc7IuraM6DdX ciHxMT9nGQ4rjJYyr3HpU8CSK8vT19VqaQMiotn73ZKmfgpm5ohT9+Woj3RXKkNzgTmG NVqMDhRjusFJmazr0JQTkfDymzRpsZ4eBWmtshRd2qAXdGKCdcqPNPbUNIfxGsIzHUJX KRLfmDSnoUmVzEzii6TcyvI5w5WwhrfKobckXDa9VOB5LNI57h6HeXqu4GG6FkLZiRqj uVhg== 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=bBjFwE3haxDz5jSbhv2Zj6IgfeFg90X23+vDnOSO4y4=; b=V1iVoIJKDDUpmrAInMi0IhJG3e3003f9vZl9/QW5UKCEJFIBnDcVdjWkYm7yc9tXk2 jYoF6yQFBYERHqBXxCRl8ZcEVusY13bfJASwKAMa/o2sVC0ukmxj6CVK2tCRx7YTk2fQ xbEOGrBVZV2Yss8kFtUm2RY0TKUcgdo9ofzsLw2CWLgmPye4SaZ2lz6EJvlOYQwfey7n 7yRdZMUpMD8HLq2RcQsppEJLa/2cbwPoP9nPgTmItE1TBtH10geJCpG5B7AAw//i7iPN G0BnqWbSfWCEWxvOKnrZEuaWPfb441J+gZ9Q5ZiDYcOn9FcqZVGO2tXAWbZB1VhCTqJR PytA== X-Gm-Message-State: ALoCoQln45WuEZY79+xVqqW8UQ2vpLJCCY8VCAM9OScRE7sSTTQY52I7gAPOFfvVP0h4P509rgxK MIME-Version: 1.0 X-Received: by 10.224.13.139 with SMTP id c11mr20836611qaa.77.1404496009859; Fri, 04 Jul 2014 10:46:49 -0700 (PDT) Received: by 10.229.162.3 with HTTP; Fri, 4 Jul 2014 10:46:49 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Jul 2014 10:46:49 -0700 Message-ID: From: Chris Palmer To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/gVrJkRGjhmEcFz7GEUqZns_BpN4 Cc: draft-ietf-websec-key-pinning.all@tools.ietf.org, "websec@ietf.org" Subject: Re: [websec] AD review of draft-ietf-websec-key-pinning-17 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 17:46:53 -0000 On Fri, Jul 4, 2014 at 6:46 AM, Barry Leiba wrote: > Hey, Chris. Thanks for all the changes, and after I send this message > I'll request last call. I think I'll make it a four-week last call, > because there won't be a telechat we can put it on until after that > anyway, so we might as well give people time during and after the IETF > meeting to comment. OK, sounds good. New version is on the way; as always, you can see the diffs at https://code.google.com/p/key-pinning-draft/source/list. Thanks again Barry, and everyone! From nobody Fri Jul 4 10:47:11 2014 Return-Path: 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 4D5831B2CC7; Fri, 4 Jul 2014 10:47:08 -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 ebWeK8AbDCrQ; Fri, 4 Jul 2014 10:47:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0991B2D88; Fri, 4 Jul 2014 10:47:00 -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.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704174700.26194.62597.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 10:47:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/MWiJm-Nn-d88UT3bcDWL9-E6hVg Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-19.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 17:47:08 -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-19.txt Pages : 26 Date : 2014-07-04 Abstract: This document describes an extension to the HTTP protocol allowing web host operators to instruct user agents 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-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-19 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 Sun Jul 6 06:58:51 2014 Return-Path: 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 D0AEF1A0317 for ; Sun, 6 Jul 2014 06:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 sE5ngfH8JGyG for ; Sun, 6 Jul 2014 06:58:48 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C651A0312 for ; Sun, 6 Jul 2014 06:58:48 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jw12so2999824veb.25 for ; Sun, 06 Jul 2014 06:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=JXliou0eJF+5pEWxxMXN1OckzNcISGDXrAtaYOK9Ycw=; b=JwdBZOBRcQKf9/CtkLKN6Xr38RRFlXyqylqRvdjW75YeB7ojGyKIcnsP2LGCu9I8pC W3ouD11jjgvrSRF+DNwOVZsUSUzR9t18xDcpDaby57ekxZkn2/KcQVR6083DcWK0ycAK Fw2buvF5MyXQ802gK+ICJo3wwoYYFEFSoWtc2iGYJFNJ5F8zu3Q9azig8J2LKX9ynjMn T7YAWgZ45QE632E0UTlQECm87bH7Z6cX+UebLNvMcIEBF9kCBD5gnm9dRJ6xJR5606bv LGWp2tCiTQ1KAEUEseZdc/jDud/ax5zMwBDkh6ETPf94rHi5l11INTqRcysUBWnuC6N7 CcpA== MIME-Version: 1.0 X-Received: by 10.220.68.140 with SMTP id v12mr21644630vci.13.1404655127834; Sun, 06 Jul 2014 06:58:47 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.106.73 with HTTP; Sun, 6 Jul 2014 06:58:47 -0700 (PDT) In-Reply-To: References: Date: Sun, 6 Jul 2014 09:58:47 -0400 X-Google-Sender-Auth: n8cSysLGBSkhnDrqif_V3vR-x8E Message-ID: From: Barry Leiba To: Chris Palmer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/KPwbQ-KI4o27m03nQ8d-fwMxr2M Cc: draft-ietf-websec-key-pinning.all@tools.ietf.org, "websec@ietf.org" Subject: Re: [websec] AD review of draft-ietf-websec-key-pinning-17 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 13:58:50 -0000 >> Hey, Chris. Thanks for all the changes, and after I send this message >> I'll request last call. I think I'll make it a four-week last call, >> because there won't be a telechat we can put it on until after that >> anyway, so we might as well give people time during and after the IETF >> meeting to comment. > > OK, sounds good. New version is on the way; as always, you can see the > diffs at https://code.google.com/p/key-pinning-draft/source/list. For everyone's info: I did request last call on this on Friday, but, as it was a U.S. holiday followed by a weekend, the Secretariat hasn't been there yet to act on it. Expect to see the last call message go out on Monday. Barry From nobody Mon Jul 7 06:02:08 2014 Return-Path: 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 9F5E71A0406; Mon, 7 Jul 2014 06:02:05 -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 hcgOmx9eEV5k; Mon, 7 Jul 2014 06:02:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7B11A0016; Mon, 7 Jul 2014 06:02:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140707130204.24073.7638.idtracker@ietfa.amsl.com> Date: Mon, 07 Jul 2014 06:02:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/GYUzqacSUGgbqte9OtIHzD0fRaM Cc: websec@ietf.org Subject: [websec] Last Call: (Public Key Pinning Extension for HTTP) to Proposed Standard X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 13:02:06 -0000 The IESG has received a request from the Web Security WG (websec) to consider the following document: - 'Public Key Pinning Extension for HTTP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-08-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an extension to the HTTP protocol allowing web host operators to instruct user agents 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jul 7 06:32:51 2014 Return-Path: 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 7DF1D1A0407 for ; Mon, 7 Jul 2014 06:02:13 -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 T56MDhqBimf2; Mon, 7 Jul 2014 06:02:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EBA1A001B; Mon, 7 Jul 2014 06:02:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: websec-chairs@tools.ietf.org, draft-ietf-websec-key-pinning@tools.ietf.org, websec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140707130206.24073.33600.idtracker@ietfa.amsl.com> Date: Mon, 07 Jul 2014 06:02:06 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/websec/4fpK9ODWgr65TbLWpqf8RHnolKA X-Mailman-Approved-At: Mon, 07 Jul 2014 06:32:47 -0700 Subject: [websec] ID Tracker State Update Notice: X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 13:02:13 -0000 Last call has been made for draft-ietf-websec-key-pinning and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ From nobody Thu Jul 31 12:27:55 2014 Return-Path: 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 515611A002A; Thu, 31 Jul 2014 12:27:52 -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 WTUx6w4WcUDW; Thu, 31 Jul 2014 12:27:49 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE901A000F; Thu, 31 Jul 2014 12:27:48 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so3270562wes.4 for ; Thu, 31 Jul 2014 12:27:47 -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=6QQszF5KsO2gg+eEaXufO+VRxMS87kBLtH9TGXrnX00=; b=IFse8Sg412RtKiuLTlV57NZxLaglbqvFdRTO/t1zw0Mhb9IP++uYBm2SWUu5qmTQoU 3lVV5QhYQv+QsBAVvnlbk4cO3+zEq5dPoINttqslyYnLdMmTxds5bQBDqHgYJItuayLY yyjxl8upbMKWAh4DjJrbQE7igB9eGWjdo3mV2In51+GVqvXnAtF/eesV/LFo9i27wFeq qW0UZCoQBoMQ+4KLQf3XD0/QkLqDh6o8rH3VutoEpbNSG8JTInwGviQs0eoLb7bcbDCZ tNy7U4qef/87+gI8VggXZvly5UEEkfQv7qrgeyEZ1MlwkP5dalTJCMpADByzr4DefysA 2j6g== X-Received: by 10.180.92.134 with SMTP id cm6mr444539wib.72.1406834866080; Thu, 31 Jul 2014 12:27:46 -0700 (PDT) Received: from [192.168.1.104] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id g8sm797828wib.18.2014.07.31.12.27.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 12:27:45 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <53DA3F13.10007@dial.pipex.com> Date: Thu, 31 Jul 2014 22:27:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53DA3F13.10007@dial.pipex.com> To: Elwyn Davies X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/zuezEWdLRyCqtW6blSblHuMDVZA Cc: draft-ietf-websec-key-pinning.all@tools.ietf.org, General area reviewing team , IETF WebSec WG Subject: Re: [websec] Gen-art LC review of draft-ietf-websec-key-pinning-19 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 19:27:52 -0000 Hi, Elwyn [ adding the WebSec mailing list ] Thanks for the review. I think the editorial comments and the = un-expanded initialisms are not controversial. The text in section 4.1 = contains our hard-earned consensus about maximum max-age. Perhaps your = comment about section 2.1.1 can be accommodated by pointing to section = 4.1 from section 2.1.1. As for the rest, I will leave up to the group, but I might also comment = as an individual. To the WebSec group: please send in comments about this. A GenArt review = (just like *Dir reviews that are likely to come in the next few days) = should be addressed just like any other comments. Pushing back is fine = if we think they are inappropriate, but comments about lack of clarity = tend to be correct when they=92re made by someone outside the working = group - someone who reads the document without having participated in = the discussion on-list and at meetings. Making changes is still up to = the working group, so please go over Elwyn=92s comments. Yoav As co-chair and document shepherd. On Jul 31, 2014, at 4:05 PM, Elwyn Davies wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-websec-key-pinning-19.txt > Reviewer: Elwyn Davies > Review Date: 31 July 2014 > IETF LC End Date: 1 August 2014 > IESG Telechat date: (if known) - >=20 > Summary: > Almost ready. There are some minor issues some of which may be as a = result of some > misunderstanding on my part. The descriptive text in the early part = of s2 is missing > some definitions that make it unclear until they appear later on. = This makes the early > descriptions more confusing that illuminating in places. Suggestions = in the detailed > comments below. >=20 > One thing that is not fully clear to me and could probably be = explained to help others > is the start up of the pinning mechanisms for a given host domain. = AFAICS Pin validation > would possibly not be carried out on a first connection to a domain = when there are no > preconfigured Pins. I am not clear if this adds anything to the risk = of a MITM attack or > does it in any way negate the value of the whole pinning process? I = was not clear if > an effective Pin validation should be carried out during the first = connection when the > UA receives the host's Pins for the first time and decides that it is = now a Pinned Host, > in that the document doesn't state that the connection is terminated = if the setting up > of the Pinned host fails because the certs don't validate. >=20 > Major issues: > None >=20 > Minor issues: > s1: The term "Pin" (as a noun) is not explicitly defined. The = definition doesn't appear > until s2.4. >=20 > s2.1.1: I'm not sure if this could be an issue.. should a maximum = possible value for max_age > be specified to avoid UA's being cluttered up with old Pins - this = might possible be a DoS > attack vehicle but I am not sure (yet) if it could be. OK.. so s2.3.3 = talks about limits. > A pointer to this discussion would be useful here >=20 > s2.2.1: Does this response behaviour apply to all possible request = types? Once a server has sent a > Pin header should it send it again on all subsequent requests on the = same TLS connection or is > that a choice? Given the "SHOULD" in s2.2.1, what are the = circumstances in which the server should > refrain from sending the Pins? [I first thought about 'Redirects' but = realized that that was probably > a really good time to send Pins!] >=20 > s2.3.1/s2.4: S2.4 states that hash algorithms might be deprecated in = future. Presumably a > deprecated algorithm should be treated as an unrecognized directive or = some such to avoid > downgrade attacks. Probably worth being explicit about this. Also = this is potentially > incompatible with the statement that 'UAs MUST recognize "sha256"' = (Para 3 of s2.4). > This results in a potential downgrade attack when and if SHA256 is = deemed to be no longer > cryptographically effective. I think this statement can be removed as = presently a UA > has no other option if it is to implement the specification. >=20 > s2.6: >> Note that the UA MUST perform Pin Validation when setting up the = TLS >> session, before beginning an HTTP conversation over the TLS = channel. > I suspect I am confused: If a UA is making its first connection to a = host for which it doesn't > have a preconfigured Pin, then it won't get the Pin(s) from the host = until it has set up the > TLS connection and received the response to the request at the HTTP = protocol level. In that case > Pin validation will pass by default (subject to local policy perhaps) = since the cache doesn't have > entries for the host. Presumably the UA should then perform Pin = validation if it has passed by > default during TLS setup (assuming that this is possible given the = layering) or does the UA have to > terminate the session and restart it so that Pin validation can be = performed? The second case may > give scope for a DoS attack. Or is it the case that Pin validation is = not needed on the first > connection... I don't see why this shouldn't be done but I may not = understand the problem. I think > some clarification about the startup of the process is needed. > Nits/editorial comments: >=20 > s1, last para: s/toegether/together/, s/but is possible/but it is = possible/ > s2.1: It would be good to expand the term OWS. >=20 > s2.1, Figure 1 caption: The acronym HPKP needs expanding. >=20 > s2.1, 2nd para after numbered bullets: > It is not the definition of hash algorithms that is relevant, but = allowing them to be > used in pin-directives thus: > OLD: > additional algorithms may be defined in the future > NEW: > additional algorithms may be allowed for use in this context in future >=20 > Also the implication of the "sha256" name should be explained = precisely - > i.e, that the SHA256 hash algorithm will be used, and a suitable = reference > for SHA256 should be given. (Again this doesn't happen until s2.4). >=20 > And finally the "Fingerprint" of what SPKI? Defining Pin formally as = noted above would help! >=20 > s2.1, last para: s/hahs/hash/ >=20 > s4.2/Figure 8: The first line of text is too wide. >=20 > s5, para 1: Is it really "HSTS or HPKP"? I thought it would be "HSTS = combined with HPKP". >=20 > s6: Needs to be more precise about *which* message headers repository = is to be updated! Presumably > the permanent one at = http://www.iana.org/assignments/message-headers/message-headers.xml#perm-h= eaders. >=20 > Also there may be some of the questions in s8.3.1 of RFC 7231 that = need specific answers. >=20 > s5, 2nd top level bullet: Expand SNI acronym. >=20