Re: [dbound] draft-brotman-rdbd

Brian Dickson <brian.peter.dickson@gmail.com> Mon, 01 April 2019 10:46 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937EF12007A for <dbound@ietfa.amsl.com>; Mon, 1 Apr 2019 03:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 lABECLSmrVmJ for <dbound@ietfa.amsl.com>; Mon, 1 Apr 2019 03:46:37 -0700 (PDT)
Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A328F12008F for <dbound@ietf.org>; Mon, 1 Apr 2019 03:46:37 -0700 (PDT)
Received: by mail-qt1-x842.google.com with SMTP id d13so10136976qth.5 for <dbound@ietf.org>; Mon, 01 Apr 2019 03:46:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b7cT/5xz5WqYnroi1VrMQmM8/ClY0/lXbxCPjdbCoos=; b=X1TUOggyClTRM+Tj4ZbsKafBk1RAdIeC8fT/LTQJ4lAuG2w6DVwTS3fYhCjOpMRs6J lJu1zaP+HGM+HH2zd1LakZnkjKlnSkjCDTtT0mFxbxM5ueN82VhvYguy05Ty4sA8rJWe ccUixJYetAMQu9Vmcqt4UsWwhAENDbEsptg6PCigtZrN73SDzNWhO/JWZT/7zqQk5uv4 3Mjl2wSZUcckPe39oTggYrdDSTTOktJIPI+CpKgAcrKGBq9cYDZmiv+Oo5h3ggBE3x2d sU/wk7oOHO8Cw05/4zjAeY67mxEozfNpJhYTV9mdu0JkHfQjq1hXd2GplxeTUc9W2ZXm 7jcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b7cT/5xz5WqYnroi1VrMQmM8/ClY0/lXbxCPjdbCoos=; b=RKrXw4cs8IAsgIk1nGXo6dPN6q0tKSKRRXnzUeN+dJrxjhpSz78od/gHhicMk1DWdB B8UG0ACwtfF5OyDgU6rekNHsjcNdGK2IGNzXDG7A+o1stmDvUceTJ5u+RTfC9HQ6XDha 5EqB/KXjyo6TH2zynMxGntrl1XbgLv+1T3/951ofXJ9gb8Cz4l6s8eTHVUTMFHjPKa8y wFGWOWa1bJZNtf+Chvot4HgCcIggiQmmtWMQBigijfHxzRBKoAHxHa0lwtInQlXiIG4x Ogvwjgmci9eCMADsiCu2aBtFPdiOASjHeimRLG8YJCYNy8Cz9JwQu6ie6CviqfKtpyrV ww1A==
X-Gm-Message-State: APjAAAVY++oQHhrQjcQz33TACMqyoQYhPx6us6We1EkL1cw+kNIwgATy Q06Xk3lUnFHUgx6nj3WPbqA8npnkihK534yprIQ=
X-Google-Smtp-Source: APXvYqxQxnut7fuqsvO9yLdohh26EAUTJaW5+LK7qtIVKZGazzmxgFs7lHo3S+qBJiPC5Qhww04p8zw0PPQQqDZqikI=
X-Received: by 2002:a0c:9666:: with SMTP id 35mr52743887qvy.30.1554115596772; Mon, 01 Apr 2019 03:46:36 -0700 (PDT)
MIME-Version: 1.0
References: <f6862326-40e1-d804-cefe-e63c79a0534d@andreasschulze.de> <7d34857c-a99b-389a-90e5-2e4fe6f4e736@cs.tcd.ie>
In-Reply-To: <7d34857c-a99b-389a-90e5-2e4fe6f4e736@cs.tcd.ie>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 1 Apr 2019 03:46:23 -0700
Message-ID: <CAH1iCipco+0Wvb1kpZ-S3EQYdsYywZzQo+sEeLikNZjMwMYMgg@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "A. Schulze" <sca@andreasschulze.de>, dbound@ietf.org
Content-Type: multipart/alternative; boundary="00000000000015e95b058575bc54"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/KIKJ6QxNyM7uph-lQM2VuZPEDlk>
Subject: Re: [dbound] draft-brotman-rdbd
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2019 10:46:41 -0000

On Sun, Mar 31, 2019 at 3:57 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>;
wrote:

