Subject: [TLS] 3DES diediedie

From: Tony Arcieri <[email-masked]>
Date: Wed, 24 Aug 2016 19:08:02 -0700

This attack was published today[*]:

https://sweet32.info/

I bring it up because I think the threat model is similar to the threats
that lead to RC4 "diediedie"

https://www.rfc-editor.org/info/rfc7465

Should there be a 3DES "diediedie"?

I believe 3DES is MTI for TLS 1.0/1.1(?) but I think it would make sense
for it to be banned from TLS 1.3.

[*] Lest anyone claim the contrary, I am not surprised by this attack, and
have pushed to have 3DES removed from TLS prior to the publication of this
attack, and can probably find a TLS implementer who can back me up on that.

-- 
Tony Arcieri

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 24 Aug 2016 22:31:49 -0400 (EDT)

> Should there be a 3DES "diediedie"?

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.

-Ben

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 24 Aug 2016 19:34:10 -0700

> recipient list on the message.

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.

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 24 Aug 2016 19:36:01 -0700

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 <[email-masked]> 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

-- 
Tony Arcieri

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Aug 2016 03:41:02 +0100

> https://sweet32.info/

Nice work.

> OpenSSL "DEFAULT" ciphersuite list.

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 bits, one could argue that the IETF has covered
that to a reasonable extent, in terms of RFCs saying to not do that.

But, if there was general support for such a draft, I'd be fine with
figuring out how to help get it done.

Cheers,
S.

[1] https://tools.ietf.org/html/rfc7525

> 
> 
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 24 Aug 2016 19:44:57 -0700

> that to a reasonable extent, in terms of RFCs saying to not do that.

Yes, aside from the 64-bit block size the the 112-bit (or sometimes
108-bit) key sizes are also notable for 3DES

-- 
Tony Arcieri

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 24 Aug 2016 22:59:23 -0400

> On Aug 24, 2016, at 10:34 PM, Tony Arcieri <[email-masked]> 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 removed from the "DEFAULT" ciphersuite list in
tomorrow's (US/Eastern, today already for folks in Europe) 1.1.0 release.

In the 1.0.x releases it will change from "HIGH" to "MEDIUM", but remains
in "DEFAULT".  Users who elect just "HIGH" ciphers will not use 3DES, but
those who go with "DEFAULT" or explicitly include "MEDIUM" will generally
continue to enable 3DES as a low preference ciphersuite.

https://www.openssl.org/blog/blog/2016/08/24/sweet32/

My personal take is quoted in:

http://arstechnica.com/security/2016/08/new-attack-can-pluck-secrets-from-1-of-https-traffic-affects-top-sites/

   "We're not making a fuss about the 3DES issue, and rating it 'LOW',"
   Dukhovni wrote. "The 3DES issue is of little practical consequence at
   this time. It is just a matter of good hygiene to start saying goodbye
   to 3DES."

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 prod vendors into action more than the already published findings?
Would our collective energies be better focused on other, more pressing
goals?

-- 
	Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 25 Aug 2016 03:28:03 +0000

>Should there be a 3DES "diediedie"?

Only if there's an actualy issue.  3DES is still very widely supported 
(particularly in financial systems and embedded), and provides a useful
backup to AES.  An attack that recovers cookie if you can record 785GB
of traffic isn't anything I'm losing any sleep over.

Peter.

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 24 Aug 2016 20:37:47 -0700

On Wed, Aug 24, 2016 at 8:28 PM, Peter Gutmann <[email-masked]>
wrote:

> (particularly in financial systems and embedded)

As someone who works professionally in the payments industry alongside
people who are directly implementing EMV protocols, let me note: those are
not IETF protocols and should not have bearing on IETF/IRTF decisions
regarding deprecations of protocols in TLS or other IETF protocols. But I'm
mainly concerned with TLS...

and provides a useful backup to AES.

So does ChaCha20.

>   An attack that recovers cookie if you can record 785GB of traffic isn't
> anything I'm losing any sleep over.

..but is not a terribly dissimilar traffic volume to recover plaintexts
from similar attacks against RC4, which received "diediedie" in RFC7465.

Perhaps notable is the RC4 attacks work across multiple session keys,
whereas SWEET32 requires the same key, but I think the practical
consequences regarding data volume limits are similar.

-- 
Tony Arcieri

---

From: Hubert Kario <[email-masked]>
Date: Thu, 25 Aug 2016 12:32:56 +0200

> Would our collective energies be better focused on other, more pressing

People that care for support of Windows XP or Windows 2003 will use 3DES 
either way. People that don't care about those OSes, are probably already 
doing everything to not negotiate it, if only to conserve TLS terminator 
resources.

When RC4 die-die-die was published, a lot of servers negotiated RC4 (because 
of BEAST), it's not the case with 3DES.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: david wong <[email-masked]>
Date: Thu, 25 Aug 2016 08:21:59 -0500

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 implementation might really well not be vulnerable (due to limiting number of messages according to specs)

David

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Aug 2016 06:33:28 -0700

> * what browser still use 64-bit ciphers? Who lets his "old" browser open

Actually, I believe that all the major browsers support 3DES.

-Ekr

* in other uses of TLS. It's not always obvious if there is a possible
> beast style attacks. And their implementation might really well not be
> vulnerable (due to limiting number of messages according to specs)
>
> David
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Ira McDonald <[email-masked]>
Date: Thu, 25 Aug 2016 09:55:10 -0400

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
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434

---

From: Hubert Kario <[email-masked]>
Date: Thu, 25 Aug 2016 15:58:31 +0200

> 3DES hasn't quite disappeared on the Internet.

but less than 0.5% will actually negotiate it, while still between 2% and 3% 
will negotiate RC4:
https://securitypitfalls.wordpress.com/2016/08/07/april-2016-scan-results/

---

From: Geoffrey Keating <[email-masked]>
Date: 25 Aug 2016 16:02:08 -0700

> Should there be a 3DES "diediedie"?

I think so.

> for it to be banned from TLS 1.3.

At least one purpose of such a RFC would be to replace the MTI ciphersuite
with a different ciphersuite.

> attack, and can probably find a TLS implementer who can back me up on that.

The problem has even been described previously on this very mailing list
<https://www.ietf.org/mail-archive/web/tls/current/msg04560.html> (the
original is off here:
<http://lists.links.org/pipermail/mogul-open/2009-November/000069.html>).

---

From: Dmitry Belyavsky <[email-masked]>
Date: Fri, 26 Aug 2016 10:58:37 +0300

Hello all,

Regarding the discussion of the Sweet32 attack, it's worth mentioning that
there is a specification of so called key meshing for the Russian GOST
cipher (which has 64-bit block as well).
Key meshing is a procedure of a predictable change of the current key after
processing an certain amount of data.
It is described in RFC 4357, Section 2.3 (
https://tools.ietf.org/html/rfc4357#section-2.3).

This key meshing defends against any attack that uses a big portion of data
encrypted with the same key.

May be it is useful to specify the similar procedure for modern ciphers too.

-- 
SY, Dmitry Belyavsky

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Fri, 26 Aug 2016 11:04:29 +0300

Dear colleagues!

I'd like to add that the described key meshing procedures (procedures to
increase the lifetime of a key) are proven to be secure (and increasing
security) in case of usage of CTR mode – see preprint at
http://eprint.iacr.org/2016/628.pdf

In case of CBC/CFB modes an additional separate key for key meshing should
be used.

Kindest regards,
Stanislav

2016-08-26 10:58 GMT+03:00 Dmitry Belyavsky <[email-masked]>:

> Key meshing is a procedure of a predictable change of the current key
> after processing an certain amount of data.
> It is described in RFC 4357, Section 2.3 (https://tools.ietf.org/html/
> rfc4357#section-2.3).
>
> This key meshing defends against any attack that uses a big portion of
> data encrypted with the same key.
>
>> [*] Lest anyone claim the contrary, I am not surprised by this attack,
>> and have pushed to have 3DES removed from TLS prior to the publication of
>> this attack, and can probably find a TLS implementer who can back me up on
>> that.
>>
>> --
>> Tony Arcieri
>>

---

From: Hanno Böck <[email-masked]>
Date: Fri, 26 Aug 2016 10:13:04 +0200

On Wed, 24 Aug 2016 19:08:02 -0700

> Should there be a 3DES "diediedie"?

I think a 3des diediedie rfc would be a good idea.

I was wondering yesterday whether I should disable 3des on my servers.
I'd likely exclude a small portion of my visitors for a very small
security gain.

Having a diediedie rfc would indicate that a significant portion of the
net agrees that we want to hard-deprecate 3des. I'd feel more
comfortable disabling it on my servers if I know that a reasonable
number of other servers will do the same thing, because users with a
3des/rc4-only browser will not only see failures on my site, they will
see failures all the time and will be forced to switch.

Forcing them to switch is also probably almost always a good thing.
Even for users who are stuck on Windows XP for whatever reason probably
have better options than sticking to builtin IE - e.g. they can use
Firefox, which is still supporting XP and offers modern ciphers.

Appart from that more operational argument, as far as I can see the
attack scenarios for RC4 and 3DES are in the same ballpark of
complexity. Not very practical, but practical enough to make us feel
uneasy, because we want TLS to provide reasonable protection even
against ulikely scenarios. We decided to deprecate RC4 with an RFC, so
it seems logical to deprecate 3DES as well.

(while we are at it: I'm not sure, do we have any official RFC
deprecating the even older ciphers - Single-DES, RC2 etc. - yet? We
could just stuff that in)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Fri, 26 Aug 2016 17:55:18 +0000

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 lightweight “designed for IoT” block ciphers have a 64 bit block size (and sometimes even smaller); see for instance Table 1.1 of https://eprint.iacr.org/2013/404.pdf     So perhaps what the Internet needs here is sound guidance on how to use 64-bit block ciphers.   Best practices here include both mandatory rekeying well below the birthday bound and/or the use of secure beyond the birthday bound modes of operation such as Iwata’s CENC.

Best,

David

From: Cfrg <[email-masked]<mailto:[email-masked]>> on behalf of Tony Arcieri <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 24, 2016 at 10:08 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Cfrg] 3DES diediedie

https://sweet32.info/

I bring it up because I think the threat model is similar to the threats that lead to RC4 "diediedie"

I believe 3DES is MTI for TLS 1.0/1.1(?) but I think it would make sense for it to be banned from TLS 1.3.

[*] Lest anyone claim the contrary, I am not surprised by this attack, and have pushed to have 3DES removed from TLS prior to the publication of this attack, and can probably find a TLS implementer who can back me up on that.

--
Tony Arcieri

---

From: Watson Ladd <[email-masked]>
Date: Fri, 26 Aug 2016 10:59:44 -0700

On Fri, Aug 26, 2016 at 10:55 AM, David McGrew (mcgrew)
<[email-masked]> wrote:
> 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 lightweight
> “designed for IoT” block ciphers have a 64 bit block size (and sometimes
> even smaller); see for instance Table 1.1 of
> https://eprint.iacr.org/2013/404.pdf     So perhaps what the Internet needs
> here is sound guidance on how to use 64-bit block ciphers.   Best practices
> here include both mandatory rekeying well below the birthday bound and/or
> the use of secure beyond the birthday bound modes of operation such as
> Iwata’s CENC.

Or use PRF instead of PRP for counter mode. I'm happy to check the
arithmetic if we want an RFC for this, but am very overcommitted on
editing right now.

>
> Best,
>
> David
>
> From: Cfrg <[email-masked]> on behalf of Tony Arcieri
> <[email-masked]>
> To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 27 Aug 2016 11:32:34 +0000

Tony Arcieri <[email-masked]> writes:

>As someone who works professionally in the payments industry alongside people
>who are directly implementing EMV protocols, let me note: those are not IETF
>protocols and should not have bearing on IETF/IRTF decisions regarding
>deprecations of protocols in TLS or other IETF protocols. But I'm mainly
>concerned with TLS...

