Re: [Patient] DOJ first on encryption services

Eric Rescorla <> Sun, 18 March 2018 12:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26AF31277BB for <>; Sun, 18 Mar 2018 05:46:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.639
X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q69feuYZBuJU for <>; Sun, 18 Mar 2018 05:46:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DFF7F126D3F for <>; Sun, 18 Mar 2018 05:46:29 -0700 (PDT)
Received: by with SMTP id s2so252852qti.2 for <>; Sun, 18 Mar 2018 05:46:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XLamRv0RGcSTjXuUxKlIgG1uRF89Rbpr6vxRk1Exr4o=; b=QD/y9HgR6YEus/+yl/jzdO7w79PTCnoJliPSePWkYoROk4KXiSsDN+ZpnOla8nzAl3 8LBDw2KVq+hC4Lu/td1XckiezOKPVvMFx95JZlsJhyKz+Yl/gQRkyW0Cbme8HYFj0yei SyUBADHkMGX3SfWTIC0b8r1xFqjxYpaS6/nUMx5NUTAC43aT+CR965SlKlQ2DWOFUhPc OZZJfZ3visJkUlK10QPXq9Infg+7wmSxTpdgEQAXYozcoTvMB2xenMvnXMictHltkChY rqHe3wCuk3j/x7VJ25woqYYyfroKBDU2S7RLbn6h//w7575ig3b6YD/aZx4Wc3q7LyRz vKKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XLamRv0RGcSTjXuUxKlIgG1uRF89Rbpr6vxRk1Exr4o=; b=KI6trx0CjZphNjE4fIJh47EewILH8o7/MuaQ6Q7CAMmBRu57+X4HSJR1hz/QPw9cvs WZYKLeVNubxAohiEm98ZcB8La2PXPTg6+EEQDwXB26MPq13YRNt41+x28iuGJ8F/Uak2 YiEHW/q/Djg5mji1pomMxKrX4V/4GKK8enLpR2WOG1xIue+qLrnwjHCmhC5Eahsrwqsy sy6ZTWwyV48tfRMSt4er4AlrQ50Ci4xPBQZfJkl87Ovp1+21AhzjsRmt30V7NVliPaXM Kh44pDAXrJpNEaUn/A0umGJ35SSFc52h5VbQhKZIqA92LLxFqzYUczLjrCSCXyUzDU81 BK5w==
X-Gm-Message-State: AElRT7FFW6ZQOw9ojW/cc4rawN5hSd7QAIDhKAhRTg1IylLA/kGEskay eZbxFkugahgmoSVGZAhKX0cs6X0lf6JXsbFrG/HNqw==
X-Google-Smtp-Source: AG47ELsZssN5ICMespGQHJGEtsSLjKH7ahBtKrcmFvkBH+mJL19RHRqyhEqg7NAtO8lNY8osoRd00M9XxR8VoK/uvbQ=
X-Received: by with SMTP id b46mr12927063qta.321.1521377188942; Sun, 18 Mar 2018 05:46:28 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 18 Mar 2018 05:45:48 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Eric Rescorla <>
Date: Sun, 18 Mar 2018 12:45:48 +0000
Message-ID: <>
Cc: "Diego R. Lopez" <>, Brian Witten <>, "" <>
Content-Type: multipart/alternative; boundary="001a113b0328eaa82d0567af3ac3"
Archived-At: <>
Subject: Re: [Patient] DOJ first on encryption services
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Mar 2018 12:46:32 -0000

On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski <>

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


> --tony
> _______________________________________________
> PATIENT mailing list