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

Sara Dickinson <sara@sinodun.com> Fri, 28 October 2016 16:08 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F0E12944A for <dns-privacy@ietfa.amsl.com>; Fri, 28 Oct 2016 09:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsEDWd1836It for <dns-privacy@ietfa.amsl.com>; Fri, 28 Oct 2016 09:08:34 -0700 (PDT)
Received: from shcp01.hosting.zen.net.uk (shcp01.hosting.zen.net.uk [88.98.24.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4602129407 for <dns-privacy@ietf.org>; Fri, 28 Oct 2016 09:08:33 -0700 (PDT)
Received: from [62.232.251.194] (port=18975 helo=virgo.sinodun.com) by shcp01.hosting.zen.net.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from <sara@sinodun.com>) 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 <sara@sinodun.com>
In-Reply-To: <971DC5AF-3A20-4096-98D8-B01239121A08@vpnc.org>
Date: Fri, 28 Oct 2016 17:08:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B05592C-B2B0-41C7-9FCA-9F51484694BB@sinodun.com>
References: <2203A3DE-5A8A-4364-ABAB-B8BA9BB19FDF@vpnc.org> <28B31793-B7D7-4DE5-B9A2-12AE639EC26C@sinodun.com> <7361F8F2-76B9-4608-A734-99EC04BD391A@vpnc.org> <6B53F353-CD20-4025-A992-7D5C1AB7B7F2@sinodun.com> <CA+nkc8A=jU-jUFdbs3ZUYd4+-jPNbe6qJO5FVENd1SrXRiwWxw@mail.gmail.com> <48A008D3-BEA0-43A6-AF96-C053CBCD3370@vpnc.org> <30ADBA4B-A18B-4537-865B-92076AF546B6@sinodun.com> <CA+nkc8AyagJSwc=mCEO=xc-jzt7MMUmvEGzpPV3rTDfEYKJ=Lw@mail.gmail.com> <971DC5AF-3A20-4096-98D8-B01239121A08@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
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 - shcp01.hosting.zen.net.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - sinodun.com
X-Get-Message-Sender-Via: shcp01.hosting.zen.net.uk: authenticated_id: sara+sinodun.com/only user confirmed/virtual account not confirmed
X-Authenticated-Sender: shcp01.hosting.zen.net.uk: sara@sinodun.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ePhsZbWljTzp24VjgxY8oeQjl4M>
Cc: Bob Harold <rharolde@umich.edu>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Subject: Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: strict privacy
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2016 16:08:36 -0000

> On 28 Oct 2016, at 16:40, Paul Hoffman <paul.hoffman@vpnc.org> 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. “

Sara.