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

Bret Jordan <jordan.ietf@gmail.com> Tue, 23 July 2019 21:52 UTC

Return-Path: <jordan.ietf@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 1FFD81200FD for <tls@ietfa.amsl.com>; Tue, 23 Jul 2019 14:52:31 -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 1LyXK1Nbqjd0 for <tls@ietfa.amsl.com>; Tue, 23 Jul 2019 14:52:28 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 0640D12001B for <tls@ietf.org>; Tue, 23 Jul 2019 14:52:28 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id d23so43461484qto.2 for <tls@ietf.org>; Tue, 23 Jul 2019 14:52:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=K8Wr+YLmq7lyehunZmpJvJao+3TyPrR5jDICGIz58Nw=; b=hkRZ5QVWxE8ZDg6jinnvFmtpgNq4OJa900maW638bIXwjWp7N1hodcf3KJkVXfz7wQ D/+z4Odf9/44SRnPzNurcD89srr0ucHWkGqlXceGzNmmC7STNN7uoyGQYn5BujrrdXGh 7/igdTZ2uu7dBL6KdO8Kpxn4M6ypwaZdZY3/Jqx3Cw9698rpMGo9e280mD+t69If6+k2 yHvBiuysVv5l+VRv1sYsPLqfh1Ct9S8KHS4TO3WAvkE9z60FvFRa/D8R9+lZ0Uppxjre L/j4NWVWf/Yd5gKlUR7RabWDT065qEtcmTrVTzv1QzLXcjNx/BZVMqs7Jr6k1iELwzfW 0GVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=K8Wr+YLmq7lyehunZmpJvJao+3TyPrR5jDICGIz58Nw=; b=ThiD8ctYgksForCj7KxVWn2tk2nnRXDVJ571j+L4jaMKq13Xxatwr8r7P2DJh/u9a7 fc1g28tYO1irJf7eIDTn2QFVCOCjzLKgg/RiigStl5It6Lrfk6Bxp3fWFRQitkiaQau3 hZDZABG7wPVW296dQqo4L0VknyC41MITqpJNbS+MYfjb8ZaAjYmpqoM/Vv+a34q23fDx TaaEiFf4dJ0T/ki+6LjDIlsPzmPLfoiiy0JlQ/SLM3+9nQR748f6jZ0ouqD8i1A9jSH0 /O1slxr04iE5qz0wDyFo4gw14agIOy7o08lYpI7olILOX2O/dsEpXaJ+8BBtzwYG0SMQ f9+A==
X-Gm-Message-State: APjAAAUMlpB4eWDLaiclucgsOAEayk9xj0M8rmaXWp540V/ep9qsGonR GheUomSTlEYdkf8pQIocgpk=
X-Google-Smtp-Source: APXvYqzmyT9s57M2B5KYvvzBgdhgzYcvQcXxLdPF1MLBZZL5f/LB3YRqi+fHEROzYPcuOXfuUVe4zw==
X-Received: by 2002:a0c:b095:: with SMTP id o21mr57533557qvc.73.1563918747083; Tue, 23 Jul 2019 14:52:27 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:19cc:7940:a396:841a? ([2001:67c:370:128:19cc:7940:a396:841a]) by smtp.gmail.com with ESMTPSA id g3sm18779549qkk.125.2019.07.23.14.52.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 14:52:26 -0700 (PDT)
From: Bret Jordan <jordan.ietf@gmail.com>
Message-Id: <FAB677BB-E812-4626-B549-01C730987C01@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_67774989-F7DA-4BD9-B4C6-11A969E8C417"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 23 Jul 2019 17:52:21 -0400
In-Reply-To: <E29654E9-4AE7-4558-910D-133529ABBCC4@sn3rd.com>
Cc: Tony Arcieri <bascule@gmail.com>, "tls@ietf.org" <tls@ietf.org>
To: Sean Turner <sean@sn3rd.com>
References: <6AF48228-19C2-41C7-BA86-BA16940C3CFF@cisco.com> <CAHOTMVJSqZxstAs6nBiXaqWDBLY8R=gYZ4WooYVXGax0UmRL-w@mail.gmail.com> <E29654E9-4AE7-4558-910D-133529ABBCC4@sn3rd.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/NLOT8mOdo5cdXonBOdiA1CpDCYY>
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: Tue, 23 Jul 2019 21:52:31 -0000

Thanks Sean.  

It is critical that we understand and discuss all sides of an issue and address all use cases that market has. Beating people down and trying to attack people or their use cases is not something we should be doing in formal standards, especially here at the IETF.


Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Jul 23, 2019, at 4:51 PM, Sean Turner <sean@sn3rd.com> wrote:
> 
> Tony,
> 
> While you may have concerns or otherwise disagree with the contents of this draft, let’s please keep discussion on this list, on all issues, polite and professional.
> 
> spt
> (as co-chair)
> 
>> On Jul 23, 2019, at 16:05, Tony Arcieri <bascule@gmail.com> wrote:
>> 
>> On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) <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
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls