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

Tony Arcieri <bascule@gmail.com> Tue, 23 July 2019 20:05 UTC

Return-Path: <bascule@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 50B8812036D for <tls@ietfa.amsl.com>; Tue, 23 Jul 2019 13:05:18 -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 c_PXQNiCv9m6 for <tls@ietfa.amsl.com>; Tue, 23 Jul 2019 13:05:15 -0700 (PDT)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 7194512039B for <tls@ietf.org>; Tue, 23 Jul 2019 13:05:15 -0700 (PDT)
Received: by mail-ot1-x32d.google.com with SMTP id x21so6923151otq.12 for <tls@ietf.org>; Tue, 23 Jul 2019 13:05:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J2Di3xkG+cmD2Fx+NZYY3fg3cEFNyqhTrbSLHeE9pOM=; b=tGDo7u1rvfWH3mrdXt4dk6q22ltyXYaGWU8j5F/KvsYQabRxP2G/Ngtj/epaiLM8rk l7x4GOkgJ/qmVHjriiEReqmp9Wp31x9SzIFb73JN/MTHLm6L13LLlCvlg6goVKUTBHJr 5K773/fVU0/Xm9Y1r/0X7OlZBJ2+TQD99f9JXB3vHJRjMbYfj4RVb1SMha9Yjjs9jWQn rlTB973UP6J3RXNurNwHBbazuAnFbbRkxOMZpP3XuXpObG6aN4lA727bu20DRzaRYeLe XJXeg4QEGrzJ7hN4ubT57YpLLUtMd1luRoq8KcZU/vLJdTXIl3cZKjA7bE6HjLDtgoUV q4Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J2Di3xkG+cmD2Fx+NZYY3fg3cEFNyqhTrbSLHeE9pOM=; b=MYiHo17iBfjd30fq3hkSJlYjy7b6A+NWxbHC5+Qm7aUgTiK0xMwAat4fNln08km/Tb plulC2nfYnUJYhC9BQJMMTGZnRlAYuPB/RfNbqLU0B454w17eLhAABRMmIPs5ge9OCx1 v9h2Orp9CPk9AUej8nz0ZkiasYpMdRUDHtas38ya3A7l7LZ0ynO354zmKCaJpD8rZlbn v5tCOqOPvPc+kKCc3Uoh9dgXC0CQlDhvqDUihLdQ5jEtcYKEqYbgECwK+nq8HrMBrXyn 2uxdPZ6jloMHKLPNph3ZgXi8sj44il5umSsJbD4mjKSaVovsJgaFdH7SBFHfWXOmWRa2 2ksA==
X-Gm-Message-State: APjAAAXIJ9TbjIdeqFytI24kONLvrddzD+PFgcqTUBsVioTr/IUBj/k8 O3BdewUS0attIOFc6AiFTWLnMv8TYu3cGXCryyk=
X-Google-Smtp-Source: APXvYqzxKN3cnTPqg4gsNN0JUWFZ1k9qqxAaPmxC1VhDB3PFenwBFK5wj4nqgIzPc/WYMd9D5FukeWf1uCT2xbjUEIc=
X-Received: by 2002:a9d:5787:: with SMTP id q7mr17895087oth.75.1563912314652; Tue, 23 Jul 2019 13:05:14 -0700 (PDT)
MIME-Version: 1.0
References: <6AF48228-19C2-41C7-BA86-BA16940C3CFF@cisco.com>
In-Reply-To: <6AF48228-19C2-41C7-BA86-BA16940C3CFF@cisco.com>
From: Tony Arcieri <bascule@gmail.com>
Date: Tue, 23 Jul 2019 13:05:03 -0700
Message-ID: <CAHOTMVJSqZxstAs6nBiXaqWDBLY8R=gYZ4WooYVXGax0UmRL-w@mail.gmail.com>
To: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f98db4058e5eb5f4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TrSZVAQSUvqJgMFAxeuwBMu3UxA>
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 20:05:18 -0000

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.