IETF Logo Mail Archive

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Mon, 17 July 2017 17:28 UTC

Return-Path: <prvs=837199222b=uri@ll.mit.edu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537501294A2 for <tls@ietfa.amsl.com>; Mon, 17 Jul 2017 10:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjXLdab4kwRq for <tls@ietfa.amsl.com>; Mon, 17 Jul 2017 10:28:08 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 64ECF131B1B for <tls@ietf.org>; Mon, 17 Jul 2017 10:28:07 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6HHS31m039203; Mon, 17 Jul 2017 13:28:03 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Roland Dobbins <rdobbins@arbor.net>
CC: IETF TLS <tls@ietf.org>
Thread-Topic: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
Thread-Index: AQHS/vR5lF141oQzb0GeHnUlNx5L9aJYMXgAgAANgICAAAOcAIAABaaAgAABXQCAAAPqgIAAAY+AgAADO4D//8BIAIAAUI+A///jCgA=
Date: Mon, 17 Jul 2017 17:28:03 +0000
Message-ID: <31C01911-5E2B-4812-B4B5-334C7D212F22@ll.mit.edu>
References: <CABkgnnU8ho7OZpeF=BfEZWYkt1=3ULjny8hcwvp3nnaCBtbbhQ@mail.gmail.com> <2A9492F7-B5C5-49E5-A663-8255C968978D@arbor.net> <CABkgnnX7w0+iH=uV7LRKnsVokVWpCrF1ZpTNhSXsnZaStJw2cQ@mail.gmail.com> <FDDB46BC-876C-49FC-9DAE-05C61BB5EFC9@vigilsec.com> <9C81BE7B-7C21-4504-B60D-96BA95C3D2FD@arbor.net> <CAEa9xj55jzch-v0mysbRSryNM0Y7Bdtevmrc3+FVxMO8EP5zWA@mail.gmail.com> <CC3CE5F8-C8C2-4A70-829D-483E26D20733@arbor.net> <CAEa9xj5eR6b_+CsSDArMWWr-u8hx5B81kDVEMEX8sgfUeMUS8g@mail.gmail.com> <C3B01C35-E3A2-4A8B-9DD7-D6E4153ED39F@arbor.net> <CAEa9xj6p0y9ZzxLJvtv9GDzzfs5s13nnLqm=4_fNDPGV+=Od8Q@mail.gmail.com> <BE4E8E4A-51FC-4211-A16F-EBA8B3F01757@arbor.net> <66C1C32C-53C2-43A4-BCB0-96DDC26A1F58@ll.mit.edu> <69018030-3157-42D4-A573-0E39E46EFAA9@arbor.net>
In-Reply-To: <69018030-3157-42D4-A573-0E39E46EFAA9@arbor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.24.0.170702
x-originating-ip: [172.26.150.37]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3583142882_1919650293"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_14:, , 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-1707170278
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zkniqhATPn6Ct92sDasXA0zxlj0>
Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jul 2017 17:28:11 -0000

    > The standard definition of “traffic analysis” is deducing 
    > information from the metadata and the patterns of communications. It 
    > explicitly does NOT rely on knowing the content of the traffic (which 
    > is assumed to be opaque).
    
    That's what I was trying to get across - that uncovering an unexpected 
    layer of encryption, even without the ability to decrypt it, is very 
    useful in a security context.    Sorry for being unclear!

You were perfectly clear. Apparently I was not clear enough explaining that the likelihood of being able to determine the presence of an unexpected layer of encryption is becoming increasingly slim, as all the bars (no pun intended :) keep rising. 

Organized crime capabilities are reaching the level of nation states, ankle biters reach up to where the organized crime was yesterday… Betting on malefactors to stay silly (send their traffic over TLS that complies with your monitoring, doing the extra work to add super-encryption but forgetting to obfuscate it, etc.) is not a safe or reasonable bet. Certainly not worth it, considering the risks that all the legitimate users will be subjected to by this feature.

v2.23.0 | Report a Bug | By Email