On 13/12/20 19:47, Joe Touch wrote:
On Dec 13, 2020, at 1:54 PM, Eric Rescorla <ekr@xxxxxxxx> wrote:
My position is that modern practice is to design protocols that have encryption
(this is strongly encouraged by RFC 7258 and also is just what we're doing)
and this document neither (a) engages with that nor (b) provides particularly
helpful guidance for encrypted protoco
+1
I don’t like the idea of over-specification to provide partial privacy or security.
Our document says:
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].
"1" asks specifications to spell out the interoperability requirements
for the IDs.
"2" explicitly asks specifications to do an appropriate analysis of the
security and privacy implications of the IDs.
"3" means: "based on the analysis you did in #2, recommend an algorithm
that mitigates the identified issues" (i.e., "do what you need to do, in
the best way you can").
I'm kind of surprised this is being contended.
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
