IETF Logo Mail Archive

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

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 20 August 2014 14:34 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 E50C21A040A for <dns-privacy@ietfa.amsl.com>; Wed, 20 Aug 2014 07:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.758
X-Spam-Level: *
X-Spam-Status: No, score=1.758 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=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 l1we4DPkq_Zv for <dns-privacy@ietfa.amsl.com>; Wed, 20 Aug 2014 07:34:56 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B231A03F0 for <dns-privacy@ietf.org>; Wed, 20 Aug 2014 07:34:56 -0700 (PDT)
Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 44F528A031 for <dns-privacy@ietf.org>; Wed, 20 Aug 2014 14:34:55 +0000 (UTC)
Date: Wed, 20 Aug 2014 10:34:53 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dns-privacy@ietf.org
Message-ID: <20140820143453.GD1065@mx1.yitter.info>
References: <00ba01cfbbf9$d561f010$8025d030$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <00ba01cfbbf9$d561f010$8025d030$@rozanak.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/ae2idDRyVoBUOc2CK4gRU1q4VXQ
Subject: Re: [dns-privacy] [SPAM] Re: 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: Wed, 20 Aug 2014 14:34:58 -0000

On Wed, Aug 20, 2014 at 12:06:29AM +0200, Hosnieh Rafiee wrote:
> 1-  Opportunistic encryption is not appropriate for the privacy of stub
> resolver to recursive resolver scenario unless the node has a possibility to
> authenticate this resolver.

I don't think this is true.  The point of the encryption independent
of authentication is for the case where you've decided to accept the
risk that your upstream resolver isn't actually trustworthy, and have
decided to trust it anyway.  You're welcome to say, "That's a bad
decision," but I don't think you've provided a reason that others
can't make that trade-off reasonably.

> If you think when your domain is signed by DNSSEC, a fake resolver cannot
> cause any problem for you

This has nothing at all to do with DNSSEC.  I think you're just
muddying the waters by bringing DNSSEC into it.  It is _certainly_
true that you can't trust DNSSEC validation without knowing exactly
who did the validation and having an authenticated channel to that.
That's completely unrelated to the privacy argument for
stub-to-resolver encryption.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

v2.23.0 | Report a Bug | By Email