Re: [TLS] Non-TLS opportunistic encryption

Tom Ritter <> Mon, 21 July 2014 17:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 20F091A026E for <>; Mon, 21 Jul 2014 10:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.779
X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TWPbC_NHcldK for <>; Mon, 21 Jul 2014 10:18:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A3081A02E5 for <>; Mon, 21 Jul 2014 10:18:02 -0700 (PDT)
Received: by with SMTP id hq11so11199249vcb.16 for <>; Mon, 21 Jul 2014 10:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YcwmOpj6Cr7pLIk6BYq0qoxPspfbtZP+x8UCCgJukbo=; b=sCknBuXzeNoYp7PjoXsCC/AthMLO9db0OOQr9ijakMEs/JfnaFoQkZqU5aYNg8ORsH tJfbsCFg/r1fioL6ySKGWTreblUkbIkrHsUhkDpFCummK3g8x+TQNKF8ih3Qa6oT06FD CNTMD1r6TbJfvdzLl3NUYKSFfY1au7HgHF33U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YcwmOpj6Cr7pLIk6BYq0qoxPspfbtZP+x8UCCgJukbo=; b=LXP+GyramtzgSxCrC67HXJ3gKp6WjDejUiZiHosb16ILjgRPzlQKq9P6Nknaty9iK9 sYGsUPE6nMHuM7u1Bt1ssQGYZpUWSGigkWwy62PnHcpoFuzOjZZ1A1GMDuqdo5smVN0S biPde0IQIBVmZ4b3ZsxmGaIsx8aemUYKKn49naHGBdL94xFfaMazhTmbig4i/h3IJDoo bzh7Y29Qr/HUJVUdsGV8wR3gvHku9jcEqS9ldtVsoNWCHFN4qBB8sIuKKJJSYvAwNxi6 HFtLpA6+AG3CVgIwTIcUaajJ6P1rW5bTFgpFKnhEvH8I+q2LWiernRgKDEZK8tYS8bUu I/6Q==
X-Gm-Message-State: ALoCoQkKLRjIevDn6ZZj41wMdYg1WZD1BUtuG0vURqGsxLlRvCz196EJSs7ejmI3yx7LhH/o/ihB
X-Received: by with SMTP id u2mr3448469vdy.84.1405963080772; Mon, 21 Jul 2014 10:18:00 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 21 Jul 2014 10:17:40 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Tom Ritter <>
Date: Mon, 21 Jul 2014 12:17:40 -0500
Message-ID: <>
To: Phillip Hallam-Baker <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "" <>
Subject: Re: [TLS] Non-TLS opportunistic encryption
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, 21 Jul 2014 17:18:03 -0000

On 19 July 2014 11:28, Phillip Hallam-Baker <> wrote:
> 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.

It's not clear to me exactly what you mean by 'weakening regular TLS'
- I'd also disagree that opportunistic encryption should get any of
the UI indicators that TLS gets.

I'm not sure if Opportunistic TLS is still on-topic for this list, but
the primary concern I've seen people put forward (and agree with)
about Unauthenticated Ciphersuites or a DH handshake is that with
self-signed certs - you can build a Convergence-style in-line
authenticity system or a CT-style after-the-fact detection system on
top of it.

With the other options, you lose that capability.  And if you try and
shoe-horn a long-lived signing key on top of that, you've reinvented
some subset of TLS+PKIX - why not just use that subset and not require
any (significant) server code changes.