Re: [TLS] TLS Impact on Network Security draft updated

N6Ghost <n6ghost@gmail.com> Fri, 23 August 2019 18:23 UTC

Return-Path: <n6ghost@gmail.com>
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 B35C212087A for <tls@ietfa.amsl.com>; Fri, 23 Aug 2019 11:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 msujoKjISaKT for <tls@ietfa.amsl.com>; Fri, 23 Aug 2019 11:23:19 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62ECE12086D for <tls@ietf.org>; Fri, 23 Aug 2019 11:23:19 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id n9so6210947pgc.1 for <tls@ietf.org>; Fri, 23 Aug 2019 11:23:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=KpTopGGykd588uydxsjMfhL4Rrg4h+r/6aR94b1GcDw=; b=ds7ff8DfSWIVFIvZHJ45IoUOXDX0+9iZk/2vmW+jwOrwT/bkdyfc4Dp12RBzju1lXs p5pHT8iMn/GHX82IbUyH77pYMrP/1cDlmFKNk1WhDU3+qaiF5WbYEHzcYefoivPS3aLf Pm6L1Aw5pVkR2XM8H/Rt3DgkAY0mGMtU1bF0RMRiDaAJ/jowHz4jlHC3Q7iSZDXNRoCG wzeV8lQ+ScpNXeJQqjHnM8HKKKxr0NDpYoBVPQeBD0rjadC+eUvLUhrBhC611qaIA2A2 PlIZRGOoSnaA8FugXghdR1PeQzlKsHETDw1zUCoMEW8bo4cbMEbVV2zdS3cBBu3nMjG2 HHAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=KpTopGGykd588uydxsjMfhL4Rrg4h+r/6aR94b1GcDw=; b=HdHMpIh/80d8kXgIU1W87fB8cY1V5GF/TsUiOiWjT7hF9z3PJdS/kiFZeMFRFce7uh Ts5ozAzhFin8YouErqUR4F8Gg4rxPui+V33Z4BQ5+sRWFqTYeZrY48zHtxUmpLq3JMF2 b4yGAY9nMAL0UYiTkKrSCoiLfWLoHjDW7OuMB1ulnWdDQPGRdzYcB40TctJu6BXbWJbw LBQOotZ1r4pwnIMRMzGc2q8r/uQZaouwvqFemmMQF3Dxv1VbXSKxf2hACKLihnswJatw iknF3zC32eBqZnQhXQixxKfm9XvDrjrrF+qruNjIHzNXlwb568diKfTXKode1qsHnoVV S+0w==
X-Gm-Message-State: APjAAAWQqN6JXOacKV+wUrorsF5WQNMR+6aNL+0Y7zKFjQsuoIAcC73V M6a+l9ipSCSda4Qnpzcr7Ek=
X-Google-Smtp-Source: APXvYqz++n2pZibjsWq2iWc+c5QjbHUG2EjiwMCh46/YZH7IQ9PrK7CFj50q6pMlG7bW0OVkjiTXUA==
X-Received: by 2002:a63:e010:: with SMTP id e16mr5039965pgh.285.1566584598864; Fri, 23 Aug 2019 11:23:18 -0700 (PDT)
Received: from [10.211.55.11] (gpsslvpn.mednet.ucla.edu. [149.142.80.30]) by smtp.gmail.com with ESMTPSA id u26sm2949237pgl.79.2019.08.23.11.23.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Aug 2019 11:23:18 -0700 (PDT)
To: tls@ietf.org, bascule@gmail.com, ncamwing@cisco.com
References: <6AF48228-19C2-41C7-BA86-BA16940C3CFF@cisco.com> <CAHOTMVJSqZxstAs6nBiXaqWDBLY8R=gYZ4WooYVXGax0UmRL-w@mail.gmail.com>
From: N6Ghost <n6ghost@gmail.com>
Message-ID: <111ad7c8-4000-00b6-92a2-9cbc4fff9210@gmail.com>
Date: Fri, 23 Aug 2019 11:23:17 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAHOTMVJSqZxstAs6nBiXaqWDBLY8R=gYZ4WooYVXGax0UmRL-w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------1C37A5F9D533EBEA0F9630AF"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Xz8zWHOc0RPlznDCLpePdgh-tTE>
Subject: Re: [TLS] TLS Impact on Network Security draft updated
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 23 Aug 2019 18:23:23 -0000

On 7/23/19 1:05 PM, Tony Arcieri wrote:
> On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) 
> <ncamwing@cisco..com <mailto:ncamwing@cisco.com>> wrote:
>
>     Hi,
>
>     Thanks to all the feedback provided, we have updated the
>     https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
>
>     draft. At this point, we believe the draft is stable and would
>     like to request its publication as an informational draft.
>
>
> I read this draft as the latest attempt in a disinformation campaign 
> by manufacturers and users of middleboxes that passively decrypt TLS 
> connections to politicize and reframe the argument around what is, at 
> its core, a fundamentally insecure practice which is incompatible with 
> technically sound and highly desirable protocol improvements to TLS.
>
> I implore you stop using overly broad terminology, euphemisms, weasel 
> words, and other deceptive language to argue your points.
>
> This draft is titled "TLS 1.3 Impact on Network-Based Security", but 
> the subtext is quite clearly the much narrower subfield of middlebox 
> TLS decryption. By using such a grandiose title which is deceptively 
> hiding the true subject matter, you are implying that middleboxes are 
> the sum total of network security.
>
> The draft begins "Enterprises [...] need to defend their information 
> systems from attacks originating from both inside and outside their 
> networks." I am co-owner of a company which heavily leverages 
> firewalls for layer 3/4 network security in conjunction with TLS. We 
> care deeply about network security, and believe that our network is 
> *more secure* specifically because we *don't* perform middlebox 
> interception of TLS.
>
> I consider our company to be in the category of enterprise TLS users, 
> and as an enterprise TLS user who cares deeply about network security, 
> I do not identify whatsoever with the claims this draft is making 
> about the needs of enterprise TLS users as a whole. In as much as what 
> it describes to "network security", it is but one niche consideration 
> within a vastly broader field, and one which is increasingly 
> controversial.
>
> I will point out, since you appear to work at Cisco, that your company 
> works on approaches to network security (e.g. malware detection) which 
> avoid decrypting TLS:
>
> https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption
>
> There is an entire world of network IDS systems beyond middleboxes 
> which passively decrypt TLS.
>
> It is factually inaccurate for this draft to be described as "TLS 1.3 
> Impact on Network-Based Security". If you are going to write a draft 
> about the impact of TLS 1.3 on middleboxes for passive TLS decryption, 
> please call a spade a spade and don't try to hide your true intentions 
> under a bunch of weasel words and overly broad claims that make it 
> sound like middlebox-related TLS decryption problems are the end of 
> network security as we know it.
>
> My 2c, on behalf of non-middlebox-using enterprise TLS users who feel 
> that attempts by middlebox-using enterprise TLS users to weaken TLS in 
> order to retain compatibility with their traffic decryption appliances 
> is a threat to the security of our enterprise TLS deployments.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


agreed, to many people think that TLS decryption at the border is 
critical to the network security program.  they think that they need to 
"decrypt" everything so they can run packet inspection on the traffic 
looking for bad packets or bad actors.

they problem with this, is at the border, those devices that can, and 
are; doing decryption see all plaintext traffic, so a compromise at that 
point, negates just about everything your doing.

I firmly believe, that TLS/SSL decryption at the border is like NAT, it 
needs to die for the betterment of mankind.


-N6Ghost