Re: [dnssd] Roman Danyliw's No Objection on draft-ietf-dnssd-srp-23: (with COMMENT)

Ted Lemon <> Mon, 29 January 2024 23:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 465E9C151540 for <>; Mon, 29 Jan 2024 15:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Status: No, score=-1.905 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rbGxi9iy0nI9 for <>; Mon, 29 Jan 2024 15:11:15 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::734]) (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 (Postfix) with ESMTPS id 584E1C151998 for <>; Mon, 29 Jan 2024 15:11:15 -0800 (PST)
Received: by with SMTP id af79cd13be357-783d8e09a1cso234347585a.3 for <>; Mon, 29 Jan 2024 15:11:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1706569874; x=1707174674;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=R0+Pl6h9L9hif95xpQAiDK3pkrL2G3/ku1jQRsGDw7w=; b=IoY85U4F2UoneIQsX/8UU1EDEFLBB9rVr6wRI5khlr4BRNvU+oiA2l9J8ZhjVzQyQI VwkW8DgT1RZcEgmF3D9In91dyVXJ8U1NzxXHBrrz4jXXLfYECKQCQTKHO0R8+8z1LLCd 7oHCjBXTINM+qTmV/aQoTcaCcdWb7yu8sejVh2Pj6LNPV2Fi/I1K0XerBCgrFJ3mup6D NyTlmBR/it8xKT+HdwKasE3cMREZmd32jw7LYxDhP/i2NWmLBl6tQ9UrmDubdmLUOeQr 4QZQOORuqtxz6FRs/5/zFcUMdSFZHrLAEniC8g+gwvL0DRxhX22gaOZvhOpmpjvr0N4m wemg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1706569874; x=1707174674; h=cc: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=R0+Pl6h9L9hif95xpQAiDK3pkrL2G3/ku1jQRsGDw7w=; b=Vh/YyoYmAAFLvrlcqm/2IKtohCNY+wyc2f4MJlVthrOUKhCCsw8Iv6z/wTbo6FVORL UVfPRfs7JtYDaJvWLH4qCLeSrboislT2p5yQsiHrv1OZOtPitcfFiaig0qSV1f6CHeQx uYByF6LLeg6sko2y6IZ+vnsTTC1rbBeWCr9aakll/8OZ1l24yuWN7gz7C7tn7s21McuE bQH9t3yaHMnRhi6PqTuHEV6eyYaXn/bS5N8KiiFxM7UVOEKO9NL1Eu9a2y1nrdzjS/d0 seM2caWTGrZbKPRykk44/lgvwj1HTucr2nh+a4yua8jUKIqePJbhlP/puQJ30oQuHTau bF5w==
X-Gm-Message-State: AOJu0Yyj2pIUGZVd2e9CgXBlcI8iYBJ6b1tidFk4fQqC9XhvVtYbjXKI Wn1eLrxHsPFdJAj5bO/VZGcfwOrYzxiNAN2Hb+7aetvNZ4KQP6yppeQ0guILw3IpX/hfRqGvmqY X1WsfxcmPmeq1kTXywWsY+DirGAQT70LCm0z1mA==
X-Google-Smtp-Source: AGHT+IF75NwGG9pxhRQjqUa6XnbNJIQLFd06ihD2EwoX/Dd0WYnaQeXD5DbMeqX8Vw1bSt2kqj5qQ3R3ml29CYTlj70=
X-Received: by 2002:a0c:f051:0:b0:68c:3d02:2fd3 with SMTP id b17-20020a0cf051000000b0068c3d022fd3mr4560998qvl.91.1706569873925; Mon, 29 Jan 2024 15:11:13 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ted Lemon <>
Date: Mon, 29 Jan 2024 18:10:37 -0500
Message-ID: <>
To: Roman Danyliw <>
Cc: The IESG <>,,,,
Content-Type: multipart/alternative; boundary="0000000000001ec50a06101dc39c"
Archived-At: <>
Subject: Re: [dnssd] Roman Danyliw's No Objection on draft-ietf-dnssd-srp-23: (with COMMENT)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Jan 2024 23:11:19 -0000

Roman, thanks for the IESG review and comment. Sorry for the long delay. :]

On Mon, Aug 21, 2023 at 2:17 PM Roman Danyliw via Datatracker <> wrote:

> Thank you to Joey Salazar for the SECDIR review.

Yes indeed!

Per this earlier comment:
> > ** Section 1.
> >   So we can only publish information that we feel safe in publishing
> >   even though we do not have any basis for trusting the requestor.
> >
> > What is the basis of considering particular information “safe”?
> I was indeed reacting to the word "safe" as noted here:
> The
> found the explanation in this thread illuminating and these would have been
> good words to include in the document.

This is what we have in the document now:

The reason for this is precisely that we have not established trust. So we
can only publish information that we feel safe in
publishing even though we do not have any basis for trusting the requestor.
We reason that mDNS <xref target="RFC6762"/>
allows arbitrary hosts on a single IP link to advertise services <xref
target="RFC6763"/>, relying on whatever service is
advertised to provide authentication as a part of its protocol rather than
in the service advertisement.</t>

This is considered reasonably safe because it requires physical presence on
the network in order to advertise. An off-network
mDNS attack is simply not possible. Our goal with this specification is to
impose similar constraints. Because of this you will
see in <xref target="add_validation"/> that a very restricted set of
records with a very restricted set of relationships are
allowed. You will also see in <xref target="source_validation"/> that we
give advice on how to prevent off-network attacks.</t>

This leads us to the disappointing observation that this protocol is not a
mechanism for adding arbitrary information to
DNS zones. We have not evaluated the security properties of adding, for
example, an SOA record, an MX record, or a CNAME
record, and so these are forbidden. A future protocol specification might
include analyses for other records, and extend
the set of records that can be registered here. Or it might require
establishment of trust, and add an authorization model
to the authentication model we now have. But this is work for a future

I think the third paragraph addresses what /information/ we consider safe,
as opposed to in what context such information could be safely registered.
I looked at the message you quoted above, and didn't find anything
mentioned there that isn't addressed in this section of the introduction. I
don't think we need to include this in the specification portion of the
document—the point in the introduction is simply to explain why service
registration instructions are constrained to just those few records that we
explicitly allow there.