Re: [TLS] Encrypted SNI

Eric Rescorla <ekr@rtfm.com> Tue, 03 July 2018 21:12 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEBF130E22 for <tls@ietfa.amsl.com>; Tue, 3 Jul 2018 14:12:05 -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 wRe7xu3w9ofF for <tls@ietfa.amsl.com>; Tue, 3 Jul 2018 14:12:02 -0700 (PDT)
Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (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 BFD62130E0F for <tls@ietf.org>; Tue, 3 Jul 2018 14:12:01 -0700 (PDT)
Received: by mail-yb0-x22d.google.com with SMTP id s8-v6so1274394ybe.8 for <tls@ietf.org>; Tue, 03 Jul 2018 14:12:01 -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=+XVjdyTMcFYiL4v9AFlvyPbqhyc2eYU28hOe0g7yD/Q=; b=QVMwpr9LsnSsGNfaT1jyce/VtH+A8Bo2uuG44np3LhAab7pU7WeerYmw6V7q+7/h+d J38F6u9pSKYjdWurCnSpZAWViRctENIUqxazJYVt1/ZMYymLjNlo9FD06RsftrFfv3Gv gEr7ru+0Uknx3Frp4+vb2UgDHHrrk2j9wJ3sKm1GZRFNUyE4TiFd8QrzhODe45CLSm/K d4VeW41pS34OZxMfqUwj2Ca3aaXILaxs//eGcNyoYlMO8OUgUabl+un5+XEEBeQR5v9a 4DPTi1Xq4xHXotlIOF8/eEd0/fZYmj51ThuU5GMtVUpUw+Zn0dKXSRo/hXdnAF0vgeuY o0XQ==
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=+XVjdyTMcFYiL4v9AFlvyPbqhyc2eYU28hOe0g7yD/Q=; b=LsN4W2gU9MPLEsNCdmc9LDwsXWvzjEDpgEv2B8NN4fpSf4ed1ojLRAySo0F/NR3i3e cVXtyw0cw4rALODDmLaGBmoAUHc0tFM8QzDmdEApimfztHaPPCy0EBKKx1Ol9hpeQNCn mDY2SRbUHCmzIfB0wO1s6yi101j1kXZDsAxDEprUjMIwxPpVcGU/tadAb1JwUExR0Kcd 54DQxD6TSdFOdhzf1rABrVxBq/4KkZ2xk9/ZJF5FGRoObXXjFPd3QcPPzKjEKVb1nl3u d9xCIH6jXKwIQyGzqkQ/9ApEsruIM5OusDr7qW7exGPDga1KsYmIOspUDBX4n+l8G42m oDfw==
X-Gm-Message-State: APt69E1JhmJHakG55PVwvnYNdVR4jdF963HDs0+97lYW6R+tXmXIan1z o7kKFr6ZLN+/EhEymL8GWABvH2XZAHtVVSxSOv37DQ==
X-Google-Smtp-Source: AAOMgpe2vAbl0F/pTdf8+uWlw3rVg+3szXBdRqXA7BGqoHJKSUnSSmr1HRX0ZGTkpSh45RNfCHoLOIxAR9jjNzwgODg=
X-Received: by 2002:a25:acd0:: with SMTP id x16-v6mr15923314ybd.407.1530652320923; Tue, 03 Jul 2018 14:12:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 14:11:20 -0700 (PDT)
In-Reply-To: <F4966CAA-454B-4152-A9E5-EA9714978CEA@gmail.com>
References: <F4966CAA-454B-4152-A9E5-EA9714978CEA@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 3 Jul 2018 14:11:20 -0700
Message-ID: <CABcZeBPee4dVZBdgcTvT-vuzudnXcx_fW6aDdLTV_J5Z+HYX0w@mail.gmail.com>
To: Bret Jordan <jordan.ietf@gmail.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dd1d3105701ec307"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2aCfACWyu7b6DoNBdiM_HnWC7Kk>
Subject: Re: [TLS] Encrypted SNI
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jul 2018 21:12:05 -0000

On Tue, Jul 3, 2018 at 10:08 AM, Bret Jordan <jordan.ietf@gmail.com>; wrote:

> From a discussion on the PATIENT list found here: https://www.ietf.org/mai
> l-archive/web/patient/current/msg00078.html
>
>
> From my personal perspective, we need to be careful with all of these
> efforts. It feels like the pendulum has swung so far to one side, the side
> of privacy-at-any-cost, that we are unknowingly increasing the risk to
> individuals and organizations by enabling threat actors and intrusions sets
> to attack networks and clients without any level of protection from the
> network.
>
> It also feels like a lot of these initiatives are being done without
> adequately involving and ensuring that enterprise networks and critical
> infrastructure can work with these changes. Question, do we know how these
> ideas and changes are going to impact an organizations ability to fulfill
> their requirements for regulatory compliance?
>

Well "these changes" covers a lot of ground, but in this particular case,
can't enterprise just strip ESNI records from DNS?

-Ekr



> The IETF work needs to do more outreach with enterprise networks and
> critical infrastructure and be fundamentally more inclusive.
>



Privacy-at-any-cost is not a holistic design.
>
> Thanks,
> Bret
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that
> can not be unscrambled is an egg."
>
>
>
> ### Copied content from the PATIENT discussion ####
>
>
> On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty <kathleen.moriarty.ietf
> at gmail.com> wrote:
>
>> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla <ekr at rtfm.com> wrote:
>> >
>> >
>> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski <tony at 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 at
>> 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-twitte
>> r-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 at ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/patient
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> PATIENT mailing list
>> >> PATIENT at ietf.org
>> >> https://www.ietf.org/mailman/listinfo/patient
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > PATIENT mailing list
>> > PATIENT at ietf.org
>> > https://www.ietf.org/mailman/listinfo/patient
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>