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

[Ted Lemon <[e-mail]>]

I just looked at the text about keys, and I'm a bit at a loss as to how it
would make sense to talk about key rollover. In thinking about what you've
said here, I think that it would have made sense to specify a key rollover
strategy in this document, but the value proposition is relatively limited.
We only have one required algorithm. I think it would make sense to think
seriously about what we can do about this that would make sense, but it's
hard to come up with a good threat model for this. What you get for
cracking this key is that you can claim the name of a device on a local
network and effectively DoS it, or maybe MiTM it. You need to have access
to the local network. When is this attack going to pay off? This is not
like cracking a key on a public web site.

I don't mean to minimize this. I think we should think about it and come up
with a strategy. But I think it's okay if that's a follow-on document. It's
hard to imagine putting post-quantum crypto into a 6lowpan device as a
software update, so we're in trouble at some point anyway.

On Mon, Jan 29, 2024 at 3:03 PM Ted Lemon <[e-mail]> wrote:

> 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 <
> [e-mail]> 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.
>