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

["Blumenthal, Uri" <uri at ll.mit.edu>]

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

IMHO the assumption is that there aren’t going to be many TLS implementations – just like there weren’t many IPsec implementations. 

Those who do find the need (and financial resources :-) to re-implement TLS (as opposed to application writers that usually – always? - take existing reference implementations) are likely to know enough to implement GCM the right way (which isn’t so hard after all).

I don’t expect “IT professionals” going off re-implementing TLS, not any more than re-implementing Linux or Windows.

Regarding SIV – let it live like other AEAD modes, with GCM having the advantage among them of being already recognized and deployed.

On 1/16/08 12:57 PM, "Dan Harkins" <dharkins at lounge.org> wrote:

>   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 at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls


-- 
Regards,
Uri




_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls