IETF Logo Mail Archive

Re: [Patient] DOJ first on encryption services

Tony Rutkowski <tony@yaanatech.co.uk> Sun, 18 March 2018 12:54 UTC

Return-Path: <tony@yaanatech.co.uk>
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 94F2C127871 for <patient@ietfa.amsl.com>; Sun, 18 Mar 2018 05:54:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ySiflqHha-Nz for <patient@ietfa.amsl.com>; Sun, 18 Mar 2018 05:54:45 -0700 (PDT)
Received: from uk-www1.yaanatech.uk (uk-www1.yaanatech.uk [46.20.116.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3EBF1270A3 for <patient@ietf.org>; Sun, 18 Mar 2018 05:54:44 -0700 (PDT)
Received: from [192.168.1.53] (pool-70-106-194-121.clppva.fios.verizon.net [70.106.194.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by uk-www1.yaanatech.uk (Postfix) with ESMTPSA id B1AA1540177; Sun, 18 Mar 2018 12:54:42 +0000 (GMT)
Reply-To: tony@yaanatech.co.uk
To: Eric Rescorla <ekr@rtfm.com>
Cc: "patient@ietf.org" <patient@ietf.org>, Brian Witten <brian_witten@symantec.com>, "Diego R. Lopez" <diego.r.lopez@telefonica.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>
From: Tony Rutkowski <tony@yaanatech.co.uk>
Organization: Yaana Limited
Message-ID: <36dee113-66a5-41cf-4d2c-14b86c70c88a@yaanatech.co.uk>
Date: Sun, 18 Mar 2018 08:54:41 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBOyyr44-ED9MMhHtzPuTq-Xt_iYeJKs6vbOUN=Stjc==g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------19FBB8C556AA02D29B536595"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/AgpOsIqMpKBol7Z2_32TufuF-20>
Subject: Re: [Patient] DOJ first on encryption services
X-BeenThere: patient@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 18 Mar 2018 12:54:47 -0000

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?

-t


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
> https://www.ietf.org/mailman/listinfo/patient

v2.23.0 | Report a Bug | By Email