Re: [IPsec] rfc 8750 question

Paul Wouters <paul.wouters@aiven.io> Tue, 10 May 2022 12:25 UTC

Return-Path: <paul.wouters@aiven.io>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C89C1594B3 for <ipsec@ietfa.amsl.com>; Tue, 10 May 2022 05:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkqOMg307K_G for <ipsec@ietfa.amsl.com>; Tue, 10 May 2022 05:25:45 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE021C1594B5 for <ipsec@ietf.org>; Tue, 10 May 2022 05:25:45 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id d6so19784204ede.8 for <ipsec@ietf.org>; Tue, 10 May 2022 05:25:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=1aq195uXme9zl1GFFyCteXElFoK/dJQx0KGpsmFEs0g=; b=QQCXMHlsER8ULjJUFibaOD9flqANfNH07RPJayGWuFd3qj9u4eN+8gg61uvXHjZ20l +Ditisq/Vme8v6xF82/45QOWfjbm9l6Ft7zkiJVujZsxjtwNgDsPxplrkWhlVs/i3fAL XlmNISv0CueQ0yXza5GUuUT4VBZZid1MVr/HM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=1aq195uXme9zl1GFFyCteXElFoK/dJQx0KGpsmFEs0g=; b=l43VLLBNOLhUq8RM04DZFQ3oqxUTq2Zel2KwiEOk+txLwWvye4e/5H3iCK5BV+W3ze 9VC2LrgkzlLRGLwVZhODXFcNRlZnjaWo0pwyqyDJO0qwRMuoTL58JsfH+InoBLTXiJDM Z1472IiKMA4lJ98FZ7sER4nd6vUh/5fASLs+6+J8nFFhc9Ikpxe7jklKMP66JUdJmUZL QY+YXcDG+yXiRSk5zoaQKv/ad7wK7MseewZkWSEwLcVZ46JmrKWsTHw/PmDD9rkW29w0 9bPmeKLBd/ueTQPAOs/tPOOc5AkfVToja1X7DislkVFMdPsxX8FrPBEhiOuHNLN6I7XX 9mjQ==
X-Gm-Message-State: AOAM5324ReSk0omr+JYW7hYu8K/z34KxMsRKNXJcs267Sb0dzpbdKyqz b9hjXA84u1mwcvPQbBASbDg6bw==
X-Google-Smtp-Source: ABdhPJwdVbBcirN58jsYusIRRzF0CBXxYxLzG0UB+cD2Kl/pF0F7GWN1G6DGOALtz41LI9zgNdv0iA==
X-Received: by 2002:a05:6402:1544:b0:428:b439:9a01 with SMTP id p4-20020a056402154400b00428b4399a01mr3351400edx.201.1652185544037; Tue, 10 May 2022 05:25:44 -0700 (PDT)
Received: from smtpclient.apple ([74.122.52.94]) by smtp.gmail.com with ESMTPSA id p4-20020aa7cc84000000b00427afbbf5e8sm1871590edt.11.2022.05.10.05.25.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 May 2022 05:25:43 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-B6DD9C90-D6ED-46BB-9D08-319C2D459295"
Content-Transfer-Encoding: 7bit
From: Paul Wouters <paul.wouters@aiven.io>
Mime-Version: 1.0 (1.0)
Date: Tue, 10 May 2022 08:25:38 -0400
Message-Id: <48675BBB-9C59-43B4-A98C-E5A1565CAF15@aiven.io>
References: <cac94813-33e1-5b7b-5245-eda7c1878513@htt-consult.com>
Cc: Valery Smyslov <smyslov.ietf@gmail.com>, ipsec@ietf.org
In-Reply-To: <cac94813-33e1-5b7b-5245-eda7c1878513@htt-consult.com>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
X-Mailer: iPhone Mail (19E258)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Zc4lAGO87RbXJR62MRR-Zg4c-kY>
Subject: Re: [IPsec] rfc 8750 question
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 May 2022 12:25:49 -0000

On May 10, 2022, at 07:59, Robert Moskowitz <rgm-sec@htt-consult.com> wrote:
> 
> 
> 
>> 20    ENCR_AES_GCM_16
>> 
>> and what RFC 8750 defined:
>> 
>> 30    ENCR_AES_GCM_16_IIV
>> 
>> The only difference is a suffix "_IIV".
> 
> Actually, I thought that was the implicit IV size.  And thus this was some kind of AND condition of the base cipher AND implicit IV.

It is.

> I really want the AES_GCM_12 used along with diet-esp.  Those 4 bytes are important when you are dealing with an MTU of 64 bytes and only have a 26 byte UDP data packet.

From RFC 8247:

As the advantage of the shorter (and
   weaker) Integrity Check Values (ICVs) is minimal, the 8- and 12-octet
   ICVs remain at the MAY level.

This explanation was not repeated in RFC8221, but the reason is the same. These weren’t really used or supported and kind of unwanted. Basically the authors of GCM really didn’t want shorter than 16 ICV but were pushed to include it.

> With diet-esp in transport mode for a single UDP app, I can have a 2-byte SPI (server will have LOTS of clients).  I COULD get by with a 1-byte SN, but that would only cover ~4 min of comm before advancing the implicit msb

So that is one packet per second. That’s a lot of traffic. Does the ICV size really matter at that point? Is it causing you to go from 1 to 2 packets per second ?

Paul

> so better a 2-byte SN and that gives word alignment for the ESP header (not really soooo important). Those 4 bytes in the ICV hurt.  And the data is only valid for 1sec for the app.
> 
> The lightweigt crypto (like Xoodyak) from the NIST LWC effort (workshop this week) looks more attractive, as I can easily only squeeze the 12 bytes out of the sponge for the tag...