Re: [dnssd] Iotdir telechat review of draft-ietf-dnssd-srp-22

Ted Lemon <> Mon, 29 January 2024 20:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0294C151540 for <>; Mon, 29 Jan 2024 12:04:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Status: No, score=-1.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_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] 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 dZND8H9MMhNI for <>; Mon, 29 Jan 2024 12:04:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::732]) (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 9AE47C151538 for <>; Mon, 29 Jan 2024 12:04:20 -0800 (PST)
Received: by with SMTP id af79cd13be357-783ef8ae70aso201808885a.2 for <>; Mon, 29 Jan 2024 12:04:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1706558659; x=1707163459;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eRLDUiDHCwik++eKNf8iR1Wi1Oo9UhG0ms0eJ2dvxus=; b=f/kw+fwZd+hE8zvLyEA604QE+33oVUHgXUuRSa6WXJR2qT1wIzcbG6RX2++S4tFMgH +vRV9Klag5jr5RQPE3xfgt/Q2J34zUWJTqkmuL/52HatZzd5nWhjYyO7PUsLq39NR4md XuDMLnAmSrx4JEBSFA4phWuIFzLRAgMhjSd84le7cZZwXgBLhESWAHsSYOn28/xUUjeK 89zq6Y03yXO5qFOZFl5wwSDJfZ/kNyPAKgaoMCTGkJpTcUgclGIv+SS4CtnEDFoeHw1U X5p+/Tz8EMn+NZYtJ2r4IP12xEowGbmF9ZRfyxnsolg3mVmDJYcZegRpXqKqy/fwxwFG i+Eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1706558659; x=1707163459; 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=eRLDUiDHCwik++eKNf8iR1Wi1Oo9UhG0ms0eJ2dvxus=; b=G9oY0kgjL6kkCBdIey+EVv3O/+AxkZETJglvPvAXFVoDzOd9WTkxivzWB40Nrdpb4T pHTEozDP5hALtzSZaNbuaqnL5dNY+Q6XxPhnoPsbwPK7CmeKlLVckldk4lGerxsEcmf0 gfjcyC3C9AVvw+/qwMn8df2W4CgFMAHDs0Mvynasdlcpz9VQLr2pgjoV+0jPdg2Z1fcM 4PCF+G3rIaib/jvxO0BplxDZuHq9DyoysGp9za1UFGOkQcinnqiqZPPHmuLOG78H/GLL j3xsxNNfCZ4kLzjSvgybMvyY6+dYZHsMUrKAazfOK6cjpdxI2ySMHAxkMKl+ttEMW7t6 bCZQ==
X-Gm-Message-State: AOJu0Ywbz0+ssGB3gbo9E0BvCOSGdW99uxuq52QKL3THnckpVQgocbYj TJhQRhWlFw4lTWf5BWqJmoRvhZkLh//toiAA8d3MM1oF4JIT23XOmKxCl3m18ohyapM3lWr94iT iE3hYygrTp/gc+7vbvqcjUql5b+jPi0N6JQgQEQ==
X-Google-Smtp-Source: AGHT+IGjL2WytjptCKnn3bvpRHkFsAtj9cD1L1EOGlin5JjLmLERR7b2OboAMehdu7aCM/V6Qm1uwOUYngAjQz3fgA4=
X-Received: by 2002:a05:6214:d84:b0:684:b789:5508 with SMTP id e4-20020a0562140d8400b00684b7895508mr6732636qve.31.1706558659129; Mon, 29 Jan 2024 12:04:19 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ted Lemon <>
Date: Mon, 29 Jan 2024 15:03:42 -0500
Message-ID: <>
To: Christian Amsüss <>
Content-Type: multipart/alternative; boundary="000000000000aa8c2e06101b26cc"
Archived-At: <>
Subject: Re: [dnssd] Iotdir telechat review of draft-ietf-dnssd-srp-22
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 20:04:21 -0000

Christian, thanks for your iot-dir review of draft-ietf-dnssd-srp. Sorry
for taking so long to respond.

On Fri, Aug 4, 2023 at 6:12 PM Christian Amsüss via Datatracker <> wrote:

> Reviewer: Christian Amsüss
> Review result: Ready with Nits
> Summary
> =======
> Doing DNS-SD without mDNS, with focus on the onboarding issue (going with a
> first-come-first-served policy), performance enhancements (vs. existing
> update
> methods) and delegation enhancements (leases). It is a more comprehensive
> approach than RFC8766 that went some way in the same direction.
> The document is generally well written and seems to be well thought
> through, to
> the extent I can see that with my rather superficial knowledge of
> established
> DNS practices. For the IoTdir reviewer perspective (through which I was
> asked
> to review this), I think this would be quite useful and implementable on
> constrained devices if they would otherwise use mDNS and DNSSEC.
> General remarks
> ===============
> * From the intruduction (that reads more like this being a pure
> optimization
>   over mDNS) to when SRP is explained at the start of section 3 to have its
>   registrar "most likely an authoritative DNS server", I'm missing how this
>   would be used on typical home routers. As the "Other discovery
> mechanisms"
>   sentence doesn't sound like there'd be big plans, so is this expected to
> be
>   usable there at all?

This document doesn't try to solve this problem. I'd like to see SRP in
home routers, but right now we don't have a spec that says how to do it.
This is work that the DNSSD working group has in charter and is in fact
working on, e.g. in draft-ietf-dnssd-advertising-proxy.

> * "and therefore we do not suggest a specific mechanism here": I think it's
>   helpful to have some example here. Yes, an example runs the risk of
> narrowing
>   the reader's mindset, but left to their own devices they might start
>   imagining something for sake of a coherent picture that is just as
> narrowing
>   but also "wrong". Is there any WIP document that could be informally
>   referenced?

We could reference the Thread specification, but adding a reference to that
is problematic since I am not sure how durable the link would be. Also, you
have to sign a license agreement to download it, which seems like not
something we want readers of IETF documents to have to do. I think leaving
this up to the specific IoT ecosystem is pretty normal.

* I'm curious as to why the instructions are described in such detail with
> all
>   their validity and combination constraints. Would it not be easier to
>   describe the equivalent post-conditions? Are implementations indeed
> simpler
>   or more secure when using just the valid combinations, as compared to
>   processing any valid update (composed of the supported RRs)?

Yes, that's why we did that. We wanted to provide a similar level of
trustworthiness to mDNS. mDNS isn't extremely trustworthy, but it's
difficult to mount an mDNS attack other than from the local network link.

> Concerning IoT devices
> ======================
> * Removing all published services: It says "retransmits its most
>   recent update". Especially with UDP based updates (but also with
> terminating
>   TCP connections), a host may not know whether the most recent change it
>   performed has been completed or not. Thus, there can be disagreement
> between
>   what the requestor and the registrar perceive as the most recent update.