> On 29/03/2019 17:06, A. Schulze wrote:
>
> > And, yes, DNSSEC shouldn't be optional. Re-using existing DNSKEYs may
> make the signature/validation stuff easier.
>
> I'm afraid I don't agree that DNSSEC can be a requirement here. RDBD
> by itself is not sufficiently compelling to cause a DNSSEC deployment.
> And DNSSEC is just not sufficiently deployed to make it a requirement.
>

I'd like to better understand the rationale for the general/specific
sentiment.

I think the disconnect starts with the question about the purpose, or
alternatively, explicit limitations, of RDBD:

   - Does the existence of RDBD records change the trust by any actor, any
   system, any mechanisms, anything?


If the answer is no, then I don't see the compelling value for RDBD, and
really have no interest here. Sorry. (However, I also don't think this is
the case.)

If the answer is yes, then IMHO, RDBD may REALLY need to check its
assumptions regarding DNS cache poisoning.
(Hint: if DNS were a pre-industrial world map, the cache would be labeled
"Here there be dragons".)

The strongest defense known against DNS cache poisoning, AFAIK, is DNSSEC.
Any others are at most weak hacks to marginally increase entropy.

Using any other type of crypto keys stored in DNS, without protecting those
with DNSSEC, is also vulnerable to cache poisoning. They are just DNS
records.
So, without using DNSSEC, successful cache poisoning can subvert RDBD,
whether or not any other signature stuff is used:

   - The attacker only needs to subvert the DNS entries for all the RDBD
   records , i.e base RDBD record(s) with signatures, and corresponding
   RDBDKEY record(s).
      - This is addressed as a security concern currently in the draft, but
      understates/underestimates the risk or effort, IMHO
significantly (or even
      fatally).
   - Since this is a DNS cache attack against both the key and signature,
   it does not require the RDBDKEY (as published on the authority
   server(s)) to be compromised.

In contrast, use of DNSSEC makes any other signature redundant/moot, at
best; it makes key management problematic on top of DNSSEC key management,
at worst.
Here's why: DNSSEC signing a record which contains a domain name meets all
the requirements of the RDBD.
Using the ZSK as the RDDBKEY devolves the RDBD record trivially:

   - All the stuff after the relating domain name in the current draft, is
   basically an RRSIG (with a few fields elided).

The gist of the above is: if you have deployed DNSSEC for a zone, the RDBD
RRTYPE does not need to consist of anything more than a domain name (FQDN).

This is not to say that an RDBD does not have value; in fact, I believe
there is significant value here.
That value can be maximized by streamlining the encoding, re-using the
signature work from DNSSEC, and keeping the RDBD RRTYPE easy to understand
and use.

Rationale, explanation, & disclaimer regarding cache poisoning weakness:

I've made assertions previously in a variety of venues, about the level of
effort required for cache poisoning being very low generally.
At some point I should probably write up the details, so it is clear to the
IETF crowd doing DNS (previously this has been shared at DNS-OARC but not
by me in the DNS-related WGs).
The root source of the weakness has been published elsewhere by others ,
and presented by them in (IIRC) the security area general session. See:

 Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous",
Technical Report 13-03, March 2013, <
http://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf>;.

My claim is that that report underestimates the degree of vulnerability of
caches to such attacks.

If the authors of RDBD would like a private detailed explanation, I'd be
happy to share it.
I am reluctant to publicly share the details just now, as I believe this
would require appropriate responsible disclosure with abundant time to fix
the underlying issues.
In particular, it is really critical to have necessary fixes deployed in
nearly all the authority operators' and recursive operators' networks,
prior to any details being published openly.

(You may not agree with the above, without me explaining the particulars.
My suspicion is you will probably agree with the above after I explain it.
Please contact me off-list for the explanation.)


Here's my opinion generally of what RDBD should be composed of:

   - DNSSEC signed RDBD records consisting of only the related-domain names.
   - Matching mutual claims of relationships should be a requirement (or at
   least a SHOULD with explanation of the security risks of relying on
   unmatched claims).
   - Ability of a domain to explicitly exclude all relationships (thus
   preventing any matches). Completely unambiguous encoding is required for
   this.
   - Optional URI record(s) pointing at some well-defined semantic blob(s)
   for what the trust implies, for whoever the consumer of RDBD is. (Probably
   out of scope for the core RDBD spec.)

Brian