Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt

Tony Finch <dot@dotat.at> Wed, 19 July 2017 14:41 UTC

Return-Path: <dot@dotat.at>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB71131CFA for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 07:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 3T1hiTLF66Kr for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 07:41:29 -0700 (PDT)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 AF63E126CB6 for <dnsop@ietf.org>; Wed, 19 Jul 2017 07:41:29 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:39480) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dXqAJ-000ltB-fZ (Exim 4.89) (return-path <dot@dotat.at>); Wed, 19 Jul 2017 15:41:27 +0100
Date: Wed, 19 Jul 2017 15:41:27 +0100
From: Tony Finch <dot@dotat.at>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
cc: Willem Toorop <willem@nlnetlabs.nl>, dnsop@ietf.org
In-Reply-To: <20170719134404.GA18669@laperouse.bortzmeyer.org>
Message-ID: <alpine.DEB.2.11.1707191504480.4413@grey.csi.cam.ac.uk>
References: <149592096439.3966.11385984990945858242@ietfa.amsl.com> <0edbf3f2-e575-3b34-d3f2-f1424f29f6e4@nlnetlabs.nl> <alpine.DEB.2.11.1707181622300.27210@grey.csi.cam.ac.uk> <20170719134404.GA18669@laperouse.bortzmeyer.org>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8BQLw008oqW2piz0dF2qpqRBjLw>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jul 2017 14:41:32 -0000

Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
>
> Cute trick. I love it.

:-)

> But it modifies the rules for response credibility (the most credible
> response is in the additionnal section, not in the answer section).
> Should we update RFC 2181, section 5.4.1?> I tend to think that the A
> record, in that example, should be treated exactly like glue, by a
> ANAME-aware client.

Interesting point.

My understanding is that, in principle, DNSSEC makes it possible to trust
parts of answers that are (in current implementations) distrusted. For
example, out-of-zone data about CNAME or MX targets. There's a big
opportunity here to reduce latency by doing a bit more work to eagerly
validate and cache additional data.

(An aside: glue appears in multiple places in the RFC 2181 5.4.1 ranking,
depending on whether the server found it in an primary/secondary zone or
got it in a referral.)

Regarding my ANAME suggestion, the key paragraphs are shortly after the
trustworkthiness ranking:

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.

The first word is the key word: "Unauthenticated" - the next paragraph says:

   When DNS security [RFC2065] is in use, and an authenticated reply has
   been received and verified, the data thus authenticated shall be
   considered more trustworthy than unauthenticated data of the same
   type.  Note that throughout this document, "authoritative" means a
   reply with the AA bit set.  DNSSEC uses trusted chains of SIG and KEY
   records to determine the authenticity of data, the AA bit is almost
   irrelevant.  However DNSSEC aware servers must still correctly set
   the AA bit in responses to enable correct operation with servers that
   are not security aware (almost all currently).

With this context, I believe RFC 2181 says that if you have validated the
additional data from an answer like the one in my example
(https://mailarchive.ietf.org/arch/msg/dnsop/Zh7viwmrR7QcJSFQvqMsb7YSRU8)
you are allowed to return it as a direct answer to queries, and you don't
have to keep it in the additional section sin bin.

It's probably also sensible to retain its low trustworthiness ranking, so
that it can be replaced in the cache by a more trustworthy answer, to
reduce the risk of replay attacks that use old data that's still within
its RRSIG validity period.

On the other hand, it might be usefully simpler to make ANAME-specific
recommendations about how to handle the additional data. Dunno :-)

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
East Sole, Lundy, Fastnet: Cyclonic 4 or 5, becoming northwesterly 5 to 7.
Moderate or rough. Showers, thundery at first, fog patches at first. Moderate
or very poor, becoming good.