Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Fri, 01 November 2019 15:46 UTC

Return-Path: <vladimir.cunat+ietf@nic.cz>
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 A2ABE120959 for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 08:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.996
X-Spam-Level:
X-Spam-Status: No, score=-6.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 ZIBVcQmieTkE for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 08:46:43 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 2F9E912096F for <dns-privacy@ietf.org>; Fri, 1 Nov 2019 08:46:41 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:fce0:91f8:a499:2d90] (unknown [IPv6:2001:1488:fffe:6:fce0:91f8:a499:2d90]) by mail.nic.cz (Postfix) with ESMTPSA id 6D017140E60; Fri, 1 Nov 2019 16:46:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1572623199; bh=K3kgXG5aTBTUhvRckyANxU70/A87pezWgIqUI/3sq8Y=; h=To:From:Date; b=sSnaasTkARgG3G1bc/z/bMm9oyHHfcXRG/DR4OiOhxX+CEn2nPHhcfSCasYbPsjzN KerBtcKIGr7k+AaW8QNRiywkXANlghr91S12y0L4Oeoii5xHw5BuMqpdbGUhQyVaV1 URdU5Yo735VRzCVsvmzSMcF/pfmJum+l6kH6bdPA=
To: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
References: <CAHbrMsDwDoTQN8Y5Zk7rSVepjwwyatEyAA6f0oJ9DESmAfHfXg@mail.gmail.com> <20191031211222.A6422DBC1C7@ary.qy> <CAH1iCiqYoXMZ0U3yt8AjUXyZVRdDnmHzSpHvYmg++ACZ-U6=zA@mail.gmail.com> <CABcZeBP-k23ZY=f6Lv5A+B+Z_4ar_9ea=G7O+KRriXNLUzKGqw@mail.gmail.com> <CAH1iCiq_HtErNkeq4hWQJnsDJPn1Zxv0uCLX+HK3QcsSzdxRww@mail.gmail.com> <CABcZeBOPWrqCcYWx+ei-O+QC_npfVhj1fG_kVFGFXhWkjyu28g@mail.gmail.com>
From: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
Cc: Eric Rescorla <ekr@rtfm.com>, Brian Dickson <brian.peter.dickson@gmail.com>
Message-ID: <386eb639-d44e-75f8-f425-d713a0f2575f@nic.cz>
Date: Fri, 01 Nov 2019 16:46:54 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1
MIME-Version: 1.0
In-Reply-To: <CABcZeBOPWrqCcYWx+ei-O+QC_npfVhj1fG_kVFGFXhWkjyu28g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------681761A68BDA7FE7247ADA73"
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/NTMZpo5Xh_Ld1yKH327Rh3G_6X0>
Subject: Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 01 Nov 2019 15:46:54 -0000

On 11/1/19 4:34 PM, Eric Rescorla wrote:
>
>     Let me re-emphasize this from the original statement: "FOR PRIVACY".
>
>     DNSSEC security is orthogonal to privacy, and is not a requirement
>     FOR PRIVACY.
>
>
> I don't believe that that's correct in this case. The issue here is
> that in order to provide confidentiality for the queries (in this case
> to the authoritative) you need to authenticate the resolver. And that
> means authentically learning the name of the resolver. So, for
> instance, if I go the learn the NS for .com and the attacker gives me
> www.attacker.com <http://www.attacker.com>, then he can learn my
> queries. The name of the resolver can be authenticated by DNSSEC or
> (less strongly) by having each query protected via secure transport.

Yes, we do want authoritative to be authenticated by the resolver, and
DNSSEC might help with that.  (As DNSSEC root TA seems more suitable for
this than some web PKI CA list.)  However, some people here also want
additional "opportunistic mode" where authentication isn't compulsory,
so I think that might be a compromise - without DNSSEC you'll only get
protection against passive attackers.