> -----Original Message----- > From: IPsec <ipsec-boun...@ietf.org> On Behalf Of Michael Rossberg > Sent: Wednesday, July 29, 2020 12:10 PM > To: Tero Kivinen <kivi...@iki.fi> > Cc: Steffen Klassert <steffen.klass...@secunet.com>; ipsec@ietf.org; Valery > Smyslov <smyslov.i...@gmail.com> > Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 > > > >> We have already the option to send the high sequence number bits when > >> a combined mode algorithm is used. > >> > >> RFC 4303, Section 2.2.1. says: > >> > >> If a combined mode algorithm is employed, the algorithm choice > >> determines whether the high-order ESN bits are transmitted or are > >> included implicitly in the computation. > > > > We do not have any algorithms that use that feature, and we do not > > have option to negotiate it in IKEv2. > > > > We could add new value for transform type 5 (Extended Sequence > > Numbers) to say that we use extended sequence number, and that we > > actually transmit the full extended sequence number. > > That would already help for the case. > > >> We could just give multicast the same option if it wants to use > >> replay protection. > > > > As others have already pointed out earlier, with multicast the upper > > layer must make care of replays and dropped packets themselves in any > > case, so doing that also on the IPsec level does not really provide > > that much more security. I mean if the multicast protocol run over UDP > > over IPsec simply has internal sequence number inside the UDP, which > > will then be authenticated by the IPsec that should be good enough for > > replay protection. > > > > There is issue that in that case attacker could do Denial of Service > > attack against the IPsec, by replaying packets, and then the IPsec > > gateway would decrypt and forward them. > > Like pointed out in the answer to Valery’s mail. There are possibly more > issues, as attackers are able to generate new traffic, they can use for > cryptanalysis (see https://www.aircrack-ng.org/doku.php?id=arp- > request_reinjection). > Having anti-replay guarantees is just a reliable foundation. IMHO the case of > applications being responsible holds just as well for unicast applications. > TCP > takes care of that, still no-one honestly discusses removing replay checks for > high volume unicast SAs. > > > When using multicast you already need to use SPI, and destination > > address as your SAD lookup (RFC4303, section 2.1), i.e. use option 2 > > there. On the other hand you could use the SPI, destination address, > > and source address to find the replay window and largest sequence > > number used if you want to do anti-replay protection on multicast SAs > > so that each sender has separate replay windows. > > This still requires to know all possible senders beforehand. Also the SAs will > still need to agree on an IV subspace and sending an explicit IV per packet. > > >>> And about security. In order to have IV combined with ESN and > >>> sub-windows identifiers this proposal removes secret salt from the > >>> nonce. This may have impact on security. > >>> I'm not a cryptographer, but I believe the impact is not negligible. > >>> On the last CFRG session a draft draft-wood-cfrg-aead-limits was > >>> discussed that calculates limits of data to be safely encrypted by > >>> various AEAD ciphers. The authors claimed that having secret salt in > >>> the nonce increases this limits in case of multi-user attacks and > >>> that the results in the draft are calculated for this case. If plain > >>> AEAD ciphers (with no secret salt) are used the limits are lower. > >> > >> A secret salt in the nonce would be a new requirement anyway. > >> I've checked RFC 4106 (ESP for GCM) and RFC 7634 (ESP for > >> ChaCha20-Poly1305), both don't require a secret salt. > > > > It is true that they do not need secret salt, but they do have > > unpredictable salt, which is created by the key derivation step. My > > understanding was that this proposal did get rid of that salt too: > > Like written already: An unpredictable value of 32bit size is of no real value > from a crypto point of view. One could simply guess the value and have a > realistic chance of being right after a couple of thousand tries.
Actually, it does add value from a crypto point of view, at least from a specific attack. In a multitarget attack, that is, an attack where we assume that the attacker has encrypted packets from a large number of SAs, and his goal is to recover the keys for any one of the encrypted packets, here is what the attacker can do (assuming GCM or ChaCha20-Poly1305); if he has packet encrypted with each SA with the same nonce, he can guess a key, and generate the internal GCM/ChaCha20 keystream based on that key/nonce combination. He can then scan through all the packets to see if the encryption makes sense (or the ICV tag works out); this can be done far faster than checking each packet individually. Assuming the packets are encrypted with AES-128, and the attacker has packets from 2**L SAs, then against this attack, we have only 128-L bits of security. By including 32 bits of unpredictable values, we make this attack 4 billion times harder, and for AES-128, that would give us 160-L bits of security. This doesn't actually add any security against attacks against a single SA, and the salt doesn't actually need to be secret. > I believe it is > only in the standard, as with 64 bit sequence numbers there where 32 bits > left; needing to be filled. Nope; it was included to increase security. For 256 bit keys, one can easily argue that this is not needed; however for 128 bit keys, it is considerably more marginal. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
