Re: [TLS] Pull Request: Removing the AEAD explicit IV

[Eric Rescorla <[e-mail]>]

On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns <[e-mail]>
wrote:

>  Sorry for being pedantic but...
>
> The Nonce is the fixed (per connection) part of the quantity of bits that
> are encrypted to produce one block of cipher text that's XOR'd with the
> plain text to produce the encrypted message block.   The Nonce plus the
> message sequence number is the per-message initialization vector.   The
> Nonce plus the message sequence number plus the block number is the per
> block value to be encrypted.   At least for CCM and GCM.
>
> The Nonce is common across all messages within a session.   (*sigh* the
> more general meaning of nonce is that of a unique per-invocation value but
> given that all per-message/per-block "nonce" usages contain the
> per-connection nonce it would be useful to not overload this too much -
> among other reasons:  an IV is not always a nonce but can be, a nonce is
> not usually an IV but can be, most messages require an IV, most blocks
> don't).  So maybe we call this the "Session Nonce" for clarity?
>

I realize that the terminology is confusing, but I'm using the terms from
RFC 5116
section 2.1 (https://tools.ietf.org/html/rfc5116#section-2.1). In this
context, the
nonce is not per-connection but rather per AEAD function invocation:

      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.

In this context, the AEAD function is invoked once for each TLS record
encryption.



> So what you're proposing is to eliminate the determination of the Nonce as
> part of the session negotiation and make it a fixed value.  E.g., we have
> an explicit nonce which is always zero which produces a per-message IV
> based on the sequence number of '0's | <sequence counter> | <block
> counter>.  As a side effect that also eliminates the per-message IV field
> (which aren't actually used by the currently defined AEAD modes AFAICT).
>

AES-GCM uses this field, which is the motivation for this change.



> That works for the currently defined pure AEAD modes (CCM/GCM at least,
> haven't looked at chacha).   Will that work in all cases for constructed
> AEAD modes?  (e.g. where we build an AEAD mode out of an encryption mode
> and an integrity mode and derive the E and I keys from a single key
> internal to the constructed mode - say  AES-CBC with CMAC for example).
> Short answer is probably not.
>
> Basically, this complete eliminates the ability to use CBC (or any cipher
> mode that requires an explicit per message IV) from TLS.  Not arguing for
> or against this at this point, but not clear that everyone understands the
> side effects of this decision.
>

As discussed at the interim, I don't believe that this is correct. See
AGL's message
for a proposed construction.

-Ekr



Mike
>
>
>
> On 3/16/2015 7:54 PM, Eric Rescorla wrote:
>
>  PR: https://github.com/tlswg/tls13-spec/pull/155
>  Target merge date: 3/21
>
>  Currently:
>
>  - AES-GCM uses a partially explicit nonce
> - The ChaCha20 draft uses the sequence number as the nonce.
>
>  As Stephen Kent has observed, the idea behind the explicit IV is to
> allow the
> cryptographic module implementing the AEAD algorithm to ensure non-reuse
> of the nonce. However, for ChaCha I believe we came to the conclusion that
> it
> was acceptable to use the sequence number as the nonce, as the module can
> check for sequential usage. This saves 8 octets on the wire.
>
>  In the interim in Seattle, we came to the conclusion that we should make
> all AEAD algorithms behave this way, which also simplifies the spec some.
> I've formatted this into a PR to verify the consensus on the list. Please
> comment
> here if you object and on the PR if you have editorial comments.
>
>  https://github.com/tlswg/tls13-spec/pull/155
>
>  -Ekr
>
>
>
> _______________________________________________
> TLS mailing [e-mail]://www.ietf.org/mailman/listinfo/tls
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>