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

Esko Dijk <esko.dijk@iotconsultancy.nl> Thu, 24 August 2023 08:11 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
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 BAF1AC14CE39 for <dnssd@ietfa.amsl.com>; Thu, 24 Aug 2023 01:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=iotconsultancy.nl
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 KIiONdNtpAG0 for <dnssd@ietfa.amsl.com>; Thu, 24 Aug 2023 01:11:38 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2097.outbound.protection.outlook.com [40.107.21.97]) (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 2DAA7C14CE3F for <dnssd@ietf.org>; Thu, 24 Aug 2023 01:11:37 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QhvaqmE2+zlLslMv3OdSyVELSiG7ww7ufszKxQYqEwkyZVW+Fjps4B4FY8a45MIjUIwqeWQPk6MXAcn7hrA09TShDqhBX6U7X8ZRMFWXbUx8p2SqGK1EQk4mr9gtku128rPxbU1gFOrg5/4RdsjIi+azlgV43JJE1H3bli7fWHTWigIWra1XC91zHyOJ4uKpIidDlOVxtAih4+nAQ72H17ty58MIV8QkSGcQM9ftc1qFJD7/PKelFYoT4IxTyWsMdGS+/uva0VTkHcMrBdiayn+7K2oG5UqB3i2PR4G1DkyFcBNbubvV0SdH7ahHhsoz8B68YeVlFVVGDeTjkqPzqA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GAGvg/ZlHEajM8nmuXabSbMiyvyL6Rp54jda6nZ/9tQ=; b=DkfJB95oGSJxlw9DcschiU0AuZG2isp8k0H8x1f1AxE1gBmP5GkVcq4UJ65kI5XMR9upmppJ0srGGj6zuslO/Ie/9GEUfe36Ow+JvevSU9zYrZRyhuVwCacccdD2rNI9tVLk5fQnL1a3nhdrvmZw3j5FWN9YC4Of+8FrlsAp6LOAB35i+k/QMnSaqVy9l8wd8rL3p6XiUuCV6hzG5v+cZ3AX2d3KuZB2DnTjBBJGn6eR9pM1UxS8mKnlRG/yG5D3sGrxelKeWXOdDkZNgK8HIFPTyJSDlVz9cYsLRgDsNUSCv7dmwYQSBnBjfiLvbqrbSz1URfOIPe3f1paFH9eJfQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GAGvg/ZlHEajM8nmuXabSbMiyvyL6Rp54jda6nZ/9tQ=; b=GVA7Tg05oQkg3wNsuSV2wC8HtsFzNUwJvHwLn/69rtmOJgpXzZ4q7mGGm03HxX3RaHtmIp0zzCctG8FUB+9lqQEPFb3k1++YXrhMzKqd/OTPfjA/92TubwIAFaP9sdLYwe+g0YMJGObEOntpG9SeEtjJtLNVy7fd+SoHD0C0W34=
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:3b9::20) by PAXP190MB1423.EURP190.PROD.OUTLOOK.COM (2603:10a6:102:1bd::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6699.27; Thu, 24 Aug 2023 08:11:32 +0000
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::6cab:dca2:fbc5:20d9]) by DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::6cab:dca2:fbc5:20d9%3]) with mapi id 15.20.6699.027; Thu, 24 Aug 2023 08:11:32 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: Ted Lemon <mellon@fugue.com>, dnssd <dnssd@ietf.org>
Thread-Topic: [dnssd] Intended behavior for eliding KEY record in DNS query response? (draft-ietf-dnssd-srp)
Thread-Index: AdmurxopT/VHTaeVTGaUrZGEqOjVmAACGpiAABWo+oAAEO4ygABtXAGACVZOTvA=
Date: Thu, 24 Aug 2023 08:11:32 +0000
Message-ID: <DU0P190MB19787D95527477F9DCE6C396FD1DA@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
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> <CAPt1N1mdc0ULdmqb2aGgRqXJxx_vgDRTpCVpeAc5YhgHzV02qg@mail.gmail.com>
In-Reply-To: <CAPt1N1mdc0ULdmqb2aGgRqXJxx_vgDRTpCVpeAc5YhgHzV02qg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=iotconsultancy.nl;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU0P190MB1978:EE_|PAXP190MB1423:EE_
x-ms-office365-filtering-correlation-id: 91d1f26e-7a43-49bf-aa41-08dba479ba31
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EtYrb/tMl81+Yb2Mzoakrp0k6aJOmkEjQcng6d4DYt+x5abRVqTgAzsnsbE4t8bfzhqYumbq6Vig1ho+NY+Iy79uq5SA64reX3drK25FhwXf0m+r/FcgYLfSrcN6/tXRTxVHFJQTKFcgUb9NiFSEpT1edZp2gvvopwux/gdqKJwVkFrTuP9c6liyjn+vDOO00WLMADeQB0MHyDa/sFHQEJ7ltQLP3cBZ3b1FwnRXsWjSPYAhQVGrFOjVN5fDCIphoc5H3r/ORdW/3Cpy3iZnK7M7/ZQi7HxOlZ4ImFVJDQAy8bNgytIxa5CYKrpm9g3CT0diu/XcuLcxz6l7m0nySWxW2AF6K9yE446bqB5qQeQLluJrhl/FfL6tT9XzdwkHqqFnrLD79jFJSkqoXbzAkyTAWp0kLcudopajmirCY3B+vyATOCnmN/wv3pD/GmHyt9tc737fVRyTL/8mb5nWwlYs1rn1oTMXLowSaIwVZj//sebHIXQnIMG41ejZs11R4pA/a0YQsteaiz0oxx2zkRE3JygzJlEG899oaNCGEcIIhdWi2EKB09+rmCt/kfRJ/8hWESMNjgoxemwB1JrnO7PwhUpbj545OXus7tcWgsBb1Fr/b2vUiB5y0wpVa484
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0P190MB1978.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230031)(39830400003)(396003)(136003)(346002)(376002)(366004)(451199024)(186009)(1800799009)(66446008)(64756008)(66946007)(76116006)(66476007)(66556008)(316002)(122000001)(478600001)(110136005)(55016003)(44832011)(38070700005)(38100700002)(71200400001)(41300700001)(53546011)(86362001)(6506007)(2906002)(9686003)(7696005)(8676002)(8936002)(52536014)(5660300002)(83380400001)(33656002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: im4Q7xjPpN9VN38uzt1HkSKlcO/i80MVti8ScsMF8wGk6Ad/uDbFSIGWbhNXke2EO6I5uyXiJz2OvOBFOJUSa2eBDnHZKdWspaYT6OSCoyiL7+nedbV4T2eLY+mzqL+13CsKBng4f/99ipV2OzBxOilFndTWeyj/qqe1Iu9gJiv+WYdj1gO2TIFbnCijVfsENISyYvo4SJdCCnUHh7daPtoUTCeMT2AQaQth3Q/JRPCq8N3Lm/vALM8Y9sDpaTG6KpL60vm32/IPyyI6+TE8qzj1NAtfWdkQNlVqeZvPL1B6WSLRbIa7tH304C4KnWeC5g7Rq7KIJPUCvjkytFUjcsEb5n6XbRvd9EmyYeHmpa5d6COTnxXKat1H+TQGC+MGyDF0C5HZGXnFfTYyyS4AP+tRpF1/lYZnCNKHtBDXIow7bCnGJ5MNJFzVDQJLKWizYTiQdYCo1vKmPKtWsawEK6y+y58zR3OF4XLuj4G14jfOkvzF6ayEIygktVG0PucIcrvwveh8nWycKwRtWIP/r6qZschFthq37jR73kmsnRxxcapQez1c4gHX3fT8+VcvFoY2Ziri+DoOh+8EsARnclEBbrwcZMYMnnbw/VI6q7R0OHKvuySEQ1N61JviHU1A416IHR8djt0Z2d620HdMv1awpbCGMiXu+v1chYQKO2tMkldDYD93IGJ09C/i9rqkia0qT5fl96OU4m3AxtbyFrZcq/mlA7F90d4ZVzIJ7lnZG1Q3gMh0V8Ygjv9DL4J3egjF6kVquk7Vwx3YQqvg9KtFtLzxEdJ3haTM9/LyEkGV4kruoh8giXgJ3w+Dv6FbxxsWiQ0BfpMnumOOCM8A+ztvhop9dYEY/NoJTJa7nSqkr68bQyc6ODFs2Rw0E+sJ6xpH8Nrhs1xAHrAHDw7eibl52XL/aJJb3WI6WAbtU5bDMyUGZeTskap6731Me2+1eM+9CN5SrlfYko9QQuneI3U6AHRHVzl23gb/X5x4SQhCHoU2zP6JR98Ag62vzOEIn6c9zOJobjrISnqmWfAxctbDflgO7MgancjIdPkQ1eiNo9k1Zrl0JhLYlDl5ZFDaqvqdjZwtjdQSfTxXRY9HEtY2aPiIe/AiJyFU2x/wXFepdgItQCcrS98dr7wfUS+5RrJpX4AdmiD8fdqValUJTmeOW6mBLhy30uWFT9GXqH3rZEMLXCzJNN4CEfhXkBrVMVgsAjhtJA9sqTfZkmvdC3JtA5481Rmfk3QJEjazrAR9rV4eAlmfwxJk4MuCO7E5wQ3S0Lpb/WdIKXLAuT4Vv8uh5ULxOoB0WD0ebR9U3kDGDBgb40zTv0xLbfuystumt+mV4GfiTDiLbuHqQN4Tfx21HhSyWUsGx3KmcDG68YiwmXvR77xi4pUHQlblfuwOpT29OnoijBBRj6mwBln44A4X7SudNOYf3Bg1ZeAvI9EMW6j9jf1oWlPSWDNWtZ4E3AWeqUax+uXY4uxvwJgdXOy5Xm7iRWhTR3yA4vT0ZFa7C0e+83n5KbjlvdTgRXWNTtr/Te6T4H7jXSgAYjGppxu1TQsgQig6hLQPGD7DUB0a/GP8lBMY+QIgOnA7B4LHpI4rm4HAlpXDpeo7XQlqDkH5p+SB6omdQ01L+VnjIi5WEStaZBw76zRoVcwtOrFhHglBsgLjRCWTSF9+14jnBQ==
Content-Type: multipart/alternative; boundary="_000_DU0P190MB19787D95527477F9DCE6C396FD1DADU0P190MB1978EURP_"
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0P190MB1978.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 91d1f26e-7a43-49bf-aa41-08dba479ba31
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2023 08:11:32.4340 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: x5gjDo7xpkqgBATkzetwvhRMAlFjFMZHbK1KYDep/rxcar2zSszF6SdJKLe1bRI9RpXiPLmdsMLIzQfWbF5lGk8IAZb09mBbADM17dFyrKs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXP190MB1423
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/c3CK8PywuAKCSOniYRDE6dZXCpM>
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: Thu, 24 Aug 2023 08:11:43 -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).

