Draft: draft-ietf-tls-rfc8446bis

Commentary: 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 can not find anything in the document regarding this which is surprising as reusing key shares enables tracking I can not 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  raised this on the TLS list in October but  '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 . 
 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 :  and mitigate other ( long - term ) user tracking or fingerprinting vectors enabled by TLS deployments and implementations .
Mailing list commentary: 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 " .
Paragraph (version A):
The client's view of the age of a ticket is the time since the
receipt of the NewSessionTicket message.  Clients MUST NOT attempt to
use tickets which have ages greater than the "ticket_lifetime" value
which was provided with the ticket.  The "obfuscated_ticket_age"
field of each PskIdentity contains an obfuscated version of the
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
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.
Paragraph (version B):
The client's view of the age of a ticket is the time since the
receipt of the NewSessionTicket message.  Clients MUST NOT attempt to
use tickets which have ages greater than the "ticket_lifetime" value
which was provided with the ticket.  The "obfuscated_ticket_age"
field of each PskIdentity contains an obfuscated version of the
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
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.