[websec] Kathleen Moriarty's Discuss on draft-ietf-websec-key-pinning-19: (with DISCUSS and COMMENT)
"Kathleen Moriarty" <Kathleen.Moriarty.ietf@gmail.com> Thu, 07 August 2014 03:15 UTC
Return-Path: <Kathleen.Moriarty.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 BF4EF1A02E1; Wed, 6 Aug 2014 20:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 TarUbpkhhROR; Wed, 6 Aug 2014 20:15:50 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 911531A0640; Wed, 6 Aug 2014 20:15:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p5
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140807031550.1175.40039.idtracker@ietfa.amsl.com>
Date: Wed, 06 Aug 2014 20:15:50 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/00oWGXS39kqlRr3VxEmo0o4B9vA
X-Mailman-Approved-At: Thu, 07 Aug 2014 15:42:07 -0700
Cc: draft-ietf-websec-key-pinning@tools.ietf.org, websec@ietf.org, websec-chairs@tools.ietf.org
Subject: [websec] Kathleen Moriarty's Discuss on draft-ietf-websec-key-pinning-19: (with DISCUSS and COMMENT)
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: Thu, 07 Aug 2014 03:15:53 -0000
Kathleen Moriarty has entered the following ballot position for draft-ietf-websec-key-pinning-19: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Overall the draft is very good, thank you for writing it. I just wanted to discuss some of the security/privacy considerations and see if we could improve the language and make sure the set of concerns are clear. The privacy consideration section reads more like possible attack scenarios that would fit into the security considerations. What privacy related concerns result from these attacks? Having that spelled out to differentiate the risks as privacy only would be helpful (if appropriate) or moving this into the security consideration section *IF* it is more generically applicable. If I am missing something and this is only privacy related, it would be good to understand that in this discussion. Adding some text on how these attacks could be used to expose privacy related information would be helpful too. For the first example, it seems it is the possibility that a report goes outside out the intended scope is the concern. The mitigation seems to be provided in the last sentence of #4, but couldn't this be other information leakage and not just privacy? Let me know if I am missing something that explains why this is privacy specific. In #3 of the second example, the last sentence includes the following clause: and giving some UAs no Valid Pinning Header for other subdomains (causing subsequent requests for m.fingerprint.example.com to succeed). Does this mean that these subdomains are succeeding when they should fail? It might just be me, but that is not clear in the text (or if they are supposed to succeed). It sounds like they are not supposed to succeed and this is the security issue. How is this privacy specific? Again, this may just be me, but an explanation would be helpful. In the last sentence of the privacy considerations section, what is meant by the description "forensic attacker"? I find this term confusing. Was this intended to mean that techniques used in forensic analysis could be used by an attacker to discern information that could be of interest? If that's the case, I think it would be clearer to the reader if that were stated instead. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Richard's comment that the document is well written and an important document, thank you for writing it. The style changed a little toward the end and I had some trouble with long sentences in the security & privacy considerations sections. This should be easy enough to fix and may be done with the RFC editor anyway. To Richard's point on operational concerns versus security concerns, are there explicit security attacks that could occur with the max-age variations described? In 4.2, I can't see this being more than an operational concern since it fails when overlapping pin sets are not used. Are we missing a gap that leads to a security concern? 4.3 makes sense to me as a security concern that drives operational practices.
- [websec] Kathleen Moriarty's Discuss on draft-iet… Kathleen Moriarty
- Re: [websec] Kathleen Moriarty's Discuss on draft… Ryan Sleevi
- Re: [websec] Kathleen Moriarty's Discuss on draft… Kathleen Moriarty
- Re: [websec] Kathleen Moriarty's Discuss on draft… Barry Leiba
- Re: [websec] Kathleen Moriarty's Discuss on draft… Kathleen Moriarty