Some of those uses are in TLS...

>So does ChaCha20.

Widely supported on z/OS, Tandem NSK, and HSMs, is it?

(Sorry, couldn't resist.  You know what I mean :-).
 
>..but is not a terribly dissimilar traffic volume to recover plaintexts from
>similar attacks against RC4, which received "diediedie" in RFC7465.

RC4 has serious cryptographic weaknesses, 3DES doesn't.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 27 Aug 2016 12:21:09 +0000

David McGrew (mcgrew) <[email-masked]> writes:

>Most of the lightweight “designed for IoT” block ciphers have a 64 bit block
>size (and sometimes even smaller); see for instance Table 1.1 of
>https://eprint.iacr.org/2013/404.pdf So perhaps what the Internet needs here
>is sound guidance on how to use 64-bit block ciphers.   Best practices here
>include both mandatory rekeying well below the birthday bound and/or the use
>of secure beyond the birthday bound modes of operation such as Iwata’s CENC.

IoT devices are, pretty much by default, insecure.  And I mean, really, really
insecure, I've heard phrases like "hack like it's 199x" a number of times
during talks on all the holes people have found in these things.  In addition,
the reason why devs are using lightweight ciphers in IoT devices is because
they know that their device can't use anything more powerful, in the same way
they they know that a strcpy() into a ten-byte fixed-size buffer is a good way
to decode network packets.

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.

So you've got something where the devices aren't vulnerable to the problem
(and nor, in any practical case, is anything else), for which the devs
involved won't even know that any guidance on the situation exists, and for
which, if anyone really wants to attack them, they can use any of the dozens
of insecure-by-design holes that are present in the device to own the whole
thing, at which point what you do with your crypto becomes meaningless.

So what you're proposing is essentially a non-solution to a non-problem...
still, if you feel like writing the memo for it, don't let me stand in your
way.

Peter.

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Sat, 27 Aug 2016 12:53:08 +0000

Hi Peter,

>thing, at which point what you do with your crypto becomes meaningless.

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.

>still, if you feel like writing the memo for it, don't let me stand in your

Gee, thanks.  

David

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Sat, 27 Aug 2016 12:35:59 -0400

> data required to perform the attack.

I agree that it would be wise to evaluate each deployment scenario to decide
which vulnerabilities have higher priority. But just a brief comment.

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 recovering the secret).
The 768GB value we gave was for recovering cookies from realistic web browser traffic that could be triggered from JavaScript.

It is true that in other TLS use cases (such as IoT) some attacks may no longer be relevant, but unless we are careful
some HTTPS attacks may even be worse in these scenarios.

Best regards,
Karthik

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 28 Aug 2016 12:01:48 +0000

David McGrew (mcgrew) <[email-masked]> 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...

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 28 Aug 2016 12:16:16 +0000

Karthikeyan Bhargavan <[email-masked]> 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
>recovering the secret). The 768GB value we gave was for recovering cookies
>from realistic web browser traffic that could be triggered from JavaScript.

Sure, and I picked the 768GB value because it looks especially unrealistic
:-).  However, for typical SCADA/IoT even a value of 100MB is probably
unrealistic in practice, for the combined reasons that the device just isn't
interesting to attack, it doesn't send enough data to collect lots of it
unless you're prepared to wait a really long time, and, most importantly,
there are a thousand easier ways to get in if you really want to.

Has anyone every seen a SCADA device that stood up to even the smallest amount
of analysis/pen-testing?  I've currently got a rather pricey security
monitoring box sitting here awaiting investigation, and I can pretty much
guarantee I'll find something like unencrypted C&C, calling home to random
addresses overseas, unauthenticated firmware updates, and who knows what else,
just from simple Pineapple or Ettercap check, let alone any kind of active
pen-testing.

So I think it's important to distinguish between a cool demo in the lab and
something an attacker would actually do.  Of all the talks and demos I've seen
of people compromising SCADA and IoT devices, precisely zero even looked at
the crypto, let alone tried to attack it [0].  So if it's something that no-
one bothers attacking because there's always an easier way, it doesn't matter
how strong or weak it is.

