[TLS] Non-TLS opportunistic encryption

Phillip Hallam-Baker <phill@hallambaker.com> Sat, 19 July 2014 16:28 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5A4BD1B28D0 for <tls@ietfa.amsl.com>; Sat, 19 Jul 2014 09:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lsOS6Nzv6L4f for <tls@ietfa.amsl.com>; Sat, 19 Jul 2014 09:28:58 -0700 (PDT)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29EE81B28C1 for <tls@ietf.org>; Sat, 19 Jul 2014 09:28:58 -0700 (PDT)
Received: by mail-we0-f176.google.com with SMTP id q58so5816550wes.7 for <tls@ietf.org>; Sat, 19 Jul 2014 09:28:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=weEL9o6UMyJAytivpy75UwDGEgMb94zvGpsETA7pjNg=; b=PZ627409U22M50uxymYe8gpVPgrR+wpru0TIsSrFw0aEOf3zzA/TKgZKELrcaoTAsu vHvX1DlPW74IPhph7XW5ZIX21p9tB+lMau1BL6cHBiH6a4q8jR+n+HO5W5RhFtO5PC69 vU+18t4HMbvf4pKMQp6+6u3QUNLLCyumLNi3bJkbYrp0lSnaKW3W7Rh524qrTmbNAg/f 4Co13gPnegdtZWRbmVG9RSqEmOy5PxxWkZhWDNxkMIvvK9J8slDq7982hOtjHw+OWI6g 09RK16y1fkR++XSzNUSGd69j24qo65AkZdnO6AJDMQ0+EtZ8Ufezt4jd2bwiS9Iqm6lV z24w==
MIME-Version: 1.0
X-Received: by with SMTP id wx2mr6371288wjb.107.1405787336601; Sat, 19 Jul 2014 09:28:56 -0700 (PDT)
Sender: hallam@gmail.com
Received: by with HTTP; Sat, 19 Jul 2014 09:28:56 -0700 (PDT)
Date: Sat, 19 Jul 2014 12:28:56 -0400
X-Google-Sender-Auth: HrB6dfjxTHr_bhEo44V4lc08e5Q
Message-ID: <CAMm+LwjYE2ZffBTX7=VYR9mvRFcr_vqBNucY2fx8N4opjMZ_Tg@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Bf0x0ip6vdWgxrEK67h08uGzZ_U
X-Mailman-Approved-At: Mon, 21 Jul 2014 09:51:52 -0700
Subject: [TLS] Non-TLS opportunistic encryption
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Sat, 19 Jul 2014 16:28:59 -0000

While at the Hope conference watching the 'HTTP must die' presentation
I had an idea that might or might not be useful.

People frequently propose use of opportunistic TLS with self-signed
credentials. This worries me for two reasons:

1) TLS is a huge standard with a lot of details that have to be got
right. It takes a lot of time and effort to implement and a lot of
memory to run. Constrained devices are going to find it very hard to
do TLS

2) One consequence of (1) is that opportunistic TLS risks weakening
the https infrastructure rather than improving the http
infrastructure. That is not a win as far as I am concerned.

So one proposal that is made is to drop the padlock icon when
non-credentialed self-signed certs or keys passed in band are in use.
This seems a very good approach to me but we still have the problem of
it being a 'thick stack'.

This is even more problematic when we consider the fact that most of
that 'thick stack' is actually involved in addressing issues that just
don't apply if we are not going to validate the end-entity-keys.

Self-signed certs are a reasonable way to exchange keys in a world
where the infrastructure has ubiquitous support for X.509 path math.
But why clutter up the client with the path math if we are not going
to check cert chains?

If we are going to insist on 'encryption everywhere' and accept
opportunistic encryption then all we need is a D-H key agreement and
some mechanism for applying encryption to packets.

The result might be TLS-Lite, a very minimal subset of TLS or it might
be a completely different protocol. But the key thing would be to keep
it separate from TLS so that ubiquitous best effort TLS does not end
up weakening regular TLS.