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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Mon, 17 July 2017 14:04 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 F3EB2131BB0 for <tls@ietfa.amsl.com>; Mon, 17 Jul 2017 07:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cbEF3stY1QjB for <tls@ietfa.amsl.com>; Mon, 17 Jul 2017 07:04:36 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 755B3129482 for <tls@ietf.org>; Mon, 17 Jul 2017 07:04:36 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6HE4ZfX009776 for <tls@ietf.org>; Mon, 17 Jul 2017 10:04:35 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Thread-Index: AQHS9u8cSScAhmTiiEWvrRLNt+JsyqJKs/sAgAkO1QCAAPElgIAAA/YAgAC+XICAABt7AIAAPk+AgAAdB4CAAEOLgIAAN5MAgAAOtwCAAANWAIAAAuSAgAGxDQCAAAyrAIAACXyA///ZAwA=
Date: Mon, 17 Jul 2017 14:04:34 +0000
Message-ID: <DEAC3D06-164E-4A18-AD5A-5B026ADA1E52@ll.mit.edu>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAOjisRxxN9QjCqmDpkBOsEhEc7XCpM9Hk9QSSAO65XDPNegy0w@mail.gmail.com> <CABtrr-XbJMYQ+FTQQiSw2gmDVjnpuhgJb3GTWXvLkNewwuJmUg@mail.gmail.com> <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <CAAF6GDc7e4k5ze3JpS3oOWeixDnyg8CK30iBCEZj-GWzZFv_zg@mail.gmail.com> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <CAAF6GDeSv+T1ww5_nr6NPgg9k44j7y04tJWC=KeaJF7Gtt+TVQ@mail.gmail.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <CAAF6GDeGKEBnUZZFXX0y0a2J2+sVg8VaHh-4H9bhN0Zzk-x9uA@mail.gmail.com> <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie> <35f4c84c6505493d8035c0eaf8bf6047@usma1ex-dag1mb1.msg.corp.akamai.com> <CAAF6GDcq6_ML3yHSQTy-t5irYLS10VVzk_R+7nAUKqQpgcCkrQ@mail.gmail.com> <a22d69c80d8d4cd2981cd6ede394c96f@usma1ex-dag1mb1.msg.corp.akamai.com> <F533492A-ACF1-498F-A03C-B829DDFFDD36@arbor.net> <057af2f23acc450a9b896f9f0c81b06d@usma1ex-dag1mb1.msg.corp.akamai.com> <96E48B74-B718-4F9E-A12E-E43E6A5147AB@arbor.net>
In-Reply-To: <96E48B74-B718-4F9E-A12E-E43E6A5147AB@arbor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.24.0.170702
x-originating-ip: [172.26.150.37]
Content-Type: text/plain; charset="utf-8"
Content-ID: <850C772FEB4F7A4ABA48E6F95E1A259A@ll.mit.edu>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_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-1707170220
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JfALA0FweCqZAtAvy2fUm6AB2x8>
Subject: Re: [TLS] 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 14:04:43 -0000

A higher-level view on this issue.

TLS has been designed as a protocol that allows two entities to communicate securely over a network controlled by an adversary, including abusive authorities.

“But we (the (network) authorities) are the good guys, and we need to break the guarantees TLS provides so we can catch criminals – and here is how we propose to break TLS-1.3”. 

Considering that unless at least one of the end-points chooses to comply with the “rules” it will not work – the claim that this measure is to help the good guys does not sound very candid.

Who is the intended target of this mechanism? What kind of criminals is it supposed to catch/detect? Surely not the malware that penetrated your infrastructure and tries to “call home”?

History shows that criminals violate laws, regulations, and even network protocols (:-) – that’s why they called criminals. Criminals also proved capable of creating quite sophisticated malware. The proponents of the “broken TLS” somehow expect that those criminals would use weakened crypto for the convenience of the network police. How much sense does this make? Experience shows that criminals use not just cutting edge – bleeding edge crypto. For example, consider Confiker. Plus, there are many ways to foil this proposed mechanism – for example, super-encrypting the data before transmission.

Then there’s an issue of the abuses. First, not all of the “legitimate” authorities are “good guys” (all the time :). Second, I’m not aware of any “network security” tool that hasn’t been subverted at some point in time. 

The likely result of the “static-dh-…” proposal is improved mass surveillance by authorities, and exploits of this mechanism by the organized crime.
 
To those who need that surveillance: stay with TLS-1.2. An important goal of TLS-1.3 is preventing the possibility of this surveillance.

To everybody: you can’t have your cake and eat it too. 
Either you have PFS and the bad guys will benefit from it too (so you need to detect and fight them using other methods), or only the bad guys have PFS and you might [0] detect them because their “protection quality” stands out amidst the ocean of the automatically-inspected & censored traffic.


[0] “Might” rather than “would”. Because there are well-known ways of hiding the presence of encryption, at the cost of increase of the ciphertext size. The hope that the encrypted traffic would stand out is unfounded. Considering how fast the attack sophistication is evolving, the likelihood that “they” would employ other countermeasures, but ignore this one is fairly low.
--
Regards,
Uri