Re: [TLS] HKDF

[Michael StJohns <[e-mail]>]

On 3/25/2015 10:36 PM, Brian Smith wrote:
> Eric Rescorla <[e-mail]> wrote:
>> On Wed, Mar 25, 2015 at 1:47 PM, Brian Smith <[e-mail]> wrote:
>>> If the IVs are secret (only shared between the two peers) then I don't
>>> see the need to change how they are calculated from the keyblock.
>> The issue is that in many cases the IV will be handled outside the crypto
>> module, and the keys should stay inside the crypto module. The traditional
>> slice and dice makes that hard.
> When the implementation cares about this, won't it also care that the
> nonce/IV is completely managed within the crypto module too?
> Otherwise, for certain things like AES-GCM, the application could
> attack the crypto module reusing a nonce in order to learn the key.

Not exactly.  On the encrypt side, there's a desire that the IV/Nonce be 
produced and controlled by the crypto module, but doing that is actually 
pretty hard given the large number of different ways of forming said 
nonce proposed by different protocols and usages (e.g. compare what TLS 
is doing to what Zigbee or other IOT protocols are doing).

On the decrypt side, you *must* provide the input IV/Nonce as an input - 
it can't be generated internally for the reasons mentioned above and 
there are also issues with lost or ignored (untimely) messages (general 
crypto issue, not typically a TLS one)
> Using the design I suggested in [1] allows the crypto module to
> completely manage the nonce/IV in a way that makes such abuse
> impossible. In fact, with that design, the crypto module doesn't even
> need to tell the application what the nonces/IVs are. And that can
> happen without changing how the nonces are derived from the keyblock.

But doing that requires that the module have yet another TLS specific 
method.

The general contract (going back to probably the first version of PKCS11 
and others) for encrypt/decrypt APIs is a per-message IV. AEAD modes 
such as CCM and GCM are trying to modify that contract to make the 
encrypt dependent on a per-session value concatenated with a per-message 
value (with a counter for the per-block part).  I'm no longer working 
with the PKCS11 folks at Oasis, but a year ago what we were looking at 
was some form of PKCS11 mechanism that might be called an IV generator.  
The set of those mechanisms was not small.


>
> Conversely, if the crypto module *doesn't* work like that, then it
> isn't clear to me that it is actually offering a useful amount of
> protection of the key material. It doesn't seem useful to make things
> more complicated in order to support that kind of design, which seems
> broken.

My personal goal is to be able to build a crypto module that has NO TLS 
specific tweaks - where I can provide as inputs (safely in that doing 
this doesn't adversely affect security) that allow the module do TLS, 
but where doing that or allowing that doesn't prevent the module from 
doing say IPSEC, Zigbee, etc also securely.

Moving to a "standard" KDF is a good start.  Removing the first message 
IV/per-session Nonce generation from the master key expansion is even 
more helpful.

Mike

>
> Cheers,
> Brian
>
> [1] https://www.ietf.org/mail-archive/web/tls/current/msg15573.html
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>