Re: [TLS] Encrypted SNI
Darin Pettis <dpp.edco@gmail.com> Tue, 03 July 2018 20:09 UTC
Return-Path: <dpp.edco@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 EF242130FC8 for <tls@ietfa.amsl.com>; Tue, 3 Jul 2018 13:09:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 x0VzAe7ZsfsW for <tls@ietfa.amsl.com>; Tue, 3 Jul 2018 13:09:32 -0700 (PDT)
Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (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 5CE98130DFB for <tls@ietf.org>; Tue, 3 Jul 2018 13:09:32 -0700 (PDT)
Received: by mail-qt0-x243.google.com with SMTP id y31-v6so2721570qty.9 for <tls@ietf.org>; Tue, 03 Jul 2018 13:09:32 -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=DJeSrOmCxGVxAvULeUDOihWlAmrXeF588Y15FSfbnL8=; b=mT8IyT511J4tBkQA6JgHzpIQj9r1Vv7ACT+blLnTLxDUMaZUgGMkR03a6soaroZuOU GbwZxtzSqxkvRvDLeHn8XIxDxbqE4jDew1Eb3a9jFNQfav+zq+qrzlLbhqopQggPSMGW hrJctMmLa715wDwOl844ZHTJmghCms0cwHvEh76KWtpC6KbiEgNjvbK5OVXaNbOuvjBx ZXitGCfAnnBXWsU91WDn/CH5YPCuZlXRJlevpISpJTyVk/NAU6KLRhHUruoswJbs2bon Wf+lvgBnBMPNjUQ2jxYdXd52DNdTiKb54jZsZmV7xYBZ9bAq5ACbFYnPMdQdALYtvvvA diEA==
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=DJeSrOmCxGVxAvULeUDOihWlAmrXeF588Y15FSfbnL8=; b=kKVrIgXOACdA34A+4vpdKq3ZQTM2RCS56JcKyMBqcN+4Ojq56w0xb1zBMdTlDdpemX UjLUSY/4s/FLcxJenp/9TV4zyHSLovs8NDEGVWsknz/0X4LTUBXK5uutgeKmWyfPqGNZ CwSHyja/rHEbnKQ2jAdEPs8GePEqiVQTlv1/m0kjxMYgOFfboHzi6MyM4IDZYMtFYEuM nvPEAcLuIz1rwA7roDMJNnHNiqa0FZQmKTKQhPEAJrja5PPnGn/kDbBqhlM1U/PwiK2d SMqxhs1UYhgiz+bQoxoTXJhGaylhuVzVqXDm4wAXjzDSLAmuHeo2SXNKRK1g4HDPZyYe c9rQ==
X-Gm-Message-State: APt69E3t0Mur7nuHP7W/KoOLM9BhqmUUsH65QGvKqjDh1MOqbrj36ZPf UIHw3L7n54L0jh0I0i0VQVBiAC87X+3Ssa5uZMU=
X-Google-Smtp-Source: AAOMgpd7ZC3HSUPt8I68+CB77G+xG039fL9Vv3kgcoMlSvDewHs6+RwKjNZXG/JyCJ51s1WCi+cuyKa+scU3nQO+/qU=
X-Received: by 2002:a0c:9208:: with SMTP id a8-v6mr27419888qva.47.1530648571467; Tue, 03 Jul 2018 13:09:31 -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: Darin Pettis <dpp.edco@gmail.com>
Date: Tue, 03 Jul 2018 15:09:20 -0500
Message-ID: <CAPBBiVTqRPRny0bpqeqGpqftpGwiwAgUo04Y1LWOzEHEhn=fpw@mail.gmail.com>
To: Bret Jordan <jordan.ietf@gmail.com>
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="00000000000060dc6a05701de42b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KW2ELl9ALLRQy0A0ybPJ04wawy0>
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: Tue, 03 Jul 2018 20:09:42 -0000
+1 On Tue, Jul 3, 2018 at 12:08 PM Bret Jordan <jordan.ietf@gmail.com> wrote: > From a discussion on the PATIENT list found here: > https://www.ietf.org/mail-archive/web/patient/current/msg00078.html > > > 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. > > 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? > > 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. > > The IETF work needs to do more outreach with enterprise networks and > critical infrastructure and be fundamentally more inclusive. > Privacy-at-any-cost is not a holistic design. > > 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." > > > > ### Copied content from the PATIENT discussion #### > > > On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty <kathleen.moriarty.ietf > at gmail.com> wrote: > >> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla <ekr at rtfm.com> wrote: >> > >> > >> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski <tony at yaanatech.co >> ..uk> >> > wrote: >> >> >> >> Your point is one that deserves further discussion, Eric - which seems >> >> likely to scale rapidly going forward. It is key. >> >> >> >> So how does draft-ietf-tls-sni-encryption it into the argument? >> > >> > >> > As you suggest, SNI encryption is intended to conceal the SNI, which of >> > course would make SNI inspection difficult. >> > >> > My evaluation of the current state of SNI encryption is that given the >> > current technical state, it will not see particularly wide deployment, >> with >> > the primary scenario being "at-risk" sites who are subject to >> censorship who >> > either hide behind or co-tenant with sites which are not subject to >> > censorship. That probably isn't going to be incredibly common right >> now. Of >> > course, this is regrettable from the perspective of people designing >> these >> > protocols, but I think that's the situation. >> >> EKR posted a draft to encrypt SNI, see: >> https://www.ietf.org/mail-archive/web/tls/current/msg26468.html >> >> It targets the CDNs who host most of the web traffic in the US at >> least. The right place to comment on this would be the TLS list of >> course, but since proposals are being posted, this is a reality and >> needs to be discussed. Those using SNI need to make sure their use >> cases are clear and understood and argue the pros and cons. >> > > Kathleen, > > Thanks for pointing out this draft. > > As they say, predictions are hard, especially about the future. In March, > the ESNI problem looked pretty intractable and then subsequently we had > this idea about why it might be workable. > > -Ekr > > Best regards, >> Kathleen >> >> > >> > -Ekr >> > >> >> On 18-Mar-18 8:45 AM, Eric Rescorla wrote: >> >> >> >> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski <tony at >> yaanatech.co.uk> >> >> wrote: >> >>> >> >>> Hi Diego, >> >>> >> >>> It is also worth referencing a relatively recent Lawfare article on >> the >> >>> scaling litigation in the U.S. against those supporting e2e encryption >> >>> services or capabilities. >> >>> >> >>> >> https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-supporting-isis >> >>> >> >>> This litigation trend is also likely to increase the insurance costs >> of >> >>> providers. Indeed, a provider that supports TLS1.3, QUIC, SNI, etc, >> may not >> >>> even be able to get insurance. It may be fun and games to play >> crypto rebel >> >>> in venues like the IETF where the risk exposure is minimal, but when >> it >> >>> comes to real world consequences and costs, the equations for >> providers are >> >>> rather different. >> >> >> >> >> >> I think this rather overestimates the degree to which both TLS 1.3 and >> >> QUIC change the equation about what a provider is able to determine >> from >> >> traffic inspection. As a practical matter, the primary change from TLS >> 1.2 >> >> is that the provider does not get to see the server's certificate, but >> it >> >> does see the SNI. Given that the SNI contains the identity of the >> server >> >> that the client is connected to and that the other identities in the >> >> certificate are often whatever the provider decided to co-locate on >> the same >> >> machine, I'm not sure how much information you are really losing. >> >> >> >> -Ekr >> >> >> >>> >> >>> >> >>> >> >>> --tony >> >>> >> >>> >> >>> _______________________________________________ >> >>> PATIENT mailing list >> >>> PATIENT at ietf.org >> >>> https://www.ietf.org/mailman/listinfo/patient >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> PATIENT mailing list >> >> PATIENT at ietf.org >> >> https://www.ietf.org/mailman/listinfo/patient >> >> >> >> >> > >> > >> > _______________________________________________ >> > PATIENT mailing list >> > PATIENT at ietf.org >> > https://www.ietf.org/mailman/listinfo/patient >> > >> >> >> >> -- >> >> Best regards, >> Kathleen >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- 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