Re: [IPsec] Teaser for pitch talk at IETF 108

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

> -----Original Message-----
> From: IPsec <[e-mail]> On Behalf Of Michael Rossberg
> Sent: Wednesday, July 29, 2020 12:10 PM
> To: Tero Kivinen <[e-mail]>
> Cc: Steffen Klassert <[e-mail]>; [e-mail]; Valery
> Smyslov <[e-mail]>
> 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.