IETF Logo Mail Archive

Re: [dns-privacy] Requirements for authoritative server preferences

Stephane Bortzmeyer <bortzmeyer@nic.fr> Wed, 04 November 2020 08:38 UTC

Return-Path: <stephane@sources.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 9F1DC3A0D95 for <dns-privacy@ietfa.amsl.com>; Wed, 4 Nov 2020 00:38:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 MJv-HSt_vNJt for <dns-privacy@ietfa.amsl.com>; Wed, 4 Nov 2020 00:38:07 -0800 (PST)
Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fe27:3d3f]) (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 C7EDF3A0D93 for <dns-privacy@ietf.org>; Wed, 4 Nov 2020 00:38:07 -0800 (PST)
Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id 796F1A02A5; Wed, 4 Nov 2020 09:38:06 +0100 (CET)
Received: by mail.sources.org (Postfix, from userid 1000) id 1F4A3190032; Wed, 4 Nov 2020 09:37:13 +0100 (CET)
Date: Wed, 04 Nov 2020 09:37:13 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: DNS Privacy Working Group <dns-privacy@ietf.org>
Message-ID: <20201104083712.GB6824@sources.org>
References: <160435765311.18774.16063151114758509438@ietfa.amsl.com> <1E8597EB-C856-4DC9-A42D-8B2142501C7A@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1E8597EB-C856-4DC9-A42D-8B2142501C7A@icann.org>
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 10.6
X-Charlie: Je suis Charlie
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/cPvZgiUyUCvhEXBZGj38HO4x9fc>
Subject: Re: [dns-privacy] Requirements for authoritative server preferences
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: Wed, 04 Nov 2020 08:38:10 -0000

On Wed, Nov 04, 2020 at 02:15:03AM +0000,
 Paul Hoffman <paul.hoffman@icann.org> wrote 
 a message of 114 lines which said:

>         In addition this SHALL include whether a secure transport protocol
>         MUST always be used (non-downgradable) or whether a secure
>         transport protocol MAY be used on an opportunistic (not strict)
>         basis in recognition that some servers for a domain might use a
>         secure transport protocol and others might not.
> 
> It is impossible for a server to tell whether a resolver is authenticating, so being able to say "you must authenticate" is kinda just posturing. The choice of whether or not to connect should always be with the resolver. Further, if a resolver is using a mechanism that requires strict authentication, it truly doesn't matter what the authoritative server has said it wants.

Nevertheless, hints from the authoritative name server can be useful,
such as "You should use DoT in strict mode but there is also a DoH
service which is quite experimental with a self-signed
certificate". Other IETF protocols have such hints from the
authoritative side about what the client should do, even if they
cannot be enforced (RFC 7208 for instance).

Is it worth the complexity? I don't know but it is not useless.

v2.23.0 | Report a Bug | By Email