[Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rpki-tree-validation-02: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Tue, 28 August 2018 16:35 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F31130DF9; Tue, 28 Aug 2018 09:35:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sidrops-rpki-tree-validation@ietf.org, Chris Morrow <morrowc@ops-netman.net>, sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153547412129.23827.3324575091222487462.idtracker@ietfa.amsl.com>
Date: Tue, 28 Aug 2018 09:35:21 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/tTSLq-JpC9_5HwiNiBkzXJaVv3k>
X-Mailman-Approved-At: Tue, 28 Aug 2018 12:16:41 -0700
Subject: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rpki-tree-validation-02: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.27
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Aug 2018 16:35:22 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-sidrops-rpki-tree-validation-02: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document is Informational, so I will make my comments non-blocking, but I think that the security considerations could be improved. It currently does a good job talking about cases where the procedure can receive inconsistent inputs (and how it behaves in the face of those inputs), as well as some other considerations, and this is great! I think that the discussion could be more powerful if it also considered how those inconsistent inputs could be produced, in particular which capabilities an attacker could have. There seem to be roughly three classes of actors for active attacks -- an attacker in the network could modify the transferred content (including number of files and directory layout) over unecrypteed rsync or http, an attacker that compromises the webserver's certificate (or obtains a fraudulent one) could do the same over encrypted https, and an attacker that compromises the TA signing key could produce fake-but-"valid" manifests, CRLs, etc.. (Is there more that could be done with a compromised non-TA CA? The potential hazards to this algorithm don't seem to be noticably distinct, though.) Some consumers may be willing to trust in the TA's integrity or even the Web PKI and not worry about those risks. Though there is always risk of accidental error, of course, and the current coverage in this document seems adequate for that risk. Some additional section-by-section comments follow. Section 3.1 The key properties needed of cryptographic hash functions are either "collision resistance" or "second preimage resistance", depending on whether the attacker gets to pick both hash inputs (the first case) or only one of them (the second). Which one is needed here would probably depend on whether the CA/issuer is trusted to not be an attacker or not, but regardless, please use the more detailed terminology. Section 3.2 [...], or use all objects whose AKI extension matches the Subject Key Identifier (SKI) extension (Section 4.2.1 of [RFC5280]) of a CA certificate. "all objects" as discovered within what scope? Section 4.2 Please expand SIA on first usage. In bullet point 1, it might help the uninitiated reader to say something after "and pass it to the object fetcher" to note that "the fetcher will then fetch all objects available from that repository". In bullet point 3, please be more clear about which manifest is "this manifest object" that is used to continue validation processing. 4. Perform manifest entries discovery and validation as described in Section 4.2.2. nit: "manifest entry discovery" (singular "entry") (Note that this implementation uses the operator configuration to decide which algorithm to use for path validation. It applies selected algorithm to all resource certificates, rather than nit: "the selected algorithm" Please expand ROA on first usage. Section 5.1.1, 5.1.2 The syntactic verification performed here is done on what should be considered "untrusted input", which means that the verification code needs to be written in a robust manner. (Given the historical recurrences of, e.g., ASN.1 decoder security vulnerabilities, we probably need to explicitly state this in the security considerations.) Section 9.1 If I understand correctly, RFC 6485 allows for (and predicts the need for) hash agility in the file hash algorithm. In this case, it would probably be appropriate to say something about how "the security of the system as a whole is limited to that of the weakest hash function allowed by consumers, but the hash agility provided for by RFC 6485 allows new (stronger) hashes to be introduced and old hash functions phased out before they are critically broken". Section 9.2 In case of a mismatch described above this implementation will not exclude an object from further validation merely because it's actual nit: "its" (no apostrophe) Section 9.3 nit: Which behavior is allowed-but-not-required -- a CA signing things not listed in the manifest, or an RP ignoring things not listed in the manifest? I suggest "This RP behavior is allowed [...]". Section 9.4 This kind of behavior would be seen as an unacceptable vulnerability in a standards-track protocol, though since this document is only informational it does not block publication. Section 9.5 It might be useful to reference Section 5.1.1 and how we sometimes fetch the entire repository contents, not limited by a manifest listing.
- [Sidrops] Benjamin Kaduk's No Objection on draft-… Benjamin Kaduk
- Re: [Sidrops] Benjamin Kaduk's No Objection on dr… Oleg Muravskiy
- Re: [Sidrops] Benjamin Kaduk's No Objection on dr… Benjamin Kaduk
- Re: [Sidrops] Benjamin Kaduk's No Objection on dr… Oleg Muravskiy
- Re: [Sidrops] Benjamin Kaduk's No Objection on dr… Benjamin Kaduk
- Re: [Sidrops] Benjamin Kaduk's No Objection on dr… Oleg Muravskiy