Re: [TLS] Consensus for AEAD IV

[Yoav Nir <[e-mail]>]

> On Apr 27, 2015, at 2:24 AM, Michael StJohns <[e-mail]> wrote:
> 
> On 4/26/2015 6:26 PM, Yoav Nir wrote:
>> Both CCM and GCM use a concatenation of the explicit IV (which is obviously not secret and allowed to be predictable) with a salt that is derived from the keying material. This concatenation forms the nonce which is input to the AEAD.
> 
> Which protocol are we talking about?

I thought it was clear from context that we were talking about how IPsec does it.

> CCM and GCM - as generic functions - use a per message Nonce.  CCM defines a block formatting function (Appendix A of the Nist Document)  that takes a nonce of 1-15 octets.  David Mc Grew's RFC on AEAD functions APIs fixes the length of that nonce to 12 bytes because that's the most common length for GCM.  That per message nonce (back to the generic again) can be created from the combination of a per-session nonce and a sequence number, randomly generated or derived from key material.
> 
> HSMs generally implement the generic interfaces described in the base CCM and GCM documents, and David Mc Grew's RFC on AEAD is a subset of those possibilities and is therefor usable with the generic interfaces.
> 
> 
>> 
>> RFC 4309 (CCM) says "The salt value need not be secret, but it MUST NOT be predictable prior to the beginning of the security association.”
>> RFC 4106 (GCM) says "The salt SHOULD be unpredictable (i.e., chosen at random) before it is selected, but need not be secret.”
> 
> In IPSEC GCM, the IV is explicitly included in each packet  (see section 3.1 of RFC4106) and hence is not secret in any way shape or form.
> 
> In IPSEC CCM, the IV is also explicitly included in each packet - see section 3 and 3.1 of RFC 4309.  Hence, also never secret in any way shape or form.

The IV is explicit. The nonce is not. In both cases the 96-bit nonce is composed of 32 implicit salt bits and 64 explicit IV bits.

>> The ChaCha20-Poly1305 for IPsec draft does the same thing, and in fact so does RFC 5288 (AES-GCM for TLS 1.2)
> 
> Citing your own draft as proof of your own argument is a bit.... well…

That WG draft is in WGLC now, so it it’s doing something that is wrong, now would be a good time to say why. It’s also doing the exact same thing that IPsec has been doing with AEADs since 4106 and TLS since 5288. All of these combined a 64-bit explicit IV with a 32-bit salt that is derived as part of the keying materials (KEYMAT for IPsec, key_block for TLS) and never ever transmitted.

> In any event, I note that your IPSEC draft doesn't actually describe the ESP payload format, so without that, I'd make the assumption that the IV is included before the payload as is described in the IPSEC ESP document.
> 
>> 
>> So no, that salt (and by extension, the proposed 96-bit value) need not be secret, but it’s never transmitted.
> In which of the above?  Maybe in the chacha20 draft... but not in the other two.
> 
> And RFC5288 does it the wrong way - getting IV (session nonce) material from the same key stream as key material.  That hopefully will be fixed with TLS1.3.  It would have been much more preferable to use a zero session nonce than extract it from the key stream.

You are saying that this is wrong. Why?

>>  This also shows that there is good precedent for generating such a doesn’t-really-need-to-be-secret value from the key_block or KEYMAT.
> 
> I'm pretty sure it doesn't.  It just shows a continuous misunderstanding of the problems with doing it this way.  

And those problems are…?

> There are ways to mitigate this a bit - but they require ensuring complete cryptographic isolation from key generation and a method of non-secret but not disclosed information that can still be used with the generic interfaces.
> 
> There was a good precedence for using RC4 and MD5 because they were fast and in wide use, but we've learned.
> 
> Later, Mike