Re: [Patient] DOJ first on encryption services

Bret Jordan <jordan.ietf@gmail.com> Sun, 18 March 2018 13:04 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 EA8EA127871 for <patient@ietfa.amsl.com>; Sun, 18 Mar 2018 06:04:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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 es57RssiE96P for <patient@ietfa.amsl.com>; Sun, 18 Mar 2018 06:04:31 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 C020B1204DA for <patient@ietf.org>; Sun, 18 Mar 2018 06:04:30 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id d10so15945073wrf.3 for <patient@ietf.org>; Sun, 18 Mar 2018 06:04:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1Aq8rh7NN7Y9C03G4RCj+M/o/dKIdZQ6I2rEozI1KBY=; b=kFOQJw0HsxFf7IsDy8QxiYlT6VT+sPvHol5gibTh83ymAaQN6Y9goNRlwZ/Fqi84Xf Xt6Bj09SZoTtClJFbgrLZu+TAlhBHiRwCFCGnzjllkAEGet1hVhNkXpJM3wbdPlhhT8i cuugQeUOxZrXKYLu/IH8U8LAtAPRBLtfw1JIpx5scnhB9gSMV3+lqsZl6VuZ6xCQ+a7V M8JBi2sxvD3m9snP5BgyuK0wrO33qET78OWJ5cFwOPb5y5ZoaIW2ZZar8v9sMDeWob1b Yidmm9oCdFkSo/fzoOLiCF/LQjemKhi4HrPl4X7+wxXXDzez1eTWztJ5RUZyrONgi2vw G4ZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1Aq8rh7NN7Y9C03G4RCj+M/o/dKIdZQ6I2rEozI1KBY=; b=ENEm7eAMwq3D0R+eIWa842oV7Z/d8+v1gEoH7XytzK+bYfyzkmaiIDfZJZWUf6licr ZRx4f2DIHAfW1TYgA4rEoo0OKOeaYAdtccp4JsfuUsB/69KKM35GHpW8HctndY/ZSKRx xh42C8g6kq8i980GyeaI5MUyMgRzNUT61FY5kBybyWVHKHGXlUXojDwQdbAYbgFppFow OpupJg6tVtKSF0U2LrFqe+gixk1wiwME8oeK3deZ0wZLptovX9w3GzaFK6uhb2A099vl sNxncvOT4RKFFypzkpIzcozqp0WM2FfnCMRpMUWmGlgcoXpLxWDf5lDkURcOYflwBWN1 PRkg==
X-Gm-Message-State: AElRT7Gj7sMWbb0xQPEj17B2M0TDSOC5MD/94+XjvyEojvZcNwQFWmvg /NDM5RXVWAWk34+ApT2jtuqHnOHo
X-Google-Smtp-Source: AG47ELvqfz90O/gITv6kunIjsXw1Lg+a6DZ0co4qTrUgcxxyzeacmp6AOhZ4IP6CsCzQIpOJMZgy7Q==
X-Received: by 10.223.132.197 with SMTP id 63mr6423965wrg.166.1521378269251; Sun, 18 Mar 2018 06:04:29 -0700 (PDT)
Received: from [172.20.2.29] ([167.98.10.68]) by smtp.gmail.com with ESMTPSA id e10sm12276717wrh.38.2018.03.18.06.04.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Mar 2018 06:04:28 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-02247A75-27CB-4257-B009-EEFDC271145A
Mime-Version: 1.0 (1.0)
From: Bret Jordan <jordan.ietf@gmail.com>
X-Mailer: iPhone Mail (15D100)
In-Reply-To: <CABcZeBMTa0Frgk3g8LwWNDZ80iV6nK=bBePpknRvLpVLrDGF-w@mail.gmail.com>
Date: Sun, 18 Mar 2018 13:04:27 +0000
Cc: "Diego R. Lopez" <diego.r.lopez@telefonica.com>, "patient@ietf.org" <patient@ietf.org>, "tony@yaanatech.co.uk" <tony@yaanatech.co.uk>, Brian Witten <brian_witten@symantec.com>
Content-Transfer-Encoding: 7bit
Message-Id: <387BE77C-3DFA-4880-AC58-DEF091A37024@gmail.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> <62E37C99-A74D-407C-99A3-00AA253BC218@telefonica.com> <CABcZeBMTa0Frgk3g8LwWNDZ80iV6nK=bBePpknRvLpVLrDGF-w@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/8HyM6M4d8a6m8i9QA_G7586rbZA>
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:04:34 -0000

Ekr,

How does the encrypted SNI work fit in to this holistically?  

Bret

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

> On Mar 18, 2018, at 12:54 PM, Eric Rescorla <ekr@rtfm.com>; wrote:
> 
>> On Sun, Mar 18, 2018 at 12:51 PM, Diego R. Lopez <diego.r.lopez@telefonica.com>; wrote:
>> Hmmm… The SNI would be a much weaker evidence than the server certificate, wouldn’t it?
>> 
> 
> This comes up a lot, but no. The basic issue is that there are two types of clients
> 
> 1. You have an ordinary client (e.g., a Web client)
> 2. You have a client which was really written by the attacker.
> 
> In the former case, SNI will appear and the client will enforce that the certificate and SNI match up, so you don't need the certificate. In the latter case, the client can of course lie about SNI, but then you can also just apparently do TLS 1.2 but actually encrypt the plaintext with some key that's been externally arranged, while generating a valid TLS 1.2 transcript. So, in neither case does the certificate really help.
> 
> Adam Langley did a good job of explaining this in more detail:
> https://www.imperialviolet.org/2018/03/10/tls13.html
> 
> -Ekr
> 
>>  
>> 
>> --
>> 
>> "Esta vez no fallaremos, Doctor Infierno"
>> 
>>  
>> 
>> Dr Diego R. Lopez
>> 
>> Telefonica I+D
>> 
>> https://www.linkedin.com/in/dr2lopez/ 
>> 
>>  
>> 
>> e-mail: diego.r.lopez@telefonica.com
>> 
>> Tel:         +34 913 129 041
>> 
>> Mobile:  +34 682 051 091
>> 
>> ----------------------------------
>> 
>> On 18/03/2018, 12:46, "Eric Rescorla" <ekr@rtfm.com>; 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-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
>> https://www.ietf.org/mailman/listinfo/patient
>> 
>>  
>> 
>> 
>> 
>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
>> 
>> The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
>> 
>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
> 
> _______________________________________________
> PATIENT mailing list
> PATIENT@ietf.org
> https://www.ietf.org/mailman/listinfo/patient