[DNSOP] Empty Non-Terminal vs NXDOMAIN in draft-ietf-dnsop-nsec-aggressiveuse

Roy Arends <roy@dnss.ec> Mon, 10 October 2016 19:52 UTC

Return-Path: <roy@dnss.ec>
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 F193812959F for <dnsop@ietfa.amsl.com>; Mon, 10 Oct 2016 12:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dnss.ec
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 Xhjr8DX-007H for <dnsop@ietfa.amsl.com>; Mon, 10 Oct 2016 12:52:35 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 01C5B12945C for <dnsop@ietf.org>; Mon, 10 Oct 2016 12:52:34 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id b81so141850761lfe.1 for <dnsop@ietf.org>; Mon, 10 Oct 2016 12:52:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=ylrIcDeSy6eA1ZzsCem+6TsXOUfJY82NXKkRP5bPrbQ=; b=IRbLI/mot+iODkVeesokU0p5H8GNIYJPLcDnVx/CppDo/sb6G6emG4DqKuR7A6bCup /yIOscE621Di7D5xYgH6QY29C5b/hdK6TeyDOoI28eZaDmqY5+9pHbFnvcFOPTZBKyNH WlmkNeZYtzySIxfn5ZHXNeHe5HiqrTwpKr9e4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=ylrIcDeSy6eA1ZzsCem+6TsXOUfJY82NXKkRP5bPrbQ=; b=jhrHw5pDY4E36GFH7WPBzDQungKYG5C4r+jFTPZafx4KNYqLbu1HCALg7yV71BhV9Q rYZ7D6ICOW1UazOvWk2JBsAGBAlvyPHzzvIWqOOefu9xn+uM/H/TzRsrqAc5uIYdhDGZ oRPUZr1/Ho/45KYEuUJs//gZ5tSo6O3axRycC+dkbpJBdf0k0j5ARLk/CaAxxIHbGoMQ WjgUO8tjKAnpM+w13bIHIVMVcquL8wSHSr+gQolp+o15KyPJxJxPfAMGuhUMGx1m9aWV dGeCmBZLEC5WgeEfyyD3q/JZdEkNSwjyVTokJmAaxpzFOT+oq2ddapvCuTyGbXMx0CiS fKng==
X-Gm-Message-State: AA6/9Rljd/IAP0iQKIJklWSnC0y56BKJQzVkmNJvKRroe/95SGgrr1ZMX49/aJsaCqWGLQ==
X-Received: by 10.194.200.162 with SMTP id jt2mr31154772wjc.172.1476129152525; Mon, 10 Oct 2016 12:52:32 -0700 (PDT)
Received: from [192.168.1.82] (host86-144-28-77.range86-144.btcentralplus.com. [86.144.28.77]) by smtp.gmail.com with ESMTPSA id au8sm31681290wjc.12.2016.10.10.12.52.31 for <dnsop@ietf.org> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 10 Oct 2016 12:52:31 -0700 (PDT)
From: Roy Arends <roy@dnss.ec>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <EA312F37-2E4C-45E0-AF0A-B0A0663B73E8@dnss.ec>
Date: Mon, 10 Oct 2016 20:52:30 +0100
To: dnsop <dnsop@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/emUw8jNXRNX4uFADUMpjEdDT2Ng>
Subject: [DNSOP] Empty Non-Terminal vs NXDOMAIN in draft-ietf-dnsop-nsec-aggressiveuse
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 10 Oct 2016 19:52:37 -0000

Having read the draft…

How does one distinguish a Empty Non-Terminal NODATA response from an NXDOMAIN response, solely by looking at the NSEC or NSEC3 records. 

There is an attack vector where an RCODE0 can be replaced by RCODE3 while keeping the rest of the response completely intact, causing an aggressive use enabled cache to deny existing records.

These kind of subtleties aren’t described in the draft, as far as I can tell. 

Roy