Re: [TLS] [Cfrg] 3DES diediedie

On Thu, Sep 8, 2016 at 12:46 PM, Yoav Nir wrote: > > Good questions, no doubt. But I don’t think they can be answered. > > Someone is going to specify protocols and algorithms. This could be the > IETF. This could be the ITU, or IEEE, or some other SDO. Makes no >

Re: [TLS] [Cfrg] 3DES diediedie

> On 8 Sep 2016, at 7:08 PM, Kyle Rose wrote: > > On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann > wrote: > The only data point I have is that every time I've tried to disable DES in > a new release (and by DES I

Re: [TLS] [Cfrg] 3DES diediedie

On Thu, Sep 8, 2016 at 8:01 AM, Derek Atkins wrote: > So they are finally up to 80-bit security? Woohoo! > That makes me feel so safe. > 1024-bit RSA is certainly less than ideal, but certainly better than nothing, which was the claim about devices in this class. Comparisons

Re: [TLS] [Cfrg] 3DES diediedie

On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann wrote: > The only data point I have is that every time I've tried to disable DES in > a new release (and by DES I mean single DES, not 3DES) I've had a chorus of > complaints about it vanishing. ... > Alarms, for

Re: [TLS] [Cfrg] 3DES diediedie

Peter Gutmann writes: > Richard Hartmann writes: > >>Is it correct when I say that the embedded programmers you talked to don't >>care about any form of DES as they need/must/prefer to do AES, anyway? > > The only data point I have is

Re: [TLS] [Cfrg] 3DES diediedie

Tony Arcieri writes: > On Tue, Sep 6, 2016 at 9:15 PM, Peter Gutmann > wrote: > > When crypto hardware support is available, it's universally AES, > occasionally > SHA-1 and/or DES, and very rarely RSA and/or DH and/or ECDSA  > > EMV

Re: [TLS] [Cfrg] 3DES diediedie

Richard Hartmann writes: >Is it correct when I say that the embedded programmers you talked to don't >care about any form of DES as they need/must/prefer to do AES, anyway? The only data point I have is that every time I've tried to disable DES in a new release

Re: [TLS] [Cfrg] 3DES diediedie

On Tue, Sep 6, 2016 at 9:15 PM, Peter Gutmann wrote: > When crypto hardware support is available, it's universally AES, > occasionally > SHA-1 and/or DES, and very rarely RSA and/or DH and/or ECDSA EMV chip cards support RSA digital signatures. Granted earlier EMV

Re: [TLS] [Cfrg] 3DES diediedie

Perhaps a way forward here is for someone to document a target platform. Or multiple target platforms, and decide which are in-scope and out of scope for us to look at. Arguing by anecdote -- this lightbulb has this 10-cent part, that car has this ARM supercore with gigs of memory -- just

Re: [TLS] [Cfrg] 3DES diediedie

Ilari Liusvaara writes: >The TLS-style asymmetric designs don't come even close to cutting it if >client lacks good entropy source. Actually they're fine, see the comment about using entropy from both sides. You can run one side of a TLS communication with zero entropy

Re: [TLS] [Cfrg] 3DES diediedie

On Wed, Sep 7, 2016 at 6:15 AM, Peter Gutmann wrote: > [a lot of really interesting stuff] Thanks for the write-up. To focus what you wrote back on the thread at hand: Is it correct when I say that the embedded programmers you talked to don't care about any form of

Re: [TLS] [Cfrg] 3DES diediedie

