Subject: [secdir] secdir review of draft-ietf-stir-cert-delegation-04

From: Carl Wallace <[email-masked]>
Date: Fri, 14 May 2021 06:32:23 -0400

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the  IESG. These comments were written primarily for the benefit of the  security area directors.  Document editors and WG chairs should treat  these comments just like any other last call comments.

This document describes how authority over telephone numbers and related identifiers can be delegated from a parent certificate to a subordinate certificate. I previously reviewed -03 last summer.

The text that was the focus on my primary concern in the previous review remains in section 4.1 with regard to affirming a TNAuthList is encompassed by its ancestors: 

"This might be performed at the time the delegate certificate
   is issued, or at the time that a verification service receives an
   inbound call, or potentially both.  It is generally desirable to
   offload as much of this as possible to the certification process, as
   verification occurs during call setup and thus additional network
   dips could lead to perceptible delay, whereas certification happens
   outside of call processing as a largely administrative function."

Some new language has been added to the Security Considerations section that states "(h)ow encompassing is policed is therefore a matter outside the scope of this document." I don't think the question is so much how it is policed, which would seem to be a nod to something like CT, but how it is used to affirm "legitimate spoofing". I don't see how a verifier can know whether or not a check has been performed or not. That the primary information used to perform the check can be external to the certificate with no binding to the certificate, no replay protections, limited origin authentication/integrity, etc. heightens the need to know that the values being relied upon are true, i.e., that they pass the encompassing check.

Aside from this and not noted last time, some guidance regarding caching of external TNAuthLists and on verifying the HTTPS certificate may be warranted, given the importance of the external mechanism.