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

"Blumenthal, Uri - 0553 - MITLL" <> Wed, 19 July 2017 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7423F13167D for <>; Wed, 19 Jul 2017 09:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3Q7fd8Xn0QL1 for <>; Wed, 19 Jul 2017 09:26:51 -0700 (PDT)
Received: from (LLMX2.LL.MIT.EDU []) by (Postfix) with ESMTP id C14A1131472 for <>; Wed, 19 Jul 2017 09:26:50 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id v6JGQmBM006779; Wed, 19 Jul 2017 12:26:48 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= <>
CC: "" <>, Watson Ladd <>
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS/ulwkltwWiCLAkez9/LKtukmkaJYpiSAgAAE/ICAAtZXgIAAGYoA//++zoA=
Date: Wed, 19 Jul 2017 16:26:47 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/f.23.0.170610
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3583312007_1490358185"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707190270
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: Wed, 19 Jul 2017 16:26:53 -0000

You said you need to look at packets to see unauthorized access. How do you that access is unauthorized unless the authorization system is doing the monitoring?


Over the years I've met with businesses who have these kinds of set ups. The way it usually works is that the analysis is secondary and based on a suspicion of some kind. For example: if an employee is suspected of insider trading, or stealing proprietary data, then the administrators may take the extreme measure of inspecting all of their traffic. This is why many corporate environments have those "No expectation of privacy" disclaimers.


Another example is where traffic to a set of suspicious destinations is subject to a higher level of scrutiny. For example, maybe traffic bound for well known file sharing services. 


This all is fairly obvious. The question is when do you start recording (and therefore examining) the traffic.


I've never seen an environment with pervasive always-on monitoring; creating a trove of plaintext would be a net security negative, and organizations rarely have the resources it would take to keep or analyze all of it anyway.  


Same question. At some point in time you need to decide to start examining all the traffic. At that point you can start capturing its plaintext. The proposed alternative seems to be capturing the ciphertext and the key so the ciphertext can be decrypted later – which makes no sense to me.



They are, though it's a big change. I think we can do better than logs; a mechanism that's in TLS itself could be opt-in and user-aware, and so less likely to be abused in other situations. There's also some basic security model advantages to encrypting the PMS under a public-private key pair, and one that isn't using the private key that the servers themselves hold. 


To use the key you need to have the corresponding ciphertext stored. It is worse time- and space-wise than storing the plaintext (encrypted under the authorities’ key). You seem to have proved that capturing the plaintext from the originating (or receiving – whatever end you own) end-point and encrypting/storing it is much better option than sending ciphertext and leaking its keys (or reusing static keys for the same purpose).