>   Is there a sufficient criterion for matching that can be described, and
> is
>   that invariant over all allowed operations? If not, how can a requestor
>   (especially a constrained one that can not keep a list of possible latest
>   server states) be sure to produce an acceptable deletion request?

This is discussed in Removing all published services. Such a
device would just remove all services. That's what Matter devices to today.

> Security
> ========
> * 3.1.3 hints that the constrained variant is prone to attacks the
> full-featurd
>   one avoids -- after stating that constrained networks *typically* have a
> more
>   restrictive joining policy.
>   If the attacks can not be mitigated differently, I'd expect that there
> would
>   be at least a firm requirement that the constrained version can only be
>   enabled on networks with particular described characteristics. The
> current
>   security considerations mention source address filtration, but neither
>   mandate it for constrained mode, nor describe alternatives.

This is discussed in 6.4. Security of local service discovery

> * 6.2 SRP Registrar Authentication could be more explicit in the attacks
> that
>   are thus possible -- MITM attacks, where the SRP registrations are
> forwarded
>   with a changed KEY and correspondingly altered signatures.

We are not trying to provide any more protection against on-link attacks
than mDNS does. An MiTM attack as you describe would require controlling
the network infrastructure in some way, and we discuss that in 6.4.
Security of local service discovery.

* It appears that there is no means for requestor to roll over its key
> (there
>   is only up to one Add KEY RR, and it must be the one used to sign). Key
>   roll-overs would happen either if the host updates its set of supported
>   algorithms, or after a suspected compromise (eg. after going to a
> firmware
>   version that closes a vulnerability). It would also help with the privacy
>   considerations when not mitigated by hiding the KEY server-side.

The sec-dir review did make the point that the level of security of the key
is not sufficient for other uses because of this, and the document now
recommends against this sort of key re-use. For the level of security SRP
provides, key roll-over will happen organically—the device can remove the
old key and register a new key. If the key has actually been compromised,
an attack on the ownership of the name can occur at this point; such
attacks can also occur at any point when the name has expired. If such an
attack occurs, the SRP client will see this as a name conflict, and will
choose a new name.

 I don't have any specific document updates based on this review yet, but
I'm pretty sure that you aren't the only person who raised these issues,
and I'm pretty sure that some text was proposed in a reply to one of the
DISCUSS comments that addresses this. I will try to remember to update you
with that information when I'm done reviewing all the comments.