Section 8.2.1 suggests two methods for IV construction: a counter and a LFSR. Both should be easy enough to implement in the cryptographic library so that the IT professional doesn't need to worry about anything. As for keys, that would depend on the IT professional, or at least on getting good entropy for the TLS library, but that is no different for CBC or SIV.
So I'm not sure I understand what problem SIV solves. We could have standards for GCM require either the counter or LFSR, but this can also be just recommended.
On Jan 16, 2008, at 5:25 AM, Dan Harkins wrote:
Hi Yoav, Actually NIST has commented on this, it's SP 800-38D. GCM is not flawed provided you abide by the recommendations in that document. Specifically section 8.2.1 for the deterministic construction of the IV (which is used by the GCM ciphersuites for TLS). Since the nonce construction in draft-ietf-tls-rsa-aes-gcm-01.txt is partially implicit the recommendations in section 8.3 should be interpreted appropriately. 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." 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. Ifyou 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 thesystem in the hands of "the IT professional" who configures it then maybe it's not for you. Now, back to my screaming above for a second. It is this notice in SP 800-38D that really makes the SIV ciphersuites attractive. All of the text in SP 800-38D (approx 8 pages of it) do not apply to SIV because it is secure even in the presence of IV misuse. That is, if the IT professional intentionally or unintentionally misconfigures, misdeploys or improperly maintains a GCM module security is voided but if that module had been a SIV module security would not be voided(assuming, of course, that the misuse by the IT professional results inIV misuse which is the a valid assumption since that's the topic of the quote above). The need for a SIV-based ciphersuites depends on whether you have any discomfort with any of the numerous requirements placed on proper use of GCM. If you think that the design considerations of SP 800-38D are met due to the nature of the TLS protocol and that the deploymentconsiderations either don't apply ("it's your problem if you misconfigureit so tough luck") or are similarly met due to the nature of the TLS protocol then SIV-based ciphersuites are probably not important enough to bring to the WG. If, on the other hand, these design and deploymentconsiderations make you uncomfortable and that a TLS module implementingGCM might be too fragile then a misuse-resistant alternative like SIV becomes important and attractive. regards, Dan.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@xxxxxxxxxxxxxx https://www1.ietf.org/mailman/listinfo/tls