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

Christian Amsüss via Datatracker <noreply@ietf.org> Fri, 04 August 2023 22:11 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnssd@ietf.org
Delivered-To: dnssd@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3B6C15DF56; Fri, 4 Aug 2023 15:11:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Christian Amsüss via Datatracker <noreply@ietf.org>
To: iot-directorate@ietf.org
Cc: dnssd@ietf.org, draft-ietf-dnssd-srp.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 11.5.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <169118709795.53328.9264294476529860341@ietfa.amsl.com>
Reply-To: Christian Amsüss <christian@amsuess.com>
Date: Fri, 04 Aug 2023 15:11:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/YHFkbYg4ZV_ysB1i_A3fRyJiFoI>
Subject: [dnssd] Iotdir telechat review of draft-ietf-dnssd-srp-22
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Aug 2023 22:11:38 -0000

Reviewer: Christian Amsüss
Review result: Ready with Nits


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?

* "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

* 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)?

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?


* 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.

* 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.

* 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.