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
- [DNSOP] Time to update RSAMD5 and perhaps DSA (al… Viktor Dukhovni
- Re: [DNSOP] Time to update RSAMD5 and perhaps DSA… Paul Wouters
- Re: [DNSOP] Time to update RSAMD5 and perhaps DSA… Ondřej Surý
- Re: [DNSOP] Time to update RSAMD5 and perhaps DSA… Viktor Dukhovni
- Re: [DNSOP] Time to update RSAMD5 and perhaps DSA… Viktor Dukhovni
- Re: [DNSOP] Time to update RSAMD5 and perhaps DSA… Hugo Salgado-Hernández
- Re: [DNSOP] Time to update RSAMD5 and perhaps DSA… Viktor Dukhovni
- Re: [DNSOP] Time to update RSAMD5 and perhaps DSA… Mark Andrews
- Re: [DNSOP] Time to update RSAMD5 and perhaps DSA… Patrick Mevzek