As Ian Grigg recently put it:

  The problem we have is not how to get stronger crypto in place, it's how to
  get more crypto in place.

Securing something like MQTT would be a good start...

Peter.

[0] Alongside simply ignoring the fact that crypto may or may not be present,
    I'm also taking things like "fails to check cert issuers" and "allows
    unauthenticated remote firmware updates" as "not looking at the crypto".

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 28 Aug 2016 13:26:07 +0100

Peter,

On 28/08/16 13:01, Peter Gutmann wrote:
> IoT.  

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 can't think of a single general-purpose IETF security standard (TLS,

Then why don't you do that? If others found it useful, then I'm sure
they'd want to use it and there'd be support for it in the IETF. (And
to be clear, I don't think your lts draft for TLS matches the above.)

One wrinkle though is that it seems that there's a real demand for
"encrypted pipe from A to B and hundreds of others using minimal
resources" spec - I'm not sure that the two party version is really
the main missing spec here.

S.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 28 Aug 2016 13:55:47 +0000

Stephen Farrell <[email-masked]> 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 not terribly useful to define a feature
set.  What I meant was low-power embedded, smart meters and the like, IoT in
the sense of "little internet-enabled things".

>>(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).
>
>Then why don't you do that?

It's a bit like designing a new { OS | programming language | network protocol
| ... }, everybody who works in the relevant field would like to have a go at
something like this, and probably have a lot of fun fiddling with it, but I'm
not sure how much appeal it would have to anyone apart from the person playing
with it.  So the answer is "for the same reason I haven't had a go at
designing a new OS, programming language, network protocol, etc".

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 29 Aug 2016 14:00:39 +0200

On Sunday, 28 August 2016 13:55:47 CEST Peter Gutmann wrote:
> 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 not terribly useful to define
> a feature set.  What I meant was low-power embedded, smart meters and the
> like, IoT in the sense of "little internet-enabled things".

while others define it as "anything that is not a general purpose computer, 
tablet or phone", in effect including also SCADA, TVs, ATMs, traffic lights, 
etc.

and for those you need proper encryption
 
> | ... }, everybody who works in the relevant field would like to have a go
> | at
> 
> something like this, and probably have a lot of fun fiddling with it, but
> I'm not sure how much appeal it would have to anyone apart from the person
> playing with it.  So the answer is "for the same reason I haven't had a go
> at designing a new OS, programming language, network protocol, etc".

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

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Mon, 29 Aug 2016 12:44:42 +0000

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

---

From: Joachim Strömbergson <[email-masked]>
Date: Mon, 29 Aug 2016 14:56:34 +0200

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
> 
> 
> 
>>> 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).
>> 
>> - 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...
>> 
>> Peter.
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          [email-masked]
========================================================================

---

From: John Mattsson <[email-masked]>
Date: Mon, 29 Aug 2016 13:20:49 +0000

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 and
that the additional cost of 1000 GE is negligible with current
manufacturing techniques (i.e. 1000 GE is small compared to the are needed
to cut out the circuit and connecting it). We already know that the energy
cost of symmetric  crypto is negligible compared to wireless communication
(this might however change with passive radio).

Would be interesting to hear more input on the relevance of AES- and
SHA-replacements in IoT hardware. Depending on the outcome the CFRG way
forward should be either:

 - Recommendation how to use block ciphers with 64 bit block size
 - Recommendation not to use block ciphers with 64 bit block size

John

On 29/08/16 14:44, "Cfrg on behalf of David McGrew (mcgrew)"
<[email-masked] on behalf of [email-masked]> 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-shu
>mow.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
>
>
>
>>>connecting
>>implement

---

