What is the purpose of 3.1.2 "Encrypted forwarder"?

[martinthomson]

I've read this several times and I don't understand it at all.

The first paragraph seems to be a restatement of overall discovery requirement of the document.

The second paragraph seems to make an argument that accessing a local resolver that supports DoT/DoH is superior to phoning home. That sits firmly in the domain of policy. A device that configures itself to phone home might do so because that is what it wants. Whatever you think about that, that is a policy decision.

My conclusion is that this section should be removed.

[chris-box]

First paragraph yes, it could be shortened.

Your point on the second paragraph seems to be that MUD enforcement is policy, and making any recommendations about specific policies for clients or servers is out of scope. In that sense I agree some wording (like "all other access should be considered suspect") should be toned down.

But deleted altogether? How does this sit with RFC8890 which says the needs of the end users (people in the home) outweigh the needs of others, including in this case the black hat who has compromised an IoT device in that home. It should be people's needs we prioritise, not those of devices or even device manufacturers. Hence I would say we need to include support for MUD-type use cases, but certainly not mandate them.

[martinthomson]

I didn't make the connection to MUD at all. Why would a device advertise a policy and then take steps to ensure that that policy couldn't be implemented?

I don't think that an appeal to RFC 8890 is at all appropriate here.

[Andrew-419]

I think an occasional reference to RFC 8890 is helpful in reminding us all not to get so drawn into the detail of the discussion that will lose sight of the importance of some items in meeting the needs of end users. In the context that Chris has raised it, it does seem an appropriate consideration,