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

Ted Lemon <> Thu, 12 October 2023 13:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6937C15153E for <>; Thu, 12 Oct 2023 06:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Status: No, score=-6.908 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_HI=-5, 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 9SfQONTHiA3h for <>; Thu, 12 Oct 2023 06:35:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f2c]) (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 67D9BC151066 for <>; Thu, 12 Oct 2023 06:35:05 -0700 (PDT)
Received: by with SMTP id 6a1803df08f44-66cfc96f475so5219316d6.3 for <>; Thu, 12 Oct 2023 06:35:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1697117704; x=1697722504;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=K4r1UmqQjkOTPiwhjOeenF8B9XAQQ5rwTNJSoGgd0dA=; b=wWw2Zh3KyHT/zqwsqNJs1pZIZ2H48KJYjZdmJHvQF8shQtpTbJ7inpJdHJuBjc2fBK YdDgbDM44ubtSL4/5Ss9Fqosc1Hkt9FpqsNLTzniLxtiwl09b4Q/4LHe1yiHgOAJBLY9 64oXaEwy3CVvn9fhkAnKNf6EHedtEdu79yV9VtVR2AkIUsRe2aZY/QX0txDCvzaFhtzK MAdJvi3qn0mFH25qBAuSI4qX3IiG1RmdggMTZOJK4pmjF0bnw0VSMgqvr4lfVpo+CEAl 3md6x20u/raNO/EesIz4HUOeeX3IwjBOkgJs5ofDHm3yKiefiS75pc2AQSer0SXWZBxd pLoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1697117704; x=1697722504; 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=K4r1UmqQjkOTPiwhjOeenF8B9XAQQ5rwTNJSoGgd0dA=; b=jJWycg8I8qkGGXEEbDFBfm8G2LtO/4rLZ/tdcOBiZOz7cChFjdr3LxPNI1ZnGK8Ogn vzxMJHp3bzNY2JTO6frbbYmmNnaqEV2DNqJgLu0PrYFYDV3aJM8y2p5gH5VbQrC08055 73pD1wgoclqWLu1Bnq1DNeTYv+PIHs5WJ6VHmQNJZtr2is7DeKcqh5ZLmGSqRkWd7HXY qkmhF8Bvjohvm6PzKvSsy500oL++DEQlcDfWgjYM2hiky+w4r5YMyYBIkMeIAbUyq9KO OR8oL1ekMm9f7Zk1QbVs3DfbT9XOqkKsKu10rd1UMQ1HofaHB/xnp0Bum977Zx1+w3nv n18w==
X-Gm-Message-State: AOJu0YwbDT9IgudbaLyxShT1yc69QmV76WryiBuEXqpYD4bshxMhEgjD jTU1LJgPd0nDXVEo3mwg9PTgwpvtZgnjTCAgjtF1XiyBKZgh/p1PnVg=
X-Google-Smtp-Source: AGHT+IHLq1P7cXlBcNvzpIJCUq7zXPan3XN2zjgnJ7wbGL6ana6VmDurepzV2ZmLI/t+EFnldo65qonSJdywdAKinc0=
X-Received: by 2002:a0c:b55a:0:b0:66d:322:1203 with SMTP id w26-20020a0cb55a000000b0066d03221203mr5190239qvd.53.1697117704397; Thu, 12 Oct 2023 06:35:04 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <DU0P190MB197824A5BFCF64175FBF48ECFDCDA@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <> <> <> <>
In-Reply-To: <>
From: Ted Lemon <>
Date: Thu, 12 Oct 2023 06:34:28 -0700
Message-ID: <>
To: Alexander Clouter <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000e9d729060785017f"
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 13:35:08 -0000

For non-constrained hosts, we require that they use TCP. So cookies don't
help. Cookies are only useful for Do53 UDP.

Hm. I think maybe I see the disconnect. I don't think we ever said this,
but the assumption here is that for the constrained use case, there is a
router between the constrained nodes and the rest of the world, and the
router can either act as an SRP server, meaning that it definitely will be
able to validate that the constrained nodes are on-link, or it can act as a
DNS proxy, meaning that it can proxy DNS messages it receives with Do53 UDP
to the SRP server over TCP, again satisfying the proof-of-locality

The idea is definitely not to make the network operator do this, since in
the vast majority of cases this will be an end user with little to no
network fu.

We didn't specify this in detail because we didn't want to (ahem) constrain
implementors to a particular approach—we just wanted to point out that they
needed to do this for the constrained use case.

On Thu, Oct 12, 2023 at 6:27 AM Alexander Clouter <>

> On Thu, 12 Oct 2023, at 13:50, Ted Lemon wrote:
> > This is why we require a TCP connection for all non-constrained nodes:
> that
> > gives us a three-way handshake.
> Sure, but I am still hung up on Source Validation, but if flogging a dead
> horse happy to let it rest, after all I only rocked up here at the eleventh
> hour... :)
> I am focusing on the non-constrained hosts and think DNS cookies may be
> able to help.
> If spoofing is considered impractical, which I am starting to think the
> group has settled on, then I'll grab my coat.
> Allowing non-TCP registration, even for full hosts, is only a suggestion.
> My concern is expecting the administrator of the registrar to have a given
> amount of control over the local network may be a big ask.
> Implementation wise, DNS cookies may mean less need for various
> administrative controls such "what is the stub interface" and where meeting
> the (really low bar) of RPF on the router/host may not be possible.
> DNS cookies though in themselves are not a trivial amount of work to
> implement, less work on one side means of course usually more work
> elsewhere...a type of work someone may consider not worthwhile.
> Cheers