Skip to main content

Early Review of draft-ietf-dnsop-structured-dns-error-03
review-ietf-dnsop-structured-dns-error-03-secdir-early-salowey-2023-06-30-00

Request Review of draft-ietf-dnsop-structured-dns-error
Requested revision No specific revision (document currently at 09)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2023-06-30
Requested 2023-05-30
Requested by Tim Wicinski
Authors Dan Wing , Tirumaleswar Reddy.K , Neil Cook , Mohamed Boucadair
I-D last updated 2023-06-30
Completed reviews Dnsdir Early review of -03 by Matt Brown (diff)
Dnsdir Early review of -03 by Di Ma (diff)
Secdir Early review of -03 by Joseph A. Salowey (diff)
Assignment Reviewer Joseph A. Salowey
State Completed
Request Early review on draft-ietf-dnsop-structured-dns-error by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/93om5O_ZadXHv-dS6QEjAgZlu3M
Reviewed revision 03 (document currently at 09)
Result Has issues
Completed 2023-06-30
review-ietf-dnsop-structured-dns-error-03-secdir-early-salowey-2023-06-30-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 is well written and useful. The document does have a good
security considerations section but I think it could be improved.

1. I think it would be good to provide more context for the recommendations in
the security considerations section (and for the processing rules in section
5.3).  For example, the information in if untrusted information in the c, j and
o fields are presented to an end user they may be used to misdirect the user to
contact a malicious party to resolve their problem which could result in
further compromise to the user's security (this could be worded better and
there may be better examples).  I think this may help readers to understand the
implications of not following the recommendations.

2. I find the SHOULD NOT make text clickable difficult.  I don't think that the
text should be clickable in general, but the contact field is essentially a
series of link so the temptation is going to be to make it clickable.  I think
the document should describe better under what conditions the link can be
clickable.  Also its probably worth saying that the fields are rendered as text
and not HTML.

3. Since links involved could be customized to the individual case privacy
considerations may be needed. Following the contact links could possibly reveal
information to another party.

4. A little bit of a nit- In section 5.3 it says if the C and J fields are
missing then discard the whole message, yet later there are cases where you
MUST ignore the C and J fields and yet can still handle the S field.  This
seems a little contradictory to me,  however I think technically its not a
problem and would be implementable as it is.