Subject: Tsvart last call review of draft-hoffman-dns-in-json-14

From: Magnus Westerlund <[email-masked]>
Date: Tue, 24 Apr 2018 08:13:35 -0700

Reviewer: Magnus Westerlund
Review result: Ready with Issues

I've reviewed this document as part of TSV-ART's ongoing effort to
review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors
for their information and to allow them to address any issues raised.
Please always CC tsv-art at ietf.org if you reply to or forward this
review.

Sorry for the late review. Looking at the document I did not find any
"transport" issues but another issue and some nits that I like to raise.

Issue:

Security Consideration

I am missing a reference or discussion to that the contained values in this
format likely contain privacy sensitive information if it can be linked to who
the requester is.

Nits:

Section 2.5:

   o  dateString - The date that the message was sent or received, given
      as a string in the standard format described in [RFC3339], as
      refined by Section 3.3 of [RFC4287]

Why isn't RFC3339 and RFC4287 includes as normative references for this
specification. The above quote indicates that it would be required to look at
these RFCs to implement handling of this value?

Section 2.5:  I wondered over this definition:

   o  dateSeconds - The date that the message was sent or received,
      given as the number of seconds since 1970-01-01T00:00Z in UTC
      time; this number can be fractional

It is not clear from how it is written, but I assume the format for this is a
JSON number, i.e. as defined in Section 6 of rfc8259? Searching the document,
this appears to be the only defined value that uses numbers, is that correctly
noted? Considering that fractional seconds, and the potential for overflow. Any
notes in the context of DNS representation about how small fractional values
that can be represented?

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Apr 2018 15:50:02 +0000

> format likely contain privacy sensitive information if it can be linked to who

It is no more likely in this format than in any format that can be used for traffic logs. If there is a profile of this format that is to be used for traffic between an individual and a server, a privacy consideration in that profile could be warranted.

> these RFCs to implement handling of this value?

Given that all fields for this format are optional, I had a hard time deciding whether things like this would be normative or informative. I can move those refs after the IESG review.

> JSON number, i.e. as defined in Section 6 of rfc8259?

Yes.

> Searching the document,
> noted?

No. Almost everything in Section 2.1 (including the booleans!) are numbers.

> Considering that fractional seconds, and the potential for overflow. Any

This is a matter for JSON (and thus RFC 8259), not for this format, I believe.

--Paul Hoffman

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Apr 2018 09:10:25 +0200

Hi Paul,

See inline.

> It is no more likely in this format than in any format that can be used for traffic logs. If there is a profile of this format that is to be used for traffic between an individual and a server, a p…

Exactly, it is the usage of this format that determines if it will be 
privacy sensitive or not. Thus, I think there is a need to note this 
possibility, and note that it is up to the profile / usage definition of 
this format to define what safe guards are needed. But, I think it is 
necessary to spend a paragraph to be explicit about the potential risk.

> Given that all fields for this format are optional, I had a hard time deciding whether things like this would be normative or informative. I can move those refs after the IESG review.

To my understanding is that all things this specification defines, 
including optional fields or features where one needs to read/understand 
the reference is a normative reference.

Please see IESG statements on normative references, especially note 1:
https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/

> No. Almost everything in Section 2.1 (including the booleans!) are numbers.

This is not that clear. At least not to me. I have limited experience 
with JSON so I try to understand what is written rather than implicit.

    o  All members whose values that are always 16 bits or shorter are
       represented by JSON integers.  One-bit values are represented as
       JSON booleans.

There are no definition of JSON integers in RFC 8259 that I can find.
There is a single mention of integers in the Numbers section.

So maybe that needs to be defined so that it is clear.

> This is a matter for JSON (and thus RFC 8259), not for this format, I believe.

My view is that if there is an underlying limitation to this field 
value, then it would make sense to make that explicit, even if the JSON 
representation has no such limitation. You had no issue doing that 
limitation when it the field is a 16-bit unsigned integer for example. 
Also, it is a question if this encoding of the DNS message accepts loss 
of precision in the field's value. And that I can't judge I don't 
understand the utilization of this field to comment on it.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 28 Apr 2018 20:54:35 +0000

This message goes along with the -15 draft I just submitted. The diffs are at:
   https://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-in-json-15

--Paul Hoffman

On Apr 25, 2018, at 12:10 AM, Magnus Westerlund <[email-masked]> wrote:
> Exactly, it is the usage of this format that determines if it will be privacy sensitive or not. Thus, I think there is a need to note this possibility, and note that it is up to the profile / usage definition of this format to define what safe guards are needed. But, I think it is necessary to spend a paragraph to be explicit about the potential risk.

Got it. I added a Privacy Considerations section that includes that, with an example.

> To my understanding is that all things this specification defines, including optional fields or features where one needs to read/understand the reference is a normative reference.

Done. 

> This is not that clear. At least not to me. I have limited experience with JSON so I try to understand what is written rather than implicit.
> 

No; instead, I (and every JSON-capable person reading the document) didn't realize that when the draft said "JSON integer" and "JSON boolean" for the past few years that it was just talking jibberish. I fixed this to be clear that they are all JSON numbers, and what the limitations of those numbers are.

Side note to everyone: ***this*** is exactly why having external-to-the-clique reviews of Internet Drafts is valuable in the IETF.

> My view is that if there is an underlying limitation to this field value, then it would make sense to make that explicit, even if the JSON representation has no such limitation. You had no issue doing that limitation when it the field is a 16-bit unsigned integer for example. Also, it is a question if this encoding of the DNS message accepts loss of precision in the field's value. And that I can't judge I don't understand the utilization of this field to comment on it.

Yep, I agree.

On Apr 27, 2018, at 5:53 PM, Amanda Baber via RT <[email-masked]> wrote:

> I don't have any insight into whether this is required, but it should be noted that the media type template in the IANA Considerations section doesn't include the "Fragment identifier considerations" and "Deprecated alias names for this type" fields introduced in RFC 6838.

"Fragment identifier considerations" does seem required, but "Deprecated alias names for this type" is an optional subfield of "Notes".