Telechat Review of draft-ietf-dnssd-srp-22
review-ietf-dnssd-srp-22-iotdir-telechat-amsuess-2023-08-04-00
review-ietf-dnssd-srp-22-iotdir-telechat-amsuess-2023-08-04-00
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? * "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? * 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 ====================== * 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? 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. * 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.