On Wed, Sep 07, 2016 at 04:15:05AM +, Peter Gutmann wrote: > Firmware is never updated, and frequently *can* never be updated. This is > typically because it's not writeable, or there's no room (the code already > occupies 120% of available storage, brought down to 100% by replacing the >

Re: [TLS] [Cfrg] 3DES diediedie

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! Derek Atkins wrote: > Because this is a light bulb that sells for $6-10. Adding $2 to the > price is just completely unreasonable. The price point needs to be > pennies. Note that this is just one example, but yes, these level of >

Re: [TLS] [Cfrg] 3DES diediedie

OK, so I said I'd get some notes on the environment within which IoT crypto has to function, here's what the peanut gallery came up with. A lot of this isn't my own work and I don't claim it to be, it's a collaboration created by people who for various business/legal reasons can't attach their

Re: [TLS] [Cfrg] 3DES diediedie

The market is moving to ARM Cortex Ms, in part because of their clean I/O architecture and good SoC support. An M0 with integrated BLE chipset is easily <1$ today at small scale. Extrapolate a few years and to volume of millions between large companies rather than small startups. Software like

Re: [TLS] [Cfrg] 3DES diediedie

Hi Dave, Might work for lightbulbs. Doesn't work for automotive sensors and ECUs, which already have proprietary security (undisclosed algorithms) and badly need to have standards-based security. Cents in cost really matter here. ARM CPUs are not and will not become the only answer in

Re: [TLS] [Cfrg] 3DES diediedie

On Tuesday, September 06, 2016 04:40:30 pm Derek Atkins wrote: > Ben Laurie writes: > > An ARM is far too much hardware to throw at "read sensor/munge data/send > > data". > > > > The question is not "how much hardware?" but "price?" - with ARMs > > including h > > /w

Re: [TLS] [Cfrg] 3DES diediedie

Ben Laurie writes: > An ARM is far too much hardware to throw at "read sensor/munge data/send > data". > > The question is not "how much hardware?" but "price?" - with  ARMs including h > /w AES coming in at $2 for a single unit, its hard to explain why you\d want > to

Re: [TLS] [Cfrg] 3DES diediedie

> On 31 August 2016 at 20:48, Hilarie Orman wrote: > > > From: Brian Sniffen > > > > > >> From: Derek Atkins > > > >> Date: Wed, 31 Aug 2016 10:17:25 -0400 > > > > > > > >> "Steven M. Bellovin"

Re: [TLS] [Cfrg] 3DES diediedie

"Steven M. Bellovin" writes: > On 31 Aug 2016, at 10:17, Derek Atkins wrote: > >> "Steven M. Bellovin" writes: >> >>> Yes. To a large extent, the "IoT devices are too puny for real >>> crypto" is a hangover from several years ago. It was once true;

Re: [TLS] [Cfrg] 3DES diediedie

On Mon, Aug 29, 2016 at 5:00 AM, Hubert Kario wrote: > > we have enough problems weeding out implementation mistakes in TLS, we > don't > need yet another protocol and two dozen implementations that come with it > Strongly agreed. Focusing energy on getting "something"

Re: [TLS] [Cfrg] 3DES diediedie

joac...@secworks.se writes: > Aloha! Aloha auinala. > Hilarie Orman wrote: > > An ARM is far too much hardware to throw at "read sensor/munge > > data/send data". > No, they are not. The Cortex M0+ is aimed at these kinds of very simple > systems that runs for many years on a single

Re: [TLS] [Cfrg] 3DES diediedie

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! Hilarie Orman wrote: > An ARM is far too much hardware to throw at "read sensor/munge > data/send data". No, they are not. The Cortex M0+ is aimed at these kinds of very simple systems that runs for many years on a single battery. Look at

Re: [TLS] [Cfrg] 3DES diediedie

On Wed, August 31, 2016 3:48 pm, Hilarie Orman wrote: > > An ARM is far too much hardware to throw at "read sensor/munge data/send > data". What about an 8051? > Hilarie -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com

Re: [TLS] [Cfrg] 3DES diediedie

> From: Brian Sniffen > >> From: Derek Atkins > >> Date: Wed, 31 Aug 2016 10:17:25 -0400 > > > >> "Steven M. Bellovin" writes: > > > >> > Yes. To a large extent, the "IoT devices are too puny for real > >> > crypto" is a

Re: [TLS] [Cfrg] 3DES diediedie

Hilarie Orman writes: >> From: Derek Atkins >> Date: Wed, 31 Aug 2016 10:17:25 -0400 > >> "Steven M. Bellovin" writes: > >> > Yes. To a large extent, the "IoT devices are too puny for real >> > crypto" is a hangover from

Re: [TLS] [Cfrg] 3DES diediedie

> From: Derek Atkins > Date: Wed, 31 Aug 2016 10:17:25 -0400 > "Steven M. Bellovin" writes: > > Yes. To a large extent, the "IoT devices are too puny for real > > crypto" is a hangover from several years ago. It was once true; for > > the most

Re: [TLS] [Cfrg] 3DES diediedie

"Steven M. Bellovin" writes: > Yes. To a large extent, the "IoT devices are too puny for real > crypto" is a hangover from several years ago. It was once true; for > the most part, it isn't today, but people haven't flushed their cache > from the old received wisdom. This

Re: [TLS] [Cfrg] 3DES diediedie

David McGrew (mcgrew) writes: >That’s great, facts leaven a debate. Yeah, but they also make it really boring, sigh. *Opinions*, now those are fun... Peter. ___ TLS mailing list TLS@ietf.org

Re: [TLS] [Cfrg] 3DES diediedie

Hi Peter, On 8/30/16, 5:41 AM, "Peter Gutmann" wrote: >David McGrew (mcgrew) writes: > >>See for instance slides 8 and 9 of Daniel Shumow's talk at NIST’s LWC >>workshop last year:

Re: [TLS] [Cfrg] 3DES diediedie

Jon Callas writes: >Current cryptographic standards work for IoT That's only if you use the circular argument that IoT is defined to be whatever can run DTLS (or whatever you take as "current cryptographic standards", the slides mention DTLS). An yeah, I can then define my IoT

Re: [TLS] [Cfrg] 3DES diediedie

David McGrew (mcgrew) writes: >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 So looking at slide 6 from that, the first four systems he lists are

Re: [TLS] [Cfrg] 3DES diediedie

On 29 Aug 2016, at 17:46, Jon Callas wrote: On Aug 29, 2016, at 5:44 AM, 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

Re: [TLS] [Cfrg] 3DES diediedie

On Mon, Aug 29, 2016 at 12:44:42PM +, David McGrew (mcgrew) wrote: > > 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. Yes, the variability of

Re: [TLS] [Cfrg] 3DES diediedie

Hi David and Peter, I think Daniels presentation is a good summary and I tend to agree with the “No lightweight cryptography in software”. But how relevant is lightweight cryptography in IoT hardware? I been hearing some hardware people stating that the number of gates is more and more irrelevant

Re: [TLS] [Cfrg] 3DES diediedie

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:

Re: [TLS] [Cfrg] 3DES diediedie

On Sunday, 28 August 2016 13:55:47 CEST Peter Gutmann wrote: > Stephen Farrell writes: > >IIRC the IoT marketing term doesn't have a very long history so I don't > >really know what substance lies behind that remark. > > I just used "IoT" because someone else had used

Re: [TLS] [Cfrg] 3DES diediedie

Stephen Farrell writes: >IIRC the IoT marketing term doesn't have a very long history so I don't >really know what substance lies behind that remark. I just used "IoT" because someone else had used it, since it's about as well- defined as "Web 2.0" I agree that it's

Re: [TLS] [Cfrg] 3DES diediedie

Peter, On 28/08/16 13:01, Peter Gutmann wrote: > David McGrew (mcgrew) 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

Re: [TLS] [Cfrg] 3DES diediedie

Karthikeyan Bhargavan writes: >If every message IoT device sends is a 16 bytes message consisting of one 8 >byte secret and one 8 byte known plaintext, then with a 64-bit cipher, we >only need roughly 64GB in order to get a meaningful collision (50% chance of

Re: [TLS] [Cfrg] 3DES diediedie

David McGrew (mcgrew) 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

Re: [TLS] [Cfrg] 3DES diediedie

> Looking at it from the other side, your typical IoT device will be sending, > for example, a 12-byte message every 15 minutes, meaning it'll take, if my > calculations are right, just under two million years to collect the 785GB of > data required to perform the attack. I agree that it would be

Re: [TLS] [Cfrg] 3DES diediedie

Hi Tony, Thanks for bringing this up; an RFC deprecating and/or discouraging 3DES would be a good thing. The only good reason to use it is backwards compatibility, and too many applications don’t heed the birthday bound. There is another issue to be considered, though. Most of the

Re: [TLS] [Cfrg] 3DES diediedie

On Thursday, 25 August 2016 09:55:10 CEST Ira McDonald wrote: > Hi, > > This survey of TLS in 1 million web servers shows that 93% support 3DES - > oof! > > https://jve.linuxwall.info/blog/index.php?post/TLS_Survey > > 3DES hasn't quite disappeared on the Internet. but less than 0.5% will

Re: [TLS] [Cfrg] 3DES diediedie

Hi, This survey of TLS in 1 million web servers shows that 93% support 3DES - oof! https://jve.linuxwall.info/blog/index.php?post/TLS_Survey 3DES hasn't quite disappeared on the Internet. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG

Re: [TLS] [Cfrg] 3DES diediedie

On Thu, Aug 25, 2016 at 6:21 AM, david wong wrote: > I don't think a RFC deprecating them is a good idea: > > * TLS 1.3 is almost here and is already doing that > * what browser still use 64-bit ciphers? Who lets his "old" browser open > for 75 hours? > Actually, I

Re: [TLS] [Cfrg] 3DES diediedie

I don't think a RFC deprecating them is a good idea: * TLS 1.3 is almost here and is already doing that * what browser still use 64-bit ciphers? Who lets his "old" browser open for 75 hours? * in other uses of TLS. It's not always obvious if there is a possible beast style attacks. And their

Re: [TLS] [Cfrg] 3DES diediedie

On Wednesday, 24 August 2016 22:59:23 CEST Viktor Dukhovni wrote: > I am not opposed to a "diediedie" RFC, if that is likely to be helpful. > For TLS, this ciphersuite is already comparatively rare, and perhaps its > disappearance will not be sped up by a "diediedie" RFC? Would an RFC > help to

Re: [TLS] [Cfrg] 3DES diediedie

> On Aug 24, 2016, at 10:34 PM, Tony Arcieri wrote: > > I am particularly interested in 3DES's usage in TLS, given its previous MTI > status in TLS, and because it was until very recently included in the OpenSSL > "DEFAULT" ciphersuite list. For the record, it is only

Re: [TLS] [Cfrg] 3DES diediedie

On Wed, Aug 24, 2016 at 7:41 PM, Stephen Farrell wrote: > On 25/08/16 03:34, Tony Arcieri wrote: > I guess there's sometimes value in those die-die-die RFCs. Given that > we have RFC7525/BCP195 [1] that already has a SHOULD NOT for effective > key sizes less than 128

Re: [TLS] [Cfrg] 3DES diediedie

It appears 3DES is not supported in TLS 1.3. I would still support a "diediedie" RFC banning its use in previous versions of TLS, despite its previous MTI status. On Wed, Aug 24, 2016 at 7:34 PM, Tony Arcieri wrote: > On Wed, Aug 24, 2016 at 7:31 PM, Benjamin Kaduk

Re: [TLS] [Cfrg] 3DES diediedie

On Wed, Aug 24, 2016 at 7:31 PM, Benjamin Kaduk wrote: > Well, there is > https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00 > but it is not really what you are looking for, I think, given the > recipient list on the message. I am particularly interested