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 15:23 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 72D131A0644 for <dns-privacy@ietfa.amsl.com>; Wed, 20 Aug 2014 08:23:47 -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_40=-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 PVknzwI_4N_5 for <dns-privacy@ietfa.amsl.com>; Wed, 20 Aug 2014 08:23:46 -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 360C31A0503 for <dns-privacy@ietf.org>; Wed, 20 Aug 2014 08:23:46 -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 2FAEC8A031 for <dns-privacy@ietf.org>; Wed, 20 Aug 2014 15:23:45 +0000 (UTC)
Date: Wed, 20 Aug 2014 11:23:44 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dns-privacy@ietf.org
Message-ID: <20140820152343.GH1065@mx1.yitter.info>
References: <00ba01cfbbf9$d561f010$8025d030$@rozanak.com> <20140820143453.GD1065@mx1.yitter.info> <814D0BFB77D95844A01CA29B44CBF8A7A28554@lhreml513-mbb.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A28554@lhreml513-mbb.china.huawei.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/7YXErrT9XNbhulb80TyH4uNSRBY
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 15:23:47 -0000

On Wed, Aug 20, 2014 at 03:00:05PM +0000, Hosnieh Rafiee wrote:

> I provided several reason that the observer doesn't exist. 

No, you provided several reasons why you think this decision is an
unreasonable one.  Prior to the evidence from a couple years ago that
national governments were doing wide-spread vacuuming up of everything
they could by perfoming passive attack through the means of tapping
lines and so on, the position you are taking was entirely reasonable.
But in the face of that evidence, some people have decided that, even
if they can't protect themselves reliably all the time, they get
enough marginal benefit from privacy to do it whenever they can, even
if it's not perfect and not terribly hard to subvert.

In other words, you are basically arguing that the benefit that will
accrue from this technique is not enough given the costs.  Others
disagree with you.  Your argument only works if we accept your premise
that the benefit is not worth the cost; if we evaluate the benefit
differently, then the cost might be acceptable.

> What I tried to explain here is that an observer role doesn't make sense in resolver scenario. 

Except that we have an existence proof that it does.


> DNSSEC just came to this game when some folks say that DNSSEC can protect this and they only need encryption.

If you had strong authentication of the resolver, then this would be
true.  Since TSIG (which I expect you remember) or SIG(0) can solve
the authentication part, then in fact the only thing you would need
_is_ encryption, and then you could rely on the DNSSEC piece as well.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com