Re: [dd] Challenges with DELEG awareness in DNSKEY

Petr Špaček <pspacek@isc.org> Thu, 02 May 2024 13:20 UTC

Return-Path: <pspacek@isc.org>
X-Original-To: dd@ietfa.amsl.com
Delivered-To: dd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70D9C157938 for <dd@ietfa.amsl.com>; Thu, 2 May 2024 06:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b="OB5ESDIT"; dkim=pass (1024-bit key) header.d=isc.org header.b="JlicIakP"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjA1ajChelr3 for <dd@ietfa.amsl.com>; Thu, 2 May 2024 06:20:53 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A98C13AE25 for <dd@ietf.org>; Thu, 2 May 2024 06:20:52 -0700 (PDT)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.2.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 509943AB015; Thu, 02 May 2024 13:20:52 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 509943AB015
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.31
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1714656052; cv=none; b=VORlPUV/c4IbrZOkxTfz4RfiIF0TSOaTleBsNhk0KhCYOvOsAFO2QESfpQy2QMH0Kg9frW1C6Px+/D3/B2t0tYUg2KdVZ/LfLftJhm76o9l3e133nxc6iC+8sXZXdv8pvJLaz4nWLeIEN3F8Dv0ysBsrZOWuPmSzUOXDtG0mnZ4=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1714656052; c=relaxed/relaxed; bh=FHyRnRUweeEK4mTlWsbbh77ZLdeyqybr6sOzmq3GxDE=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=KhjPXsCk54jzORnriYNVI2s2X2N8deWk2yzZgEEr/Z7xQC3JjkpWXl0yp0VIGKy/27N4b2oW2vL+LjAFTWhSHNiRBytX20Y410Gqhchuzdg3CeIbGTHb0eKB/HRKuawYU2v+h45+bgW1iQoAtcqCNxA5RgZ7mwzA7W3Yp6XsqQc=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 509943AB015
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1714656052; bh=FHyRnRUweeEK4mTlWsbbh77ZLdeyqybr6sOzmq3GxDE=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=OB5ESDITbfSfh3PutlNWwYO7HEZHb5z+x63I1SFwLL2aNvntn09OEJHnUpvdsB4SN ozf3CZGnWVWDgjZIZmvAUrsoLtEUCX8lfkjFL2fHbqB3zajXWUCrbZTlzAlW6U7KCq pjqpIWivt/w6+pJAJuEoV9+PkLHAz7OaJ2mPGSL4=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 4B5041144279; Thu, 2 May 2024 13:20:52 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 2A6CD114439D; Thu, 2 May 2024 13:20:52 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 2A6CD114439D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1714656052; bh=FHyRnRUweeEK4mTlWsbbh77ZLdeyqybr6sOzmq3GxDE=; h=Message-ID:Date:MIME-Version:To:From; b=JlicIakPJ3cZFTULFH4MTb8DlRnp8VntMKgMAmSVmy18r/79Dma6+n0aTtNzU8uib U5pCtsRQUelc12f86QlJddJhcZWZNItcIa2dXeNKvCIz99ZnZP306xDJnRuAhiBsed e+DiVMe52eeDMohrWnqCxdgfTo2nzRCfTcJgqR2A=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id LmUZh6NrqnCr; Thu, 2 May 2024 13:20:52 +0000 (UTC)
Received: from [83.148.32.161] (unknown [83.148.32.161]) by zimbrang.isc.org (Postfix) with ESMTPSA id 752781144279; Thu, 2 May 2024 13:20:51 +0000 (UTC)
Message-ID: <01ed9499-e556-403d-88f7-d4380049ac55@isc.org>
Date: Thu, 02 May 2024 15:20:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Roy Arends <roy@dnss.ec>, Bob Halley <bhalley=40cloudflare.com@dmarc.ietf.org>
Cc: dd@ietf.org
References: <CAB1+oZ5vkivgegiL7CaAN9GKpymqgMiC+VpXr_1X--ohVcd4cQ@mail.gmail.com> <4ACA5E62-B870-45E6-96B4-C39FD0244B6B@dnss.ec>
From: Petr Špaček <pspacek@isc.org>
Content-Language: en-US
Autocrypt: addr=pspacek@isc.org; keydata= xsFNBF/OJ/4BEAC0jP/EShRZtcI9KmzVK4IoD/GEDtcaNEEQzPt05G8xtC0P4uteXUwW8jaB CdcKIKR4eUJw3wdXXScLNlyh0i+gm5mIvKPrBYNAMOGGnkbAmMQOt9Q+TyGeTSSGiAjfvd/N nYg7L/KjVbG0sp6pAWVORMpR0oChHflzKSjvJITCGdpwagxSffU2HeWrLN7ePES6gPbtZ8HY KHUqjWZQsXLkMFw4yj8ZXuGarLwdBMB7V/9YHVkatJPjTsP8ZE723rV18iLiMvBqh4XtReEP 0vGQgiHnLnKs+reDiFy0cSOG0lpUWVGI50znu/gBuZRtTAE0LfMa0oAYaq997Y4k+na6JvHK hhaZMy82cD4YUa/xNnUPMXJjkJOBV4ghz/58GiT32lj4rdccjQO4zlvtjltjp9MTOFbRNI+I FCf9bykANotR+2BzttYKuCcred+Q7+wSDp9FQDdpUOiGnzT8oQukOuqiEh3J8hinHPGhtovH V22D0cU6T/u9mzvYoULhExPvXZglCLEuM0dACtjVsoyDkFVnTTupaPVuORgoW7nyNl0wDrII ILBqUBwzCdhQpYnyARSjx0gWSG1AQBKkk5SHQBqi1RAYC38M59SkpH0IKj+SaZbUJnuqshXh UIbY1GMHbW/GDhz7pNQFFYm2S4OPUBcmh/0O0Osma151/HjF7wARAQABzR9QZXRyIMWgcGHE jWVrIDxwc3BhY2VrQGlzYy5vcmc+wsGXBBMBCABBAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4B AheAAhkBFiEEEVO2++xeDVoSYmDzq9WHzfBlga4FAmWT+REFCQelsxMACgkQq9WHzfBlga7y 2Q//Ug58UI9mlnD/guf9mHqpJIMrBs/vX8HlzylsDcZUBTp2TJpzNh/CygPWrHY+IvA9I9+t Ygp0sB+Z9OtVZgW3bpWJ0iWe6N89Q0kwOuhJ75LsfR1V73L5C826M6bLQjYTj6HiwS9Nf+N0 jADhEV/p1KtCuZfwBkYJ4ZM+Na0zWerGPkGw9T9O0gfs0ePehzJ5V0OK0nCqMuC1h8o/rhCb vRCmxdAbNjrOrgKa7HN5DadP/tKstJMM09aXlT5q96fRIyCQyqXQoCrijCWvgAxgjABdh1TB /XsYvBC8+4wy5ZBtTcnxXGrMhrSxU2/vIK6RjDju7OIRClMNepEzvt0gNzxwwxIXVOzl5ioC i/Okovk1rZneFFxbVvaMyIJgY/hShJV7Ei+5S9UZUv6UUmRQ6zukeiSVZrtXs6fWLVlUnBDl Cv/fXi25hrymqNfPSBSB0tyc6YepR1Rq9omTni6DYmEHQuhPMHJ2fuiNNyBaH+9EI7go5e0J LvXVLJGXkMdTcmYHja1pDjmQ1K71gewfPWGFmn0JTa92GuZJaR/4MVePvoV0NTpCP0HiKIg5 0+AOdpvkJReFKTQOX08SwkUkgvy9h9WjBMpD5ymMs4gjJwXtcT1+aVtj9Xcw6tQde9Yyjxde a6UZ3TUfys8qZ8ZKmMKTaCUFukKzWDJMZ91V1b/OwU0EX84n/gEQANARNXihDNc1fLNFZK5s O14Yg2TouK9eo9gGh4yLSrmZ3pjtnuJSpTWmGD4g0EYzhwWA/T+CqjUnrhsvzLQ1ECYVqLpM VqK2OJ9PhLRbx1ITd4SKO/0xvXFkUqDTIF6a5mUCXH5DzTQGSmJwcjoRv3ye+Z1lDzOKJ+Qr gDHM2WLGlSZAVGcUeD1S2Mp/FroNOjGzrFXsUhOBNMo8PSC4ap0ZgYeVBq5aiMaQex0r+uM4 45S1z5N2nkNRYlUARkfKirqQxJ4mtj5XPC/jtdaUiMzvnwcMmLAwPlDNYiU0kO5IqJFBdzmJ yjzomVk1zK9AYS/woeIxETs+s6o7qXtMGGIoMWr6pirpHk4Wgp4TS02BSTSmNzParrFxLpEU dFKq3M0IsBCVGvfNgWL2pKKQVq34fwuBhJFQAigR9B3O9mfaeejrqt73Crp0ng0+Q74+Llzj EIJLOHYTMISTJyxYzhMCQlgPkKoj+TSVkRzBZoYFkUt4OXvlFj73wkeqeF8Z1YWoOCIjwXH9 0u2lPEq0cRHHyK+KSeH1zQJ4xgj0QDGPmkvi81D13sRaaNu3uSfXEDrdYYc+TSZd2bVh2VCr xrcfzQ1uz9fsdC9NPdNd7/mHvcAaNc5e9IhNh67L54aMBkzlJi18d0sWXOOHkyLSvbHnC/OP wv7qCf69PUJmtoeHABEBAAHCwXwEGAEIACYCGwwWIQQRU7b77F4NWhJiYPOr1YfN8GWBrgUC ZZP5UgUJB6WzVAAKCRCr1YfN8GWBrgxpD/949Tz7EtrE9e2yJ4np+y7uW8EDusVM3QsBdkYk yaQTupITew8WWQtNF/QK/MKRi+e/382t78nBq+T7G9PrRi7E4WS9dXdgJiFz25h3mC4TABJZ b6MLcEreLWTaqnR/D6F3AnNXh7GJFY4E6PAwC60W0R9G6R0E+2XeZX011NEGiBMvgZnqzzjU L9h8Gz7a/EsQync4cvLbruPt/UaOV0khKTefsOFj3q3wLY6qN2qw7HfgFRBCh6ME2XRvnwAd iv0pF4HRbXoFalkAsNEYkWQ6mkJjdYCHOWm3TWqXhalgGKqIOrQyMpH2mJpZllKBQiBiQMUz qz0cO9OqBk3xvNLplI3VNcC0WeQ8LEqyYKth2T78hVaIw8K0IcVmZQwXVxL03gojaJ5bK2O+ 2FfqKMcIiU+bqaTXntx+FYRQKblsUBYD77uU9sPVyKWIiHvukLTx7GY1ttn6gZDSIek/tTR7 oaei+xLh5JUgZpMZ4JHnirDWHbrJzYN95e8HWA/+qAOTsa+igZGsc6yA1oJIAnCwkclcLAgc x3GVVeEL+/b9CugZ+1OfbxlRK7gAeu0kyKiEXrUvCQPnPByIIfj4I4IvZO4552cmmnbn31f9 X/9nw+M4qAqOK7bRg65ucv71TayUehNJrfJSYx6P1tXIwzu19tIgtdWTcsszNWALfaUFtg==
In-Reply-To: <4ACA5E62-B870-45E6-96B4-C39FD0244B6B@dnss.ec>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/7qdBtSs57yuvxYUd4f31LUCLu5k>
Subject: Re: [dd] Challenges with DELEG awareness in DNSKEY
X-BeenThere: dd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DNS Delegation <dd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dd>, <mailto:dd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dd/>
List-Post: <mailto:dd@ietf.org>
List-Help: <mailto:dd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dd>, <mailto:dd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2024 13:20:57 -0000

On 20. 03. 24 16:19, Roy Arends wrote:
>> On 20 Mar 2024, at 13:48, Bob Halley <bhalley=40cloudflare.com@dmarc.ietf.org> wrote:
> 
>> 1) The draft talks about “the DNSKEY record” but the DNSKEY RRset of
>> an authority may contain many keys.
> 
> A dedicated DNSKEY, unused for signing, solely present for the purpose of signalling to a validating resolver that it should expect authenticated denial records in a delegation response, will do.

This is also my preference. I don't see real downsides to this approach 
as long as we accept this signal is on per-zone level.

- TTL is controlled by child - can be even 1 minute if operator is 
really scared of turning it on
- can have unknown/reserved algorithm number and zero-length payload so 
bloat should not be an issue
- it indicates new parent-side & signed RR type so I think it's very 
much DNSSEC related and not really "overloading" as mentioned by Ed in 
the other subthread

If we define the bit to mean "DELEG RRset or its nonexistence must be 
signed" it even allows experimentation with DELEG answers from auth 
without downgrade protection.

-- 
Petr Špaček