Re: [TLS] Encrypted SNI
Tony Arcieri <bascule@gmail.com> Wed, 04 July 2018 16:31 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 50B9E130E18 for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 09:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 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_PASS=-0.001, URIBL_BLOCKED=0.001, URI_TRY_3LD=1.999] autolearn=no 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 Zfjbta7PkNAN for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 09:31:03 -0700 (PDT)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 DC01C130DE1 for <tls@ietf.org>; Wed, 4 Jul 2018 09:31:02 -0700 (PDT)
Received: by mail-vk0-x22f.google.com with SMTP id d74-v6so3383473vke.10 for <tls@ietf.org>; Wed, 04 Jul 2018 09:31:02 -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=c8i2dN2EbWhgTi+vczX8Rhk6z11g3doMffkXdrX3mcU=; b=dhdAvCnwZqBp/OPrBGUvb1MsreTZbjPgNf5DuBtDJgfaQo6H40fJS3Wtv6P6A8BpkM RLdfhXMcnWzlIx6Qd/0IIzJnwzN71RoamBhqiL/bqd6PKhXWqpk965pQhov1MY4tbQJk KG+I+rNdGvrCCESFXiuzAlbvP/rH8xT66mN90aOAbzon0mwJxGyrWHKktlbmE+vtx9vx zKIEEgv/xASq+GHfO3K5nISxxgqFKsEmaa7Q6gVhTHwG1H9231yj81VAVpowj9aasZtp /TJlG4S6gTX25w+V/4yC4+MgIF8a7NaQ4VsOeeBrDV7pLexulOP5Ah+Ym6BMYjRGZdf8 3HxQ==
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=c8i2dN2EbWhgTi+vczX8Rhk6z11g3doMffkXdrX3mcU=; b=Z3VBXxFVrOXe2PH7EReZhFzftct4FLZlJKkWKOknM6QhkAGVV6A0YDMgd6sse/0R6L 4K7mFC4y6tsxIC3S+sdnjfmWbidLUZZj0QQOsEqo9Vgpb+jTNjJpBqyKlHQMImDq3nvN 3T//U8gpuXOYh3OCvlJ2Fd7ohsMioAmSwkdl+NiPr2/85XSqKNZ4EIVebKL4+xaEavli LXvKrMSLaWd/GvpWpaJh7OxBZs22EipTi9VWc/Brn35opumqLdskrVM7ZtXHrdd3U3Ho Woqf86CuJ4ACSFRcyjc1WQw0KSbv/s7VbF3hmJyhEode+us9yf4eaGxDjPQMlO3yz1O2 bIHw==
X-Gm-Message-State: APt69E0tVzfTBndWZipnPOaTA9uQacWDO45jP2wgZrOpJckGk2gH2dRi xaf48aCKkjwUtGfIow2CznOn8YQEr63sfXc9vRs=
X-Google-Smtp-Source: AAOMgpfh9pKjndoImU5rKzbCV67ZdWFvWZ36sQrGawkBxS7nHNFSqwwtSLdekjqWm5mgGRAPnCPUjrP1jZbmnbTpy9w=
X-Received: by 2002:a1f:a38b:: with SMTP id m133-v6mr1483666vke.20.1530721861388; Wed, 04 Jul 2018 09:31:01 -0700 (PDT)
MIME-Version: 1.0
References: <F4966CAA-454B-4152-A9E5-EA9714978CEA@gmail.com>
In-Reply-To: <F4966CAA-454B-4152-A9E5-EA9714978CEA@gmail.com>
From: Tony Arcieri <bascule@gmail.com>
Date: Wed, 04 Jul 2018 09:30:50 -0700
Message-ID: <CAHOTMV+pHoYLPoQmmGvSmBLemX=NEuGqi=aQKAC2tnh5D9WqAQ@mail.gmail.com>
To: jordan.ietf@gmail.com
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cc4f4405702ef400"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/LoBSl36ytZhu0TuxLfIyDGnT92Q>
Subject: Re: [TLS] Encrypted SNI
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 04 Jul 2018 16:31:06 -0000
On Tue, Jul 3, 2018 at 10:08 AM Bret Jordan <jordan.ietf@gmail.com> wrote: > From my personal perspective, we need to be careful with all of these > efforts. It feels like the pendulum has swung so far to one side, the side > of privacy-at-any-cost, that we are unknowingly increasing the risk to > individuals and organizations by enabling threat actors and intrusions sets > to attack networks and clients without any level of protection from the > network. > Speaking as an industry practitioner and network security professional, don't trust the network. That is the entire purpose of TLS. As one of my present job capacities I micromanage Juniper SRX firewall rules. However, my personal view of the value provided is that it's a defense-in-depth measure at best. There are already many ways for attackers to take surprising and unexpected paths through the network which are much more interesting and useful than through a DNS+CDN's frontend terminator. Just as one example of such a path which is incredibly hard to block is Amazon S3, where you can attempt to whitelist a particular bucket by hostname, and even try to do NIDS to ensure that S3 requests only go to mybucket.s3.amazonaws.com by inspecting SNI and rejecting anything but a particular bucket in the SNI, but after TLS has been established an attacker can send a Host: header of attackerbucket.s3.amazonaws.com and S3 doesn't care what domain you used to get there or what SNI you sent. > It also feels like a lot of these initiatives are being done without > adequately involving and ensuring that enterprise networks and critical > infrastructure can work with these changes. Question, do we know how these > ideas and changes are going to impact an organizations ability to fulfill > their requirements for regulatory compliance? > I am a co-founder of a technology company, and was formerly on the information security team of a publicly traded next-gen fintech company. Speaking as a representative of industry, I would once again like to make it very clear that demands for "visibility" represent one perspective within industry as a whole. I think if it were possible to take a hum "from industry", you would find it quite divided on this topic, particularly between older larger companies and smaller, newer ones. Having aided (in some cases instrumentally) with PCI-DSS, HIPAA, and SOX audits in a modern fintech company with a card storage environment and massive cash flows to account for and safeguard, my professional opinion as someone on the information security team for that company is that the net effect of ESNI on any of the compliance strategies being used is 0. I think you might get a different perspective from someone whose compliance strategy is largely predicated on e.g. Blue Coat "Visibility" appliances who think things like passive SNI inspection are good indicators that traffic flows are legitimate. However, while I'm aware this approach is quite popular with e.g. older financial institutions, as noted above with the S3 example it's still leaky. As long as you have a "legitimate" frontend that can reach a backend which will honor the Host header over what's in SNI and can get to both "legitimate" and attacker-controlled resources, attackers can already bypass things passive SNI inspection. That said, I think there are very much legitimate enterprise use cases of this feature (see below). > If we continue down these paths, then I fear networks will be required to > wrap all traffic in some other less secure protocol, outright deny some of > these protocols, or be forced to fully proxy all traffic or take an > approach that Google has done with their BeyondCorp design. > In my opinion BeyondCorp-style designs are considered state-of-the-art by the security teams of companies I respect, including the public fintech company I formerly worked at which is presently in the process of migrating from VPN-based access to a BeyondCorp-style approach. As someone presently solving this problem for my company, I have recently deployed Google's Identity Aware Proxy (IAP) to provide "front door" authentication to internal web applications. IAP works by having you point DNS at Google's frontend web servers, which terminate HTTPS, check for a credential, and if it isn't present perform an OAuth flow. It integrates with the rest of Google's suite of "BeyondCorp" tools including things like Cloud Identity and Endpoint Verification to ensure all access to internal tools is both strongly authenticated and coming from a known healthy endpoint. The important point here is that everyone using IAP is pointing DNS at the Google frontend. In conjunction with e.g. Google Domains or GCP Cloud DNS, IAP could support this approach to ESNI. In a BeyondCorp architecture, ESNI would provide confidentiality for the DNS names of internal tools being accessed through IAP. Using something like DoH in conjunction with dns.google.com, we can completely reduce the parties who are able to determine which internal tools are being accessed to Google exclusively. Is there enterprise value to actually protecting this information? Well, like network security, it is (or at least should be) only defense-in-depth. But I still see value in defense-in-depth. As an industry practitioner, from the perspective of the sorts of companies I work at, I see no downsides of this approach. Instead see an interesting feature which I want to use. Framing things in terms of "privacy" versus "industry concerns" is a false dichotomy, and one we continue to see being perpetrated by the "visibility" camp, e.g. https://www.ncsc.gov.uk/blog-post/tls-13-better-individuals-harder-enterprises (which had an awesome response from agl: https://www.imperialviolet.org/2018/03/10/tls13.html) They are using this as a rhetorical tactic to spin the "visibility" debate, when the reality is that the interests of individuals and enterprises are not at odds. What are at odds are improving Internet security for everyone versus the interests of e.g. Blue Coat's customers whose compliance story presently depends on their ability to break their own security from a single point of compromise. More modern techniques like endpoint agents, tracing frameworks, and other observability tools can tick the same compliance checkboxes and solve the same problems like debugging complicated service-oriented architectures. But it seems some people stuck on the Blue Coat model would rather make Internet security worse for everyone than invest in updating to a more modern approach. Enterprises can benefit from privacy just as much as individuals. However, not all enterprises within industry as a whole are ready to take advantage of it. When seeking out industry input for IETF, make sure you're not only paying attention to a particularly vocal segment whose views are not representative of industry as a whole. -- Tony Arcieri
- Re: [TLS] Encrypted SNI Ackermann, Michael
- [TLS] Encrypted SNI Bret Jordan
- Re: [TLS] Encrypted SNI Hanno Böck
- Re: [TLS] Encrypted SNI Kathleen Moriarty
- Re: [TLS] Encrypted SNI Darin Pettis
- Re: [TLS] Encrypted SNI Benjamin Kaduk
- Re: [TLS] Encrypted SNI Brian Sniffen
- Re: [TLS] Encrypted SNI Eric Rescorla
- Re: [TLS] Encrypted SNI Paul Wouters
- Re: [TLS] Encrypted SNI nalini elkins
- Re: [TLS] Encrypted SNI Tony Arcieri
- Re: [TLS] Encrypted SNI Ben Schwartz