Re: [STDS-802-11-TGBH] TGbh language for Annex Z (WAS: Agenda uploaded - plans for call)
Hi Amelia,
Thanks for the clarification.
Temporary identifiers should be used or at least permitted, especially for the use of short-lived services such as network probes -> Annex Z established a (semi)-temporary identifier that is generated by an AP and transmitted to a non-AP.
--><Jay> If I understand correctly, the first rule is about how the STA use the temporary identifier, nothing with how to generate the temporary identifier...
Of cause it's nothing with Annex Z.
Let's continue to debate from the first rule, and then next till to the end. And see how long we can make all the rule clear enough..
Thanks
Best Regards
Jay Yang
-----Original Message-----
From: Amelia Andersdotter <amelia.ieee@xxxxxxxxxxxxxxx>
Sent: 2023年4月13日 21:04
To: Zhijie Yang (NSB) <zhijie.yang@xxxxxxxxxxxxxxx>; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh language for Annex Z (WAS: Agenda uploaded - plans for call)
On 2023-04-13 09:34, Zhijie Yang (NSB) wrote:
>
> Hi Dan,
>
> Please clarify which items the Annex Z meet according to the Privacy
> Recommendations provided by Amelia?
>
> How to determine less or more “security and privacy”, what’s the
> threshold, “50%--NOK, 100%--comparable”?, hope you can give more
> clarification on them before adding them.
>
> Amelia came up with some new privacy points to 11bh group, I say the
> 11bh group need carefully to review them one by one. Why you become
> impatient?
>
They are not new. 802E-2020 was discussed in the beginning of this TG.
If I could make a stab, it'd be:
Temporary identifiers should be used or at least permitted, especially for the use of short-lived services such as network probes -> Annex Z established a (semi)-temporary identifier that is generated by an AP and transmitted to a non-AP.
Temporary identifiers should not persist across different stages of the communication process and should be restricted to specific protocol exchanges -> Annex Z allows for this behaviour but doesn't require it, since the use-case for the identifier in Annex Z (and device ID in
general) is specifically to create linkability and persistence of the identifier.
When switching to a new temporary identifier, variable fields such as sequence numbers should be reset to their default value or to a non-deterministic value. Where multiple temporary identifiers are used concurrently, their replacement should be synchronized to avoid correlation between sets of old and new identifiers -> The procedure in Annex Z can be applied at any time, but it is not up to the Annex to specify this behaviour. It would have to be specified in Clause 12.
A personal device persistent or temporary identifier should not be stored by any device specified by the standard other than the devices using those identifiers to provide or support the service. -> Annex Z and Clause 12 seem to fulfill this recommendation.
Persistent and temporary identifiers should not be stored by any device for longer than is required to provide or support the service. -> The functionality to be defined by TGbh assumes "support for the service" to require a (semi)permanent identifier. Annex Z is one way that such a semi-permanent identifier could be generated with a high level of security and privacy.
Periodic communications or transmissions of deterministic values or identifiers should occur at non-correlatable intervals. -> Not applicable.
Temporary identifiers should not be shared across services. -> Depending on your definition of service, not applicable. Else, the functionality to be defined by TGbh assumes "support for the service" to require a (semi)permanent identifier (across services).
The use, persistence, and storage of identifiers by devices specified in the standard, and their configurability, should be described in the standard. -> This is what Clause 12 and Annex Z by the TGbh draft 0.2, does.
But I don't think we need to debate or discuss this for 1 year.
802E-2020 is meant to be a tool that enables asking the right evaluation questions for a given proposal - it's not an arbitrator of what is right and wrong, it's a recommendation with some loosely set directions. For me it was personally helpful only to write this e-mail, I must admit.
Best regards,
Amelia
> You know, this group spend almost 1 year to discussion pre-association
> identification scheme, and have some consensus finally. If we follow
> such working style, I’m afraid we need spend a long time to discussion
> that part.
>
> If you or the group have enough efforts, let’s go on.
>
> Thanks
>
> Best Regards
>
> Jay Yang
>
--
^\...~...~...~...~...~.../^
Amelia Andersdotter
^\...~...~...~...~...~.../^
________________________________________________________________________
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1