Re: [dns-privacy] New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt

Jacob Appelbaum <jacob@appelbaum.net> Tue, 19 August 2014 20:02 UTC

Return-Path: <jacob@appelbaum.net>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8EA1A040F for <dns-privacy@ietfa.amsl.com>; Tue, 19 Aug 2014 13:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 gWmNZTrtejDZ for <dns-privacy@ietfa.amsl.com>; Tue, 19 Aug 2014 13:02:39 -0700 (PDT)
Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B70D81A0661 for <dns-privacy@ietf.org>; Tue, 19 Aug 2014 13:02:39 -0700 (PDT)
Received: by mail-qa0-f47.google.com with SMTP id i13so6165191qae.34 for <dns-privacy@ietf.org>; Tue, 19 Aug 2014 13:02:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ed2Dogrb6YV3aV4Kf5Soewl6GcyESZBeJQ2ydKUQs8g=; b=NHt6PMsTAoIAMArWBB1uevdpy7eNE1DqnWMKNcCvS3i4zXCDM0tg4Y1EUGMhknyipd r2jvRRFvdQBk4A1hN7BMfe6qreH+CwHUxjx7zQpuZgaScRKgRONkVeOniu5AVjVxba4X T7uWq+QDw1ndjDwuyMGh3irljlpWYo7KzrePgUO9SnsrENjMw3jLjMcCazL3s11x4o7n u8C+XCdwYYxca/XCXIniHn1qfNS6lpVJnimlO1zckZgS7mSvmoduUrQnynnAC5OEiMGK 3EJrR9smK5YLiU38ITeyrrInrUi2UAWGJ+J3K/3ryo/BIckFPPw2SAnOeHcvJIFHH4CV Ur9w==
X-Gm-Message-State: ALoCoQkA4693zLuYLJzS8+ITNaGPFILv7UTOG+BXryLCOpLqh9txJA11Se65u/oAZ2DErMHi7Z0W
MIME-Version: 1.0
X-Received: by 10.224.129.201 with SMTP id p9mr10272908qas.75.1408478558675; Tue, 19 Aug 2014 13:02:38 -0700 (PDT)
Received: by 10.140.91.50 with HTTP; Tue, 19 Aug 2014 13:02:38 -0700 (PDT)
X-Originating-IP: [178.20.55.16]
In-Reply-To: <AD3938CD-1928-452F-8EC1-FE7D64CB950B@vpnc.org>
References: <20140818175701.12317.96810.idtracker@ietfa.amsl.com> <FF99C324-2959-48EB-A187-18007F7AA364@vpnc.org> <CAJE_bqeoUx2gFsnVgZYfoWASkHaMgKW4tR552YRmQ4ZNzH1M=g@mail.gmail.com> <361D96E3-CD31-4E2B-88E3-46E44D6F8C3D@vpnc.org> <CAFggDF3G3JEnPLVqZ2PjX8hCBP5-rkh7jGBWMvMxgpFSN7g1yw@mail.gmail.com> <AD3938CD-1928-452F-8EC1-FE7D64CB950B@vpnc.org>
Date: Tue, 19 Aug 2014 20:02:38 +0000
Message-ID: <CAFggDF2Z75q_Pb5WFAWZym6RWS4U=mkLiwPfRWBO5fbWPsGfvQ@mail.gmail.com>
From: Jacob Appelbaum <jacob@appelbaum.net>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/noou5-I9fIXZM-_IOHOjcAUmwaA
Cc: dns-privacy@ietf.org, 神明達哉 <jinmei@wide.ad.jp>
Subject: Re: [dns-privacy] New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 19 Aug 2014 20:02:41 -0000

On 8/19/14, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> On Aug 19, 2014, at 11:51 AM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
>
>>> Sure, let's be explicit. Proposed addition to the policy section:
>>>
>>> If a recursive resolver does not respond on port 443 or set up a TLS
>>> session, the stub resolver MAY use the normal DNS protocol on port 53.
>>>
>>
>> I'm not a fan of making it possible for an attacker to downgrade with
>> a single (non-cryptographically protected) TCP RST packet. If I
>> configure a resolver and declare it to be secure (and use it as such),
>> why not fail closed?
>
> Because then hosts that use stub resolvers will not be able to use the DNS
> at all.

That is correct and that is exactly what I expect when my network is
attacking me. Rather than leaking that I'm being visited an ad name
that implies I've visited a gay dating site, I want it to fail closed.
If I declare it as secure, I want it to remain secure - where the
security here is all about *confidentiality* and DNSSEC does the rest
with regard to integrity, etc.

>
>> Why not detect that as an attack or as outright
>> network censorship?
>
> We could add such detection, but only if the value outweighs the complexity
> and possible failure modes.

If the TLS connection fails to complete (authenicated or not), it
should be as simple as returning something like E_CENSORSHIP_DETECTED.
An error like "Unable to connect securely to resolver, please contact
your ISP" would be fine.

Most OSes don't do anything remotely helpful when DNS fails. It might
be nice if that failure mode was privacy preserving...

>
>> This seems to fail if there is an active attacker that blocks TLS
>> traffic - is there a way for the resolver to somehow learn in-band on
>> port 53 that this attack is happening?
>
> Probably, but you still haven't said what value there is in knowing that. A
> stub resolver has no log and no way of alerting anyone that it discovered
> something important.

If my resolver allows upgrading to a secure method of communication,
I'd like to know. Furthermore, I'd like to automatically upgrade to
that secure communications path if it was available. An OS could probe
for a specific record type - similar to say, version.txt.

e.g.: nslookup -q=txt -class=CHAOS query.privacy.bind.

It could even learn the likely fingerprint of the server ala DANE, for example.

>
> Let me know if I'm missing something obvious.

Hope that helps.

All the best,
Jacob