Hi Paul,

Thank you for your reply.  In our draft, we are trying to reconcile RFC 8452 
(AES-GCM-SIV) with RFCs 5282 and 4106, specifying AES-GCM in IKEv2 and ESP 
respectively.  The NIST standard for AES-GCM (SP 800-38D) defines an IV as a 
Nonce used in an AEAD, and a Nonce is defined as "a value that is used only 
once within a specified context" (but not necessarily random).  In fact, in 
AES-GCM, the IV is not usually entirely random.

RFCs 5282 and 4106 specify a payload field called "Initialization Vector" for 
AES-GCM.  AES-GCM-SIV instead takes a "Nonce" argument, which is then used 
internally to derive the synthetic IV.  My question in the email was trying to 
ask, "is it okay if we rename the Initialization Vector field to Nonce?"  We 
could even add a relabeled diagram to the -02 draft akin to Figure 1 of RFC 
5282 to make this clearer.

With regards to mandating the randomness of the nonce: RFC 8452 says it is 
RECOMMENDED to have the GCM-SIV nonce be random.  Since the security 
degradation is graceful if a nonce is reused, we did not feel that we should 
say the nonce MUST be random.

Best,
Casey


________________________________
From: Koning, Paul <[email protected]>
Sent: Wednesday, September 16, 2026 12:55 PM
To: [email protected] <[email protected]>; [email protected] 
<[email protected]>
Subject: RE: New Version Notification for 
draft-guthrie-ipsecme-aes-gcm-siv-01.txt


Your second point is a bit odd.  To me, “nonce” means a value that MUST be 
strongly random because that is required for the security / correctness of the 
algorithm.  Conversely, a value that is not security sensitive might be random, 
or constructed in some other way, with either option being safe, I would not 
call “nonce”.



You indicated that you would “recommend” this field to be entirely random.  
That tells me it’s not a nonce.  But if in fact a secure random value is 
required to achieve the  security properties you aim for, then “nonce” seems 
correct but in that case you need to require, not merely recommend, it to be 
securely random.



               paul




Internal Use - Confidential

From: [email protected] <[email protected]>
Sent: Wednesday, September 16, 2026 12:36 PM
To: [email protected]
Subject: [IPsec] Fw: New Version Notification for 
draft-guthrie-ipsecme-aes-gcm-siv-01.txt



[EXTERNAL EMAIL]

Hi IPSECME,



We've just published an updated version of our I-D specifying the use of 
AES-GCM-SIV in ESP and IKEv2.  Version -01 updates the introduction and fixes 
some other typos from the -00.



Any feedback is welcome.  We're additionally curious if there are thoughts on 
the following items, some of which are included as ednotes in draft:

  *   Is it okay to rename the IKE IV field to Nonce (since GCM-SIV has a nonce 
instead of an IV)?
  *   We'd prefer to recommend that nonces be entirely random.  This is 
different from AES-GCM where the nonces are implicit.
  *   We opt to set the GCM-SIV authentication tag as the ESP ICV field, as 
opposed included at the end of the ciphertext field.



Best,

Casey





________________________________

From: [email protected]<mailto:[email protected]> 
<[email protected]<mailto:[email protected]>>
Sent: Wednesday, September 16, 2026 9:29 AM
To: Casey Wynn (GOV) <[email protected]<mailto:[email protected]>>; Nicholas 
Gajcowski (GOV) <[email protected]<mailto:[email protected]>>; Rebecca 
Guthrie <[email protected]<mailto:[email protected]>>
Subject: New Version Notification for draft-guthrie-ipsecme-aes-gcm-siv-01.txt



A new version of Internet-Draft draft-guthrie-ipsecme-aes-gcm-siv-01.txt has
been successfully submitted by Casey Wynn and posted to the
IETF repository.

Name:     draft-guthrie-ipsecme-aes-gcm-siv
Revision: 01
Title:    Using AES-GCM-SIV in the Internet Protocol Version 2 (IKEv2) and 
Encapsulating Security Payload (ESP) Protocols
Date:     2026-09-16
Group:    Individual Submission
Pages:    9
URL:     
https://www.ietf.org/archive/id/draft-guthrie-ipsecme-aes-gcm-siv-01.txt 
[ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-guthrie-ipsecme-aes-gcm-siv-01.txt__;!!LpKI!lWEb48RMdtSMTGTUpPqAYV6BMyQ7ooHIlj4adp3r1XOMS-1V6ZriMdcozPahfQ5w7YXK2cfgdmnAgHNFJHs$>
Status:  https://datatracker.ietf.org/doc/draft-guthrie-ipsecme-aes-gcm-siv 
[datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-guthrie-ipsecme-aes-gcm-siv__;!!LpKI!lWEb48RMdtSMTGTUpPqAYV6BMyQ7ooHIlj4adp3r1XOMS-1V6ZriMdcozPahfQ5w7YXK2cfgdmnAN3K-xAs$>
HTML:  
https://www.ietf.org/archive/id/draft-guthrie-ipsecme-aes-gcm-siv-01.html 
[ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-guthrie-ipsecme-aes-gcm-siv-01.html__;!!LpKI!lWEb48RMdtSMTGTUpPqAYV6BMyQ7ooHIlj4adp3r1XOMS-1V6ZriMdcozPahfQ5w7YXK2cfgdmnAnDd7Cbc$>
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-guthrie-ipsecme-aes-gcm-siv-01 
[datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-guthrie-ipsecme-aes-gcm-siv-01__;!!LpKI!lWEb48RMdtSMTGTUpPqAYV6BMyQ7ooHIlj4adp3r1XOMS-1V6ZriMdcozPahfQ5w7YXK2cfgdmnAgSAEnF8$>
Diff:      
https://author-tools.ietf.org/iddiff?url2=draft-guthrie-ipsecme-aes-gcm-siv-01 
[author-tools.ietf.org]<https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url2=draft-guthrie-ipsecme-aes-gcm-siv-01__;!!LpKI!lWEb48RMdtSMTGTUpPqAYV6BMyQ7ooHIlj4adp3r1XOMS-1V6ZriMdcozPahfQ5w7YXK2cfgdmnAVjKffxs$>
Abstract:


   This document specifies the use of AES-GCM-SIV in the Internet Key
   Exchange Protocol version 2 (IKEv2) and the Encapsulating Security
   Payload (ESP) protocols.  This document also adds AES-GCM-SIV to the
   IANA IKEv2 registry for "Transform Type 1 - Encryption Algorithm
   Transform IDs."  AES-GCM-SIV is a nonce misuse-resistant
   authenticated encryption with associated data (AEAD) algorithm based
   on AES-GCM.



The IETF Secretariat

_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to