Re: [Cfrg] [TLS] 3DES diediedie
Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 07 September 2016 00:56 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C0F12B012 for <cfrg@ietfa.amsl.com>; Tue, 6 Sep 2016 17:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.808
X-Spam-Level:
X-Spam-Status: No, score=-5.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9JJgh2IttwP for <cfrg@ietfa.amsl.com>; Tue, 6 Sep 2016 17:56:33 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903A712B280 for <cfrg@irtf.org>; Tue, 6 Sep 2016 17:56:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0BA6CBEE6; Wed, 7 Sep 2016 01:41:11 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxpS3Up8Vemy; Wed, 7 Sep 2016 01:41:06 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F3007178001; Wed, 7 Sep 2016 01:40:16 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1473208817; bh=AasPo2RShzmRbmYMTMuBmOZbUMoyq7Mzb5F+z7BqqxI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=SxGg1iJgFSE1W8QUdCgOa3LtxXVPQZFNt1xboS5cKKCSoqFP05owHwsU7NL8NLjcy cvyL9QVvlkTEXym9eHd7stKLC4xhGTHb1W6ylXiWH9B1msW1U1d1fIoMQDpNXt9bUa Yv1kidQHpd0CdLr3FtTWYsbQ4rSCCXxvJY6IkGZY=
To: Ira McDonald <blueroofmusic@gmail.com>, Watson Ladd <watsonbladd@gmail.com>
References: <20160906114030.18292816.41703.89024@ll.mit.edu> <57CEAE6F.1040608@secworks.se> <sjmeg4wvjut.fsf@securerf.ihtfp.org> <d1b84ec2-5b02-b285-8304-e3b393d9ee4a@cs.tcd.ie> <CAN40gSv3dOENg_fh-4OFgJ72UFNNX9rr=v2HtoiNaLDMwh21NA@mail.gmail.com> <CACsn0c=ZPKFV06m4haSU_iGfRFF_tj8jwEmpJeXJJwA+kaMN_A@mail.gmail.com> <CAN40gSsjzfYwK4tUJmdxXA6NnFVpfDDe9KdV3xyBDcPwv9+7xw@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <fe218a2c-ff81-3d5f-e856-2ff89b5e03fe@cs.tcd.ie>
Date: Wed, 07 Sep 2016 01:40:16 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAN40gSsjzfYwK4tUJmdxXA6NnFVpfDDe9KdV3xyBDcPwv9+7xw@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms090703060301060301010605"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/Ofwh5NiGiWh_uldSvjjNaWrEeYs>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, Joachim Strömbergson <joachim@secworks.se>, Hilarie Orman <hilarie@purplestreak.com>
Subject: Re: [Cfrg] [TLS] 3DES diediedie
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Sep 2016 00:56:37 -0000
Hiya, On 07/09/16 00:54, Ira McDonald wrote: > Hi Watson, > > I wasn't arguing (and NIST isn't) for small blocksizes. > > I was just trying to suggest that the common IETF/IRTF perception > that vertical industry demand for "lightweight cryptography" will just > go away is naive. It may also be unwise (though perhaps not naive) to assume that developing a radically new technology is quicker than just waiting until current-good stuff is sufficiently easy and cheap to choose. Yes, I know the arguments against that, but I also recall WAP - that is an existence proof that quite large sections of industry can convince themselves of things that just won't pan out, and never were going to - in that case it took so long to develop the supposedly new thing that the not-new thing (IP) was entirely usable before they got done. Maybe it's an inherent part of such failures to be less well remembered;-) > A lot of governments around the world and a lot > of ITU-T and ISO projects are predicated on the availability of one > or more "lightweight cryptography" algorithms. Sure. And there's also a bunch of "5G requirements" that call for breaches to the laws of physics in some network near you in 2020. Just because a bunch of folks claim that they want/need 1ms RTTs does not mean that can happen. > > It would be a good thing if cryptographers active in IETF/IRTF lists > would engage with these projects and use their expertise to point > out issues in specific algorithms. Document a specific algorithm then, including its design criteria and full documentation. Though I do hope we don't end up spending loads of time thinking about algorithms designed by organisations with a history of trying to promote dodgy crypto. (*) Personally, I think the approach of specifying crypto based on device capability is broken. What ought (but won't) be done is to map device capability to the sensitivity of the application and to decide to use or not use that device for that application. Even though the launch/don't-launch decision for a missile is very simple, I would argue that using the cheapest CPU for that is just wrong and bad design. I'd also argue that engineers who choose to design things that they know are insufficiently secure are doing the equivalent of designing a bridge that will fall down in normal use. I'd call both unethical, no matter that they may produce bigger short-term profit. I also think that the former just seems less unethical because we don't yet have enough history of dealing with these things well, but that will change. I would really not like to be the person who in 20 years has to admit to having designed some of the small-device crap that's now being deployed and that expects to still be used in 20 years. S. (*) Yes, I mean simon and speck and nsa. I don't necessarily include nist on that naughty-list. There is and totally should be a durable and significant price to pay for dual-ec. > > 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: blueroofmusic@gmail.com > Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 > May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > On Tue, Sep 6, 2016 at 7:44 PM, Watson Ladd <watsonbladd@gmail.com> wrote: > >> On Tue, Sep 6, 2016 at 4:36 PM, Ira McDonald <blueroofmusic@gmail.com> >> wrote: >>> Hi, >>> >>> I'm usually immediately corrected. >>> >>> But I wanted to observe that, after my recent years working in the >>> auto security area, there are extreme cost constraints (and power >>> constraints) on CPUs in small sensors and smaller auto ECUs. >>> >>> Cents matter. Dollars are out-of-the-question. >>> >>> Auto product development and ISO26262 safety validation cycles >>> mean that today's new project will be fielded in three to five years. >>> >>> FWIW, US NIST is sufficiently concerned about their perception of >>> the need for lightweight crypto to have created a Lightweight Crypto >>> project that will select multiple algorithms based on an open process. >>> They are currently building on previous work in ITU-T and ISO. They >>> recently issued this draft report (in public review until October 31st): >>> >>> http://csrc.nist.gov/publications/drafts/nistir- >> 8114/nistir_8114_draft.pdf >>> >>> One could argue "well then they won't use TLS", which may be true, >>> but's it's a dangerous path IMHO. >> >> This doesn't make the security issues with small blocksizes vanish. In >> particular we've addressed the issue in TLS 1.3 with key rotation >> mechanisms and lifetime limits. >> >>> >>> 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: blueroofmusic@gmail.com >>> Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 >>> May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 >>> >>> >>> On Tue, Sep 6, 2016 at 5:23 PM, Stephen Farrell < >> stephen.farrell@cs.tcd.ie> >>> wrote: >>>> >>>> >>>> Hi Derek, >>>> >>>> On 06/09/16 21:44, Derek Atkins wrote: >>>>> I'm afraid I have to disagree here. What's it's done is pushed >>>>> yesterday's computation capabilities into smaller and smaller devices, >>>>> lower and lower on the food chain. C.f. my previous email about a >> light >>>>> bulb. Cost is definitely a concern, as well as power and performance. >>>> >>>> I think that's true but not the entire story. >>>> >>>> Another part of the trade off is that any device that >>>> connects to the Internet and runs s/w is potentially >>>> vulnerable and usable to attack the network. >>>> >>>> So we're not only talking about security/crypto to >>>> protect someone's choice of what colour a bulb appears, >>>> but rather we're very often talking about the protection >>>> of a small computer on the network, and of the security >>>> of the network as a whole. >>>> >>>> That last I think argues strongly for support for >>>> sufficiently good crypto everywhere. And I'm not sure >>>> what sufficiently good options exist that are notably >>>> lighter weight than AES. (And if one does support good >>>> crypto then there seems less reason to use less good >>>> crypto for some functions.) >>>> >>>> Note that I'm arguing against weaker crypto or crypto >>>> of unknown or possibly-problematic provenance here. So >>>> I'm not arguing for HW-AES-everywhere. But it is also >>>> true that AES-everywhere would avoid this significant >>>> problem. >>>> >>>> That said, I do realise that this is not a winning >>>> argument as people will develop feature-rich devices >>>> with crap security and there's no device-police to stop >>>> them, but we (as in cfrg) should really also bear in >>>> mind that any weaker crypto anywhere has significant >>>> downsides as many devices really do need what we currently >>>> consider strong crypto because they connect to the >>>> Internet and may not get any updated s/w for quite some >>>> time. >>>> >>>> So... it's tricky - I think we know what's right but we >>>> also know that that's not what "the market" is going >>>> to produce;-) >>>> >>>> S. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Cfrg mailing list >>>> Cfrg@irtf.org >>>> https://www.irtf.org/mailman/listinfo/cfrg >>>> >>> >>> >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/cfrg >>> >> >> >> >> -- >> "Man is born free, but everywhere he is in chains". >> --Rousseau. >> >
- Re: [Cfrg] [TLS] 3DES diediedie Viktor Dukhovni
- [Cfrg] 3DES diediedie Tony Arcieri
- Re: [Cfrg] 3DES diediedie Benjamin Kaduk
- Re: [Cfrg] 3DES diediedie Tony Arcieri
- Re: [Cfrg] 3DES diediedie Tony Arcieri
- Re: [Cfrg] [TLS] 3DES diediedie Stephen Farrell
- Re: [Cfrg] [TLS] 3DES diediedie Tony Arcieri
- Re: [Cfrg] [TLS] 3DES diediedie Peter Gutmann
- Re: [Cfrg] [TLS] 3DES diediedie Tony Arcieri
- Re: [Cfrg] [TLS] 3DES diediedie John Mattsson
- Re: [Cfrg] [TLS] 3DES diediedie Stephen Farrell
- Re: [Cfrg] [TLS] 3DES diediedie Hubert Kario
- Re: [Cfrg] [TLS] 3DES diediedie david wong
- Re: [Cfrg] [TLS] 3DES diediedie Eric Rescorla
- Re: [Cfrg] [TLS] 3DES diediedie Ira McDonald
- Re: [Cfrg] [TLS] 3DES diediedie Hubert Kario
- Re: [Cfrg] [TLS] 3DES diediedie Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] [SSH] [TLS] 3DES diediedie denis bider (Bitvise)
- Re: [Cfrg] 3DES diediedie Geoffrey Keating
- Re: [Cfrg] [SSH] [TLS] 3DES diediedie Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] [SSH] [TLS] 3DES diediedie David Jacobson
- Re: [Cfrg] [TLS] 3DES diediedie Dmitry Belyavsky
- Re: [Cfrg] [TLS] 3DES diediedie Stanislav V. Smyshlyaev
- Re: [Cfrg] [TLS] 3DES diediedie Hanno Böck
- Re: [Cfrg] [TLS] 3DES diediedie Иван Лавриков
- Re: [Cfrg] 3DES diediedie David McGrew (mcgrew)
- Re: [Cfrg] [TLS] 3DES diediedie Watson Ladd
- Re: [Cfrg] [TLS] 3DES diediedie Peter Gutmann
- Re: [Cfrg] 3DES diediedie Peter Gutmann
- Re: [Cfrg] 3DES diediedie David McGrew (mcgrew)
- Re: [Cfrg] [TLS] 3DES diediedie Karthikeyan Bhargavan
- Re: [Cfrg] 3DES diediedie Peter Gutmann
- Re: [Cfrg] [TLS] 3DES diediedie Peter Gutmann
- Re: [Cfrg] [TLS] 3DES diediedie Stephen Farrell
- Re: [Cfrg] [TLS] 3DES diediedie Peter Gutmann
- Re: [Cfrg] [TLS] 3DES diediedie Hubert Kario
- Re: [Cfrg] 3DES diediedie David McGrew (mcgrew)
- Re: [Cfrg] [TLS] 3DES diediedie Joachim Strömbergson
- Re: [Cfrg] 3DES diediedie John Mattsson
- [Cfrg] (confusing the issues) Re: [TLS] 3DES died… Rene Struik
- Re: [Cfrg] 3DES diediedie Ilari Liusvaara
- Re: [Cfrg] [TLS] (confusing the issues) Re: 3DES … Dave Garrett
- Re: [Cfrg] 3DES diediedie Jon Callas
- Re: [Cfrg] (confusing the issues) Re: [TLS] 3DES … Jon Callas
- Re: [Cfrg] 3DES diediedie Steven M. Bellovin
- Re: [Cfrg] (confusing the issues) Re: [TLS] 3DES … Rene Struik
- Re: [Cfrg] (confusing the issues) Re: [TLS] 3DES … Greg Rose
- Re: [Cfrg] 3DES diediedie Peter Gutmann
- Re: [Cfrg] 3DES diediedie Peter Gutmann
- Re: [Cfrg] 3DES diediedie David McGrew (mcgrew)
- Re: [Cfrg] 3DES diediedie Peter Gutmann
- Re: [Cfrg] [TLS] 3DES diediedie Derek Atkins
- Re: [Cfrg] 3DES diediedie Derek Atkins
- Re: [Cfrg] 3DES diediedie Hilarie Orman
- Re: [Cfrg] [TLS] 3DES diediedie Brian Sniffen
- Re: [Cfrg] [TLS] 3DES diediedie Hilarie Orman
- Re: [Cfrg] 3DES diediedie Steven M. Bellovin
- Re: [Cfrg] [TLS] 3DES diediedie Joachim Strömbergson
- Re: [Cfrg] [TLS] 3DES diediedie Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] [TLS] 3DES diediedie Hilarie Orman
- Re: [Cfrg] [TLS] 3DES diediedie Joachim Strömbergson
- Re: [Cfrg] [TLS] 3DES diediedie Kyle Rose
- Re: [Cfrg] [TLS] 3DES diediedie Richard Hartmann
- Re: [Cfrg] 3DES diediedie Derek Atkins
- Re: [Cfrg] [TLS] 3DES diediedie Hilarie Orman
- Re: [Cfrg] [TLS] 3DES diediedie Ben Laurie
- Re: [Cfrg] [TLS] 3DES diediedie Ben Laurie
- Re: [Cfrg] [TLS] 3DES diediedie Joachim Strömbergson
- Re: [Cfrg] [TLS] 3DES diediedie Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] [TLS] 3DES diediedie Joachim Strömbergson
- Re: [Cfrg] [TLS] 3DES diediedie Derek Atkins
- Re: [Cfrg] [TLS] 3DES diediedie Derek Atkins
- Re: [Cfrg] [TLS] 3DES diediedie Stephen Farrell
- Re: [Cfrg] [TLS] 3DES diediedie Salz, Rich
- Re: [Cfrg] [TLS] 3DES diediedie Ira McDonald
- Re: [Cfrg] [TLS] 3DES diediedie Watson Ladd
- Re: [Cfrg] [TLS] 3DES diediedie Ira McDonald
- Re: [Cfrg] [TLS] 3DES diediedie Dave Garrett
- Re: [Cfrg] [TLS] 3DES diediedie Ira McDonald
- Re: [Cfrg] [TLS] 3DES diediedie Philip Levis
- Re: [Cfrg] [TLS] 3DES diediedie Stephen Farrell
- Re: [Cfrg] [TLS] 3DES diediedie Tony Arcieri
- Re: [Cfrg] [TLS] 3DES diediedie Peter Gutmann
- Re: [Cfrg] [TLS] 3DES diediedie Joachim Strömbergson
- Re: [Cfrg] [TLS] 3DES diediedie Ilari Liusvaara
- Re: [Cfrg] [TLS] 3DES diediedie Joachim Strömbergson
- Re: [Cfrg] [TLS] 3DES diediedie Stephen Farrell
- Re: [Cfrg] [TLS] 3DES diediedie Ilari Liusvaara
- Re: [Cfrg] [TLS] 3DES diediedie Joachim Strömbergson
- Re: [Cfrg] [TLS] 3DES diediedie Joachim Strömbergson
- Re: [Cfrg] [TLS] 3DES diediedie Richard Hartmann
- Re: [Cfrg] [TLS] 3DES diediedie Peter Gutmann
- Re: [Cfrg] [TLS] 3DES diediedie Peter Gutmann
- Re: [Cfrg] [TLS] 3DES diediedie Salz, Rich
- Re: [Cfrg] [TLS] 3DES diediedie Derek Atkins
- Re: [Cfrg] [TLS] 3DES diediedie Tony Arcieri
- Re: [Cfrg] [TLS] 3DES diediedie Peter Gutmann
- Re: [Cfrg] [TLS] 3DES diediedie Stephen Farrell
- Re: [Cfrg] [TLS] 3DES diediedie Derek Atkins
- Re: [Cfrg] [TLS] 3DES diediedie Derek Atkins
- Re: [Cfrg] [TLS] 3DES diediedie Derek Atkins
- Re: [Cfrg] [TLS] 3DES diediedie Kyle Rose
- Re: [Cfrg] [TLS] 3DES diediedie Tony Arcieri
- Re: [Cfrg] [TLS] 3DES diediedie Ilari Liusvaara
- Re: [Cfrg] [TLS] 3DES diediedie Yoav Nir
- Re: [Cfrg] [TLS] 3DES diediedie Kyle Rose
- Re: [Cfrg] [TLS] 3DES diediedie denis bider (Bitvise)