Re: [Patient] DOJ first on encryption services

Eric Rescorla <ekr@rtfm.com> Sun, 18 March 2018 12:55 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 40FF9127873 for <patient@ietfa.amsl.com>; Sun, 18 Mar 2018 05:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] 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 oontZrcudCLv for <patient@ietfa.amsl.com>; Sun, 18 Mar 2018 05:55:03 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 CB15B1270A3 for <patient@ietf.org>; Sun, 18 Mar 2018 05:55:02 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id y6so15382033qtm.7 for <patient@ietf.org>; Sun, 18 Mar 2018 05:55:02 -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=O/dCjH6sAoM/B4ie3Ho9QP+PxQthDNjq5A0i8RXmbzA=; b=1p/mb+Jq3s8fPajwU10Ap9LnRr2lpA7xp95vsC+/iMWkuUucyWbrFaJ662ucVG6WTw SZE2UtSgP/+6N+R/lrHlt+mpr+BqI7w4uJhZNk4DMEYPK6xb80waFPTqemHYQ7/Gow3D bS80Nu3JXVjxjT1wt4lSLgd6p73hw73dnPSTQFzKSqoeXz4y+3MdFSFTM5Xze7tx7jL4 OQRKpqWhn/fYK/Hk2U/A6L9Rjn1gGgKGpLT7onBETGao7+TVameFRuJ/O/hWDrDpRSBw PevpmZDuXHTMSf7IGZAbTOQXORwF/CKOYru93lk1zrdk3Fm2xUzPyR1IunY/d0cJyi7O eglw==
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=O/dCjH6sAoM/B4ie3Ho9QP+PxQthDNjq5A0i8RXmbzA=; b=ojKjFskCYH/w7lguz1x8JqACzNkZRSkhsiG6WS5y4cweFW8r+Im/bsqG9e3PqDbGSf qPNQnqUWjfc6SVJMJxHVeSRqycDJdEw4sWP18WdvWrpTlpHqN0s2dzAvbgjNxw9gY9CX gtbOPnWQzkkEiBJp2DT6kIAwdMvl9Uc9rZ7cCCL5LFY6yFRX736B9nPW8vqvjO6n5nkL WTN2mIwenHnhekKFIHjHnbf0ZkYiehUIqDgqqh5IVXzSUo0SHMWO0SGefzbkZ5gp3sBa 4o5bx+64kSmhTS69SJgFR0ARcRaC6p91DS7dgEkejECC0diGnP8tvRjilvEBQ0FHfoG2 0lAA==
X-Gm-Message-State: AElRT7HGiPvPzW9+adcn4uxVwTSKWACx0jDvkLKl5tx1Qiwp2vpiyuXl 4qQqOIMWpr4tIRPJqmKNwfqZHI+YpxaqbGEaPcNyjA==
X-Google-Smtp-Source: AG47ELshfe5uYkUIzvSli2kygb7sAcVShGW19w1L8PmgNE2xb7i5PqigJvfuRpVtlrwN97jV7p34O3WvpvJvzPbe2E8=
X-Received: by 10.237.44.100 with SMTP id f91mr13196716qtd.80.1521377701791; Sun, 18 Mar 2018 05:55:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.37.234 with HTTP; Sun, 18 Mar 2018 05:54:21 -0700 (PDT)
In-Reply-To: <62E37C99-A74D-407C-99A3-00AA253BC218@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> <62E37C99-A74D-407C-99A3-00AA253BC218@telefonica.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 18 Mar 2018 12:54:21 +0000
Message-ID: <CABcZeBMTa0Frgk3g8LwWNDZ80iV6nK=bBePpknRvLpVLrDGF-w@mail.gmail.com>
To: "Diego R. Lopez" <diego.r.lopez@telefonica.com>
Cc: "tony@yaanatech.co.uk" <tony@yaanatech.co.uk>, Brian Witten <brian_witten@symantec.com>, "patient@ietf.org" <patient@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c05df4a7c26a30567af59fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/rEh3GT3-ibEzM7T3F74-CBO3yPo>
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:55:06 -0000

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 <+34%20913%2012%2090%2041>
>
> Mobile:  +34 682 051 091 <+34%20682%2005%2010%2091>
>
> ----------------------------------
>
> 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
>