Re: [Patient] DOJ first on encryption services

Eric Rescorla <ekr@rtfm.com> Sun, 18 March 2018 13:07 UTC

Return-Path: <ekr@rtfm.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 563C2127871 for <patient@ietfa.amsl.com>; Sun, 18 Mar 2018 06:07:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 dY4j-QyjDliP for <patient@ietfa.amsl.com>; Sun, 18 Mar 2018 06:07:40 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 B79701204DA for <patient@ietf.org>; Sun, 18 Mar 2018 06:07:39 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id w6so2711428qkb.4 for <patient@ietf.org>; Sun, 18 Mar 2018 06:07:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9iGBc+SarlrU6UKnYez20g2o4X3yl2ysCDRy5IGDvMM=; b=ovEuKfEiml5Ims+XtuRgkC83pDEhW8N2tH2p6wkQKR42XoZI+yT529WCdf1QM4jw7/ ycfFEfgSPzD2P170B3fLk1ZCbspGCKs2c/FfyOaOgEU59fDI6OcXrEBQNoAaLcvaQVqO +5lo+h2wtFsNeOluKE+BlXZL90WTLY9LMXUC2BTsyDcftqKO1uoTTE5cLSTkYxuSvC/A 7Mtwdz1FDqqZUguIG8gaLHC2s0aT8fR3bpX/aZNOpKSLVn5IbrnPE5VtHfSlazOWCwrs BZwNh8It2HTGOVaL4CB9KsI548nJkmKU8ggZMey+7Aw0cZJiYivOVb0NdjmKx0vRQGOY 3Ihw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9iGBc+SarlrU6UKnYez20g2o4X3yl2ysCDRy5IGDvMM=; b=gtivLn0Oo7tR3Mi5w+k0LtKXkO3yUr1OPaU9QoT81sex+NzD8GVi9Ka0yU4OzNVotB f456FybAd7pWgNWNAbBTLYVxoeSLDRCpSNhvADrBKZNenJ5N/XXGHoRLEXzIr8YEZ6Xy WtmC6RCvdc3414c7XOPtLYjLMsm5/t5isszYhDtb4PdfyR4Rfqlo2PSzPWSo/nThF6Tq 2Ahhnn6E/Y//jAI/GQoqXw+oI8fHs1YPCvwYsGQXBqiBqzn6nIJBvonLKc82SLbvVwSa SdJ6jXNeCVPUZM/xFBwV4P7ckaajNJgdhZAakzaarI/H+TuHkgf4/R5qXlXFysEIfj5a Sf4Q==
X-Gm-Message-State: AElRT7Fen7KAbsbOMhMIv7XFSpe+0nQxA/xSB0/+VJwH/SdwhYgjTGt2 Dy+4k1dWP8va+WUJ5BRJ7QtAagKjeTcXO/jboAfYdw==
X-Google-Smtp-Source: AG47ELveXrL8V5OsfM1itfhXxMPpe8yGPQ+OpwFOVCehmNwlmfQqJ4AL6Y3/dyzg331uD1MKxnBHW+WVwGdVFJvqxqQ=
X-Received: by 10.55.198.153 with SMTP id s25mr11974208qkl.221.1521378458756; Sun, 18 Mar 2018 06:07:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.37.234 with HTTP; Sun, 18 Mar 2018 06:06:58 -0700 (PDT)
In-Reply-To: <36dee113-66a5-41cf-4d2c-14b86c70c88a@yaanatech.co.uk>
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 18 Mar 2018 13:06:58 +0000
Message-ID: <CABcZeBOjAMK9kgVvCrfaZDxmk0qH-PX83AkCodkcw9uwhEyJrQ@mail.gmail.com>
To: tony@yaanatech.co.uk
Cc: "patient@ietf.org" <patient@ietf.org>, Brian Witten <brian_witten@symantec.com>, "Diego R. Lopez" <diego.r.lopez@telefonica.com>
Content-Type: multipart/alternative; boundary="001a11430b289a79600567af86c3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/Ki0uJXQM2Be7mfJ_PxJyf_fITow>
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 13:07:41 -0000

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

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>;
> 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-ag
>> 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.
>
> -Ekr
>
>
>>
>>
>> --tony
>>
>>
>> _______________________________________________
>> PATIENT mailing list
>> PATIENT@ietf.org
>> https://www.ietf.org/mailman/listinfo/patient
>>
>
>
>
> _______________________________________________
> PATIENT mailing listPATIENT@ietf.orghttps://www.ietf.org/mailman/listinfo/patient
>
>
>