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

["Iván Arce (Quarkslab)" <[e-mail]>]

Hello

On 12/15/20 1:18 AM, 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; 

I suggested text to address that point by specifically calling out that
identifiers covered by authenticated encryption may not suffer from the
described weaknesses. I also explained why "may" or "could" is
appropriate, as the presence of cryptography is not by itself a solution
to every possible problem. It depends on how it is applied and the
properties of the transient ID in the specific protocol at hand.

> and, it suggests an overly
> specific identifier generation algorithm. 

This is simply not the case. There isnt any single algorithm in the
draft, it merely requires the author of a protocol to recommend an
algorithm to address any potential security & privacy issue identified
in the protocol. It does require the author todo the exercise of
identifying potential issues.

The document points at another draft
(https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation-03)
where 4 specific algorithms are listed as suitable for different
scenarios. The algorithms in that draft are not made of up thin air,
they were actually used in different protocols to address security and
privacy problems.

For example, RFC 6528 which is a Proposed Standard proposed a very
specific algorithm to address security issues in TCP ISN generation.
https://tools.ietf.org/html/rfc6528#page-4

> 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.

Indeed, all abstraction is artificial but most protocols use some form
of transient numeric identifier as described in the draft so it isnt an
invalid abstraction.

Our abstraction is based on empirical evidence, actual documented issues
involving numeric IDs in different protocols.

We've seen that over 30+ years the same issues have arised in protocols
at different layers due to the way those IDs are generated, we looked at
the many occurrences of such events, classified and abstracted the
common reasons of why it happened. The intention of the draft is,
precisely, to present this as a general problem with the use of IDs,
(since there is evidence that supports that view) that can be dealt with
proactively rather than how it is done now, on a case by case basis
years after a protocol specification is published and several
implementations are found flawed.

If protocol authors cannot learn from the past experience in IP, TCP,
DNS and other protocols that introduced, and years later solved these
problems then we are bound to repeat those experiences.  The intention
of our draft is to present the issue to protocol authors and provide
them with a resource to help them address it, should they need to do so
in their protocol.

> 
> 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 is exactly the opposite.

The list was built as a result of looking at actual, real problems in
various protocols. A non-exhaustive list of them is presented in Section
1. An actual, historical review of those problems in a subset of those
protocol is included in [I-D.irtf-pearg-numeric-ids-history]
(https://www.ietf.org/archive/id/draft-irtf-pearg-numeric-ids-history-04.txt)
which was originally part of the same draft but later forked to a
separate document as a result of WG discussion.

> 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
> 
> That list of issues seems somewhat self-referential, another way of
> saying "protocols that do not comply with the recommendations in this
> document". 

That is is what distinguished all the cases that we looked into.
What we identified is that when there was a security or privacy issue
due to use of a transient ID, the root cause was one of those 3 cases.

It can hardly be self-referential because the problems and their causes
precede the writing of our draft. The list describes what has happened,
it isn't a fantasy we made up to fabricate a draft.

> 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.

That is a partial characterization of the problem that does not cover
some actual attacks that occurred in real life.

Off-path attackers have no visibility over ID fields used in network
flows between other peers, and yet injection attacks have been possible
because transient IDs were used in ways that made communications
vulnerable. Notorious examples cases are TCP session hijacking and DNS
cache poisoning, to name just a few.

Correlation attacks are certainly possible even in the case of IDs not
"visible on the wire", for example when a legitimate peer can infer
current, past or future state of the other peer by sampling a sequence
of IDs provided by the counterpart.

Making protocol objects not "visible on the wire" does not prevent
spoofing, strong authentication and integrity does. Cryptography can
provide all or just some of those properties, confidentiality (making
things "not visible on the wire") is not sufficient.

But even if authenticated encryption (or "deterministic encryption" as
some people call today) is employed, the specific properties of the
protocol objects protected with encryption may still weaken the protocol.

>
> 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.

I could equally argue that QUIC is at odds with the proposed practice.
As I mentioned in prior emails, I do not believe that should prevent or
delay publication of QUIC as our draft is still being discussed.

In any case, I find it at a minimum odd that the case of a single
protocol specification (or rather two to be fair since Eric Rescorla
mentioned QUIC and DTLS) is brought up as an example of recent practice
as if such practice was widespread in every IETF WG.

And since you mentioned QUIC please note that in "21.1.1.4.  Parameter
Negotiation" which is part of the draft's Security Considerations the
authors write:

   Connection IDs are unencrypted but integrity protected in all
   packets.

which is consistent with my above comment about what "invisibility on
the wire" gains us. Accordint to the authors, in QUIC, connection IDs
are visible but cannot be tampered with by an on-path attacker. Whether
that is sufficient to address all potential issues of transient
identifiers, I dont know. It's a 150+ page document and I might read it
all sometime in the future. At a first glance and as I noted in a prior
email, I believe the Coneection ID in QUIC is sufficiently complex to
require a more in depth analysis.


> 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.

If the delay was to address, before publication, a weakness identified
in the use of transient IDS proposed in the protocol then it would be
justified. I would rather see that happening than having the protocol
promoted to PS, implementations deployed massively, and years later find
out that they suffer a common problem due to lack of proper guidance on
how to deal with security and privacy associated to certain protocol
objects.

> I don't think that the document should be published as is.

I've proposed text that acknowledges that use of authenticated
encryption to protect transient identifiers may or could eliminate or
mitigate the weaknesses we describe.

Are there other specific things in the document that you think should be
addressed ?

regards,
/ivan

-- 
Iván Arce
CTO - Security Analysis
Quarkslab