From: Rene Struik <[email-masked]>
Date: Mon, 29 Aug 2016 09:26:18 -0400

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!
>
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBCAAGBQJXxDECAAoJEF3cfFQkIuyNY1UP/2lUJo53s27wlqvgPWpZYWzi
> HViof7jYA7yvbZm9SeYkV88y4sOMUQrhSsAWUZ7GfwcjkjC8+sL8mD7uacPx0zpW
> rAnLnAHJbnU8rkWRT2OKWiZBvwMpMNw/UYGy13dwilRExj22N4dsLK98vath3r52
> FjAIL2GpCWUuzPB6P5d+B8MjEwEr1tEYzvlvWo032RB91irOOKveryGGe5ifnSKj
> SP1a9CbakaLdTHMkrhOre0I4Ckr2A97eI3oo/5QjRJ81zKJ/4VZzOOe3lGjPkXhO
> kzkANctte+Eb5ttlaXcg/dL7lStzaYo8rnm3PRHsBKpHr/oNEgbdJti1U78/MfLf
> o0v+s4TbY7YBPXOU7zKWpo9VD1Mcq9eMAslIQokEE2CfIq3wBSEEgKwJXu6HVSht
> Ohahc7HUBnz2+uXJ+x4hl/bW/qM3DFhTfhPCYQ11IiXpPlxhsAnxbszBe4XtHd7y
> z2Uc+Jef8aUq7sEGYBdcnGs+SSNFQwtUIicKI3pU61xvtAhqRriNOsfmCVvC2V7Z
> iz5EodInPjUBkVMwDbmiFd5lp782SqYZsivwabPGE1p2GG+o421KZmQJ3VRC3ctw
> xjwk2HszIv7Wo+gomL0hqF7Wi0YIP556rRYrRMc9gLV513xzxD5T99eR+2HtiRJF
> TvYYPXZjzP087liGF7SA
> =Z0iM
> -----END PGP SIGNATURE-----
>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 29 Aug 2016 16:38:49 +0300

> IoT devices are connected to the Internet in some way.

Yes, the variability of capabilities of IoT devices is extreme. From
devices that just barely can run some cipher gated to PSK, to ones
that can easily run TLS without any hacks to save resources.

There is no way to make TLS realistically work for the first kind,
since just the flexibility of TLS would impose unreasonable burden,
even if profiled down.

If one limits oneself to the low end, I would think that anything
that can realistically handle any profile of TLS can probably handle
a real symmetric cipher (>=128 blocks, >=128 bit keys).

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Mon, 29 Aug 2016 13:03:45 -0400

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

---

From: Jon Callas <[email-masked]>
Date: Mon, 29 Aug 2016 14:46:47 -0700

> On Aug 29, 2016, at 5:44 AM, David McGrew (mcgrew) <[email-masked]> wrote:
> 
> Hi Peter,
> 

Definitely. But to quote Shumow's talk on Slide 10 (which has the title "IoT Does Not Need Its Own Crypto Standards"):

• Current cryptographic standards work for IoT
	• Current standards are not a limit on IoT performance.
	• Perspective: Common IoT platforms are approximately as 
	  powerful as PCs from 15 years ago when AES was standardized.

And on Slide 11:

• Adding new standards can be problematic:
	• New standards, especially with lower key sizes could be 
	  used in scenarios where they aren’t intended.

	Example: Standardizing ECC over 160bit prime for an RFID
	  card and it ends up being used for https; block cipher
	  with 80bit key space ends up being used to encrypt hard
	  drives.

His conclusion (slide 13) says that we don't need Lightweight Crypto in software, but admits there are some hardware places (like RFID) for it.

And that gets to Peter's basic, good points. While Peter is being brash, his larger point is the same point as Shumow's, that we should just be using our existing toolbox and that even *that* has too many choices. The AllJoyn suite, which is the most stripped down, is brilliantly simple: RSA, ECDSA/ECDHE P256, and AES-CCM. You can quibble with it, but it's to the point. (My quibbles would be to toss RSA and Curve 41417 instead because it has an ARM NEON implementation that's as fast as P-160. But those are quibbles.)

