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

["David McGrew (mcgrew)" <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> wrote:

>
>   Hi Daniel,
>
>On 2/23/17 3:12 PM, Daniel Franke wrote:
>> 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?
>
>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.
>
>>
>> Or should it treat this as a request for deterministic encryption and
>> 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.
>
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/cfrg