Hello Eric, Fernando On 12/13/20 5:38 AM, Fernando Gont wrote: > Hello, Eric, > > Thanks for your comments! In-line.... > > > On 12/12/20 18:44, Eric Rescorla wrote: .. >> >> At a high level, many of the attacks listed here (especially in TCP) >> result from the reliance (potentially accidental) on unpredictable >> identifiers as a countermeasure against various forms of attack. For >> instance, TCP is subject to a variety of off-path injection attacks >> which are partly mitigated by randomizing sequence numbers and port >> numbers. However, the more modern practice is to cryptographically >> authenticate datagrams, thus preventing injection attacks even if the >> port and sequence number are predictable. > > I don't think the two are mutually-exclusive. Nobody is arguing that > randomizing numeric IDs is an alternative to cryptographic authentication. Indeed. I would further argue that use of authenticated encryption is not warranted on all protocol designs so dismissing the need for security and privacy considerations for transient IDs on the basis that "we encrypt and authenticate the packets anyway" is not a good stance in general. >> Turning to specific examples, Section 4 lists a number of practices >> that are described as "common flaws". Out of these, QUIC and >> DTLS both arguably do the following: >> >> o Employing trivial algorithms (e.g. global counters) that result in >> predictable identifiers >> >> o Initializing counters or timers to constant values, when such >> initialization is not required >> >> And potentially: >> >> o Employing the same increment space across different contexts >> >> However, due to their design, QUIC and DTLS are intended to be >> resistant to attacks based on these choices. In particular, they: >> >> 1. Cryptographically authenticate datagrams in order to prevent >> injection attacks. >> >> 2. Encrypt the packet/sequence numbers so that they are not exposed on >> the wire (QUIC all the time and DTLS 1.3). >> >> Of course, it might be the case that these defenses are insufficient >> (that would be useful to know!) but this document does not provide >> much assistance in making that evaluation. The intend of the document is not to provide cryptoanalysis guidance to evaluate specific protocol designs but to provide general guidance on how to deal with use of transient numeric identifiers in protocol design. Indeed, the two protocols that you singled out do not follow our guidance (they hardly could as the document we are reviewing is not yet officially published) and assessing if the lack of precision for the generation of transient IDs weakens the protocols would be a matter for the respective authors to deal with. IMO, in the case of QUIC, the Connection ID section specification is sufficiently complicated to warrant more in-depth analysis. >> Moving to the requirements in S 5, I note that neither QUIC nor DTLS >> recommends an algorithm for generating connection IDs, which would >> violate requirement #3. >> >> 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]. >> >> Instead, QUIC provides requirements for how CIDs must work but not an >> algorithm >> (https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-32#section-5.1). >> >> >> Connection IDs MUST NOT contain any information that can be used by >> an external observer (that is, one that does not cooperate with the >> issuer) to correlate them with other connection IDs for the same >> connection. As a trivial example, this means the same connection ID >> MUST NOT be issued more than once on the same connection. > > I believe that not recommending a good/safe choice for generating IDs > has been proved to be problematic. Indeed, that has been the case even in documents that describe the use of cryptographic algorithms in protocols. See, for example, the case of "RFC 25288 - AES Galois Counter Mode (GCM) Cipher Suites for TLS" which in section 3 states: (https://tools.ietf.org/html/rfc5288#section-3) The nonce_explicit is the "explicit" part of the nonce. It is chosen by the sender and is carried in each TLS record in the GenericAEADCipher.nonce_explicit field. The nonce_explicit length (SecurityParameters.record_iv_length) is 8 octets. Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security. The nonce_explicit MAY be the 64-bit sequence number. The case below is quite similar and even more specific (it hints at a particular way of implementing it) than the QUIC example and yet it lead to discovery 8 years later of at least 4 vulnerable implementations deployed on the Internet, as described by Bock at. al. in "Nonce-Disrespecting Adversaries: Practical Forgery Attacks on GCM in TLS" (https://eprint.iacr.org/2016/475.pdf) Note that in the AES-GCM in TLS case the need for a counter was warranted but not explicitly called for and such underspec'd text lead to flawed implementations. In other cases, a random nonce/ID is better than a numeric sequential value, we argue that authors should assess what is appropriate in their particular case and write their spec and rationale for it accordingly. > If a protocol is successful enough, > it's very likely that you will see multiple independent implementations > (from folks that are not involved in the protocol design, etc.), and > that bad choices will be made if there is no recommendation. See my preceding paragraph as an example case of that. > >> I'm not saying that cryptographic protocols don't need to take care in >> identifer selection, but the guidance in this document does not seem >> very helpful in that respect. I'd like to dig deeper into that feedback. In which way do you think it does not seem helpful. What would you expect it to say to be helpful? Suggested text would be welcomed. Baring a more detailed proposal I propose to include text that explicitly calls out 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. Does that sound like a sensible caveat? Note however that even authenticated encryption over transient Id fields would not prevent some possible attacks, for example privacy leaks where reuse of an ID sequence across different contexts enables a peer to reveal information about the other peer. An example of the above issue motivated "Security and Privacy Considerations for IPv6 Address Generation Mechanisms" (https://tools.ietf.org/html/rfc7721) >> It's no doubt the case that the IETF >> will in the future design some non-cryptographic protocols where this >> kind of guidance will be on-point, but I don't think that in 2020 >> we should publish a document as BCP which ignores so much of current >> practice. >From this commentary I understand that what the BCP ignores is the use of authenticated encryption over transient ID fields in modern protocol design. As proposed above, we could call that out explicitly. Are there any other things of current practice that we ignored ? >> On the specific topic of requirements and updating RFC 3552. While I >> understand the urge to list out some requirements for protocols, this >> level of specificity is a poor match for 3552, which is quite general >> in its requirements. > > FWIW, this work was motivated when we realized that the same kind of > problem had been plagued all sort of protocols from different layers. > > If we experience the same problem in multiple specifications of > different protocols, and multiple implementations of each of such > protocols, I would expect that we should be doing something to at least > prevent that same problem from continuing plaguing protocol > implementations and specifications. > Our intent is to provide general guidance to protocol designers/authors so the issues we pointed out, commonly seen at different protocol layers, are addressed proactively early on. If such general guidance is heeded, that would minimize the effort of assessing the security and privacy implications of transient IDs on a protocol by protocol basis. > >> I *would* be in favor of strengthening cc's requirements (for >> instance, at this point, I believe we should require formal analysis >> for cryptographic protocols) but I don't think that should happen by >> piecemeal adding requirements based on the interests of individual >> draft authors. We drafted our document with the intention of addressing what we perceived as a reoccurring, yet overlooked problem, in protocol design or implementation, not to serve our personal interests. Requiring formal analysis of cryptographic protocols would be a significant improvement for future protocol design and I believe its a topic that has been discussed on IETF mailing lists, I am looking forward to such a change. In the meantime, I argue that our recommendations for transient IDs do not prevent other recommendations. regards, /ivan -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
