Telechat Review of draft-ietf-acme-caa-08

Request Review of draft-ietf-acme-caa
Requested rev. no specific revision (document currently at 10)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2019-05-28
Requested 2019-05-17
Authors Hugo Landau
Draft last updated 2019-06-22
Completed reviews Secdir Last Call review of -06 by Hilarie Orman (diff)
Genart Last Call review of -06 by Roni Even (diff)
Secdir Telechat review of -08 by Hilarie Orman (diff)
Assignment Reviewer Hilarie Orman 
State Completed
Review review-ietf-acme-caa-08-secdir-telechat-orman-2019-06-22
Posted at
Reviewed rev. 08 (document currently at 10)
Review result Has Nits
Review completed: 2019-06-22


	                Security review of
     CAA Record Extensions for Account URI and ACME Method Binding

Do not be alarmed.  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

The subject of this document is DNS records describing certificate
issuance policies and how the policies can be made more granular
through the use of two new parameters: accounturi and
validationmethods.  The first parameter designates particular accounts
that can act as CAs for a domain, the second parameter names the
methods that can be used for validation.

This version is laudable in its amplification of the security
considerations section.

Section 5.6 discusses the case in which the CA does not use DNSSEC
and is vulnerable to MITM attacks.  The final paragraph says that
the new parameters are still effective in this case.  I do not think
that it is the intent of the authors to support the idea of a CA
not using DNSSEC, but the text has a positive slant to it, which
might be interpreted as a recommendation.  Some slight wordsmithing
would be helpful.

As nearly as I can tell, there are no security problems.

The phrase "as such" is used 4 times in section 5.  It has no effect
on the meaning of the sentence, and I recommend universal deletion.