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

Alexander Clouter <> Thu, 12 October 2023 09:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E6A7C1522AD for <>; Thu, 12 Oct 2023 02:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.107
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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b="RwyvcNQh"; dkim=pass (2048-bit key) header.b="IPbstAW2"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PONXcmEOBiUa for <>; Thu, 12 Oct 2023 02:40:39 -0700 (PDT)
Received: from ( []) (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 (Postfix) with ESMTPS id B17ECC1519B7 for <>; Thu, 12 Oct 2023 02:40:39 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 91B3E5C0442; Thu, 12 Oct 2023 05:40:38 -0400 (EDT)
Received: from imap46 ([]) by compute3.internal (MEProxy); Thu, 12 Oct 2023 05:40:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= cc: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=fm1; t=1697103638; x=1697190038; bh=eY QKcmNCMMvBYx699m26NpgYCCH4kLIr05r/gG8iKCU=; b=RwyvcNQhcpbUTADvRp NPUCwawNi9lHbxXOYmjCt0pLjs8TmP1VqZgQmoJQn92fmbt2FOMbTVeaZo153wh5 atwFhjSDesgBQnAkOXao/q0I+fDLMygD5RYx00Do24MIN8E8Ym0Z7Sa8kr7nEbm1 loDiB3E8bV/CB+u0dQwX/t8eRg6bJwqL4p7RG6DaHjkzAiAWIdoQJhez07hRsNG5 Kci/JVx6r+grqJt35sK2GYWErXOdYGaYNCPy11MUJYdjBiw8+44p086poOXVwWeX r739Um9ZFuBVWaymEqWpIKwiPNjRSNgwo9ljDOYLJ4BYs3gdmbfLGRcJ6GxeAkMK +u7Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc: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=fm2; t=1697103638; x=1697190038; bh=eYQKcmNCMMvBY x699m26NpgYCCH4kLIr05r/gG8iKCU=; b=IPbstAW2cZwmkzx/hy/+sPMj51gXA Tx7Vhtd0VUAp3R5LY44X6nhgoBMf1mTQwKNoDc2g+mS70sccj5KR96eGbtTdH0Tu 6r7ynzRIuGjsIJSOcJGezuIF+TPS3/Sqg2Wd5oZxa8FoNK2XEySGDvrtk1NupV/c yfvCQbS1c5Dg/WjtVwVniPoYhEPgoIFhFvB7lCGq7jS+uj4cu7Kpa+p3Eu0dXjtm ocf9Q9vnwClBfx/5/DtIu7/tBsgP/nZy8HMLsq265xiByhinFw4N97fncsCEbpff Wco7gseFvi/9nlUC6DSuLe7E+cXeryvz9WZ6pXTFjjH3hw1gBtQQiq8/Q==
X-ME-Sender: <xms:Fr8nZZuETBqzx7zaFkvnf1tNOZPxKoZVQSt-_sthVuQ7Chv-JQE0Gg> <xme:Fr8nZSfUkeJdrDPivFGvNVoRm4TT9yYLSfD_F1qr-jGQU0rOvc0bOoWFyocA-dbn4 xA7dfFwLvgZcH09Rw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedriedtgddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvfevufgtsehttd ertderredtnecuhfhrohhmpedftehlvgigrghnuggvrhcuvehlohhuthgvrhdfuceorghl vgigodhivghtfhestghorhgvmhgvmhdrtghomheqnecuggftrfgrthhtvghrnhepveeghe ejueevkeevvdfhheeuudefheegudeutdelleeiteehgeffieettddugfdunecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvgigodhivghtfh estghorhgvmhgvmhdrtghomh
X-ME-Proxy: <xmx:Fr8nZcy2BtoPc4ZjUvmjFPmF2ooiXS0Y9ELVG_v57j6a_S_4NEUT5g> <xmx:Fr8nZQOJCo495lh1Yx9RqLPUnk9HWN6kbLEH2jziA63ou4kxcb_6dA> <xmx:Fr8nZZ_MnBb6xSFkBH93F35ZI_QB6r_gdcZTx4BpcXA4PCqxCK4mTQ> <xmx:Fr8nZeLE9xnUWI4l1WjCF2A9CWgCA4dKnm6f04X51HLCRf0Wpe5tig>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0C5232A20085; Thu, 12 Oct 2023 05:40:37 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1019-ged83ad8595-fm-20231002.001-ged83ad85
MIME-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <> <DU0P190MB197824A5BFCF64175FBF48ECFDCDA@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <>
Date: Thu, 12 Oct 2023 10:40:16 +0100
From: Alexander Clouter <>
To: Ted Lemon <>
Cc: "" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-23.txt
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: Thu, 12 Oct 2023 09:40:45 -0000

On Tue, 10 Oct 2023, at 14:27, Ted Lemon wrote:
> If we'd had this idea early on, I'd say it was a good idea and worth doing,
> but at this point maybe what we have is good enough and we should not mess
> with it.

Thought of something else whilst working on my own SRP implementation.

You may be able to lean on DNS cookies (RFC 7873) which could also provide an option for implementers to relax the need for TCP in some situations.

I see the change actually being in the DNS Lease draft and would affect the lease times returned by the responder. If there is no server cookie in the request, the returned KEY lease time is reduced. When there is a server cookie in the request, the request is treated in the existing prescribed fashion.

So a implementation could either opt for or provide an administrative option on how to behave when:

There is no DNS cookie option:

 * ignore the request
 * lower the KEY lease to a much smaller value (minutes rather than hours)

There is a DNS cookie but without a server cookie:

 * ignore the request
 * lower the KEY lease to a much smaller value (minutes rather than hours)
 * set the KEY lease to zero to indicate for the client to retry the original request with the requested lease times; the retry will include the server cookie and sail through

If someone is offlink and trying to spoof, they will not be able to retry with a cookie. 

I am not sure lowering a lease to a lower value adds anything material to the problem, but offered it here as an example. Maybe it at least provides a way to garbage collect faster and  more interestingly provide an option for something actually requesting with a server cookie to kick out a bad actor registration without any complexity (server cookie registrations cuckoo out non-server cookie registrations).

The only problem I can see is if you have a on-path (RFC 7873, section 1.2) bad actor and your legit clients do not implement DNS cookies. The bad actor would push out the legit devices. Personally I see this as a reason for implementers to include DNS cookie support but this is not a space I work in so maybe this along sinks the idea.

A huge improvement over my original GTSM TTL=255 (RFC 5082) suggestion is I think this is a lot easier to reason about but more importantly it is optional and automatically negotiable between peers, plus is now no longer limited to IP traffic.


If this does not cause too much grumbling, I can try to put together some language for your draft(s)? Not a problem if the idea does not stick, it at least is food for thought.