Re: [Patient] DOJ first on encryption services

Bret Jordan <jordan.ietf@gmail.com> Tue, 03 July 2018 16:44 UTC

Return-Path: <jordan.ietf@gmail.com>
X-Original-To: patient@ietfa.amsl.com
Delivered-To: patient@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD47612F1A6 for <patient@ietfa.amsl.com>; Tue, 3 Jul 2018 09:44:25 -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 zX4un7sC8rYs for <patient@ietfa.amsl.com>; Tue, 3 Jul 2018 09:44:17 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 998F112F1AB for <patient@ietf.org>; Tue, 3 Jul 2018 09:44:17 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id y124-v6so4230463itc.0 for <patient@ietf.org>; Tue, 03 Jul 2018 09:44:17 -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=9QD7januhbI61cTqWzih3xD5xV8yYfyI6OXzKEAYLxc=; b=pNkZjKnuMeYjR4NCJnx8sa6ly+UUKNzkd2l48HwOw1yGBbhiaVh9cWkn6iRS5Oolp4 XfchukFWwDMMDKUtn5aJmuXX6tZ0/eF8UneU9WQMwGWngC8aFdl1Z7kVVDZqcsHp6vNc +CMgV+gQr6O0bmgaLAXptOweGimRG/i56MD6OBtT0mxmHnFkKOUV5pyGKZ9keFv0z/dE Ppxa4kcVX4QMsnj79eU/SYUmUnfDw0kRxVCIQfmEn+uBvaUXnukDW7QmCsoSg6d/64nw fZ1DzKj2FBDtz0uek+7lqKn9DlXHRy46GMrGROrf/x9zbcgIqoXYMotd4j5FsGIqQm4g k4Fg==
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=9QD7januhbI61cTqWzih3xD5xV8yYfyI6OXzKEAYLxc=; b=cHkyxG9IAwZZlYnnRj+KJ0q2xuzcLKCoIU6yDmnNCAf0s16C7EqvsVEsd6BoQe/ikN YSa5LMsplJ6BcY1hbVRlNYXzO4xdM2bxbJG2O5Ms+w736Mg4pU0Nypj3TFYXuPkHuL4w YxXps1DwjzOJBGeCpeiVthGj1vlT+OGclDSv+jtCKJFvtWwzKZYVpUGtKJvh+SXKXuj6 AfJzB3E+LBJ2r05XqXrW/K6TICDoqPNekG6LQye9NkuodiW6Ac05d2n2sxenqE1LmrTE QqNA55h2hrLw/1tYizoOrVBpyit4K9wyunyz9OYMDpChYpt9r9jWEbbG1SHY12j2bvV/ x+Zg==
X-Gm-Message-State: APt69E087WCjlSUUW7hzD1E9gh4s8sv59/vvHretDyt02yMeqlcxXSDK gUMQSF81u21wFmu4AUyPmcw=
X-Google-Smtp-Source: AAOMgpfn86TrGSN8KQyKkww9j6VDI0gjHGHi8OlUb28BAG9/eaUg3Y8AY2YcWKA8WnsGd3TOXI5mFA==
X-Received: by 2002:a02:84cd:: with SMTP id f71-v6mr24312506jai.42.1530636256907; Tue, 03 Jul 2018 09:44:16 -0700 (PDT)
Received: from [10.249.203.139] (67-128-146-21.dia.static.qwest.net. [67.128.146.21]) by smtp.gmail.com with ESMTPSA id x67-v6sm815382ita.11.2018.07.03.09.44.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 09:44:15 -0700 (PDT)
From: Bret Jordan <jordan.ietf@gmail.com>
Message-Id: <06B68C38-6D6A-48E8-8C61-9B9A032174E0@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A1731D11-F560-40D9-B974-9E56FC53790A"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Tue, 3 Jul 2018 10:44:04 -0600
In-Reply-To: <CABcZeBO+mWZKX6hZr9J5OpV3Z4PZrTkFzfQAPPiA=bCVobAP3w@mail.gmail.com>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "patient@ietf.org" <patient@ietf.org>, tony@yaanatech.co.uk, Brian Witten <brian_witten@symantec.com>, "Diego R. Lopez" <diego.r.lopez@telefonica.com>
To: Eric Rescorla <ekr@rtfm.com>
References: <02be9028-a8fd-f527-826b-5361de1470ce@yaanatech.co.uk> <F8164D9E-92C2-4440-BD06-6D81852918B8@telefonica.com> <9d71af7a-cdf2-7590-6e12-e3207e2c4736@yaanatech.co.uk> <CABcZeBOyyr44-ED9MMhHtzPuTq-Xt_iYeJKs6vbOUN=Stjc==g@mail.gmail.com> <36dee113-66a5-41cf-4d2c-14b86c70c88a@yaanatech.co.uk> <CABcZeBOjAMK9kgVvCrfaZDxmk0qH-PX83AkCodkcw9uwhEyJrQ@mail.gmail.com> <CAHbuEH6Q8bQkzSKmLErYKm2usv3oaOV1VbNKyPRz_YrjN6T=3Q@mail.gmail.com> <CABcZeBO+mWZKX6hZr9J5OpV3Z4PZrTkFzfQAPPiA=bCVobAP3w@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/TQCMT5x_fnpIa7IV7GShLd15FDE>
Subject: Re: [Patient] DOJ first on encryption services
X-BeenThere: patient@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <patient.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/patient>, <mailto:patient-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/patient/>
List-Post: <mailto:patient@ietf.org>
List-Help: <mailto:patient-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/patient>, <mailto:patient-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jul 2018 16:44:26 -0000

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."

> On Jul 3, 2018, at 9:59 AM, Eric Rescorla <ekr@rtfm.com>; wrote:
> 
> 
> 
> On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com <mailto:kathleen.moriarty.ietf@gmail.com>> wrote:
> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote:
> >
> >
> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski <tony@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 <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@yaanatech.co.uk <mailto:tony@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 <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@ietf.org <mailto:PATIENT@ietf.org>
> >>> https://www.ietf.org/mailman/listinfo/patient <https://www.ietf.org/mailman/listinfo/patient>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> PATIENT mailing list
> >> PATIENT@ietf.org <mailto:PATIENT@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/patient <https://www.ietf.org/mailman/listinfo/patient>
> >>
> >>
> >
> >
> > _______________________________________________
> > PATIENT mailing list
> > PATIENT@ietf.org <mailto:PATIENT@ietf.org>
> > https://www.ietf.org/mailman/listinfo/patient <https://www.ietf.org/mailman/listinfo/patient>
> >
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen
> 
> _______________________________________________
> PATIENT mailing list
> PATIENT@ietf.org
> https://www.ietf.org/mailman/listinfo/patient