Hello, Joe,
On 14/12/20 13:51, Joseph Touch wrote:
[...]
+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").
#3 jumps to an algorithm.
Of course! What's the point of having every implementer do the necessary
work to come up with an algorithm to comply with the interoperability
implications, without causing trouble?
Haven't we learned anything from history?
Every single ID I can think of has had a flawed recommendation in a
spec, and/or a flawed implementation:
* ephemeral port numbers
* IPv6 IIDs
* IPv4 Frag ID
* IPv6 Frag ID
* TCP sequence numbers
* DNS TID
... you name them.
It's quite surprising that given the bad record, we are even discussing
this. -- unless there's any interest in having vulnerable specs and/or
implementations.
In your other post, you say that:
"in cases where protocols require cryptographic
algorithms to provide confidentiality and integrity (ie.
authenticated encryption) of the transient identifier fields some of
the inherent weaknesses in transient ID generation *may* be
mitigated.”
MAY - really? So basically you’re comfortable recommending these
pseudo-obfuscation methods, but refer to cryptographic algs as MAY?
Yes, may -- as in possibility (i.e., "could", should I say?).
QUIC employs cryptographic methods. Yet the connection-IDs are not
encrypted. And even if they were, if an implementation were to generate
CIDs based on e.g., a global counter, that would leak out (to the remote
endpoint) the number of connections that have been established.
So yes, crypto does not necessarily solve all problems, as it should be
evident.
What it ought to say, first line of the doc, is “if your protocol
expects or uses cryptographic protection means, stop reading here;
you’re fine.”
No. IMO, it needs to say what it says: "Do the right thing, because
there's plenty of evidence that when you don't, you'll screw up. Allways
fail on the safe side".
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
