Skip to main content

Telechat Review of draft-ietf-stir-cert-delegation-04
review-ietf-stir-cert-delegation-04-secdir-telechat-wallace-2021-05-20-00

Request Review of draft-ietf-stir-cert-delegation
Requested revision No specific revision (document currently at 04)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2021-04-20
Requested 2021-04-13
Authors Jon Peterson
Draft last updated 2021-05-20
Completed reviews Genart Last Call review of -03 by Ines Robles (diff)
Secdir Last Call review of -03 by Carl Wallace (diff)
Secdir Telechat review of -04 by Carl Wallace
Assignment Reviewer Carl Wallace
State Completed
Review review-ietf-stir-cert-delegation-04-secdir-telechat-wallace-2021-05-20
Posted at https://mailarchive.ietf.org/arch/msg/secdir/-wD2FqxjZtGUHZJm06ApKNpClHU
Reviewed revision 04
Result Has Issues
Completed 2021-05-14
review-ietf-stir-cert-delegation-04-secdir-telechat-wallace-2021-05-20-00
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.