On 17/12/20 07:06, Martin Thomson wrote:
On Thu, Dec 17, 2020, at 20:42, Fernando Gont wrote:
FWIW, our argument is essentially that if constancy is not required
in a given context, then you should generally avoid it. i.e.,
"unlinkability", where possible, should be the default.
I'm not sure that this is sufficient if it means uncoordinated
changes, or that that works in every context. This says nothing about
cross-layer coordination or managing trade-offs at different layers.
Note:
The text you were quoting essentially just summarizes the most root
causes of of flawed generation of transient numeric IDs.
And yes, there are cases where problems arise because constancy wasn't
required for some context, but the algorithm resulted in such constancy.
It follows that, "avoid linkability, where possible" would avoid such
issues -- however, this *is not* a recommendation in this document.
This is another reason to avoid making such strong recommendations.
These are the only recommendations in this document:
When a protocol specifies transient numerical identifiers, it is
critical for the protocol specification to:
1. Clearly specify the interoperability requirements for the
aforementioned identifiers (e.g., required properties such as
uniqueness, along with the failure severity if such properties
are not met).
2. Provide a security and privacy analysis of the aforementioned
identifiers.
3. Recommend an algorithm for generating the aforementioned
identifiers that mitigates security and privacy issues, such as
those discussed in [I-D.irtf-pearg-numeric-ids-generation].
Which of these would you deem as "too strong" or disagree with?
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
