Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-23.txt

Alexander Clouter <alex+ietf@coremem.com> Tue, 31 October 2023 16:15 UTC

Return-Path: <alex+ietf@coremem.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 84C35C15155B for <dnssd@ietfa.amsl.com>; Tue, 31 Oct 2023 09:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (2048-bit key) header.d=coremem.com header.b="AhfxHLxX"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="DCEYcT+U"
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 Xar8CGef8DBN for <dnssd@ietfa.amsl.com>; Tue, 31 Oct 2023 09:14:58 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 B5D8DC1705F9 for <dnssd@ietf.org>; Tue, 31 Oct 2023 09:13:37 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7FB235C0161 for <dnssd@ietf.org>; Tue, 31 Oct 2023 12:13:34 -0400 (EDT)
Received: from imap46 ([10.202.2.96]) by compute3.internal (MEProxy); Tue, 31 Oct 2023 12:13:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coremem.com; h= cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1698768814; x=1698855214; bh=wZ TtMObgHpJPzrGV+VPLwlGzmn5i38LF0N7+iky8hnw=; b=AhfxHLxXPL03tpXcn9 rbsBAVTwiwqzk+SrloUBRjo01j5eCPM+y6IA+RaEFKCk0CKllgYDTnazXWchnR8X YJ3b3zdA+HLlCKkAIkE7ej1kOy5Oz6lwr0A9AFRNX+fsv62vydQpqX8LkQ0zD9u5 LlCWMEiySY7h6C1RuOYBh2oR1MGcaYTnRV+HCN+mH0fGJ0KX7VRs2KYXGcRAE2Pe VIN7g476FAM1n1mcet8IQeB9tEj36nneSwrx6ZaI0r4dUR0r/7OU7xybIps7/VnC IrACW6hdODXeYEg8CFxcXNuuxP4GWViUJISEiP+ZB4o0fTClMSontmZQtABkSH6h yKNg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1698768814; x=1698855214; bh=wZTtMObgHpJPz rGV+VPLwlGzmn5i38LF0N7+iky8hnw=; b=DCEYcT+UwroXO0cFH5GUWPseKos5s 1ti2+W4iZnS5Pob01ARpHoNxkESJxxeDXSzoQHtqGVxNnWfXWSmfdhIjqHt+8Tph OMFCF+ud4CN3DPYIWq4bKH17hdCTDlDblBvdj8flsZqb5xB+tLnnOd48x8y1qhO2 DRRTtqUAHEp+GTtBbCjPGnlJNOuUfiPUajmRaiWZ+K+8MCjCB10PbDnLdHo0q4sy qdZW1WtFc0gnU9/6v/8gKbGjjVzzSIw5FuJlvWAJqk50XurjdIo01jd4KhUQKpHi aZuK2Q6LHZO/gGt5AKhZr0gVm+tgw3qxf6XXQCSJWSYM5TUvPeFIMHYxQ==
X-ME-Sender: <xms:ridBZa-WzKa1UmPGSFIYQk4wkd4NrefXKLomwzZgxtbrcc_2iaPD0g> <xme:ridBZat-x8dcFbWNOjUSvtl6ILRBdWuwmEQXsMf1ZxsP3a6kO-S7-xjBaKx-XIP9p _2IidcgMzD71pSiwQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddtvddgkeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedftehlvgigrghnuggvrhcuvehlohhuthgvrhdfuceorghl vgigodhivghtfhestghorhgvmhgvmhdrtghomheqnecuggftrfgrthhtvghrnhepuedtud ffffdtveekgfefveffleevgefffeegffegvdekfedtvdejhfetveekteelnecuffhomhgr ihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegrlhgvgidoihgvthhfsegtohhrvghmvghmrdgtohhm
X-ME-Proxy: <xmx:ridBZQDpwlKCjTS3AbN0SibnRrDcmGhP4smAdDho6dDSq1xRwBnBcA> <xmx:ridBZSehNmsBWqnsAL3Y-jcq4cMBqt2Exr82sluwSnOB88jUr_xslQ> <xmx:ridBZfNrQ1nLa8N9vsZTrsR90nuhDCALOKj3JPXHjRPIbKxTEYX6VQ> <xmx:ridBZVaIkZbLqwFuMioJ5cP8_i-y6J9s60VEp1ivUOxt3A1HlYCfRQ>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3FE852A20085; Tue, 31 Oct 2023 12:13:34 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1048-g9229b632c5-fm-20231019.001-g9229b632
MIME-Version: 1.0
Message-Id: <8e212aa0-dd57-4733-8992-6d4f9b5aa3a5@app.fastmail.com>
In-Reply-To: <169118866241.13601.15936262706231533955@ietfa.amsl.com>
References: <169118866241.13601.15936262706231533955@ietfa.amsl.com>
Date: Tue, 31 Oct 2023 16:13:13 +0000
From: Alexander Clouter <alex+ietf@coremem.com>
To: dnssd@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/RXUiWIRiz71pRmtyeTw3_VEBFcY>
Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-23.txt
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: Tue, 31 Oct 2023 16:15:03 -0000

Hello,

On Fri, 4 Aug 2023, at 23:37, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Extensions for Scalable
> DNS Service Discovery (DNSSD) WG of the IETF.
>
>    Title           : Service Registration Protocol for DNS-Based Service Discovery
>    Authors         : Ted Lemon
>                      Stuart Cheshire
>    Filename        : draft-ietf-dnssd-srp-23.txt
>    Pages           : 40
>    Date            : 2023-08-04

I've been working on my own implementation and stumbled onto some greyness around the KEY RR.

I have not been able to find anything definitive on what the flags should be set to, maybe I missed it though.

Appendix C provides an example where flags=513 and if you go spelunking through the mdnsresponder[1] and openthread[2] sources you find they both use this value too. 

>From this you can of course go an swot up on RFC2535 section 3.1.2 to decode 513, and it mostly makes sense why the values are as they are, but as a reader I only came to this conclusion after reading another implementation and not from this draft.

It would be helpful to include a suggestion guiding the reader as right now I personally am using '513' as a magic interop number instead of because I consciously decided it suited my needs.

Maybe something along the lines of a new section just before section 6.6 ('Required Signature Algorithm'):
----
Section 6.X: Guidance on the KEY RR Flag Field

RFC2535 section 3.1.2 breaks this field up in to several parts and it is RECOMMENDED:

 * A/C: set to 0b01 (prohibit confidentiality)
 * NAMTYP: set to 0b10 (ie. HOST/ENTITY[3])
 * SIG: set to 0b0001 (ie. GENERAL)

It is RECOMMENDED you use 16897 (0b0100001000000001) but as an SRP registrar you MUST accept 'A/C & 0b10 == 0'.
----

I am proposing A/C=0b01 as I do not know enough about the DNSSEC crypto sausage making machine to state what should be and hoping this prompts someone who knows this to suggest something more appropriate.

Cheers

Alex

[1] https://github.com/Abhayakara/mdnsresponder/blob/d7779d704ef6e4724d0d0fd4a11a91ff9caa4004/ServiceRegistration/srp-client.c#L1203
[2] https://github.com/openthread/openthread/blob/7074a43e4577d32d5535d52e7940ed2ea7e3a528/src/core/net/srp_client.cpp#L1309
[3] wonderfully you can only tell the difference between ENTITY and HOST by reading the bind9 source[4] to find out they map to the same value
[4] https://github.com/isc-projects/bind9/blob/3f205f3218915e00d5a7162d7665adfef473d8ba/bin/dnssec/dnssec-keygen.c#L589