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

Ted Lemon <> Thu, 12 October 2023 12:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3953C14CE2E for <>; Thu, 12 Oct 2023 05:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Status: No, score=-1.907 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KndUHgLlL4hE for <>; Thu, 12 Oct 2023 05:51:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f31]) (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 51A02C14F726 for <>; Thu, 12 Oct 2023 05:51:17 -0700 (PDT)
Received: by with SMTP id 6a1803df08f44-65b162328edso4902926d6.2 for <>; Thu, 12 Oct 2023 05:51:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1697115077; x=1697719877;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=98w2jcEc6T9N+pEIFecWMVaTyYZ2SCv8AOSY0vkm34g=; b=JsrJvu1dfM5TknBYg+i+v/tjRm7n/vXmjIQRkaUepxyHPK6Nyb52dN5srVMsicG4kL a4hxwqRdBbEQsFB9YAqFFGWiVstgEQa7X89qnl1bf2vTWqK35hgcEsuelog5E8m/Ksw9 WKhitz1AV9IPSMVI0+38CIqxd/3Bo86p6cMCQeTCTtuUL2ZkH3UlZbolka7/wCoNC9k8 assq0lMXpZfxl08nLtCaz205LNo3+NcPjaz8clHDMmEnuf4Sm2/FwQOd2aqwRFeEzOFS B0RZYEPCtw0fKraeq7oAiY7+vHBdfc63xfRHkOlNk6uq5V4jCLf0Y1m1WFBO18vwYtds BJIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1697115077; x=1697719877; 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=98w2jcEc6T9N+pEIFecWMVaTyYZ2SCv8AOSY0vkm34g=; b=w3oUA2JCwoyPe624rxn1xG9l2x7wX8/ZUKiC6GcHdFx5bQnKEDI1tWNXVzeIsxV/pz is5CWjd8ozdBdXgL3aD6DNvQPCUEzbCFAOxS1OjKw5BhAqlFtkdfehWVPrumMhF/BkSP yYlmnYq4kivtrQd6mG5pCAF30jkCDNR5Kv8FZL0+TsDyQiUA8SehIOVv52IVtiAT45yX 7vmeOYgVV45MDTYdL2sA7S7pKXSroxjeKqukWXrFzvvD3wmcpLxDLu+Lb19owBB02Pez ylbEG2ArLvS2KsYpowEtHGuypcFz61QRgwOQxfCTNE5FaQkMRJbN6knCXbNPbgnJslwe x5gQ==
X-Gm-Message-State: AOJu0YwvgR1/2qG545OSrF2HOJCpmKFYRD1RJtDUD6DgfyqarW3/L6DU XrinFdpUTmkomBJ4QmW/mEXUo3ICkED/YqH644QPWK1SFIL4RNBeE6U=
X-Google-Smtp-Source: AGHT+IEHNDpr1A/te6OwtpSxCYF+h3R3T6s1eKGgccApeRQgjNi4l12jq6M1JtdBrfAfPXOkB+Wb7oLFnCwmX5l3xg8=
X-Received: by 2002:ad4:418a:0:b0:658:65ed:7e8 with SMTP id e10-20020ad4418a000000b0065865ed07e8mr25718861qvp.57.1697115076931; Thu, 12 Oct 2023 05:51:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <DU0P190MB197824A5BFCF64175FBF48ECFDCDA@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <> <>
In-Reply-To: <>
From: Ted Lemon <>
Date: Thu, 12 Oct 2023 05:50:40 -0700
Message-ID: <>
To: Alexander Clouter <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000004dcc1a0607846570"
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 12:51:22 -0000

This is why we require a TCP connection for all non-constrained nodes: that
gives us a three-way handshake.

On Thu, Oct 12, 2023 at 2:40 AM Alexander Clouter <>

> 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.
> Thoughts?
> 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.
> Cheers