IETF Logo Mail Archive

Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-algorithm-update

Mark Andrews <marka@isc.org> Mon, 15 April 2019 14:03 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 57DE21200B1 for <dnsop@ietfa.amsl.com>; Mon, 15 Apr 2019 07:03:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 MvDuM2FqEC1A for <dnsop@ietfa.amsl.com>; Mon, 15 Apr 2019 07:03:40 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 CF614120292 for <dnsop@ietf.org>; Mon, 15 Apr 2019 07:03:40 -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 187593AB03F; Mon, 15 Apr 2019 14:03:40 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 053AD160052; Mon, 15 Apr 2019 14:03:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E8A1F160053; Mon, 15 Apr 2019 14:03:39 +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 9dkcQPlBN_z8; Mon, 15 Apr 2019 14:03:39 +0000 (UTC)
Received: from [172.30.42.90] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 9C441160052; Mon, 15 Apr 2019 14:03:39 +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 (16E227)
In-Reply-To: <EC649C91-7015-4EAF-839D-5C58D604793C@icann.org>
Date: Tue, 16 Apr 2019 00:03:37 +1000
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Michael StJohns <msj@nthpermutation.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F7D471E-B77B-4A01-90F0-97E73CDB61D6@isc.org>
References: <ec7ed79a-ae9c-bf6e-3ce7-1b529aa894fa@nthpermutation.com> <4CD31719-BC63-4038-9FD0-580B4C04BB64@isc.org> <A65F9777-A9C7-424B-B31C-A0FA33B48198@icann.org> <B3BBEDAE-235A-4BFA-AE49-44EA05CD5003@isc.org> <EC649C91-7015-4EAF-839D-5C58D604793C@icann.org>
To: Edward Lewis <edward.lewis@icann.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EA-DGFnzK3gol4vKoxC16w-8gxE>
Subject: Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-algorithm-update
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 15 Apr 2019 14:03:45 -0000

Well I think it is time for more fine tuning.  It’s still only PS. 

-- 
Mark Andrews

> On 15 Apr 2019, at 23:21, Edward Lewis <edward.lewis@icann.org> wrote:
> 
> A few follow ups:
> 
> On 4/14/19, 22:35, "DNSOP on behalf of Mark Andrews" <dnsop-bounces@ietf.org on behalf of marka@isc.org> wrote:
> 
>> You don’t publish DS records (or trust anchors) for a algorithm until the incoherent state is resolved (incremental signing with the new algorithm is complete).
> 
> While that makes sense, the protocol can't (not simply doesn't) forbid it.  The publisher of the DS resource record set may be a different entity than the publisher of the corresponding DNSKEY resource record set.  Because of the possibility of misalignment, the protocol as to be specific in order to be robust.
> 
>> You can only check if all records are signed with a given algorithm by performing a transfer of a zone and analysing that.  There is no way to do it with individual queries.
> 
> The historic error involved a resolver, upon receipt of a response, declaring a data set invalid when the set of RRSIG resource records did not cover all the DNSSEC security algorithms that the rules for zone signing specified, as opposed to validating the data set in question because there were sufficient records to build a secure chain.
> 
>> As for the original question, if all the DNSKEYs for a algorithm are revoked I would only be signing the DNSKEY RRset with that algorithm.
> 
> This makes complete sense, but is not in-line with the letter of the protocol's rules.  That's the issue.
> 
> The consequence of following the protocol's current rules is a lot of deadweight.  Namely, unusable RRSIG resource records sent in each reply of authoritative data just to include the DNSSEC security algorithm.  The signatures need not make mathematic sense - as no one would need to validate them - with one exception. Where ever there is a division of key responsibilities such as having one organization manage the KSK and a different manage the ZSK, a ZSK may be "forced" to exist by rule and operational configuration.
> 
> (Removed the remainder of the thread history...)
> 
> 
>

v2.23.0 | Report a Bug | By Email