Re: [TLS] Industry Concerns about TLS 1.3

Seth David Schoen <> Wed, 28 September 2016 00:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 397B912B513 for <>; Tue, 27 Sep 2016 17:17:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.319
X-Spam-Status: No, score=-9.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AZOJk2aE4eXe for <>; Tue, 27 Sep 2016 17:17:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CDF3012B030 for <>; Tue, 27 Sep 2016 17:17:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=mail2; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=AKixHekQU1DomtlWnAwPiDZJTMjcSX71j4XxtxHebls=; b=nl8NJx9tfHpiYu36aPK90h69wgsUJq5gHVnKTRqDISTuJmuAyaM5B+KGXnQ/4KXHB81UjNSBAXxmxxMDGe62tzSICUN/Hg1Fv2HqHe0I4ShTfxCCr0NlKN+ilkcKnc3AAFWedB0kpmC78qZ3Tt4bBNzKFVc0Ge5peB+tYaDfnQQ=;
Received: from localhost ([]:53612 helo=demorgan) by with esmtp (Exim 4.80) (envelope-from <>) id 1bp2Yh-0002SC-MY; Tue, 27 Sep 2016 17:17:11 -0700
Date: Tue, 27 Sep 2016 17:17:11 -0700
From: Seth David Schoen <>
To: BITS Security <>, "" <>
Message-ID: <20160928001711.GW25826@demorgan>
References: <> <> <> <20160927183022.GM25826@demorgan>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20160927183022.GM25826@demorgan>
User-Agent: Mutt/1.5.24 (2015-08-30)
Received-SPF: skipped for local relay
Received-SPF: skipped for local relay
Archived-At: <>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Sep 2016 00:17:15 -0000

Seth David Schoen writes:

> This configuration might be a bit dangerous because it means that
> "servers, firewalls, load balancers, Internet proxies, and mainframes"
> would all possess the information needed to decrypt _each other's_
> traffic, so someone inside or outside the organization who can steal
> that information can then read all of the traffic, even traffic that was
> originated by devices they don't know about or have a relationship to.

Existing tools may not support this very well out of the box, but a
somewhat safer technique if you want to decrypt sessions of devices that
you administer would be to have the devices produce their DH parameters
using device-specific or at least organizational unit-specific secrets,
ideally ones that change regularly over time.

People with audit authority can then know all of the secrets, but they
don't have to be known to everyone in the entire organization, and a
device doesn't need to have the information necessary to decrypt all
the prior traffic that it generated.

It's still hard for the audit unit to be confident that it's destroyed all
the copies of old secrets, and the audit unit is still a juicy target for
an attacker who wants to compromise a lot of traffic, but at least there
wouldn't be extremely valuable long-term organization-wide cryptographic
secrets on nearly every device in the organization!

Seth Schoen  <>
Senior Staff Technologist             
Electronic Frontier Foundation        
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107