Re: [IPsec] rfc 8750 question

Robert Moskowitz <rgm-sec@htt-consult.com> Tue, 10 May 2022 12:42 UTC

Return-Path: <rgm-sec@htt-consult.com>
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 CB29CC159526 for <ipsec@ietfa.amsl.com>; Tue, 10 May 2022 05:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.756
X-Spam-Level:
X-Spam-Status: No, score=-3.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.857, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 gt5-l2GSmqtb for <ipsec@ietfa.amsl.com>; Tue, 10 May 2022 05:42:31 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC48CC159524 for <ipsec@ietf.org>; Tue, 10 May 2022 05:42:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id DC44262569; Tue, 10 May 2022 08:41:42 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vD5vfx7vvQtF; Tue, 10 May 2022 08:41:34 -0400 (EDT)
Received: from [192.168.160.11] (unknown [192.168.160.11]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 1DBAB62434; Tue, 10 May 2022 08:41:30 -0400 (EDT)
Content-Type: multipart/alternative; boundary="------------lhGJqjJN7k0eq27r8A6XzAT7"
Message-ID: <1ee26147-a40c-f14f-7285-5c900791878f@htt-consult.com>
Date: Tue, 10 May 2022 08:42:13 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0
Content-Language: en-US
To: Paul Wouters <paul.wouters@aiven.io>
Cc: Valery Smyslov <smyslov.ietf@gmail.com>, ipsec@ietf.org
References: <cac94813-33e1-5b7b-5245-eda7c1878513@htt-consult.com> <48675BBB-9C59-43B4-A98C-E5A1565CAF15@aiven.io>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
In-Reply-To: <48675BBB-9C59-43B4-A98C-E5A1565CAF15@aiven.io>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Kxk0kTsy0LQqpwleSo1rsZfkwSE>
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:42:32 -0000


On 5/10/22 08:25, Paul Wouters wrote:
> 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 ?


FAA mandate that the Location/Vector information for the UA be updated 
at least once per second (similar in EU and Japan).  Then there are a 
few other messages, like if the Operator moves, DHS (proxying through 
FAA) wants to know where the Operator is. Operators tend not to move as 
much as UA, so no 1/sec mandate there.

Of course all this position data is suspect.  Altitude can be off 10M 
due to the ionosphere action, but FAA really does not care.  You do NOT 
want a replay of all those video meetings...

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