IETF Logo Mail Archive

[dnsext] Insecure Delegation Proofs

Sean Wells <snwells82@gmail.com> Thu, 30 June 2011 19:18 UTC

Return-Path: <snwells82@gmail.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDF811E823C for <dnsext@ietfa.amsl.com>; Thu, 30 Jun 2011 12:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.987
X-Spam-Level:
X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSQLPC02AFCU for <dnsext@ietfa.amsl.com>; Thu, 30 Jun 2011 12:18:24 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDA111E8201 for <dnsext@ietf.org>; Thu, 30 Jun 2011 12:18:23 -0700 (PDT)
Received: by vws12 with SMTP id 12so2280876vws.31 for <dnsext@ietf.org>; Thu, 30 Jun 2011 12:18:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=YRmf5QQr9tEXoYIbxZED70eZmsPysx9JxBs4e4NXjA8=; b=kcLnEPS+7Q4hEnAyM1IA0Id44FEcSdb5o8+KVxhBMGY7rjBOQSyrPvWwVSDZ9P/Z5g TOBp6uAAtuwKqrbSXZfU7aR49bATi4VOabsaiKrx7G4GrVn4w/GEQShjnHSUn4YExNL1 0raosthL+ddeJHMzP6EpgkSdwROt2BThZYQ64=
MIME-Version: 1.0
Received: by 10.52.160.68 with SMTP id xi4mr3267993vdb.106.1309461492974; Thu, 30 Jun 2011 12:18:12 -0700 (PDT)
Received: by 10.220.198.200 with HTTP; Thu, 30 Jun 2011 12:18:12 -0700 (PDT)
Date: Thu, 30 Jun 2011 12:18:12 -0700
Message-ID: <BANLkTinRXEmhC_5ikFfoXczat6+4UPJ1pA@mail.gmail.com>
From: Sean Wells <snwells82@gmail.com>
To: dnsext@ietf.org
Content-Type: multipart/alternative; boundary="bcaec53f977922c3e904a6f2c3fc"
Subject: [dnsext] Insecure Delegation Proofs
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2011 19:18:25 -0000

Hi,

DNSSEC bis updates document states:

[RFC4035] Section
5.2<http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-12#section-5.2>specifies
that a validator, when proving a

   delegation is not secure, needs to check for the absence of the DS
   and SOA bits in the NSEC (or NSEC3) type bitmap.  The validator also
   needs to check for the presence of the NS bit in the matching NSEC
   (or NSEC3) RR (proving that there is, indeed, a delegation), or
   alternately make sure that the delegation is covered by an NSEC3 RR
   with the Opt-Out flag set.  If this is not checked, spoofed unsigned
   delegations might be used to claim that an existing signed record is
   not signed.


The last sentence is confusing: what is a "spoofed unsigned
delegation" ? Let us say that there are two delegations one of which
is secure.


a.com is secure, so there is a DS record in com

b.com is insecure, so there is a NSEC record for b.com in com with DS,
SOA bits not set but the NS bit set.


I am looking up the DS record for "a.com". The attacker is responding
the NSEC record for b.com (or it was already in my cache). In this
case, the owner name does not match the SNAME (a.com). I thought we
checked the bitmap of the NSEC only if the owner name matches. This
NSEC record might still be accepted depending on what is there in the
"Next domain field". Is this the attack that is being described ?


regards,
Sean

v2.23.0 | Report a Bug | By Email