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

"Paul Hoffman" <paul.hoffman@vpnc.org> Thu, 27 October 2016 15:18 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 9E5551294F4 for <dns-privacy@ietfa.amsl.com>; Thu, 27 Oct 2016 08:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 HxV-lO9XdPyw for <dns-privacy@ietfa.amsl.com>; Thu, 27 Oct 2016 08:18:35 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FCEF129675 for <dns-privacy@ietf.org>; Thu, 27 Oct 2016 08:18:12 -0700 (PDT)
Received: from [10.32.60.105] (50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u9RFIAnh020579 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Oct 2016 08:18:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230] claimed to be [10.32.60.105]
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: "Sara Dickinson" <sara@sinodun.com>
Date: Thu, 27 Oct 2016 08:18:11 -0700
Message-ID: <7361F8F2-76B9-4608-A734-99EC04BD391A@vpnc.org>
In-Reply-To: <28B31793-B7D7-4DE5-B9A2-12AE639EC26C@sinodun.com>
References: <2203A3DE-5A8A-4364-ABAB-B8BA9BB19FDF@vpnc.org> <28B31793-B7D7-4DE5-B9A2-12AE639EC26C@sinodun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/hea4oXSMbtLnqS0nGr8_pl-7BgI>
Cc: 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: Thu, 27 Oct 2016 15:18:39 -0000

On 27 Oct 2016, at 6:45, Sara Dickinson wrote:

>
>> On 23 Oct 2016, at 00:26, Paul Hoffman <paul.hoffman@vpnc.org> 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?

I apologize for not giving feedback at the time; I was waiting for other 
people to chime in and then forgot.

That text is really good. However, instead of at the end of Section 4, I 
would put it right after Table 1, replacing "Since Strict Privacy 
provides the strongest privacy guarantees it is preferable to 
Opportunistic Privacy".


>> 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. “

Yes, I saw that there, but it makes no sense in this document because we 
explicitly allow for both going to no TLS and not telling the user about 
whether TLS is in use. I think that bit in RFC 7435 only applies to 
systems where the user sees that TLS is in use. We really should take it 
out of this document; otherwise, we have to add in a lot more about 
users knowing about the use of TLS.

--Paul Hoffman