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

[Michael StJohns <[e-mail]>]

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?


In original TLS, the IV produced during session setup was actually not 
"the" IV, but "an" IV used for the first message.  Then McGrew's AEAD 
modes repurposed the IV data produced as a nonce for the AEAD modes.

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).

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.

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 list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls