On 15/12/20 01:18, Christian Huitema wrote:
I think there are two main issues in the document: it does not
distinguish between identifiers that are "visible on the wire" and those
that are only visible by the endpoints;
The identifiers are the same.
draft-irtf-pearg-numeric-ids-generation analyzes e.g. how a predictable
identifier can be exploited by somebody that sees the ID (or can sample
some),as well as by attackers that can't.
If a protocol employs numeric IDs and does not encrypt the ID, then both
on-path systems and the remote endpoint will see the ID. If the protocol
does employ encryption, then only the remote endpoint sees the IDs.
So, "who sees the identifiers" doesn't really change the identifier
type: it just constrains who can exploit them and how.
and, it suggests an overly specific identifier generation algorithm.
This particular document does not discuss any algorithms. In fact, the
advice says:
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].
So the algorithms are provided as *examples*. It's not a requirement to
pick one of the algorithms in draft-irtf-pearg-numeric-ids-generation.
The document also suffers from
trying to fit different kinds of protocol parameters in a single
abstract category, the "Transient Numeric Identifier". This feels
somewhat artificial.
All of the parameters are identifiers of some sort. It's the same type
of parameter (a transient numeric ID), employed for identifying
different data objects.
The generalization is not artificial. We came up with it after realizing
that all transient numeric IDs fall into one of the categories in
draft-irtf-pearg-numeric-ids-generation, based on the interoperability
requirements and failure severity.
Fixing the lack of distinction between "visible on the wire" and
"visible by the end-points" would require fixing the section 3 regarding
"issues". The current list of issues feels theoretical and detached from
the actual attacks. It lists:
o Protocol specifications that under-specify the requirements for
their identifiers
o Protocol specifications that over-specify their identifiers
o Protocol implementations that simply fail to comply with the
specified requirements
These are the three usual failures associated with the specification of
numeric identifiers. All flawed IDs I know of are the result of one of
these three issues.
They certainly are *not* the actual attacks, but rather the reasons why
implementations end up with flawed IDs.
That list of issues seems somewhat self-referential, another way of
saying "protocols that do not comply with the recommendations in this
document".
That's certainly not what we mean. The above text means:
* Some specs fail to spell out requirements (they spec'ed lesss than
they should have) -- so implementations end up picking flawed algorithms
because the spec failed to spell out the requiredments for the IDS.
* Some specs over-specify their IDs (the specified more than they should
ahve), leading to flawed IDs. e.g., traditional IPv6 SLAAC, where the
requirement should have been that the IID is unique, but the spec ended
up requiring hosts to embed the MAC address in the IID.
* At times, protocol specs do a good job, but implementations fail to
comply with the spec, and end up employing flawed IDs. (the protocol
spec was good, but the implementors screwed up).
Nothing in this list self-references this document. It talks about the
relevant specs for each of the IDs we analyzed.
If we want to provide guidance, we should instead look at
categories of attacks enabled by classic mistakes, such as injection
attacks, correlation attacks, or spoofing attacks. That's the point at
which we can make a distinction between "visible on the wire" and not --
injection attacks, correlation attacks and spoofing attacks by third
parties are mitigated if the identifier is not visible, but spoofing
attacks by the connected peer are not.
Such discussion is in
https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation-03 .
As noted, the analysis mentions what an attacker that doesn't see the
IDs can do, and what an attacker that can sample the IDs can do. At the
end of the day, it doesn't matter if the attacker doesn't see the IDs
because he's off-path, or because the relevant protocol encrypts the
numeric IDs -- at the end of the day, the attacker sees the IDs, or he
doesn't.
EKR mentions how much the document is at odd with recent practice, like
the design of QUIC. QUIC does use a number of identifiers: connection
identifiers, packet numbers, stream numbers, data offsets within
streams. If that document had been available before the design of QUIC,
would it have help development? My personal opinion is no, it would not
have make the protocol better. It might have created a hurdle during the
last call reviews, forcing the developers to discuss why they would not
comply with the recommendation in this draft, and creating additional
delays in the process for little practical result.
I disagree. I do think that, for example, the specification of
connection IDs is sub-optimal.
I missed the LC for that document. But my understanding is that IESG
review is pending. So hopefully the issue will be raised -- not to
thwart progress, but to help improve the spec.
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
