Hi Ben, > Hi Valery, > > On Tue, Jul 26, 2022 at 12:04:34PM +0300, Valery Smyslov wrote: > > > > If we assume that we are in Dolev-Yao threat model, then an attacker has no > > access > > to inside the hosts, but it has an unlimited power on the network. > > Generally speaking > > with this model the most sensible thing is to count only the outgoing > > traffic > > and not the incoming traffic. Below is described why. > > Without making a statement about your conclusion, are you aware of the > discussion in > https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-05#section-4 > about an Integrity Limit that bounds the number of decryption attempts, > whether succesful or unsuccesful, using a single key?
Thank you for pointing to this document. Yes, I'm aware of this work (and I think the document is very important). To mount an attack on authentication there must be a channel from the receiver to the attacker, so that the latter may learn whether a forgery attempt was successful. The channel may be on a protocol level (e.g. TCP ACKs) or outside the protocol (e.g. electromagnetic emission or metering power consumption etc.). If we assume no such channels exists (e.g. unidirectional video stream over UDP is received by a host placed in a shielded box with autonomous power supply etc.) then forgery attacks are impossible, so my conclusion should be applicable (note, that I mentioned that side channels are out of scope). That said, I agree, that in real life this is not the case in many situations, so we should also take the amount of received data into considerations. So, the corrected advice for implementations - both sender and receiver should count the amount of data processed by them (sent or received correspondently) and should initiate the rekey when the corresponded threshold is reached. Note, that this doesn't change the conclusion, that assigning a party who will initiate next rekey beforehand is not a good idea from cryptography point of view. In addition to the example from my original message, consider the following situation. Let the sender and the receiver have negotiated that next rekey will be initiated by the sender. After that the sender has no or very little data to send for some period of time. During this period an attacker may send an arbitrary amount of data to the receiver trying to break authentication key. Since the receiver cannot initiate the rekey process, it has limited choice of what to do in this situation (and it depends on the type of side channel the attacker uses, which the receiver might not know). It seems that the most safe defense would be to start dropping all the received packets once some threshold is reached (in should initiate the rekey at this point, but it couldn't). But this actually means the termination of service, so DoS. Regards, Valery. > Thanks, > > Ben _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
