Re: [Patient] DOJ first on encryption services

Eric Rescorla <ekr@rtfm.com> Tue, 03 July 2018 16:00 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 4BEAB13108B for <patient@ietfa.amsl.com>; Tue, 3 Jul 2018 09:00:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] 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 TaHsaqt1P4N4 for <patient@ietfa.amsl.com>; Tue, 3 Jul 2018 09:00:14 -0700 (PDT)
Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (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 E1FA4130EE5 for <patient@ietf.org>; Tue, 3 Jul 2018 09:00:13 -0700 (PDT)
Received: by mail-yb0-x231.google.com with SMTP id s1-v6so923095ybk.3 for <patient@ietf.org>; Tue, 03 Jul 2018 09:00:13 -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=XJVzDLdyHMO8tZAQm/LRlUMKR2LowJbUOOz3XBCp8lc=; b=wYE3m0AyMV6H5Sf41KUaayQctOt5FS3KdwyUQ3K0fR9nJ/vXVGKug6cM4Iu/tFrFZX 9d82wanmO5oVbvL3j3kjS/9NgsIZ48HBIeH1UWl5c0xTGtHPS8LlBY/GIiKi++KNl+oe nvnAMUoVi1LdUcMsIAxlMFMfnDf8G6ZvkLpnuk9IDgmj7BF4y2/ZkbjwibXVcsQn2pDP ymQcwgOd4KGvB8ho4/TCQfHgjDw0ARTBeY7N9oRxQk0iYD8ygO3iligyRsSMyGlwCa3r xpEUGj//hAgw+DvPfQvrQ4EgiSHlNq4Iboqj8MWfbdvzdBdcpo8FQy/UeSvTxEct7bo8 MG4w==
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=XJVzDLdyHMO8tZAQm/LRlUMKR2LowJbUOOz3XBCp8lc=; b=Qjd4RLF3EApvFpIEY8ORnAY8cYOBf1ylCIFdP/sgFdaGwctfe/znhku2YWTTM1ALgM uSU2Dg55RXt5MblcAov3BzOVltubWnwLJHNXI1u3GXRdzN9+tEmnQY+EgDfherZq1NbR zkiQ10SEALWGKRGaUmECTZGK/lh6lgFrQIR13oZYiX4zjDK1wjRN0PczVKjJ5586sRZH bcqi8NPm9oyR0aHjGCRbWZiM1spu10101VGCfW9SA8KWgMmLZg8wqwLVspPMq3p6G8GL ZvbcZ5Q74ostPMfAgL1v8XuekjEMQuNoZTVqvrvi6q8Lw54Z/z7zaYhG8HW/uEPqrwIc zj+w==
X-Gm-Message-State: APt69E1xJJPPyxgTibhmDs6hMdLEOckyu/ibMjFOVSTXpneOozdZPnzB Z0ckUix7ox/8TKZGl+yLFSagRHLuZiOI1f6x8hB2Ng==
X-Google-Smtp-Source: AAOMgpdO54TO37l+xUtqplqTWJkshrmtQy8DwKQHcWmvJeI7X+P2w5aJw8qPcMOb1MggtFs8ZIKkZEIJrs8Tfw7HoXo=
X-Received: by 2002:a25:acd0:: with SMTP id x16-v6mr15291583ybd.407.1530633613114; Tue, 03 Jul 2018 09:00:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 08:59:32 -0700 (PDT)
In-Reply-To: <CAHbuEH6Q8bQkzSKmLErYKm2usv3oaOV1VbNKyPRz_YrjN6T=3Q@mail.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> <36dee113-66a5-41cf-4d2c-14b86c70c88a@yaanatech.co.uk> <CABcZeBOjAMK9kgVvCrfaZDxmk0qH-PX83AkCodkcw9uwhEyJrQ@mail.gmail.com> <CAHbuEH6Q8bQkzSKmLErYKm2usv3oaOV1VbNKyPRz_YrjN6T=3Q@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 03 Jul 2018 08:59:32 -0700
Message-ID: <CABcZeBO+mWZKX6hZr9J5OpV3Z4PZrTkFzfQAPPiA=bCVobAP3w@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: tony@yaanatech.co.uk, "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="000000000000ca929e05701a6803"
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/Wf747R2TQQlETpQRx8I149xYxOQ>
Subject: Re: [Patient] DOJ first on encryption services
X-BeenThere: patient@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 03 Jul 2018 16:00:31 -0000

On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:

> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >
> > 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 posted a draft to encrypt SNI, see:
> https://www.ietf.org/mail-archive/web/tls/current/msg26468.html
>
> It targets the CDNs who host most of the web traffic in the US at
> least.  The right place to comment on this would be the TLS list of
> course, but since proposals are being posted, this is a reality and
> needs to be discussed.  Those using SNI need to make sure their use
> cases are clear and understood and argue the pros and cons.
>

Kathleen,

Thanks for pointing out this draft.

As they say, predictions are hard, especially about the future. In March,
the ESNI problem looked pretty intractable and then subsequently we had
this idea about why it might be workable.

-Ekr

Best regards,
> Kathleen
>
> >
> > -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-
> 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
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> PATIENT mailing list
> >> PATIENT@ietf.org
> >> https://www.ietf.org/mailman/listinfo/patient
> >>
> >>
> >
> >
> > _______________________________________________
> > PATIENT mailing list
> > PATIENT@ietf.org
> > https://www.ietf.org/mailman/listinfo/patient
> >
>
>
>
> --
>
> Best regards,
> Kathleen
>