Re: [TLS] Consensus Call on MTI Algorithms

Daniel Kahn Gillmor <> Mon, 06 April 2015 20:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 438C11A9115 for <>; Mon, 6 Apr 2015 13:08:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8_Irjq0OusSi for <>; Mon, 6 Apr 2015 13:08:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9B9781A9111 for <>; Mon, 6 Apr 2015 13:08:54 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id F4183F984 for <>; Mon, 6 Apr 2015 16:08:51 -0400 (EDT)
Received: by (Postfix, from userid 1000) id 955E320042; Mon, 6 Apr 2015 15:08:50 -0500 (CDT)
From: Daniel Kahn Gillmor <>
In-Reply-To: <>
References: <> <> <20150402194417.GJ10960@localhost> <> <20150402203412.GK10960@localhost> <>
User-Agent: Notmuch/0.18.2 ( Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Mon, 06 Apr 2015 16:08:50 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] Consensus Call on MTI Algorithms
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Apr 2015 20:08:56 -0000

On Fri 2015-04-03 05:14:21 -0400, Peter Gutmann wrote:
> For the other class, those that can run TLS, the reason for running it isn't
> to talk to another device running TLS (you use your homebrew protocol for
> that), it's so they can be controlled via a web interface.  For these devices
> the profile is "whatever we need to implement to talk to a web browser/smart
> phone/web control/AJAX/whatever".  That is the entire device profile.  Since
> the underlying hardware can't handle this, you get approaches like the ones
> I've talked about in the past, 1024-bit keys for everything (perfectly OK for
> embedded device security

While this profile may be "perfectly OK for embedded device security",
once the device is presented to the Internet and to peers like "web
browser/smart phone", there's a pretty nasty UI/UX issue: the browser
and the smartphone normally don't have any idea that they're talking to
a constrained device that doesn't warrant/deserve a high standard of

Put another way: if we make our browsers willing to accept lower
security for our IoT devices, how do we get them to require higher
security for confidential messaging applications or banking transactions
or video chat?

Without a clear UI/UX story to solve this distinction for normal users,
a simple assertion that weaker crypto is "perfectly OK" for some class
of device puts all the rest of the network at risk.