Subject: [Cfrg] RFC 5297 and absent vs. zero-length nonces

From: Daniel Franke <[email-masked]>
Date: Thu, 23 Feb 2017 18:12:26 -0500

The IANA considerations section of RFC 5297 (Synthetic Initialization
Vector (SIV) Authenticated Encryption Using the Advanced Encryption
Standard (AES)) gives N_MIN as 1. However, S2V is perfectly capable of
accepting zero-length arguments. Furthermore, passing a zero-length
argument to S2V is distinct from not passing that argument at all (as
done in the case deterministic encryption). How should an
implementation behave when provided with a zero-length nonce?

Should it return an error, since its length is under N_MIN?

Should it pass it along to S2V just like any other nonce input?

Or should it treat this as a request for deterministic encryption and
not pass any nonce to S2V?

---

From: Dan Harkins <[email-masked]>
Date: Thu, 23 Feb 2017 18:08:57 -0800

Hi Daniel,

> implementation behave when provided with a zero-length nonce?

The registry that RFC 5297 updated with its IANA Considerations was
created by RFC 5116 to specify parameters for nonce-based AEAD modes. So
when using RFC 5297 through that interface you're saying you want to
use a nonce. RFC 5297 places the most minimal of requirements on such
use: N_MIN of 1 octet.

   The registry does not say what to do if someone tries to use the
mode in a way that is not defined for the registry so officially I
don't know what the answer is. We can evaluate your suggestions though.

(As an example, AES-GCM can take a nonce of 16 octets but the registry
makes N_MIN = N_MAX = 12. What do you do if you send 16 octets to
AES-GCM through this interface? Got me.)

> Should it return an error, since its length is under N_MIN?

   That would seem like the prudent thing to do since it is in violation
of the registry parameters.
> Should it pass it along to S2V just like any other nonce input?

   Since the registry mandates N_MIN as 1 then passing a zero length
nonce "just like any other nonce input" seems wrong. So I'd say don't
do that.

> not pass any nonce to S2V?

   Well the registry is not for deterministic encryption so I would
say using it that way is not appropriate and would not think this
is correct.

   Seems to me that if you want to use AES-SIV (or any of the AEAD
modes from RFC 5116) in a way that is not defined by RFC 5116 then
use them through some raw interface and not the constrained one
created by RFC 5116. You'll note that the RFC 5116 interface also
assumes that all AAD is a single blob and does not support AES-SIV's
vector of AAD. What do you do with this registry if you need/want
to pass a vector of AAD to AES-SIV? Well, I'd say you don't use this
registry as your interface.

   Hope this helps,

   Dan.

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Fri, 24 Feb 2017 12:26:36 +0000

Hi Dan,

RFC 5116 does allow zero-length nonces and provide guidance around their use.   From that doc:

      A nonce N.  Each nonce provided to distinct invocations of the
      Authenticated Encryption operation MUST be distinct, for any
      particular value of the key, unless each and every nonce is zero-
      length.  Applications that can generate distinct nonces SHOULD use
      the nonce formation method defined in Section 3.2, and MAY use any
      other method that meets the uniqueness requirement.  Other
      applications SHOULD use zero-length nonces.

   Each AEAD algorithm MUST accept any nonce with a length between N_MIN
   and N_MAX octets, inclusive, where the values of N_MIN and N_MAX are
   specific to that algorithm.  The values of N_MAX and N_MIN MAY be
   equal.  Each algorithm SHOULD accept a nonce with a length of twelve
   (12) octets.  Randomized or stateful algorithms, which are described
   below, MAY have an N_MAX value of zero.

Clearly SIV modes can and should set N_MIN to zero.  I guess the N_MIN=1 got missed during the review of RFC 5297.  (I recall discussing the N_MAX guidance during the review process, but I think N_MIN went unnoticed.)

If N_MIN can be changed in RFC 5297 from 1 to 0 with an Errata, that would be the best way to go.   Otherwise, I suggest creating new IANA entries for the existing SIV modes that reference that RFC, but change N_MIN to zero.    

Best,

David

On 2/23/17, 9:08 PM, "Cfrg on behalf of Dan Harkins" <[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>Cfrg mailing list
>[email-masked]
>https://www.irtf.org/mailman/listinfo/cfrg

---

From: Daniel Franke <[email-masked]>
Date: Fri, 24 Feb 2017 10:49:27 -0500

On 2/24/17, David McGrew (mcgrew) <[email-masked]> wrote:
>Clearly SIV modes can and should set N_MIN to zero.  I guess the N_MIN=1
> got missed during the review of RFC 5297.  (I recall discussing the N_MAX
> guidance during the review process, but I think N_MIN went unnoticed.)
>
>If N_MIN can be changed in RFC 5297 from 1 to 0 with an Errata, that would
> be the best way to go.   Otherwise, I suggest creating new IANA entries
> for the existing SIV modes that reference that RFC, but change N_MIN to
> zero.

If we agree that a change is in order, that I hope we can also agree
that an erratum would suffice. Having two different IANA codepoints
that differ only in the value of N_MIN sounds like it would sow a
hideous amount of confusion.

It sounds like the three of us agree, at least, that my option 3,
treating a zero-length nonce as a request for deterministic
encryption, is the Wrong Thing. For my own purposes, I'm just doing an
RFC 5297 implementation (look for a release announcement RSN) and not
aspiring to create a general RFC 5116 interface, so I think I can go
ahead and allow zero-length nonces regardless of whether it's strictly
RFCily-correct to do so. My function signature looks like this:

int AES_SIV_Encrypt(AES_SIV_CTX *ctx,
                    uint8_t *out, size_t *out_len,
                    uint8_t const* key, size_t key_len,
                    uint8_t const* nonce, size_t nonce_len,
                    uint8_t const* plaintext, size_t plaintext_len,
                    uint8_t const* ad, size_t ad_len);

It'll give you deterministic encryption if the `nonce` argument is
NULL, and encryption with a zero-length nonce if `nonce` is non-NULL
and `nonce_len` is 0.

---

From: Dan Harkins <[email-masked]>
Date: Fri, 24 Feb 2017 13:26:11 -0800

Hi David,

> Clearly SIV modes can and should set N_MIN to zero.  I guess the N_MIN=1 got missed during the review of RFC 5297.  (I recall discussing the N_MAX guidance during the review process, but I think N_…

   Yes, SIV _can_ accept a zero-length nonce but since SIV is unique in that
it is both a probabilistic AEAD mode and a deterministic "keywrapping" mode
that also accepts AAD such a change might create some confusion. (Option 
3 of
Daniel's question).

> If N_MIN can be changed in RFC 5297 from 1 to 0 with an Errata, that would be the best way to go.   Otherwise, I suggest creating new IANA entries for the existing SIV modes that reference that RFC…

   I can see why one would want to use SIV deterministically as a better
keywrapping scheme than AES-Keywrap (accepts AAD, no odd length requirements
on plaintext, no padding needed, has a security proof) but I don't see why
someone would want to use it probabilistically with a zero length nonce.
RFC 5116 is for AE modes not deterministic keywrapping modes and if someone
wants to use SIV in its AE mode then what's wrong with mandating he or she
passes at least a 1 byte nonce?

   Unless you can think of a way to avoid the confusion I'd rather not make
the change.

   regards,

   Dan.