Skip to main content

Last Call Review of draft-hoffman-dns-in-json-14

Request Review of draft-hoffman-dns-in-json
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-04-20
Requested 2018-03-23
Authors Paul E. Hoffman
I-D last updated 2018-04-26
Completed reviews Opsdir Last Call review of -14 by Shwetha Bhandari (diff)
Secdir Last Call review of -14 by Watson Ladd (diff)
Genart Last Call review of -13 by Stewart Bryant (diff)
Tsvart Last Call review of -14 by Magnus Westerlund (diff)
Genart Telechat review of -15 by Stewart Bryant (diff)
Assignment Reviewer Watson Ladd
State Completed
Request Last Call review on draft-hoffman-dns-in-json by Security Area Directorate Assigned
Reviewed revision 14 (document currently at 16)
Result Has issues
Completed 2018-04-26
---------- Forwarded message ----------
From: Watson Ladd <>
Date: Thu, Mar 29, 2018 at 1:27 PM
Subject: SECDIR review of draft-hoffman-dns-in-json
To: "<>" <>,,

Dear all,

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.

The summary of the review is ready with issues.

I have some very strong reservations about defining a data format
without some strong round-tripping guarantees and with as much
flexibility as this one. The JSON format for DNS packets is intended
to permit representation of malformed packets, and has a high degree
of flexibility, with an intent that applications define profiles of it
for themselves.

There are considerable security implications to doing this not
addressed in the Security Implications section, in addition to obvious
interoperability issues. For example, if we have a filter for JSON
representations of DNS packets, this filter must share the same
semantics for the output JSON as the consumer, even in the face of
such bizzarities as HEX and regular fields with different contents,
malformed length fields, etc. etc. I expect that this can and will
cause serious issues.

I would suggest we not represent invalid packets and ensure all valid
packets have a unique representation. Failing that the security
consideration should at minimum be amended to include a discussion of
these issues. A schema that can be used to validate DNS packets
represented in JSON could also help address these problems.

Watson Ladd

"Man is born free, but everywhere he is in chains".