Folding back up to the subject here -- AES is faster than DES. That is one of the reasons it was selected as AES. (So are Twofish and Serpent.) We need to toss all 64-bit block ciphers. They were okay way back in the 1900s. It is no longer then. AES is cheap and getting cheaper. We don't need to patch up any of those old ciphers with meshing or what. We just need to use what's in our toolbox. 3DES needs to go solely because it's a patch on DES that needs to be patched for its small block size. I know it's boring to just use AES, but it meets all the goals.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Mon, 29 Aug 2016 14:48:40 -0700

> On Aug 29, 2016, at 6:26 AM, Rene Struik <[email-masked]> 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).

Yes, we should just stop using 64-bit block ciphers and deal with the issues you mention within the context of larger blocks.

	Jon

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 29 Aug 2016 21:21:38 -0400

On 29 Aug 2016, at 17:46, Jon Callas wrote:

>>   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 
> Definitely. But to quote Shumow's talk on Slide 10 (which has the 
> title "IoT Does Not Need Its Own Crypto Standards"):
>
> His conclusion (slide 13) says that we don't need Lightweight Crypto 
> in software, but admits there are some hardware places (like RFID) for 
> it.
>
> And that gets to Peter's basic, good points. While Peter is being 
> brash, his larger point is the same point as Shumow's, that we should 
> just be using our existing toolbox and that even *that* has too many 
> choices. The AllJoyn suite, which is the most stripped down, is 
> brilliantly simple: RSA, ECDSA/ECDHE P256, and AES-CCM. You can 
> quibble with it, but it's to the point. (My quibbles would be to toss 
> RSA and Curve 41417 instead because it has an ARM NEON implementation 
> that's as fast as P-160. But those are quibbles.)
>
> Folding back up to the subject here -- AES is faster than DES. That is 
> one of the reasons it was selected as AES. (So are Twofish and 
> Serpent.) We need to toss all 64-bit block ciphers. They were okay way 
> back in the 1900s. It is no longer then. AES is cheap and getting 
> cheaper. We don't need to patch up any of those old ciphers with 
> meshing or what. We just need to use what's in our toolbox. 3DES needs 
> to go solely because it's a patch on DES that needs to be patched for 
> its small block size. I know it's boring to just use AES, but it meets 
> all the goals.

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.

It pays to look again at David Wagner's slides from 2005, on sensor nets 
and crypto: https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf

         --Steve Bellovin, https://www.cs.columbia.edu/~smb

---

From: Rene Struik <[email-masked]>
Date: Mon, 29 Aug 2016 21:31:47 -0400

My argument was aimed at focusing on the real topic at hand, not at 
mixing this with "religious" beliefs as ditching ciphers without clear 
justification (no matter how ancient 3-DES may be [I was in elementary 
school then]).

I think it is unwise thinking too lightly about writing IETF drafts with 
"die-die-die" in the title, just because one feels like it, in an almost 
context-free manner. Or, is the idea to launch an entire series of 
die-die-die drafts, because one finds some excuse to do so? I cannot 
deny I also like shiny new things and we may all suffer from 
not-invented-here syndromes, but acknowledging this playing in the 
background of our perceptions should also give us some reason to pause 
and have some restraint here.

Rene

---

From: Greg Rose <[email-masked]>
Date: Mon, 29 Aug 2016 22:15:05 -0700

Rene, thanks for clarifying my thoughts on this. You're right, in one sense, piling on on the bandwagon is often counterproductive. I'm reminded of Dijkstra's article "goto statement considered harmful", in 1968, which was cogent and important, but inspired any number of "XXX considered harmful" statements that weren't ... 

But, if you're writing in C (which I think we mostly shouldn't be any more, but that's a different question), there's no practical alternative to using goto! Check this, then check that, then check the other thing... You can't maintain code that has this as one big "if" statement, and you won't get it right if there are 18 layers of nested "if" statements either.

But back to the original question: In my job I had to continually face the objection that "security [any form] was too expensive to implement". My personal breakthrough was understanding the legal concept of "burden of proof". Was it my job to prove that the security wasn't too expensive? Or was it the (non-security) people's job, in the face of the requirement for security (agreed by management), to prove that it WAS too expensive? I could at least argue that measuring the answer was cheaper than either (a) continuing to argue, or (b) implementing it. Guess what the answer was?

