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

Sara Dickinson <> Fri, 28 October 2016 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52F0E12944A for <>; Fri, 28 Oct 2016 09:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JsEDWd1836It for <>; Fri, 28 Oct 2016 09:08:34 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4602129407 for <>; Fri, 28 Oct 2016 09:08:33 -0700 (PDT)
Received: from [] (port=18975 by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from <>) id 1c09hf-0003Cf-7V; Fri, 28 Oct 2016 17:08:29 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
From: Sara Dickinson <>
In-Reply-To: <>
Date: Fri, 28 Oct 2016 17:08:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Paul Hoffman <>
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: <>
Cc: Bob Harold <>, "" <>
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: Fri, 28 Oct 2016 16:08:36 -0000

> On 28 Oct 2016, at 16:40, Paul Hoffman <> wrote:
> On 28 Oct 2016, at 8:27, Bob Harold wrote:
>> In Section 5 on Opportunistic Privacy, I am not sure "MAY" is correct.  If
>> the user chooses Opportunistic, I would think the server MUST try to be
>> secure, in whatever ways are possible, but MAY fall back to less secure,
>> only if those fail.

I think it is this text that Bob is referring to:

“Clients using Opportunistic Privacy SHOULD try for the
   best case but MAY fallback to intermediate cases and eventually the
   worst case scenario in order to obtain a response.  It therefore
   provides no privacy guarantee to the user and varying protection
   depending on what kind of connection is actually used.”

One reason I left this as a SHOULD not a MUST because forcing a client to try all available servers for a secure encrypted connection can introduce significant latency into the resolution process which is probably undesirable for Opportunistic. For example, the client has 5 recursive resolvers configured. Authentication fails on the first, but encryption is ok. MUST the client try everyone of the other server to try to get an authenticated & encrypted connection or can it just use the encrypted connection it already has set up, given that it is using Opportunistic Privacy anyway? Appendix A touches on this a little bit too in terms of probing for server capabilities. 

And yes, if we decide to go for keeping it simple then I think this should be  

“Clients using Opportunistic Privacy SHOULD try for the
   best case and SHOULD fallback to intermediate cases and eventually the
   worst case scenario in order to obtain a response. “