Hi Valery, On Mon, Aug 01, 2022 at 12:45:59PM +0300, Valery Smyslov wrote: > 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.
Yes, I think I agree with all of this. Thanks for talking through it. -Ben _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