Thanks; at first glance this seemed ok for me. However today I have trouble understanding the requirement.


  *   Is the “MUST NOT” condition always applicable?  Or only if the SRP Registrar keeps a “zone that is not signed” i.e. conditional.
     *   If the MUST NOT is conditional then maybe the text should be rephrased to make this clear.
     *   I.e. it seems ok to store the KEY record in the zone and delete that KEY record from any query answer, as long as the SRP Registrar doesn’t apply DNSSEC security for its zone.
  *   What is the “SRP server” ? Should this be “SRP Registrar”?
     *   See also other references to “SRP server” in the document.
  *   “no data” is kind of cryptic – should we just say “NOERROR with zero answer records” ?
  *   What does it mean for a “zone to be not signed” ?  (I’m probably missing some DNS background here. In my mind, SRP updates can be signed but not an entire zone.)
  *   A related question that came is why not just replace the KEY record contents by a dummy value (e.g. 0x0) if the purpose is to hide the contents of the KEY record only.


Regards
Esko


From: Ted Lemon <mellon@fugue.com>
Sent: Friday, July 7, 2023 21:15
To: Esko Dijk <esko.dijk@iotconsultancy.nl>; dnssd <dnssd@ietf.org>
Subject: Re: [dnssd] Intended behavior for eliding KEY record in DNS query response? (draft-ietf-dnssd-srp)

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<mailto:mellon@fugue.com>> wrote:
Op wo 5 jul 2023 om 03:06 schreef Esko Dijk <esko.dijk@iotconsultancy.nl<mailto: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?