Re: [TLS] (confusing the issues) Re: [Cfrg] 3DES diediedie

[Dave Garrett <[e-mail]>]

Within this line of thought, an unlimited-key-use-diediedie would have far more value. An RFC precisely defining a set of key data limits would address both this 3DES issue as well as AES and any other cipher. As cited on https://sweet32.info/ , data limits is a primary way Mozilla is dealing with this attack.


Dave


On Monday, August 29, 2016 09:26:18 am Rene Struik wrote:
> I think it is a mistake to think that simply using block ciphers with a 
> larger block size is enough to counter attacks, as the literature on 
> successful side channel attacks on such block cipher demonstrates. The 
> real message is that one should not reuse keys ad infinitum, which 
> unfortunately seems hard to sink in.
> 
> Singling out 3-DES in this respect does not seem to tackle the real 
> issue (which is a system security issue often only paid lip service to 
> in practice).
> 
> Rene
> 
> On 8/29/2016 8:56 AM, Joachim Strömbergson wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > Aloha!
> >
> > As a side note, there has been a bunch of lightweight block ciphers
> > suggested the last few years, most of them with a block size of 64 bits.
> > And there has been discussion on IETF maillists about IETF accepting
> > them. For example the SIMON and SPECK ciphers. These ciphers can have
> > block sizes as small as 32 bits.
> >
> > https://www.cryptolux.org/images/a/a0/Beaulieu-DAC2015.pdf
> > https://eprint.iacr.org/2015/209.pdf
> >
> > Yours
> > JoachimS
> >
> >
> >
> > David McGrew (mcgrew) wrote:
> >> Hi Peter,
> >>
> >> You make a bunch of good points.   But it is also worth noting that
> >> some people feel that current crypto standards, including IETF
> >> standards, are suitable for IoT.   See for instance slides 8 and 9 of
> >> Daniel Shumow's talk at NIST’s LWC workshop last year:
> >> http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shumow.pdf
> >> Also, CoAP isn’t on his list, but it could be, and it uses DTLS.   So
> >> while I agree with you that overuse of a 64-bit block cipher is far
> >> from the biggest security concern for IoT, the IETF should expect its
> >> protocols to be used in some IoT scenarios.
> >>
> >> The malleability of the term IoT is causing trouble here.   Slide 6
> >> of Daniel’s talk is quite revealing.  To my thinking, by definition
> >> IoT devices are connected to the Internet in some way.
> >>
> >> David
> >>
> >>
> >>
> >> On 8/28/16, 8:01 AM, "Peter Gutmann" <[e-mail]>
> >> wrote:
> >>
> >>> David McGrew (mcgrew) <[e-mail]> writes:
> >>>
> >>>> I don’t think you understood my point. IoT is about small devices
> >>>> connecting to the Internet, and IETF standards should expect
> >>>> designed-for-IoT crypto to be increasingly in scope.  It is
> >>>> important to not forget about these devices, amidst the current
> >>>> attention being paid to misuses of 64-bit block ciphers, which
> >>>> was the ultimate cause of this mail thread.
> >>> But the IETF has a long history of creating standards that
> >>> completely ignore IoT.  I can't think of a single general-purpose
> >>> IETF security standard (TLS, SSH, IPsec, etc) that has any hope of
> >>> working with IoT devices (say a 40Mhz ARM-core ASIC with 32kB RAM
> >>> and 64kB flash).  This is why the ITU/IEC and a million
> >>> lesser-known standards bodies are all busy inventing their own
> >>> exquisitely homebrew crypto protocols, most of which make WEP look
> >>> like a model of good design.
> >>>
> >>> (I've always wanted to sit down and design a generic "encrypted
> >>> pipe from A to B using minimal resources" spec, and I'm sure many
> >>> other people have had the same thought at one time or another).
> >>>
> >>> So it seems like you've got:
> >>>
> >>> - The "TLS = the web" crowd (browser vendors and the like) who will
> >>> implement whatever's trendy at the moment and assume everyone has a
> >>> quad-core 2GHz CPU with gigabytes of RAM and access to weekly live
> >>> updates and hotfixes.
> >>>
> >>> - Embedded/SCADA folks who need to deal with 10-15 year product
> >>> cycles (see my TLS-LTS draft for more on this) and are kind of
> >>> stuck.
> >>>
> >>> - IoT people, who can't use any standard protocol and will get the
> >>> least unqualified person on staff to invent something that seems OK
> >>> to them.
> >>>
> >>> I'm not sure that a draft on theoretical weaknesses in 64-bit block
> >>> ciphers is going to affect any of those...