Re: [TLS] Re: SIV as WG item?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



I've re-read the section in SP 800-38D and all it says is that the same combination of key and IV should never be re-used.

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


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 in
IV 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 deployment
considerations either don't apply ("it's your problem if you misconfigure
it 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 deployment
considerations make you uncomfortable and that a TLS module implementing
GCM 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 at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.