Re: [dns-privacy] Datatracker State Update Notice: <draft-ietf-dprive-rfc7626-bis-04.txt>

Eric Rescorla <> Mon, 20 January 2020 22:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C1EA120045 for <>; Mon, 20 Jan 2020 14:38:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mfYgqrQxr5HR for <>; Mon, 20 Jan 2020 14:38:29 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A60D4120128 for <>; Mon, 20 Jan 2020 14:38:28 -0800 (PST)
Received: by with SMTP id o13so711067ljg.4 for <>; Mon, 20 Jan 2020 14:38:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s2A2aVGbwABeSJasVj5q5WemLS4oBzPym+o0zpirgCs=; b=p5xh3gbopzO84PcvCpsriUuolg7Lwqr27ljoj2LwM5TxKOGvuMbEFX4JkAKlr5Kwp1 IVTG2GdYO80j/BFLrs4Bjxdo404tG8J+nfjvAve5Z5TjaVC4UxOJovSMlpjuliPouXmX B8zLl5OQPrc+fvxNCBItgvq57JcQ3wnNUNE3E5QsjZF7gTNmTf2TMGA+DQSDa7onl3jz 6ns1sM3lXh8KlqksKJ/VSW9HUSBeOILpb2iJ94Ej7VVKF3q+EQ9rM/NlB7WnnwXWqyHf EmBWkY+0BDcWKa1jnifMdo9dL3AVqZUZXNzou07G8I/fJmTHR7W8LbIbQ2DqGLAJMGBp Wa6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s2A2aVGbwABeSJasVj5q5WemLS4oBzPym+o0zpirgCs=; b=sRSzwM+RUjhEO9fjKittOrjNEKRgOZA153ya9GHlntqWL0AvmgWqAMjMe/5N8QTqBK ZdkuOYddBb6kHzxTxYVXKS9hnL/Fdf3CawCi2smtOMS9LvTyR+TVHqy4mEKid7eG23zx jYXVwwZD6RZOiQVUJqzceJxYZx78Jr/jzoNJrKF9h7Y9JLKM+FHqKQZmLd0TsEJ4/E+q hK9Wpaohd8GtdPef9beV331qFVUT4LFw1ko3ulaQ2oW2CQzPswYChyRcASTApNC/cHIz SNNwUeogpz9zKblEJI1A7ArkZ+WVj+B0QK9nlvCq2ftTvewWsxyJlua9+YHDCe+a8H5t vjpA==
X-Gm-Message-State: APjAAAVd9DmgAQs1ybUAyBHqMN8afK9fHlcCsLgf0FcVvp761C3J2P2I 5T2pFrZLldiyLNWlCEV2qlanxD453Q9MHQqAc2fVcg==
X-Google-Smtp-Source: APXvYqyzfXxye7rDmI2WEB0RpG+8PV+HfBek3cKJeVFNlEHIALYtPNZphN9QZJTTJCx2COdH3o7k9FWeqGgvqJpxPJw=
X-Received: by 2002:a2e:9015:: with SMTP id h21mr15080756ljg.69.1579559906792; Mon, 20 Jan 2020 14:38:26 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Mon, 20 Jan 2020 14:37:49 -0800
Message-ID: <>
To: "Eric Vyncke (evyncke)" <>
Cc: "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000256d24059c99f324"
Archived-At: <>
Subject: Re: [dns-privacy] Datatracker State Update Notice: <draft-ietf-dprive-rfc7626-bis-04.txt>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Jan 2020 22:38:31 -0000

Review comments attached:

S 3.1.
>      described above, and may not have any confidentiality requirements.
>      However, the same is not true of a single transaction or a sequence
>      of transactions; that transaction is not / should not be public.  A
>      typical example from outside the DNS world is: the web site of
>      Alcoholics Anonymous is public; the fact that you visit it should not
>      be.

Well, technically what you want to conceal is the origin of the
transaction or its linkage to other transactions. The existence of the
query for that A record isn't secret.

S 3.4.2.
>      fingerprint [2] values can be used to fingerprint client OS's or that
>      various techniques can be used to de-NAT DNS queries dns-de-nat [3].
>      Note that even when using encrypted transports the use of clear text
>      transport options to decrease latency can provide correlation of a
>      users' connections e.g.  using TCP Fast Open [RFC7413] with TLS 1.2.

Why does this say TLS 1.2? Any use of TFO will have the same

Perhaps you are thinking of TLS session tickets here?

S 3.4.2.
>      services available.  Given this, the choice of a user to configure a
>      single resolver (or a fixed set of resolvers) and an encrypted
>      transport to use in all network environments can actually serve to
>      identify the user as one that desires privacy and can provide an
>      added mechanism to track them as they move across network
>      environments.

I don't understand this paragraph. It's not the choice of specific
resolvers that leaks data, but the choice to turn on encryption, In
fact, from an identification purpose, the more resolvers that support
encrypted transport, the better signal this is.

S 3.4.2.
>      identify the user as one that desires privacy and can provide an
>      added mechanism to track them as they move across network
>      environments.
>      Implementations that support encrypted transports also commonly re-
>      use sessions for multiple DNS queries to optimize performance (e.g.

Note: session is a technical term in TLS that refers to the
association not the connection. I would say "connection"

>      o  communicate clearly the change in default to users
>      o  provide configuration options to change the default
>      o  provide configuration options to always use the system resolver

I get that you think this is neutral, but all of this is equally true
about dynamic discovery via DHCP, it's just that that's the status
quo, so you don't notice it. In this context, this text is tendentious.

>      Application-specific changes to default destinations for users' DNS
>      queries might increase or decrease user privacy - it is highly
>      dependent on the network context and the application-specific
>      default.  This is an area of active debate and the IETF is working on
>      a number of issues related to application-specific DNS settings.

This, too, could be said about the current situation.

On Mon, Jan 20, 2020 at 1:47 PM Eric Vyncke (evyncke) <>

> Thanks to Sara and Stéphane for the -04 revised I-D.
> After reading the -04, I think that most of the IETF Last Call comments
> are addressed (and consensus needs to be balanced -- even for informational
> document) and that the document sticks to facts.
> But, as section 3.5.1 ("in the recursive resolvers") raised a lot of
> discussions during the first IETF Last Call, and as the authors reacted to
> those comments by deep changes in the text, let's have a new IETF Last Call
> before proceeding with IESG evaluation.
> Again, thank you to the reviewers and the authors
> Regards,
> -éric
> On 20/01/2020, 22:34, "IETF Secretariat" <>
> wrote:
>     IESG state changed:
>     New State: Last Call Requested
>     (The previous state was Waiting for AD Go-Ahead::AD Followup)
>     The previous last call raised several points. The authors have worked
> on those points and this new informational IETF draft has substantive
> changes; enough to go trigger a new IETF Last Call.
>     -éric
>     Datatracker URL:
> _______________________________________________
> dns-privacy mailing list