Re: [DNSOP] Time to update RSAMD5 and perhaps DSA (algs 1 and 3) to MUST NOT?

Patrick Mevzek <mevzek@uniregistry.com> Thu, 06 December 2018 21:38 UTC

Return-Path: <mevzek@uniregistry.com>
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 CB4401311D9 for <dnsop@ietfa.amsl.com>; Thu, 6 Dec 2018 13:38:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uniregistry.com
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 Mcdz-kO6bIks for <dnsop@ietfa.amsl.com>; Thu, 6 Dec 2018 13:38:36 -0800 (PST)
Received: from a.mx.uniregistry.net (a.mx.uniregistry.net [64.96.177.8]) (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 CE12C130F19 for <dnsop@ietf.org>; Thu, 6 Dec 2018 13:38:36 -0800 (PST)
Abuse: Forward to abuse@uniregistry.com with full headers
X-Virus-Scanned: Content filter at a.mx.uniregistry.net
Powered-By: https://www.uniregistry.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniregistry.com; s=bravo; t=1544132315; bh=qJFRM19XhDYIbtJgZf9Ejbhv/daC5pjS0DbrW1QclnI=; h=Subject:To:References:From:Date:In-Reply-To; b=pk0LOdQ/9dYv4y88VfB9QFMsph6yXvg9/lKziyOu3pFR+VLusWM0CrmEozmtwJx7s G+Tb582DfQrv7PDGbSMesC6ukbT6sg1J78FiRXTO+c7aGtzH6s6sszgz8808tcpWnG IKY+d+y2AGI2N0MRRv5+X6LPpIbj5ne7uQdjKJVtzGAtWQZ57b8iqaXAKIUkU/n9pX MOYgujRrlpusHXLsnToM1L24fKbPVajK14+i143mn9EVtyIFEbbZA4NPCQQ7OJqKyq TcLxsYcU54wdBH0kMj+CRgAmV8WI9RwcYNs1wlHQV+aFoNeP0nzu6RT0UfASrnpZ68 gvFALyb/WOewQ==
Received: from PatrickM.local ([66.54.123.66]) (authenticated bits=0) by a.mx.uniregistry.net (8.15.2/8.15.2/Debian-8) with ESMTPSA id wB6LcXMX007357 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 6 Dec 2018 21:38:34 GMT
To: dnsop@ietf.org
References: <20181201195126.GK4122@straasha.imrryr.org> <A30290FE-DED7-46BD-B07B-7E795F6B3334@isc.org> <20181205221417.GW79754@straasha.imrryr.org> <20181205235455.GY79754@straasha.imrryr.org> <20181206132655.lngnprkmv7wckv4b@nic.cl> <20181206205942.GA79754@straasha.imrryr.org>
From: Patrick Mevzek <mevzek@uniregistry.com>
Organization: Uniregistry
Message-ID: <23f7be50-ccce-f0be-0307-4da6c0ed2b15@uniregistry.com>
Date: Thu, 06 Dec 2018 16:38:32 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.3.2
MIME-Version: 1.0
In-Reply-To: <20181206205942.GA79754@straasha.imrryr.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_U4l9KQ5hI4gLIFHg2m72Dvn98I>
Subject: Re: [DNSOP] Time to update RSAMD5 and perhaps DSA (algs 1 and 3) to MUST NOT?
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: Thu, 06 Dec 2018 21:38:39 -0000

On 2018-12-06 15:59 -0500, Viktor Dukhovni wrote:> To prevent crappy DS 
records, the registrar or registry would need
> to check that the zone contains a matching key (matching key tag
> and hash value) before publishing the DS record. 

That would then prohibit prepublishing the DS record in advance of the 
DNSKEY one as it happens for some scenarios ("standby" key for 
emergencies for example).

See https://tools.ietf.org/html/rfc7583#section-3.3.2

DNSSEC data through EPP can be also done during the domain:create at 
which point obviously the domain name does not resolve yet and hence 
there are no DNSKEY to check, but you may still want to publish a DS 
record in advance.

See https://datatracker.ietf.org/doc/html/rfc4310#section-3.2.1

> IIRC some registrars don't support direct input of DS records,
> rather they accept DNSKEY RRs, and compute the DS.  

Some registries also allow only DNSKEY and deal with DS records themselves.
Some others ask registrars to send DNSKEY + DS, probably in order to 
double check the DS was computed correctly.
-- 
Patrick Mevzek