Re: [dnssd] Intended behavior for eliding KEY record in DNS query response? (draft-ietf-dnssd-srp)

Ted Lemon <mellon@fugue.com> Fri, 07 July 2023 19:15 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2091C1516E1 for <dnssd@ietfa.amsl.com>; Fri, 7 Jul 2023 12:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20221208.gappssmtp.com
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 9E6tX9Ykyray for <dnssd@ietfa.amsl.com>; Fri, 7 Jul 2023 12:15:40 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 31A5CC151535 for <dnssd@ietf.org>; Fri, 7 Jul 2023 12:15:40 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id af79cd13be357-76758b855edso166831685a.0 for <dnssd@ietf.org>; Fri, 07 Jul 2023 12:15:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20221208.gappssmtp.com; s=20221208; t=1688757339; x=1691349339; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=wkLiY7s9sg5Xg2JFFdImpXRETCclYUFp1DkI9RSFXKI=; b=B5xen08XK9w+CgipWr3l50JKhv708QexLqAFdDxDLyjW0WjrF14jaPKfJ4ChC+1WOQ hFdcCLNAD8DYdTP/hRxbhHcwruI3cg9/CASS4ekIrIay3KgYZ+bTUuIvO+rrBy9TEFlF jJ50r2yEDdeZBhMyX2C+SMY4SvLMaSx3zjoIkYblCq4Y3chzwovueLCMih8hpJI9J+aa bKVOeYy0Tl+fZtHwCQk+O3toM9IaDlJm2acF80UABJeKzgITjTchiDTLbV6wMeMEZafW ZIKfpfUpQij3Qe2r4mU1zAUHWmWsXURIT7yWyAcWuFMRDteWTi5G8s5eKslLFMEZLDkP kd0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688757339; x=1691349339; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wkLiY7s9sg5Xg2JFFdImpXRETCclYUFp1DkI9RSFXKI=; b=FW+D9lbIYBobdh6kXOf+gMF2b0I0ZQiw+owqWrquTa5EmESv9v3MgnZ60tKxg51tH8 Q6bvr5rIPElljzKD9pwXObBHlv9UlPsDzbqNJSy3dxBmwbLUVcULiB01z0jjYslLzkuX zx38WSaxMBbD9ps4alpa3LnjZP+iILWMn8mSvPQaHKZRR89hoI7/K2oMnnEolHMo+zqc QH+iZm/9wg63vyiahZLfwXO4cymbfKJWFhoaY6XB/XE2BAmujN/tTt1wrLPc0QyZYuAp OQjRie2ljxBT6+EjtFyupt3CfZps3cCQNB1OGnvoesB57FR/SThre3OFcQw3LHKf7Y8I acmA==
X-Gm-Message-State: ABy/qLbuQ93d93dCGHKLrzh9AHE8uzI4zCmduVj7HEYe17P49Zbw7Mu7 uswcE7yfgv/CJcU1Q4T20U+GOXzeRaATOiPCB1tNMzMKrPA99G2PFHA=
X-Google-Smtp-Source: APBJJlFaI3QDer57KC4kDENOoWpE6eidvbEeIIz88OQkUGFZAJnRsDYCqy+idUk26H0h6iVKcmk8A7JA1oNLZJ/0u+8=
X-Received: by 2002:a05:6214:2a8f:b0:637:963e:9646 with SMTP id jr15-20020a0562142a8f00b00637963e9646mr5923156qvb.32.1688757339287; Fri, 07 Jul 2023 12:15:39 -0700 (PDT)
MIME-Version: 1.0
References: <DU0P190MB1978200A6FCB7259C8B3B0C5FD2EA@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1knidoVUHDFvd+6BW2msCVkjRfRi3COxpHpZKtjGFZFOQ@mail.gmail.com> <DU0P190MB1978076949E643E64EDC73E7FD2FA@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1mi+6ma=MyEofp_gzRF9So1=EhKnXiqwwr8gAPxK=ecyA@mail.gmail.com>
In-Reply-To: <CAPt1N1mi+6ma=MyEofp_gzRF9So1=EhKnXiqwwr8gAPxK=ecyA@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 07 Jul 2023 15:14:57 -0400
Message-ID: <CAPt1N1mdc0ULdmqb2aGgRqXJxx_vgDRTpCVpeAc5YhgHzV02qg@mail.gmail.com>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>, dnssd <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000520af705ffea752d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/J7Yj_Bhutm8ilcnazu_SPrRar6E>
Subject: Re: [dnssd] Intended behavior for eliding KEY record in DNS query response? (draft-ietf-dnssd-srp)
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jul 2023 19:15:40 -0000

I've updated the text to say:

To avoid DNSSEC validation failures, an SRP server that refuses to return a
KEY record MUST NOT store the
KEY record in the zone itself. Because the key record isn't in the zone,
the nonexistance of the KEY record can be
validated. If the zone is not signed, the server MAY instead return a
negative non-error response (either NXDOMAIN or
no data).

On Wed, Jul 5, 2023 at 11:03 AM Ted Lemon <mellon@fugue.com> wrote:

> Op wo 5 jul 2023 om 03:06 schreef Esko Dijk <esko.dijk@iotconsultancy.nl>
>
>> The “why” is maybe not so relevant – if something is optional in a spec
>> to NOT do, implementers will jump on it by NOT doing the thing. They even
>> don’t implement RECOMMENDED functions in my experience ;-)
>>
>> For the testers, it means they have to test for the possible variants and
>> need to know what to test against.  Right now as specified there’s 3 cases
>> possible: 1) return KEY ; 2) return RCODE=0; 3) return RCODE=5 .
>>
>
> Okay, that makes sense. This is a pretty late clarification. Chairs, do
> you object to me including this in the forthcoming update?
>
>>