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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Mon, 17 July 2017 18:30 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 2688712ECB7 for <tls@ietfa.amsl.com>; Mon, 17 Jul 2017 11:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 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, URIBL_BLOCKED=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 BQsuRUgKpos2 for <tls@ietfa.amsl.com>; Mon, 17 Jul 2017 11:30:11 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id B317E12EC1D for <tls@ietf.org>; Mon, 17 Jul 2017 11:30:11 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6HIUA2c028071 for <tls@ietf.org>; Mon, 17 Jul 2017 14:30:10 -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///ZAwCAAFOrAP//9omA
Date: Mon, 17 Jul 2017 18:30:09 +0000
Message-ID: <609DCA58-706B-4AA1-AFF6-2DC1D6069BD8@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> <DEAC3D06-164E-4A18-AD5A-5B026ADA1E52@ll.mit.edu> <B675B1F6-FCD3-45A4-9345-0D6597CF801F@arbor.net>
In-Reply-To: <B675B1F6-FCD3-45A4-9345-0D6597CF801F@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_3583146609_428120313"
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-1707170293
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PQCH6hOvBjH7FyMR4KAdfg_fOwM>
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 18:30:15 -0000

On 7/17/2017, 11:04, "Roland Dobbins" <rdobbins@arbor.net> wrote:
    The actual concern of intranet operators is the inadvertent breakage of 
    an important mechanism used for troubleshooting and security in the 
    context of TLS-encrypted traffic on their own networks, within their own 
    span of administrative control.

Something similar was brought up several decades ago, when some agencies expressed concerns that wide-spread availability of encryption would make national security and law enforcement jobs impossible. Thankfully, those fears proved unfounded then. They are likely to prove so now.

    > 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.
    
    To clarify, this technique is for use on intranets, within a single span 
    of administrative control.

“Intranet” is an administrative term, and has no technical meaning. As such, it has no bearing on the protocols.

Not to mention the obvious lack of enforcement mechanisms – how are you going to enforce on the protocol level that “this technique” never crosses the administrative domain?
    
    > 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”?
    
    Actually, it's been used for this very purpose, quite successfully, for 
    many years.  It's also used to detect and classify lateral movement and 
    propagation of malware and attacks within an intranet.

You can’t seriously expect this method of surveillance to stay available forever, as the criminals get smarter and their tool chest gets enriched by exploits from higher-level organizations? 

In any case, there are better mechanisms and tools to address this risk.    

    And it's used to detect and prevent malware downloads by intranet user 
    populations.

There are better tools for that.
    
    > The proponents of the “broken TLS” somehow expect that  those 
    > criminals would use weakened crypto for the convenience of the ntwork 
    > police. How much sense does this make?
    
    In most cases, the attackers don't use any additional crypto at all.  
    When they do, it's most often poor crypto.

You must be lucky then. Criminals that we’re concerned with, aren’t that dumb.
    
    > Experience shows that criminals use not just cutting edge – bleeding 
    > edge crypto.
    
    You're absolutely correct that a few do - as you note, Conficker is a 
    good example of that.

My point is that we should look at the trend – not just the status quo. And the trend shows the attackers become smarter.
    
    > Plus, there are many ways to foil this proposed mechanism – for 
    > example, super-encrypting the data before transmission.
    
    Sure.  But the ability to infer the presence of superencryption is 
    extremely valuable in and of itself.

If the adversary allows you to infer it. It’s next to impossible with the large-scale traffic, when the adversary is crafty enough.
    
    > 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.
    
    Again, to clarify, this mechanism for use on intranets within a single 
    span of administrative control.  Like you, I would work to dissuade 
    anyone from using it across the public Internet.

Again, technically there is no such thing as “intranet”. It’s an *administrative* domain, and there is no distinction protocol-wise.

The only “dissuade” I’d consider is when it’s enforced on the protocol level (on the wire), and there are unambiguous ways to detect it (and explicitly opt in, or opt out).
    
    > The likely result of the “static-dh-…” proposal is improved mass 
    > surveillance by authorities, and exploits of this mechanism by the 
    > organized crime.
    
    Let's remember that this technique is in use on intranets around the 
    world, and that's the focus, here.

Let’s not forget that from the protocols point of view there is no “intranet”. There’s only “Internet” – a network of interconnected networks. Administrators can draw boundaries around hosts and routers they think they control – but it has no impact on the protocols themselves. 
    
    > 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.
    
    The ability to infer superencryption is quite important, per the above.

First, this ability depends on your adversary letting you have it – it is not given. Second, I find it concerning that you seem to be OK with the second option of the choice I outlined.
    
    > Because there are well-known ways of hiding the presence of 
    > encryption, at the cost of increase of the ciphertext size.
    
    We should also keep in mind that are also ways to counter-detect these 
    obfuscation techniques, too.
    
For an individual connection – very likely so. For all the connections your subjects have within the company, and/or with the outside world? Not hardly. 

    > The hope that the encrypted traffic would stand out is unfounded.
    
    Actually, it does stand out, in many cases.

In fewer and fewer cases. As adversaries learn, they encode that learning into the tools that then become available to the lower-skills-level attackers. 
    
    > Considering how fast the attack sophistication is evolving, the 
    > likelihood that “they” would employ other countermeasures, but 
    > ignore this one is fairly low.
    
    This technique certainly isn't a universal panacea, as you rightly point 
    out.  

:-)

    But it's an extremely valuable and important technique that's been 
    in broad use for quite some time, so maintaining a mechanism for 
    intranet operators to analyze TLS-encrypted traffic within their own 
    spans of administrative control is important and worthwhile, IMHO.

We disagree here. 

Not to mention that a country might consider the entire traffic within its borders as “intranet”. Some already do (and some don’t even stop there). I’d rather that these operators mature and realize that as the time goes, some new capabilities arrive, and some old capabilities wither and die. 
    
    We don't want to inadvertently drive them into using proprietary, 
    non-auditable crypto.  That would be bad for everyone.

Publish that crypto, and it’s not proprietary any more. Subject it to an audit – and it’s now audited/auditable.