IETF Logo Mail Archive

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

Mark Andrews <marka@isc.org> Tue, 03 April 2018 13:23 UTC

Return-Path: <marka@isc.org>
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 12D5912E8D3 for <dnsop@ietfa.amsl.com>; Tue, 3 Apr 2018 06:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 F57HxPTGdess for <dnsop@ietfa.amsl.com>; Tue, 3 Apr 2018 06:23:23 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7997312E8E8 for <dnsop@ietf.org>; Tue, 3 Apr 2018 06:23:15 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 3B9CF3AB03B; Tue, 3 Apr 2018 13:23:15 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 25FA6160054; Tue, 3 Apr 2018 13:22:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 13FA416007A; Tue, 3 Apr 2018 13:22:45 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BUSnzfL9F-WW; Tue, 3 Apr 2018 13:22:45 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B6B12160054; Tue, 3 Apr 2018 13:22:44 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Mark Andrews <marka@isc.org>
X-Mailer: iPhone Mail (15D100)
In-Reply-To: <c62db666-fc1b-8ef8-8fbb-42443e1b69a0@pletterpet.nl>
Date: Tue, 03 Apr 2018 23:22:41 +1000
Cc: Frederico A C Neves <fneves@registro.br>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B754A32-E4AD-4D77-8A2F-60DCDD5BAF4E@isc.org>
References: <20180329184513.GF62218@registro.br> <c62db666-fc1b-8ef8-8fbb-42443e1b69a0@pletterpet.nl>
To: Matthijs Mekking <matthijs@pletterpet.nl>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vvb0OyW3heiENgx_O6AG1P7b8JE>
Subject: Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 03 Apr 2018 13:23:30 -0000


-- 
Mark Andrews

> On 3 Apr 2018, at 22:37, Matthijs Mekking <matthijs@pletterpet.nl> wrote:
> 
> Hi Frederico,
> 
>> On 03/29/2018 08:45 PM, Frederico A C Neves wrote:
>> I was looking at our server to evaluate the MIXFR implementation and
>> it seams to me that the current text covering dnssec aware client
>> logic don't take in account that a posterior record at the addition
>> section, by an MIXFR DNSSEC aware server, will implicitly replace the
>> RRSIG RRset.
> 
> I am unclear what case you are covering.
> 
> 
>> Logic could be simplified only to Deletions of RRs, when they conclude
>> a removal of a RRset, or RRsets by itself.
> 
> No, also if there is an RR addition, it means the RRset has changed, so existing RRSIG records can be implicitly removed.

Poor logic. Take the case where you add a new algorithm to the DNSKEY RRset there is no requirement to update existing RRSIG.

Even when re-signing you can’t remove RRSIG with the same key id unless you know that the server prevents duplicate key ids.  For the general case you need to validate the RRset against the RRSIG to give the DNSKEY then you can delete RRSIGs generated from that DNSKEY. 

>> All the other canonrequirementses, addition or replacement, will be covered
>> automatically by an addition or replace of a RRSIG RRset. There is no
>> need to extra client logic to remove RRSIG, at addition of a RR, and
>> at deletion of a RR if it not remove the RRset.
> 
> Note there is no such thing as an RRSIG RRset. I tried to clarify this in the terminology bis document:
> 
>  https://www.ietf.org/mail-archive/web/dnsop/current/msg22118.html
> 
> Note that adding an RRSIG is different than replacing an RRSIG.
> 
> 
>> This is documented as issue #10 and includes proposed text.
>> https://github.com/matje/mixfr/issues/10
> 
> I think it makes more sense to keep the text as is, that is when changing an RRset implicitly remove the corresponding RRSIG records. I am opposed to only removing corresponding RRSIG on a RR deletion.
> 
> Best regards,
>  Matthijs
> 
> 
>> Fred
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

v2.23.0 | Report a Bug | By Email