Re: [Last-Call] Last Call: <draft-gont-numeric-ids-sec-considerations-06.txt> (Security Considerations for Transient Numeric Identifiers Employed in Network Protocols) to Best Current Practice

[Fernando Gont <[e-mail]>]

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492