Re: [dnsext] Checking RRSIG RR validity

"George Barwood" <george.barwood@blueyonder.co.uk> Fri, 31 December 2010 17:54 UTC

Return-Path: <george.barwood@blueyonder.co.uk>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7743A67C2 for <dnsext@core3.amsl.com>; Fri, 31 Dec 2010 09:54:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.224
X-Spam-Level:
X-Spam-Status: No, score=0.224 tagged_above=-999 required=5 tests=[AWL=0.822, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyb8Omy9JNml for <dnsext@core3.amsl.com>; Fri, 31 Dec 2010 09:54:52 -0800 (PST)
Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id 0AEB63A6832 for <dnsext@ietf.org>; Fri, 31 Dec 2010 09:54:51 -0800 (PST)
Received: from [172.23.170.137] (helo=anti-virus01-08) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1PYjDl-0004Fj-0U; Fri, 31 Dec 2010 17:56:57 +0000
Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from <george.barwood@blueyonder.co.uk>) id 1PYjBm-0003HS-0f; Fri, 31 Dec 2010 17:54:54 +0000
Message-ID: <5C578182DAA04FE6B9CF4A18B7BC0D95@local>
From: George Barwood <george.barwood@blueyonder.co.uk>
To: Sean Wells <snwells82@gmail.com>, dnsext@ietf.org
References: <AANLkTinkmbx7yaTcd6P9sBryzQa7An2FMCS8aFk7jhb7@mail.gmail.com>
Date: Fri, 31 Dec 2010 17:55:12 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_06AA_01CBA913.DF6A75C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
Subject: Re: [dnsext] Checking RRSIG RR validity
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 31 Dec 2010 17:54:54 -0000

I agree the standard is not explicit here. These are my thoughts on this:

Checking Signer Name in RRSIG record

The standard is not very clear on how the Signer Name in an RRSIG record is checked. It simply says "The RRSIG RR's Signer's Name field MUST be the name of the zone that contains the RRset." ( RFC4035, section 5.3.1 )

Unfortunately a validating resolver does not know the zone in a secure way, so it's unclear how this is to be implemented.

Instead, the actual checks need to be:

(1) The Signers name must be equal to or a direct ancestor of the Owner of the RRSIG.

(2) If TypeCovered is DS, the Signers name must not be equal to the Owner of the RRSIG.

(3) The Signers name must not be above the Active trust anchor.

Optionally, for types that can only occur signed in the zone apex ( SOA, NS, DNSKEY, NSEC3PARAM ) an additional check that the Signers name is equal to the Owner of the RRSIG can be performed.

>From http://www.george-barwood.pwp.blueyonder.co.uk/DnsServer/NotesOnDNSSSEC.htm

Regards,
George
  ----- Original Message ----- 
  From: Sean Wells 
  To: dnsext@ietf.org 
  Sent: Friday, December 31, 2010 4:54 PM
  Subject: [dnsext] Checking RRSIG RR validity


  Hi,


  In section 5.3.1 of RFC 4035 :


  The RRSIG RR's Signer's Name field MUST be the name of the zone
  that contains the RRset.  The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
  RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
  set.My question is with respect to the first two MUSTs: "MUST be the name of the zone" and "MUST be present in the zone's apex DNSKEY RRset". What does a validating stub resolver (that uses recursive query mode) expected to do for implementing these two MUSTs ?
ThanksSean

------------------------------------------------------------------------------


  _______________________________________________
  dnsext mailing list
  dnsext@ietf.org
  https://www.ietf.org/mailman/listinfo/dnsext