[Gen-art] Gen-art LC review of draft-ietf-websec-key-pinning-19
Elwyn Davies <elwynd@dial.pipex.com> Thu, 31 July 2014 13:05 UTC
Return-Path: <elwynd@dial.pipex.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2471B27A2 for <gen-art@ietfa.amsl.com>; Thu, 31 Jul 2014 06:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level:
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 ADiWEEWRyNCH for <gen-art@ietfa.amsl.com>; Thu, 31 Jul 2014 06:05:34 -0700 (PDT)
Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by ietfa.amsl.com (Postfix) with ESMTP id 80C031A0360 for <gen-art@ietf.org>; Thu, 31 Jul 2014 06:05:28 -0700 (PDT)
X-Trace: 115957827/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$OFF_NET_AUTH_ACCEPTED/TUK-OFF-NET-SMTP-AUTH-PIPEX-Customers/81.187.254.252/None/elwynd@dial.pipex.com
X-SBRS: None
X-RemoteIP: 81.187.254.252
X-IP-MAIL-FROM: elwynd@dial.pipex.com
X-SMTP-AUTH: elwynd@dial.pipex.com
X-MUA: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoYIAMw+2lNRu/78/2dsb2JhbABZg2BXAYJ3yCkRh0mBHYUkFS8SLwYCBSECEQJMDQEHAQEFiD0JpSqXWBeBLIwaggaDAIFRBZtkgVKFNI1Ng0prAYEEJA
X-IPAS-Result: AoYIAMw+2lNRu/78/2dsb2JhbABZg2BXAYJ3yCkRh0mBHYUkFS8SLwYCBSECEQJMDQEHAQEFiD0JpSqXWBeBLIwaggaDAIFRBZtkgVKFNI1Ng0prAYEEJA
X-IronPort-AV: E=Sophos;i="5.01,772,1400022000"; d="scan'208";a="115957827"
X-IP-Direction: OUT
Received: from neut-f.netinf.eu (HELO [81.187.254.252]) ([81.187.254.252]) by smtp.pipex.tiscali.co.uk with ESMTP/TLS/DHE-RSA-AES128-SHA; 31 Jul 2014 14:05:26 +0100
Message-ID: <53DA3F13.10007@dial.pipex.com>
Date: Thu, 31 Jul 2014 14:05:23 +0100
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: General area reviewing team <gen-art@ietf.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/_r7EjRD5RYQMe1BuxTeZwUhziv8
Cc: draft-ietf-websec-key-pinning.all@tools.ietf.org
Subject: [Gen-art] Gen-art LC review of draft-ietf-websec-key-pinning-19
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Jul 2014 13:05:38 -0000
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. 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) - 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. 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. Major issues: None Minor issues: s1: The term "Pin" (as a noun) is not explicitly defined. The definition doesn't appear until s2.4. 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 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!] 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. 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: 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. s2.1, Figure 1 caption: The acronym HPKP needs expanding. 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 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). And finally the "Fingerprint" of what SPKI? Defining Pin formally as noted above would help! s2.1, last para: s/hahs/hash/ s4.2/Figure 8: The first line of text is too wide. s5, para 1: Is it really "HSTS or HPKP"? I thought it would be "HSTS combined with HPKP". 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-headers. Also there may be some of the questions in s8.3.1 of RFC 7231 that need specific answers. s5, 2nd top level bullet: Expand SNI acronym.
- [Gen-art] Gen-art LC review of draft-ietf-websec-… Elwyn Davies
- Re: [Gen-art] Gen-art LC review of draft-ietf-web… Yoav Nir
- Re: [Gen-art] Gen-art LC review of draft-ietf-web… Barry Leiba
- Re: [Gen-art] Gen-art LC review of draft-ietf-web… Yoav Nir
- Re: [Gen-art] [websec] Gen-art LC review of draft… Tobias Gondrom
- Re: [Gen-art] [websec] Gen-art LC review of draft… Chris Palmer
- Re: [Gen-art] Gen-art LC review of draft-ietf-web… Chris Palmer
- Re: [Gen-art] Gen-art LC review of draft-ietf-web… Jari Arkko
- Re: [Gen-art] Gen-art LC review of draft-ietf-web… Elwyn Davies
- Re: [Gen-art] Gen-art LC review of draft-ietf-web… Chris Palmer
- Re: [Gen-art] Gen-art LC review of draft-ietf-web… Elwyn Davies
- Re: [Gen-art] Gen-art LC review of draft-ietf-web… Ryan Sleevi