[IPsec] Use of AEAD algorithms as pure encryption algorithms

Valery Smyslov <smyslov.ietf@gmail.com> Thu, 20 April 2023 07:42 UTC

Return-Path: <smyslov.ietf@gmail.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 1AF99C1522AB; Thu, 20 Apr 2023 00:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ZcMfRzRvZ_XA; Thu, 20 Apr 2023 00:42:06 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 7F493C151B35; Thu, 20 Apr 2023 00:42:01 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-4ec816d64afso1709952e87.1; Thu, 20 Apr 2023 00:42:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681976519; x=1684568519; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=ETlFhS+iidvW8I/UKlNi5L75tZaEh2LF9luQl1/AMFI=; b=nVIqk14wUvAxdQXOlC+nLw6hWm+Z6RXImc+O0YTw0JDkiDTWhetZH3RIcxiE6TlHu2 8IHVuVnYdXpfgxh8B/yTPxERo/KPiQTez8VFjpWgYKYoJOAzPXUllaWLXaronC5Bg+st kUrc5ggT8eGG3sjIjXEdQP5hzOZhPNkmMm1nV/xdsxmV6XRyq7d2i0HgjwLbayjroFq5 112nZIUaPfQrhLZHoR12cfUAqzB0nYUJYGhgFPa7+DNjtjQ3k2LZFibftfYNGEYZrfIH cJhZKsFFi3pk+VS4Hra0Qk1wIq6eewBbLvYPv4zzQMqSvwxsi7OjRx29oNzKJGKznpop GL+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681976519; x=1684568519; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ETlFhS+iidvW8I/UKlNi5L75tZaEh2LF9luQl1/AMFI=; b=e92wQ004pMLLpePXSnoZl7RjJ75C1tpZGiCIKe2or0Bab4fFvulV0CimfxZmhV2SP7 5aNNzEkQAatuXl5D0c5A98Eb4ogO2+pJiYoIUY/mZAjfa6qcxAjubvVIdxZiPRgX2BlW KD+uRz/rMmhwZg5ZGFw0LvrpVbfzEA0VcBvaYkx7cx7WUMv8kx/oYFaUrN0iYJm6CV7l JeQUd8QdiUiOxbxCXL8H2Igw+Y7/NbqcGaV2GhneT3Gj+nSnaaJLW+V/YQxf5MvfH6Ka AJZ4jbilZpGN2PZDMAV2cxFwKz2fjqoptmKnyYkbfPnaTf+CyIywojB3t8V+uOzafuqD Fgfg==
X-Gm-Message-State: AAQBX9cUz8mM+JKSXIkDLM5xDdeReXDzOQPvnxi/54Q1BOYZGu6Or9dp bH86fdCWR/3cu5CKblZcuTxP155mO+8=
X-Google-Smtp-Source: AKy350Y3/EQWBOmfdhsn6+ZjmxSjlMC4uaNDM74bC7UDkh23fZXVIGG8UB3haK35YCCZ3yHbtbslTA==
X-Received: by 2002:a05:6512:110a:b0:4dc:8049:6f36 with SMTP id l10-20020a056512110a00b004dc80496f36mr1187814lfg.1.1681976518410; Thu, 20 Apr 2023 00:41:58 -0700 (PDT)
Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id a28-20020a2eb17c000000b0029c96178425sm144894ljm.19.2023.04.20.00.41.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2023 00:41:57 -0700 (PDT)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: cfrg@ietf.org, IPsecME WG <ipsec@ietf.org>
Date: Thu, 20 Apr 2023 10:41:59 +0300
Message-ID: <083b01d9735b$97767000$c6635000$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdlzWy9mr6gRLEYLTt2jpEwROsK/Ig==
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/-UvEpBRlMeGih8hzXqVGvg5f-RA>
Subject: [IPsec] Use of AEAD algorithms as pure encryption algorithms
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 20 Apr 2023 07:42:10 -0000

Hi,

I have a question to the crypto community regarding the use of AEAD algorithms as pure
encryption algorithms. The use case is as follows.

In G-IKEv2 (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/) we have a situation
where keys are transferred inside the G-IKEv2 message. The message itself is encrypted and
integrity protected. In addition, each of individual keys inside this message is encrypted too
with a different key(s) (it can be the same key for all encrypted keys or different key for each encrypted key,
but in any case these keys are different from the key protecting the message).
The reason for this construction is to prevent the G-IKEv2 engine which forms and parses 
messages from accessing any sensitive information inside the messages.

The algorithm for protecting the message itself and individual keys inside the message is the same - 
it is one of IKEv2 Encryption transforms 
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5
The reason for this is to simplify implementations - the algorithm for protecting the message will be 
supported anyway, so there seems to be no reason to negotiate another one.
In many cases this algorithm will be an AEAD algorithm (like AES-GCM).

The problem is that there may be quite a lot of encrypted keys inside a single message,
and since G-IKEv2 operates over UDP (and over multicast!), the size of the message matters - 
large messages will be fragmented by IP level and due to known issues with firewalls
might not get through, so we want to make the message small. And for each protected key 
the authentication tags would consume almost the same space, as the encrypted content.

So, the design is that even when using an AEAD algorithm, the individual
keys inside the protected message are only encrypted and their authentication tags produced by the AEAD algorithm,
are not transmitted. On a receiving side it must be possible to decrypt keys without performing an integrity check.
Note, that the message itself is encrypted and integrity protected, so we are sure that all message content, 
including all encrypted keys, is not altered.

My questions to the crypto community:
1. Is it generally OK to use AEAD algorithms as pure ciphers.
2. Do existing APIs to AEAD algorithms allow to decrypt an encrypted blob without checking its integrity.

Regards,
Valery.