Change:
The document has a section on Client Tracking Prevention which is what is relevant for the Web. For IoT the TLS server is often a device. That device might be something that a person takes with them. Motivation for changes is given by the charter.
This seems to be an easy fix. Just chaning the heading from "client tracking prevention" to "client and server tracking prevention" seems to do the job
Fixed
I cannot find anything in the document regarding this which is surprising as reusing key shares enables tracking I cannot find anything in the document that states that reuse of keys are allowed or forbidden but my understanding from earlier discussions in the TLS WG is that this is allowed as summarized in draft-ietf-tls-hybrid-design TLS 1.3 does not require that ephemeral public keys be used only in a single key exchange session; some implementations may reuse them Key shares should probably have similar text as Tickets Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of a ticket allows passive observers to correlate different connections. But the requirement for key share applies to both clients and servers. The sentence "This addition prevents passive observers from correlating connections unless tickets are reused." is not correct unless both tickets and key shares are not reused.
Found that Illari raised this on the TLS list in October but Illari's comment did not seem to get any response which is also surprising. You can probably get a paper published by investigating how reuse of key shares enables tracking. URL
For clients the considerations seems very similar to reuse of tickets. The client is in charge of its own privacy. The server side seems more worrying. A server reusing key shares between two clients can be used by an attacker to correlate connections between two different clients and use that to figure out the server even when ECH is used.
Motivation for normative SHOULD NOT (or MUST NOT) change can be found in charter-ietf-tls-06 Security and privacy goals will place emphasis on the following: Identify and mitigate other (long-term) user tracking or fingerprinting vectors enabled by TLS deployments and implementations. Should there be "SHOULD NOT reuse key shares between client hellos"? I did't find such requirement (or maybe it is there but I just missed it), which I think is odd, given that there is similar requirement for tickets, and reusing key shares has similar impact as reusing tickets. Such reuse is especially bad if SNI differs, or if the group is not actually safe for key reuse. (In case of hybrid key exchanges, implementations might reuse shares within the same client hello. E.g., reusing the same X25519 key both for x25519 and x25519+kyber768.) And then section 5.5 contains "SHOULD not". I presume that should be "SHOULD NOT". -Ilari

Discussion:
ticket age formed by taking the age in milliseconds and adding the "ticket_age_add" value that was included with the ticket (see NSTMessage), modulo 2^32.  This addition prevents passive observers <del> from correlating connections unless tickets are reused.  Note that the "ticket_lifetime" field in the NewSessionTicket message is in seconds but the "obfuscated_ticket_age" is in milliseconds.  Because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even in milliseconds. </del> <ins> from correlating connections unless tickets or key shares are reused. Note that the "ticket_lifetime" field in the NewSessionTicket message is in seconds but the "obfuscated_ticket_age" is in milliseconds. Because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even in milliseconds. </ins> 4.2.11.2.