RE: [TLS] Re: SIV as WG item?

["Dan Harkins" <dharkins@xxxxxxxxxx>]

  Yes, they are all about "cryptographic hygiene". Notice how the
fact that the key is "fresh" is only one of the considerations in
SP 800-38D? The fact that TLS produces "fresh" keys does not, by
itself, mean that it is secure or complies with requirements listed
in SP 800-38D. That is necessary but in no way is it sufficient.

  You may think that there is some other aspect to TLS that makes it
unique so that it can only be implemented in a way that precludes any
of the problems that the SP 800-38D addresses. Only I don't agree.

  Dan.

On Wed, January 16, 2008 1:26 am, Pasi.Eronen@xxxxxxxxx wrote:
> Dan Harkins wrote:
>
>>   It is also important to look at section 9.1 regarding design
>> consideration. For instance the module responsible for construction
>> of the nonce must be inside the FIPS140 cryptographic boundary.
>> And in the case of power loss of an entity implementing GCM, "for
>> [the TLS GCM ciphersuite] all of the deterministic elements that are
>> necessary to construct the IV would have to be available when the
>> power is restored. For example, these elements could be stored in
>> non-volatile memory."
>
> This storage requirement applies only to implementations that
> also store (or are in some way able to recover or reuse) the key
> itself.
>
> (Section 9.1, "If the generation unit cannot recover from a loss of
> power, then the authenticated encryption function shall enter a
> failure state until a fresh key can be established.")
>
>>   There are also operational considerations in section 9.2 that lists
>> questions that must be answered when deploying a GCM implementation.
>> It states, "Compliance with the uniqueness requirement on IVs, and
>> hence THE SECURITY OF GCM, ultimately DEPENDS ON THE IT PROFESSIONAL
>> WHO CONFIGURES, DEPLOYS, AND MAINTAINS THE GCM MODULESS within a
>> particular system." (emphasis mine and I apologize for screaming).
>>
>>   So yes, defer to NIST. If you read SP 800-38D and are satisfied
>> that all of the relevant requirements are adhered to then GCM is
>> secure. If you don't feel it's possible to guarantee that all of
>> those requirements can be met or if you don't feel comfortable
>> placing the security of the system in the hands of "the IT
>> professional" who configures it then maybe it's not for you.
>
> As far as I can tell, all (or almost all) of these considerations
> are about ensuring proper IV generation and other "cryptographic
> hygiene" to ensure one given key doesn't end up being used in
> different contexts (e.g. across power loss, with different GCM
> mode options, etc.). With complications such as system backups,
> this will ultimately depend on the IT administration procedures
> as well.
>
> Those concerns don't really seem to apply to protocols that
> always establish fresh keys, and during that key establishment,
> agree on how the key will be used.
>
> Best regards,
> Pasi
>




_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls