Hello Joseph On 12/17/20 8:35 PM, Joseph Touch wrote: > > >> On Dec 14, 2020, at 9:12 PM, Fernando Gont <fgont@xxxxxxxxxxxxxxx >> <mailto:fgont@xxxxxxxxxxxxxxx>> wrote: >> >> Flawed IDs introduce problems. IDs that are not flawed do not. > > Christian has expressed much of my position, with the exception of the > following: > > IMO - protocols MUST NOT limit how IDs are selected or used. The issue > isn’t the protocol spec; it’s the implementation. > If the use of IDs creates a known security problem they should, yes. If guidance is not heeded things like those described here will continue to happen: note CVE-2020-17439, another instance of good old off-path DNS cache poisoning due to use of predictable DNS TXIDs [PDF] https://www.forescout.com/company/resources/amnesia33-how-tcp-ip-stacks-breed-critical-vulnerabilities-in-iot-ot-and-it-devices/ > I.e., an *implementation* MAY do so. These recommendations MAY be > useful, to that end. > > What I want to avoid is breaking the potential for IoT devices to use > these protocols simply because they can’t implement the approaches > described here. I don't think this is really a concern given that IoT devices are already implementing some of the proposed algorithms. For example, RFC 6528 is a Proposed Standard and mandates (with SHOULD): 3. Proposed Initial Sequence Number Generation Algorithm TCP SHOULD generate its Initial Sequence Numbers with the expression: ISN = M + F(localip, localport, remoteip, remoteport, secretkey) where M is the 4 microsecond timer, and F() is a pseudorandom function (PRF) of the connection-id. F() MUST NOT be computable from the outside, or an attacker could still guess at sequence numbers from the ISN used for some other connection. The PRF could be implemented as a cryptographic hash of the concatenation of the connection-id and some secret data; MD5 [RFC1321] would be a good choice for the hash function. It is possible that some devices do not follow that advice but any device with a working PRNG should be capable of doing it. > > I also want to avoid a receiver saying “hey, sender, you picked the IDs > badly, so I won’t connect to you”. I don't think this is mandated anywhere. In fact our draft does not even mandate that consideration is given to the security & privacy factors of IDs, documented and an algorithm recommended. But protocol authors may very well say: "for the ID field <x> use a global counter initialized in 0 and incremented by 1 in each packet or any other algorithm, we are aware of the security & privacy consenquences, this is a conscious decision, see Security Considerations for further discussion of our attacker model" > That’s where I worry this is headed, and want to avoid. I understand the concern but I do not see how our draft could lead to that. regards, /ivan -- Iván Arce CTO - Security Analysis Quarkslab -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
