Re: [dns-privacy] Registry framework for draft-ietf-dprive-early-data

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 22 July 2020 19:36 UTC

Return-Path: <ilariliusvaara@welho.com>
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 B4E263A08E4 for <dns-privacy@ietfa.amsl.com>; Wed, 22 Jul 2020 12:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.63
X-Spam-Level:
X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, SPF_HELO_NONE=0.001, SPF_NONE=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 b09RTLhszO9g for <dns-privacy@ietfa.amsl.com>; Wed, 22 Jul 2020 12:36:50 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1b.welho.com [83.102.41.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5CA03A08A9 for <dns-privacy@ietf.org>; Wed, 22 Jul 2020 12:36:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 379931EC39; Wed, 22 Jul 2020 22:36:49 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id CIPUikbQlkN2; Wed, 22 Jul 2020 22:36:48 +0300 (EEST)
Received: from LK-Perkele-VII (84-253-234-84.bb.dnainternet.fi [84.253.234.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5DFFD7A; Wed, 22 Jul 2020 22:26:55 +0300 (EEST)
Date: Wed, 22 Jul 2020 22:26:52 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Brian Haberman <brian@innovationslab.net>
Cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Message-ID: <20200722192652.GA486629@LK-Perkele-VII>
References: <d812edb8-b3b3-d1db-13e8-8da9a945516d@innovationslab.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <d812edb8-b3b3-d1db-13e8-8da9a945516d@innovationslab.net>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/NejhHIy39VmhJKvGxzxo0nSWhZY>
Subject: Re: [dns-privacy] Registry framework for draft-ietf-dprive-early-data
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, 22 Jul 2020 19:36:53 -0000

On Wed, Jul 22, 2020 at 12:00:43PM -0400, Brian Haberman wrote:
> Hi all,
>      I have a proposal for the working group that I would like some
> feedback on. https://tools.ietf.org/html/draft-ietf-dprive-early-data-00
> calls out the need for an IANA registry to track which RR Types are
> allowed to be carried as early data during the TLS session establishment
> process. Rather than creating yet another IANA registry, I propose that
> we add a column to the current RR Type registry that indicates whether
> the RR Type is allowed as early data. For reference...
> 
> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
> 
> Thoughts on this?

I think this is a Bad Idea.

The fact that RRTYPE is data RRtype (1-127, 256-61439) already
establishes it is safe to send as QTYPE in QUERY. Having any unsafe
things there would already cause major security issues, as DNS
specifications are very clear that servers MUST NOT refuse
requests by data QTYPE. Yes, some data TYPEs are special (especially
NS, CNAME and some DNSSEC stuff), but it is still requirement to not
have any harmful effects.

However, this does not make any of them safe, only that none is
specially unsafe. With recursives, bad things happen if network
attacker can replay 0-RTT data after cache expiry. At worst, this can
completely compromise the query contents. It looks that one could
check the ticket age with fairly tight tolerances (failing is only
one (likely fast) extra RTT) to prevent this from happening.

Types that are not data RRtypes might be more mixed bag. Those may
have side effects, and also contains the infamous TYPE *. The reason
that TYPE is infamous is that its semantics are not quite sensible,
and especially that it tends to cause large answers.

Then there are CLASSes. The data CLASSes (1-127 and 32768-57343) need
to be safe. The other defined classes are NONE and *, which have no
sensible semantics in QUERY. Also unlike unknown TYPEs, unkown CLASSes
can be refused (REFUSED is sensible for authoritative, and NXDOMAIN for
recursive).

However, there is a potential source of unsafety even in QUERY
with data QTYPE: EDNS extensions. The base EDNS is safe and essential.
However, EDNS extensions can do who knows what, and some of them might
be very much not safe. However, there are some that seem useful.

On useful end, there are various DNSSEC advertisment extensions (e.g.,
??U and edns-key-tag). As well as Extended DNS Error. On dubious end
there are things like LLQ and UL (and potentially other stuff as well).


-Ilari