Re: [TLS] Industry Concerns about TLS 1.3

Yoav Nir <> Wed, 28 September 2016 17:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F90D12B2BA for <>; Wed, 28 Sep 2016 10:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UC13reYecLKe for <>; Wed, 28 Sep 2016 10:51:29 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1411E12B2B1 for <>; Wed, 28 Sep 2016 10:51:29 -0700 (PDT)
Received: by with SMTP id l132so84305578wmf.1 for <>; Wed, 28 Sep 2016 10:51:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=TruxnojhVZcGDXsIVUgYNUN7eUPcMFilzFOSKS4DC6I=; b=bEcFY07huM6dv3eOL8I0+U1XJ8NsmZdidCbqz856dYW8dK8rixB0jA0nIY+a/vEp8i BUrLXfiVZW5qGWThN4qedRVibbLolerqL2wlRRJVIdvkcs9iyQzeXzLwZJVSFCgFcQ/h tHrcIqgKzCDJd/taOVNnU4hpVZh2J9K9pcqgWA3kiGUywagEDVT/If+FS1zCylfLiwvs LEtro8zCOSagMNvjjNZhPkGBhiJwY/YWpmQ2rR+/ZJ4KTKuL/khXvFpw7ClSZ825pc+6 m8xhkyw1C4dzQpb3IDUPaYmQLb/z1UPaaR7eafBS5TIr8v2jAsAlfONNpFQ6odp5Xiel fgng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TruxnojhVZcGDXsIVUgYNUN7eUPcMFilzFOSKS4DC6I=; b=jfxjOWweHqvqcwLUr7BIKQnyr+YpCWJRTpe2LLi1Zkf42EFMI4Zc5i09wycC8N2DQv Npqct6v38G8psTXnPtca8d0z9v5cA175xJ6yJJHJw06c6nimgkkpkvTdFPuV3sjwT5sa 6sx42egwkvZGEZuDKYjjcInJw9rnDrN1PwCwXCiAf/fuf9pMmomGi7YmlM9oKwQeaubp Ub4c1NGfh0VLFkN45P3DmgtIPBX3DCoxaqAht/JikT6o4eOYdfc8YTgC4L7Xkb/KAS4Z IyU7KtX40CvABdB/Je8AprvN5WH/XeVjIfFJnLmI518tnClivI69wg+i0gqQW1eEkUvm Sj7Q==
X-Gm-Message-State: AA6/9Rn6FfiZHFXCNL5wf2sMrmTxd9mZGlWxTjaIJLfpglsCXQK4QjgWtb/EmdTDGeW2jQ==
X-Received: by with SMTP id z6mr9670418wmc.125.1475085087529; Wed, 28 Sep 2016 10:51:27 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id vx7sm5220873wjc.1.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 28 Sep 2016 10:51:26 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F948D0E9-554F-49B9-BE94-783E0F947713"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Wed, 28 Sep 2016 20:51:25 +0300
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Dan Brown <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "" <>
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 17:51:31 -0000

> On 28 Sep 2016, at 7:16 PM, Dan Brown <> wrote:
> As I understand the concern, the worry is that Bud is compromising Bob's (TLS) server, to somehow send Bob's plaintext to the wrong place.
> The proposed (existing?) strategy has Bob compromising his own forward-secrecy to stop Bud, but only after the cat is out of the bag. This seems a high price (no forward-secrecy) to pay for little gain (cat-out-of-bag).
> It seems wiser for Bob to somehow monitor or log what is being done with his own plaintexts at his own server. I know little about existing products to do this, but from my theoretical perspective, it ought to be easier than compromising forward-secrecy (logging ciphertexts).
> If proper plaintext monitoring or logging is somehow too costly, then yes...

I don’t really understand under what circumstances logging, monitoring or storing the plaintext is not feasible, while storing the ciphertext is. Because if you don’t store the ciphertext, then keeping static or ephemeral keys around doesn’t buy you much.  It’s true that current server products don’t log or store the plaintext, but they could easily be modified to do that. There are extensions to browsers that store the plaintext if you want.

Maybe if the good folks at the Bluffdale facility are willing to let you download their copy of your captured ciphertexts, then it makes sense to store only ephemeral or static keys. Otherwise it seems cheaper to store the plaintext than to store both ciphertext and keys.