Subject: [DNSOP] Last Call: <draft-ietf-dnsop-qname-minimisation-07.txt> (DNS query name minimisation to improve privacy) to Experimental RFC

From: The IESG <[email-masked]>
Date: Mon, 09 Nov 2015 18:48:51 -0800

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'DNS query name minimisation to improve privacy'
  <draft-ietf-dnsop-qname-minimisation-07.txt> as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2015-11-23. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document describes one of the techniques that could be used to
   improve DNS privacy, a technique called "QNAME minimisation", where
   the DNS resolver no longer sends the full original QNAME to the
   upstream name server.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-qname-minimisation/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-qname-minimisation/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/2469/
   https://datatracker.ietf.org/ipr/2542/

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 11 Nov 2015 11:23:01 +0100

On Mon, Nov 09, 2015 at 06:48:51PM -0800,
 The IESG <[email-masked]> wrote 
 a message of 35 lines which said:

> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send substantive
> comments to the [email-masked] mailing lists by 2015-11-23.

I have the personal feeling that documents with intended status
"Experimental" require more or less the same quantity of efforts and
scrutiny as the ones intended for the standards track :-(

---

From: Maarten Wullink <[email-masked]>
Date: Wed, 11 Nov 2015 12:32:55 +0100

I just read you draft about qname minimisation again and i discovered
that besides limiting the number of labels the resolver is sending to
the authoritative it also proposes to replace the qtype with "NS" when
sending queries to authoratives.

This is understandable for privacy concerns but it also makes it
impossible (or at least much more difficult) to perform security
analysis at the vantage point of the authoritive server operator such
as a ccTLD.

Detecting spamruns when the MX count/percentage is suspicious is a use
case that will no longer be possible. Other security detection algo's
will probaly also suffer.

Is this something the group discussed? and maybe something you want to
add to the security section of the draft?

Cheers,

Maarten

Op 11-11-15 om 11:23 schreef Stephane Bortzmeyer:
> On Mon, Nov 09, 2015 at 06:48:51PM -0800, The IESG
> <[email-masked]> wrote a message of 35 lines which said:
> 
> "Experimental" require more or less the same quantity of efforts
> and scrutiny as the ones intended for the standards track :-(
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
> 

- -- 
Maarten Wullink | Research Engineer
SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM
T +31 (0)26 352 55 45 | M +31 (0)6 21 26 87 55 | F +31 (0)26 352 55 05
[email-masked] | www.sidn.nl
pgp key: http://pgp.mit.edu/pks/lookup?op=get&search=0x4F2A495C4B1BF08B

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 13 Nov 2015 09:08:26 +0100

On Wed, Nov 11, 2015 at 12:32:55PM +0100,
 Maarten Wullink <[email-masked]> wrote 
 a message of 63 lines which said:

> I just read you draft about qname minimisation again and i
> discovered that besides limiting the number of labels the resolver
> is sending to the authoritative it also proposes to replace the
> qtype with "NS" when sending queries to authoratives.
> 
> analysis at the vantage point of the authoritive server operator
> such as a ccTLD.

This is known (section 5) and discussed in appendix B. 

> Is this something the group discussed? and maybe something you want
> to add to the security section of the draft?

It was a consequence of the Dallas meeting where the point was raised
<https://www.ietf.org/proceedings/92/slides/slides-92-dnsop-0.pdf> and
the consensus was clearly to focus on the most privacy-preserving
solution, leaving alternatives in appendixes
<http://www.ietf.org/proceedings/92/minutes/minutes-92-dnsop>.

See also <https://github.com/bortzmeyer/my-IETF-work/issues/9>,
<https://github.com/bortzmeyer/my-IETF-work/issues/11>,
<https://centr.org/system/files/share/centr-report-ietf92-20150518_0.pdf>
(section "More Privacy Work in DNSOP")