Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: strict privacy

Sara Dickinson <> Thu, 27 October 2016 13:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 238B31294F5 for <>; Thu, 27 Oct 2016 06:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P6sXyTMi_JvP for <>; Thu, 27 Oct 2016 06:45:41 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9FEB1293EE for <>; Thu, 27 Oct 2016 06:45:31 -0700 (PDT)
Received: from [] (port=14401 by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from <>) id 1bzkzc-0003pe-Pt; Thu, 27 Oct 2016 14:45:27 +0100
From: Sara Dickinson <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7331E27B-38EC-45BD-9989-F327C9332F16"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
Date: Thu, 27 Oct 2016 14:45:18 +0100
In-Reply-To: <>
To: Paul Hoffman <>
References: <>
X-Mailer: Apple Mail (2.3226)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id: user confirmed/virtual account not confirmed
Archived-At: <>
Subject: Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: strict privacy
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Oct 2016 13:45:43 -0000

> On 23 Oct 2016, at 00:26, Paul Hoffman <> wrote:
> Greetings. The tone in Section 4 about strict privacy seems completely wrong to me. I recognize that there some users really want to be able to configure strict privacy for themselves, but the text in the section ignores the fact that if strict privacy cannot be achieved in a particular session, a user is likely to turn off DNS-over-TLS. The text here makes opportunistic privacy seem like a weak second cousin, not a legitimate choice for people who want to encrypt where possible. If a user sees "you can't use the Internet because of your setting for DNS over TLS", the result will be less overall privacy than if the document primarily emphasizes opportunistic privacy, and describes strict privacy only for those users who are willing to have no internet connectivity at some times.

Hi Paul, 

We started but didn’t conclude a similar, smaller scale discussion during your review of the -03 version. Based on that discussion I proposed the following text for the end of section 4:

"Strict Privacy provides the strongest privacy guarantees and therefore SHOULD
always be implemented in DNS clients along with Opportunistic Privacy.

A DNS client that implements DNS-over-(D)TLS SHOULD NOT default to the use of
clear text (no privacy). 

The choice between the two profiles depends on a number of factors including
which is more important to the particular client:
*  DNS service at the cost of no privacy guarantee (Opportunistic) or
*  guaranteed privacy at the potential cost of no DNS service (Strict).

Additionally the two profiles require varying levels of configuration (or a
trusted relationship with a provider) and DNS server capabilities therefore DNS
clients will need to carefully select which profile to use based on their 
communication privacy needs. 

A DNS server that implements DNS-over-TLS SHOULD provide at least one credential
in order that those DNS clients that wish to do so are able to use Strict
Privacy (see Section 2).”

I didn’t get any further feedback on this so didn’t include the text in the next version (which I really should have). I’d like to think we could work on improving this text to paint the correct picture of the 2 classes of user and which profile is most suitable for them? 

> Also: why is "hard failure" the fourth bullet describing Opportunistic Privacy? That would only apply to Strict Privacy, correct?

Not necessarily. From RFC7435: “Opportunistic security protocols may hard-fail with peers for which a
   security capability fails to function as advertised. “