[lamps] AD Review of draft-ietf-lamps-x509-policy-graph-02

[Roman Danyliw <[e-mail]>]

Hi!

I performed an AD review of draft-ietf-lamps-x509-policy-graph-02.  Thanks for the work on this document to address DoS vulnerabilities in X.509 policy validation.  My feedback is below.  It's primarily around how this guidance stiches into revising RFC5280.

** Section 3.1.

   *  An intermediate certificate which asserts policy object
      identifiers (OIDs) OID1, OID2, and OID5.  It contains mappings
      OID1 to OID3, and OID1 to OID4.
…
   This would result in the tree shown in Figure 1.

I don’t see any reference to OID5 in Figure 1.

** Section 4.
   Compared the original policy tree structure described in [RFC5280],
   the policy graph grows linearly instead of exponentially.  This
   document deprecates the original policy tree structure.  X.509
   implementations SHOULD instead perform policy validation by building
   a policy graph.  This mitigates the denial-of-service attack by
   removing the asymmetric cost in policy validation.

-- What does “deprecates” mean in this context and how does this align with the normative SHOULD here and this document updating Section 6 of RFC5280?  Under what circumstance should the RFC5280 algorithm still be used?  Put in another way, deprecate seems to mean “don’t use it” but SHOULD allows for exceptional use whose rational is best documented.

-- Editorial.  s/Compared the original/Compared to the original/.

** Section 4.2

   An implementation which outputs the entire tree may be unable switch
   the format to a more efficient one, as described in Section 4.1.
   X.509 implementations SHOULD NOT output the entire valid_policy_tree
   structure and instead SHOULD limit output to just the set of
   authorities-constrained and/or user-constrained policies, as
   described in [X.509].

I’m having trouble following the link between the first and second sentence.  Under what circumstance should implementations that are using the algorithm in Section 4.1 output the entire valid_policy_tree?

** Section 6.1.
   X.509 validators typically already allow limiting the depth of a
   certificate chain.  This can limit the attack, however a large depth
   limit may still admit attacks.  By modifying the example in
   Section 3.2 to increase the number of policies asserted in each
   certificate, an attacker could still achieve O(N^(depth/2)) scaling
   or higher.

If validators already limit the depth but it is not effective, is further clarifying guidance needed on how to tune this depth parameter?  I’m trying to understand how this is a valid mitigation if the text notes it is still a problem.

** Section 6.2

6.2.  Limit Policy Tree Size

   If existing stable interfaces force the validator to build a full
   policy tree (see Section 4.2), the validator SHOULD limit the number
   of nodes in the policy tree, and reject the certification path if
   this limit is reached.

-- What are “existing stable interfaces”?

-- Can the guidance be given on the configuration of the validator in limited the number of nodes?  What is that a function of?   

Regards,
Roman