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

Matthijs Mekking <matthijs@pletterpet.nl> Tue, 03 April 2018 13:28 UTC

Return-Path: <matthijs@pletterpet.nl>
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 6954312E8E6 for <dnsop@ietfa.amsl.com>; Tue, 3 Apr 2018 06:28:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_PH_BODY_ACCOUNTS_PRE=0.001, 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 UvINIWmUhD3C for <dnsop@ietfa.amsl.com>; Tue, 3 Apr 2018 06:28:44 -0700 (PDT)
Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 5BB9312E8E2 for <dnsop@ietf.org>; Tue, 3 Apr 2018 06:28:44 -0700 (PDT)
Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w33DGvZi125564; Tue, 3 Apr 2018 13:28:43 GMT
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2h4aby822t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 03 Apr 2018 13:28:43 +0000
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w33DSgpv024854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 3 Apr 2018 13:28:43 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w33DSgqM026500; Tue, 3 Apr 2018 13:28:42 GMT
Received: from [172.19.129.14] (/216.146.45.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 03 Apr 2018 06:28:42 -0700
To: Mark Andrews <marka@isc.org>
Cc: Frederico A C Neves <fneves@registro.br>, dnsop@ietf.org
References: <20180329184513.GF62218@registro.br> <c62db666-fc1b-8ef8-8fbb-42443e1b69a0@pletterpet.nl> <2B754A32-E4AD-4D77-8A2F-60DCDD5BAF4E@isc.org>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <cae98e47-23c7-efea-9edd-548653d1ef7f@pletterpet.nl>
Date: Tue, 03 Apr 2018 15:28:37 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <2B754A32-E4AD-4D77-8A2F-60DCDD5BAF4E@isc.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8851 signatures=668697
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804030138
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/I8eiCwyHYk6wreTcEKWFksV64bs>
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:28:48 -0000


On 03-04-18 15:22, Mark Andrews wrote:
> 
> -- 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.

If I add a DNSKEY record to the RRset, I would definitely want a new 
RRSIG because the data changed, so the existing signature is no longer 
useful.


> 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.

Implicit RRSIG deletion is only for RRSIG records covering the RRset 
that has changed. It is not meant for re-signing purposes, nor is it 
meant for sophisticated DNSKEY tracking.


- Matthijs


>>> 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
>