[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [TLS] Re: SIV as WG item?
In the AES-GCM ciphersuite in TLS the nonce is managed by the TLS
implementations. The segment of "IT professionals" that need to deal
with nonces is not those that deploy systems, rather it is those that
implement the TLS module. It is possible that an implementer may
incorrectly implement a cryptosystem. This is true regardless which
mode is used (GCM,SIV,CBC, etc.)
In addition, as Eric mentioned, while GCM and SIV are both AEAD
ciphersuites, they have different performance characteristics. It is
likely that a user choosing GCM would be unhappy replacing it with SIV.
Cheers,
Joe
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@xxxxxxxxxx]
> Sent: Wednesday, January 16, 2008 9:58 AM
> To: Yoav Nir
> Cc: Simon Josefsson; tls@xxxxxxxx
> Subject: Re: [TLS] Re: SIV as WG item?
>
>
> The GCM ciphersuites for TLS use the deterministic nonce
> construction.
> You can ignore the other one in SP 800-38D. Just pay
> attention to the sections I listed.
>
> Like I said, if you think that GCM cannot be implemented in
> TLS in such a way that it could fall under any of the topics
> SP 800-38D addresses then SIV is not for you.
>
> I, on the other hand, doubt that "IT professionals" on whom
> the security of GCM depends (according to SP 800-38D) will
> understand the nuance around IV management. In fact,
> experience shows that "IT professionals" will routinely cut
> corners with security to make things be more scalable-- group
> pre-shared keys anyone? If all you care about when deploying
> a security system is to merely get your boss off your back
> then the special circumstances surrounding the particular
> module in the system you deploy is not of paramount concern.
>
> But it's fine. If you think that it is impossible to misuse
> your GCM implementation then bully for you. Do you also think
> that it is impossible to misuse _ANY_ TLS implementation of
> GCM? Is there something in TLS that makes SP 800-38D not apply?
>
> Dan.
>
> On Wed, January 16, 2008 1:38 am, Yoav Nir wrote:
> > 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.
> >
> >
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@xxxxxxxxxxxxxx
> https://www1.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls