Re: [TLS] Draft RHRD
Nick Sullivan <nicholas.sullivan@gmail.com> Wed, 01 November 2017 16:10 UTC
Return-Path: <nicholas.sullivan@gmail.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 D3BFA13FEB7 for <tls@ietfa.amsl.com>; Wed, 1 Nov 2017 09:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 gXQ4QV-H7cAH for <tls@ietfa.amsl.com>; Wed, 1 Nov 2017 09:10:36 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c: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 60ECB13FE5C for <tls@ietf.org>; Wed, 1 Nov 2017 09:08:20 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id r196so5890213wmf.2 for <tls@ietf.org>; Wed, 01 Nov 2017 09:08:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=80Sax2bqZfWbP+S53rJ9Oxtq+vlcNfJouoT7Zmzx700=; b=bfMZuH9Hs8D36ZEkoDMjjNvWWe1FllrOCgwHblcK/UzzoXjEk9THUGSJw7H1weKacy uYTsDt7KXcmit0wPEy7G5DS8ROJPPl/n2Q2CMP0p9UqS0BJWlGgP72H1LoUkKXsQ1y24 y0UDAVsJQPGEjUjpmBcKzu4Ongdz9XFHYDmdJAxjWSWSu6AXOEP5Qh50wvrlhpj5basA lTkt/qar0ykAkXo3cqYHJoFyiA4Ys9+NbRejcXUBhA6gKv813z0tK7z64rrNTJwL/NG4 I+4K19doSQA0iFRmzhjLNQhfcW1p/FwYBcHN4Q2nsF/HIVFm16KjNp3/RAVrJ6Yp+qsN yioQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=80Sax2bqZfWbP+S53rJ9Oxtq+vlcNfJouoT7Zmzx700=; b=hOwVJnJPjHtIBbBjVOyqlfLRD3ANu9eHbEoCK/lpkKOhM8hbW1TvEvkqwPUqJvxVHH gFdIx8fIpEhWegorWNjPra6Y06dJIDpb1/t6Zv8BsbpUECAXoa3K7z0xkm4t7aXZf6CH KilKqfKNK/PVctXblMGdbDpT65/MUxPDKrSX07n/VVu0qeS2Yvh8Wb5u9gdoWx1g7ZC2 tpifMb5wJZ8C/FE5Q/d9KppSXkY9LWjCPRDqGQ615tOXG9DRLp6/21nkpizbl3OrbtR2 m+znwJ0IqrtRkFYQkYGpreBUv4b/2Yq5qHtmIJnerXZ3LOwf0UP3LI8H1/cSaic5UeMp +nhw==
X-Gm-Message-State: AMCzsaXK2mzGQ5r32lJA391t+IsjiL2kis/xOEg4g0I7SEcwep+Aihja X+pVAQFJ+iHBR5Ms4njbed2mrZKx2wZyJoPwpoI=
X-Google-Smtp-Source: ABhQp+Sb7aSusehKU1qLkrj7ZQ6uxMDA/vS89sll6mR6AWTefKF8lFMcmHNT6dS5ENKZpm9uhKG4EBoKWZhKhDhgHmA=
X-Received: by 10.28.87.17 with SMTP id l17mr616562wmb.158.1509552498649; Wed, 01 Nov 2017 09:08:18 -0700 (PDT)
MIME-Version: 1.0
References: <C2DD7992-0A5A-4970-8DDB-DBA651B4D6D7@akamai.com>
In-Reply-To: <C2DD7992-0A5A-4970-8DDB-DBA651B4D6D7@akamai.com>
From: Nick Sullivan <nicholas.sullivan@gmail.com>
Date: Wed, 01 Nov 2017 16:08:07 +0000
Message-ID: <CAOjisRzBarfdVPf4OaQ_7PeL+dGsv5stw-ofCPC2bGU16HHr_g@mail.gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11443a5273af4f055cee1488"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/U2kcPmMEMUOb1QQ4P5_X4bhIpSM>
Subject: Re: [TLS] Draft RHRD
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 01 Nov 2017 16:10:43 -0000
Rich, I think you're mixing things up a bit. There is no false comparison. I am not comparing draft-rhrd to the Wireshark option, they are fundamentally different. I'm comparing draft-rhrd to draft-green. The wireshark option requires storage of n keys to inspect n connections, both draft-rhrd and draft-green only require a single master key to inspect n connections. The Wireshark option is always possible with TLS, it just has scaling issues. You export the session keys on a connection-by-connection basis from one of the endpoints and can then use them to decrypt the transcript after the fact. This is possible with TLS 1.2, TLS 1.3 and every version of TLS that uses symmetric keys for encryption. This keeps TLS a two-party protocol, and is my preferred solution to datacenter visibility, and I assume Stephen's as well. There have been arguments here that this is not a tenable solution in some environments, but I haven't found them convincing for the datacenter visibility case. The other two options, the master key options draft-rhrd and draft-green, turn TLS into a quasi three-party protocol. Server operators can just implement draft-green (or a variant thereof that doesn't repeat DH keys, but instead generates them deterministically) no matter what the IETF says. It's not prohibited by TLS 1.3 either structurally or by policy. If datacenter operators want a master key option and there is no standard to use, they can just implement draft-green and the client will have no idea this is happening. Your rejection of the cleartext signal expresses implies a preference for draft-green over draft-rhrd, not a preference for the wireshark option over draft-rhrd. Without draft-rhrd, it's likely that draft-green gets implemented whether it's standardized or not and no client will be able to opt out or even know that it's happening. In the situation where draft-green become the de facto standard for key escrow in TLS, the public debates around national firewalls trying to force clients to opt into wiretapping will become moot, firewalls won't have to block users who have the cleartext signal, they'll just force servers to implement draft-green unbeknownst to users. Users won't have any option, or any knowledge that servers are using a master key to protect the confidentiality of their connection and that their security may be lessened because of it (compared to a Wireshark-type system which is more difficult to implement at nation-scale due to how many keys you need to manage). Furthermore, researchers won't be able to measure the prevalence of this type of technology. With draft-green, civil society goes dark, with draft-rhrd, there will be public data to inform a public debate. Nick On Wed, Nov 1, 2017 at 7:19 AM Salz, Rich <rsalz@akamai.com> wrote: > In https://www.ietf.org/mail-archive/web/tls/current/msg24789.html, Nick > Sullivan concluded: > > > > >- on the other hand using draft-rhrd is safer than allowing organizations > to hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with > non-forward-secret cipher suites > > > > I think this sets up a false comparison. Existing TLS 1.3 debugging > systems – Wireshark – can debug individual TLS sessions with the session > key information being made available. This is what the RHRD draft would > require an organization to do, but it adds the additional signaling that > the client is willing to allow it. The Wireshark example shows that the > signaling is not needed. Servers can unilaterally do it now. > > > > I maintain that the cleartext signal servers no useful purpose, except to > provide a mechanism for entities to segregate traffic. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] Draft RHRD Salz, Rich
- Re: [TLS] Draft RHRD Stephen Farrell
- Re: [TLS] Draft RHRD Russ Housley
- Re: [TLS] Draft RHRD Salz, Rich
- Re: [TLS] Draft RHRD Nick Sullivan
- Re: [TLS] Draft RHRD Salz, Rich