I believe that there's a place for 64-bit block ciphers, still. But I believe that there's a corresponding requirement that the analysis be done, and that provision for re-keying must be engineered in, before they can be used. The alternative, just go to 128-bit blocks, is sometimes cheaper, and sometimes easier, and sometimes both. But no handwaving is required... do the analysis!

Greg.

> On Aug 29, 2016, at 18:31 , Rene Struik <[email-masked]> wrote:
> 
> My argument was aimed at focusing on the real topic at hand, not at mixing this with "religious" beliefs as ditching ciphers without clear justification (no matter how ancient 3-DES may be [I was in elementary school then]).
> 
> I think it is unwise thinking too lightly about writing IETF drafts with "die-die-die" in the title, just because one feels like it, in an almost context-free manner. Or, is the idea to launch an entire series of die-die-die drafts, because one finds some excuse to do so? I cannot deny I also like shiny new things and we may all suffer from not-invented-here syndromes, but acknowledging this playing in the background of our perceptions should also give us some reason to pause and have some restraint here.
> 
> Rene
> 

Phone:  +1 619 890 8236 
GPG/PGP:  1081A37C  232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 30 Aug 2016 09:41:36 +0000

David McGrew (mcgrew) <[email-masked]> writes:

>See for instance slides 8 and 9 of Daniel Shumow's talk at NIST’s LWC
>workshop last year:

So looking at slide 6 from that, the first four systems he lists are desktop
PCs (in all but form factor), it's only the last two that are down at the
resource levels of IoT.  I'm not sure why he picked the Arduinos there because
I wouldn't really consider them terribly representative of IoT devices, was it
to get something that people are familiar with?  Even if you're wanting to
restrict yourself to well-known complete systems I think at least an ESP8266
(80Mhz SoC with 96K RAM, 64K flash, no multiply or divide by default) should
get a mention.

Slide 9 is even further removed from IoT practicality, that stuff may be fine
on the PC-equivalents but won't work on real IoT gear.

I'm currently working with some embedded systems guys to come up with a list
of requirements for IoT crypto (as with the TLS-LTS stuff, various IP/legal
issues means many contributors don't want to say anything in public), I'll
post it to the list when we've finished arguing :-).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 30 Aug 2016 09:50:44 +0000

Jon Callas <[email-masked]> 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 to be
"whatever can't run DTLS" :-).  Stand by for a requirements list coming from a
bunch of IoT/embedded people...

Peter.

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Tue, 30 Aug 2016 11:25:20 +0000

Hi Peter,

>post it to the list when we've finished arguing :-).

That’s great, facts leaven a debate.

thanks

David

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 31 Aug 2016 08:00:10 +0000

>That’s great, facts leaven a debate.

Yeah, but they also make it really boring, sigh.  *Opinions*, now those are
fun...

Peter.

---

From: Derek Atkins <[email-masked]>
Date: Wed, 31 Aug 2016 10:17:25 -0400

"Steven M. Bellovin" <[email-masked]> 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 is certainly true for AES, mostly because many small chips are
including AES accelerators in hardware.  It's not quite true for public
key solutions; there are still very small devices where even ECC takes
too long (and yes, there are cases where 200-400ms is still too long).

> It pays to look again at David Wagner's slides from 2005, on sensor
> nets and crypto:
> https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
>
>

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 31 Aug 2016 22:54:13 -0400

> too long (and yes, there are cases where 200-400ms is still too long).
Certainly plausible.  What I'm saying is (a) don't assert, measure; and
(b) measure again next year because tech keeps improving.

As for your specific points: if AES is indeed feasible, we don't need
new ciphers.  If elliptic curve is too slow, the only answer is architectures
that don't use public key at all; we're not going to find new, cheaper
public key algorithms without a *lot* of effort and the people who can
do that sort of thing are too busy working on post-quantum crypto.

The remaining approach is a cheaper protocol than TLS.  That shouldn't
be hard at all, especially if we're going back to KDCs.