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.