Re: [dnssd] Paul Wouters' No Objection on draft-ietf-dnssd-srp-25: (with COMMENT)

Ted Lemon <> Mon, 18 March 2024 03:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7910AC14F6BD for <>; Sun, 17 Mar 2024 20:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Status: No, score=-1.906 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_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)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TH2uzdRoygy1 for <>; Sun, 17 Mar 2024 20:59:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::735]) (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 986EEC14F5E5 for <>; Sun, 17 Mar 2024 20:59:05 -0700 (PDT)
Received: by with SMTP id af79cd13be357-789f00aba19so40488685a.0 for <>; Sun, 17 Mar 2024 20:59:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1710734344; x=1711339144;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wYhFSd3k/pYDz8uMNAOBujqmAQ9/XEf7/zxXmelmSWw=; b=Ug/wJETkRnP4S4Nz4KY3PaqVGXKOeAfRnW4sRDqL0fXIxETJLW8y8GI/gUzhlZlXBY V2Etapdk7F9REYoQEa1lZYR6JjoY4eZVxWrQFb3jM5VMn9OJkNOqTN7DMayF47dKC5Iy 94gHzjV+sharb/f0zokSpUZwcN/tfbTICE51upRoVfLeQJVH2lWmW3WFlQCXN5rNk7fB NOWZjKCUuCh5pUZ/dKmaIVm88pJ7VwZu4y9/gEo4UV6yZ8QGwgtatCmFVLv/dzKTFTaJ 4LyF2iHnzoypPGJNju/eO3r39opglI5lRCqlRzxaWRAKxzx9T+wVWPGVBXU5n0QHIgZ1 3GOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1710734344; x=1711339144; 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=wYhFSd3k/pYDz8uMNAOBujqmAQ9/XEf7/zxXmelmSWw=; b=VCZpZx+8Wl8jqwzECTM07dOOvECR1kH/oktu+7vnrGo52lvCpd+TwbA+JfPDdFQb2S erqINlqzv8UXEkQ30KFo9wD43GHZwkzAwyzbaE/ztHNcBWnEBKvopcTOynOSzHt511IF 87saqnn1fiOlh6950EfA2xdylhdYi18xyGK6d2ab8pmR18FW6fMyZP8+r9LgwlhPBx9i t4Vm8ygoGO8iKJsuPP+ugBYFMK+f4toJ6HlpKn6McQQz56LDzR/pw1/pQZQo6IaU69JG em8kpzykFPGhpoarMVFZjaREPKroXb/U6yzr/ru8ZWSm1XE7GpNiCf5ir5nRiMDbW2/B zIdA==
X-Forwarded-Encrypted: i=1; AJvYcCUCvRFcs2Jmpb+LTz3bNQKyyZzvQuuenJIiWSxJPH5gPi5E9ST1N5NMAa7nUjT8K5Wik7V+oI5/B1cEsbYpBA==
X-Gm-Message-State: AOJu0YyRCrYuUm5VXnA0LNSC01y0mwlYans0BVWR/VJTv2gTeqjH9TVI KDgBl+030H0O7cp9qqA9q7e8rEzfLKdVx757Z/4jfGuwbYGRe1Zr0lqkYllBRssOsum8muEzXwS Q+fbmsYzkc+TCWCqK1BpTi5bHVRxFNV8LLEQhYA==
X-Google-Smtp-Source: AGHT+IH4lxIxnaUY4JuHs1wROzVH/epuwhm8FiPpJisHdK9H4jeiLRS+jMvEAcyv+Cl/PRYJT2A20R6XoO89CdO/7RA=
X-Received: by 2002:a0c:fc4e:0:b0:691:1b11:e676 with SMTP id w14-20020a0cfc4e000000b006911b11e676mr606534qvp.27.1710734344219; Sun, 17 Mar 2024 20:59:04 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ted Lemon <>
Date: Mon, 18 Mar 2024 13:58:27 +1000
Message-ID: <>
To: Paul Wouters <>
Cc: The IESG <>,,,,
Content-Type: multipart/alternative; boundary="000000000000e488ba0613e7609c"
Archived-At: <>
Subject: Re: [dnssd] Paul Wouters' No Objection on draft-ietf-dnssd-srp-25: (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, 18 Mar 2024 03:59:06 -0000

There are two scenarios for SRP: the constrained-client case and the normal
client case. For the constrained client case, we do indeed use UDP, but in
this case we really want to keep it simple and avoid sending extra packets.
So for this use case we allow UDP but recommend that the SRP registrar
validate the incoming UDP packet to see that it's from the local link and
not some other link. In this case we're relying on the constrained link
being on a different interface than the infrastructure link, and the SRP
registrar being directly connected to that link.

There is a gap there, but I think requiring cookies is not the way out of
the problem. In the SNAC use case, if there is an infrastructure registrar,
the registrar might be one hop away from the requestor, so the interface
trick doesn't actually help in that case, and we can't use the hop count
either. We haven't ever tried to build a solution that does this, so it's a
bit of an open issue. We expect to write an additional spec that talks
about this use case, so we've simply left it unsolved for now.

In any case, the third paragraph of section 6.1 says all that we currently
have to say about this, and we don't make explicit requirements. DNS
cookies would solve this use case, but the cost would be an extra signature
on the second message and some extra traffic on a constrained network that
we'd just as soon avoid, so I really would like to leave solving this for a
later document.

On Mon, Mar 18, 2024 at 1:44 PM Paul Wouters via Datatracker <> wrote:

> Paul Wouters has entered the following ballot position for
> draft-ietf-dnssd-srp-25: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about how to handle DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thanks for dropping by at the SEC AD office hours. Note there is is
> confusion
> still because I understood you said SRP is always TCP, but that does not
> seem
> to be the case if I read
> As a related argument is that SRP clients implement TCP, but might not
> implement DNS-COOKIES, and there is no advertisement/negotiation on whether
> COOKIES can be used, I think it is reasonable to not mention COOKIES as
> alternative for TCP in this case. I do hope a future rev of the spec might
> take
> cookies into consideration to avoid TCP.