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

"Blumenthal, Uri - 0553 - MITLL" <> Wed, 19 July 2017 17:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B7CA131B54 for <>; Wed, 19 Jul 2017 10:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yLYCqWKArRrP for <>; Wed, 19 Jul 2017 10:15:06 -0700 (PDT)
Received: from (LLMX2.LL.MIT.EDU []) by (Postfix) with ESMTP id 4013A131474 for <>; Wed, 19 Jul 2017 10:15:05 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id v6JHF49m035904 for <>; Wed, 19 Jul 2017 13:15:04 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: "" <>
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS/ulwkltwWiCLAkez9/LKtukmkaJYpiSAgAAE/ICAAtZXgIAAGYoA//++zoCAAEWCAIAABMAA///DOoA=
Date: Wed, 19 Jul 2017 17:15:03 +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_3583314903_2066918823"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_12:, , 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-1707190274
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 17:15:12 -0000

>> That's not what I've seen. Instead, I see administrators creating port mirrors on demand and then
>> filtering the traffic they are interested in using standard tcpdump rules, and I see MITM boxes
>> that selectively decrypt some traffic to look inside it and apply some kind of security filtering.
>> In the former case, DNS lookups and IP/port destinations are commonly used to trigger some suspicions too. 
>  Correct.

Yes I realize all that. That is the “traditional” way.

My point is that if you own/control the endpoint, then it doesn’t matter from the architecture point of view where you tap – and if TLS is not broken (i.e., does not allow you to “selectively decrypt”) you can tap the plaintext at the endpoint. You just need a different set of tools. But considering how today’s endpoints are loaded with tons and tons of “security software”, it seems rather straightforward. 

It’s not like you have an opaque endpoint, and the switch is the only place your visibility starts.
>> That's not how the tcpdump/wireshark approach usually works. You give it the private key and
>> decrypts the TLS connection as it's happening.
>  Correct. 
> Ex-post-facto is insufficient to purpose.  Real-time is the focus.  Archiving is rarely done,
> and is typically just snippets representative of the incident in question. 

Yes. The contention is between being able to decrypt already-encrypted traffic on-demand, and being able to tap the traffic before the encryption (or after the decryption) on-demand.

Your current tools to the first. Evolvement of the technology is pushing you towards the second. Arguing against it IMHO would have as much effect as arguing against exporting strong crypto had decades ago. Or are you simply trying to delay the inevitable?