Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Ilari Liusvaara <> Sun, 16 July 2017 05:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A867C12700F for <>; Sat, 15 Jul 2017 22:48:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H-tgAal5cjnR for <>; Sat, 15 Jul 2017 22:48:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F30F0120726 for <>; Sat, 15 Jul 2017 22:48:14 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2ACD62280A for <>; Sun, 16 Jul 2017 08:48:12 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id wiYdW9_w7NYv for <>; Sun, 16 Jul 2017 08:48:11 +0300 (EEST)
Received: from LK-Perkele-VII ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D04D421C for <>; Sun, 16 Jul 2017 08:48:10 +0300 (EEST)
Date: Sun, 16 Jul 2017 08:48:10 +0300
From: Ilari Liusvaara <>
Message-ID: <20170716054810.5lyb3butdcvwqsrh@LK-Perkele-VII>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: NeoMutt/20170609 (1.8.3)
Archived-At: <>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-Mailman-Version: 2.1.22
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: Sun, 16 Jul 2017 05:48:17 -0000

On Sun, Jul 16, 2017 at 01:39:17AM +0100, Stephen Farrell wrote:
> On 15/07/17 23:55, Colm MacCárthaigh wrote:
> > So far responses on the mailing list have been saying "Don't use
> > pcap, instead run proxies".
> Sorry, but that is incorrect. Some list participants
> have said "we need pcap" and others have said that
> "no, we do not need to use packet capture." And others,
> myself included, consider that there is dearth of
> evidence.
> The only reason to point that out is that it's one
> amongst a pile of statements from the proponents of
> drafgreen, that make assumptions that are pretty
> clearly counter-factual.

The architetures I have seen proposed, and some quick characteristics
of each (each has its good sides, bad sides and security impacts, minor
or major):

No visibility at all:

- Rely on IoC for malware (can be highly effective in low-background
  networks, high-background networks are a lost cause anyway).
- Debug network by TCP correlation (can be highly effective if issue is
  within networking).
- Application looging for debugging endpoint problems.
- No visibility infrastructure to exploit.

Packet captures with OoB key logging:

- Can have visibility at both sides.
- Can be high data amounts, but pcaps are much larger. Trigger jointly
  to reduce storage.
- Can asymmetrically encrypt the key data (and possibly also transport-
  encrypt for additional layer of security).
- Can give additional very-low-background channel w.r.t. malware.

Packet captures with in-band key logging:

- Can have visibility at both sides.
- Needs opt-in from both sides for server-side logging (client-only
  for client-side logging).
- Asymmetrically encrypts the key data.
- Can't easily use transport-encryption for additional protection.
- Automatically triggers jointly with packet captures.


- Can archive full visibility.
- Potentially heavy processing for lots of connections.
- Central point of attack in well-visible place.
- Required anyway in certain kinds of networks.

DH secret sharing (draft-green type):

- Visibilty on server side only.
- Needs proxies for external connections to avoid static or shared DHs
  from leaking.
- Pull leaves visible central point of attack visible.
- Push has self-vulernabilities.

And then there is major difference between _architecture_ (specify the
parts, requirements on them and analyze the results, without specifying
anything concretely implementable), _framework_ (specify places to
plug parts, but do not specify enough to make it interoperable) and
_protocol_ (specify something that is implementable and interoperable).
The difference between last two is especially large.

If draft-green had been about architecture and did the analysis well
(and had appropriate status for such draft, informational), it would
be much much less controversial than the current one, which is a
_protocol_ and labeled standards-track at that.

My opinion is that if the WG wants to work on "TLS 1.3 visibility", it
should be about various architectures, part requirements thereof and
analysis of results thereof. Good analysis of impacts is a goal
(something desriable to archive), interoperability is an anti-goal
(something _undesirable_ to archive). The WG sure as heck should not
work on interoprerable attack protocol (like one proposed in
draft-green). Of course, such "visibility architectures" document
would be quite a bit of work, especially considering that it would
actually requires analysis, which is much harder than just specifying
something interoperable.

However, I don't care too much if "visibility" architecture work is
done here or not. I do very much care that attack protocol work is
_NOT_ done here, nor anywhere else within IETF (can't do much about
various industry SDOs filled with industry hacks, I am sure there is
plenty of those to go around).