[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
- [dns-privacy] draft-ietf-dprive-dtls-and-tls-prof… Paul Hoffman
- Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-… Sara Dickinson
- Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-… Paul Hoffman
- Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-… Sara Dickinson
- Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-… Bob Harold
- Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-… Paul Hoffman
- Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-… Sara Dickinson
- Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-… Bob Harold
- Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-… Paul Hoffman
- Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-… Paul Hoffman
- Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-… Sara Dickinson