Re: [TLS] [Cfrg] 3DES diediedie

Hubert Kario <hkario@redhat.com> Mon, 29 August 2016 12:00 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747BB12D0B7 for <tls@ietfa.amsl.com>; Mon, 29 Aug 2016 05:00:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.47
X-Spam-Level:
X-Spam-Status: No, score=-7.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 pdJ_b_apgvyd for <tls@ietfa.amsl.com>; Mon, 29 Aug 2016 05:00:45 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C5612D729 for <tls@ietf.org>; Mon, 29 Aug 2016 05:00:43 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 30485A0771; Mon, 29 Aug 2016 12:00:42 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7TC0eVS014926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Aug 2016 08:00:41 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 29 Aug 2016 14:00:39 +0200
Message-ID: <2123223.JzJ8ujFHJJ@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.7-300.fc24.x86_64; KDE/5.25.0; x86_64; ; )
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D053AB@uxcn10-5.UoA.auckland.ac.nz>
References: <CAHOTMV+r5PVxqnSozYyqJqq_YocMKV06aAa-43t+5Huzh7Lo=A@mail.gmail.com> <b2fb4b70-7b65-2d6c-2073-c9db8d86f608@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73F4D053AB@uxcn10-5.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2215477.aiTK73ayqa"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 29 Aug 2016 12:00:43 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PDFpe97VAHShq8etWqKIJiz-HhY>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, "David McGrew \(mcgrew\)" <mcgrew@cisco.com>
Subject: Re: [TLS] [Cfrg] 3DES diediedie
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Aug 2016 12:00:46 -0000

On Sunday, 28 August 2016 13:55:47 CEST Peter Gutmann wrote:
> Stephen Farrell <stephen.farrell@cs.tcd.ie> 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".

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
 
> >>(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".

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

-- 
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