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

Hi Valery, a few comments inline. On Tue, Jul 28, 2020 at 11:13:33AM +0300, Valery Smyslov wrote: > Hi, > > a few thoughts about this proposal. > > > * 64 bit sequence counters in each header to ease protocol handling and > > allow for > > replay protection in multicast groups

[IPsec] My comments on "Proposed improvements to ESP"

Scott Fluhrer \(sfluhrer\) writes: > As for the idea of moving the integrity check value before the > encapsulated packet, well, that idea might help on your platform; > however it strikes me that the advantage would likely be fairly > platform dependent. Yes. In several kernel implementations the

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

Steffen Klassert writes: > 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

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

On Wed, Jul 29, 2020 at 04:22:15PM +0300, Tero Kivinen wrote: > Steffen Klassert writes: > > > > 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 tha

Re: [IPsec] My comments on "Proposed improvements to ESP"

On Wed, Jul 29, 2020 at 03:57:01PM +0300, Tero Kivinen wrote: > Scott Fluhrer \(sfluhrer\) writes: > > As for the idea of moving the integrity check value before the > > encapsulated packet, well, that idea might help on your platform; > > however it strikes me that the advantage would likely be fa

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

>> >> We have been analyzing issues ESP has in current data-center networks and >> came to >> the conclusion that changes in the protocol could significantly improve its >> behavior. Some >> of results will be presented next Tuesday in a pitch talk at IETF 108. This >> mail is just a >> small t

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 i

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

> -Original Message- > From: IPsec On Behalf Of Michael Rossberg > Sent: Wednesday, July 29, 2020 12:10 PM > To: Tero Kivinen > Cc: Steffen Klassert ; ipsec@ietf.org; Valery > Smyslov > Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 > > > >> We have already the option to send

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

Michael Rossberg writes: > 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). If any of our algorithms are vulner

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

> > 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 p

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

> -Original Message- > From: IPsec On Behalf Of Tero Kivinen > Sent: Wednesday, July 29, 2020 2:30 PM > To: Michael Rossberg > Cc: Steffen Klassert ; ipsec@ietf.org; Valery > > > Like written already: An unpredictable value of 32bit size is of no > > real value from a crypto point of vie

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

> -Original Message- > From: Michael Rossberg > Sent: Wednesday, July 29, 2020 2:35 PM > To: Scott Fluhrer (sfluhrer) > Cc: ipsecme mailing list > Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 > > > > > Actually, it does add value from a crypto point of view, at least from a

Re: [IPsec] [EXTERNAL] IPsec Digest, Vol 195, Issue 22

kernel/doc_changes From: IPsec on behalf of "ipsec-requ...@ietf.org" Reply-To: "ipsec@ietf.org" Date: Wednesday, July 29, 2020 at 3:01 PM To: "ipsec@ietf.org" Subject: [EXTERNAL] IPsec Digest, Vol 195, Issue 22 [EXTERNAL SENDER: This email originated from outside of Stratus Technologies. Do

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

Scott Fluhrer \(sfluhrer\) writes: > No, RFC4106 (June 2005) predated 800-38D (November 2007) by over two years. Ah, didn't check the dates, and the NIST document didn't really explain the reason behind it, it just said you preferrably need to have 32-bit fixed part. > Instead, it was inserted to