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 <noreply@xxxxxxxx> 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
======================
* 3.2.5.5.1 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 3.2.5.5.1. 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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
