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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
