Re: [dnsoverhttp] [Ext] feedback on draft-hoffman-dns-in-json-11

Paul Hoffman <paul.hoffman@icann.org> Sat, 22 April 2017 16:34 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: dnsoverhttp@ietfa.amsl.com
Delivered-To: dnsoverhttp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514FC1294B9 for <dnsoverhttp@ietfa.amsl.com>; Sat, 22 Apr 2017 09:34:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMLJgRRlV9ew for <dnsoverhttp@ietfa.amsl.com>; Sat, 22 Apr 2017 09:34:18 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B9312949E for <dnsoverhttp@ietf.org>; Sat, 22 Apr 2017 09:34:18 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 22 Apr 2017 09:34:15 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Sat, 22 Apr 2017 09:34:15 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: "Wiley, Glen" <gwiley@verisign.com>
CC: "dnsoverhttp@ietf.org" <dnsoverhttp@ietf.org>, Matthew Miller <m_and_m@mozilla.com>
Thread-Topic: [Ext] [dnsoverhttp] feedback on draft-hoffman-dns-in-json-11
Thread-Index: AQHSuhjsRjKXWNZrbUC82sroJbc1eKHSDbUA
Date: Sat, 22 Apr 2017 16:34:15 +0000
Message-ID: <F7151DFF-6025-429E-A0C5-D3AA5D6ADABA@icann.org>
References: <5729A9DB-03C7-494E-8828-510F40BFEEA2@verisign.com>
In-Reply-To: <5729A9DB-03C7-494E-8828-510F40BFEEA2@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: multipart/signed; boundary="Apple-Mail=_B7560584-4061-4B84-A439-4649E83F2833"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsoverhttp/36qtpE3EyG6k9EoPQKc2SyzTDIQ>
Subject: Re: [dnsoverhttp] [Ext] feedback on draft-hoffman-dns-in-json-11
X-BeenThere: dnsoverhttp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of DNS over HTTP <dnsoverhttp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsoverhttp>, <mailto:dnsoverhttp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsoverhttp/>
List-Post: <mailto:dnsoverhttp@ietf.org>
List-Help: <mailto:dnsoverhttp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsoverhttp>, <mailto:dnsoverhttp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Apr 2017 16:34:20 -0000

On Apr 20, 2017, at 1:58 PM, Wiley, Glen <gwiley@verisign.com> wrote:
> 
> it’s not clear from the Abstract if this draft is proposing the SJON format as an out-of-band telemetry transport format for non-dns-resolver consumption (i.e. transposing RFC1035 queries into JSON format for downstream research, monitoring, etc) or if this is intended to be a new DNS query/response format. This should be clarified in the Abstract.

It is not intended exclusively for either. That's why the abstract says "This document describes a general format for DNS message data in JSON."

>  
> If the intent is the former then this doesn’t raise concerns.
>  
> If the intent is the latter, I have a couple of concerns:
> -          The JSON format may substantially increase the size of the query/response message
> o    In this case, the new format may necessitate TCP vs UDP due to fragmentation
> o    This may increase effectiveness of reflector amplification attacks especially if an attacker is able to query using an RFC1035 format but request a response in JSON format.
> -          DNS privacy – it just makes it that much easier for an observer with little technical knowledge to view DNS traffic information
>  
> Could the same goals (making it easier for applications to examine only parts of a DNS message) be achieved using more terse encoding formats such as ASN.1 or AVRO?

Absolutely. For a current example of a binary format for JSON with a specific use case, see draft-ietf-dnsop-dns-capture-format.

> It’s not clear to me in section 1.1 or 2.6 how we differentiate QNAME label separators in ASCII format and literal dots ‘.’ (0x2E) in QNAME labels. Even though this is not a valid label character, these definitely do occur in the DNS echo system and we need a way to differentiate them from label separators.

This is the exact same problem with the display format described in RFC 1035. If that is a concern for the developer, they should use the "HEX" version of names, which only uses the wireformat.

> Section 1.1, bullet 5 says:
>  
> “The encoding for the DNS object is ASCII as described in [RFC0020].  This is done to prevent an attempt to use a different encoding such as UTF-8 for octets in names or data.”
>  
> Yet, section 4 says:
>  
> Streaming DNS objects is performed using [RFC7464]
>  
> However, section 2, paragraph 2 of RFC7464 says:
>  
> “JSON text sequences MUST use UTF-8 encoding”

ASCII encoding is a proper subset of UTF-8 encoding, so there is no conflict here.

--Paul Hoffman