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

"Paul Hoffman" <paul.hoffman@vpnc.org> Sat, 22 October 2016 23:26 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 84CD01294DB for <dns-privacy@ietfa.amsl.com>; Sat, 22 Oct 2016 16:26:32 -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 orTDgqEsF20t for <dns-privacy@ietfa.amsl.com>; Sat, 22 Oct 2016 16:26:31 -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 3D1FC1294A3 for <dns-privacy@ietf.org>; Sat, 22 Oct 2016 16:26:31 -0700 (PDT)
Received: from [10.32.60.49] (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 u9MNPK1A032834 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <dns-privacy@ietf.org>; Sat, 22 Oct 2016 16:26:29 -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.49]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: dns-privacy@ietf.org
Date: Sat, 22 Oct 2016 16:26:30 -0700
Message-ID: <2203A3DE-5A8A-4364-ABAB-B8BA9BB19FDF@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/mXQFD4yWe2irbCFnSKeSKegKmuI>
Subject: [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: Sat, 22 Oct 2016 23:26:32 -0000

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.

There are many ways that strict privacy can fail. The most obvious one, 
which we still see repeatedly, is a name server that forgets to renew 
its certificate. There are many others, all of which can be controlled 
by an attacker: SRV chains that accidentally get changed, CNAME chains 
that change, temporary unavailability of OCSP or CRL information, and so 
on. Note that many of these attacks are not on-path between the user and 
the name server. An attacker who wants to force users to choose to not 
use DNS-over-TLS can block any of these to anger users enough to turn 
off DNS-over-TLS.

I propose that Section 4 be completely recast. Keep in all the stuff 
about opportunistic allowing on-path attackers to view and modify 
traffic, but start with the attitude that most users would prefer the 
chance of some encryption but always get Internet service, and that 
fewer users would want no internet service if there is anything wrong 
with the authentication. That is, emphasize opportunistic privacy 
because it is less fragile and less likely to be later turned off.

I'm not going to write up the full recast unless there is consensus in 
the WG to do so. Clearly, I'm not the one to judge that consensus.

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

Even if the WG doesn't want to recast the section to emphasize (what I 
consider) the profile more people will want due to its resilience, I 
still would like to see the following sentence removed: "Since Strict 
Privacy provides the strongest privacy guarantees it is preferable to 
Opportunistic Privacy." It is only preferable to people who are willing 
to lose all Internet connectivity, not to everyone.

--Paul Hoffman