Re: [TLS] Is there a way forward after today's hum?

Tom Ritter <tom@ritter.vg> Thu, 20 July 2017 15:20 UTC

Return-Path: <tom@ritter.vg>
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 65821131CE6 for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 08:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg
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 YWL-AReFren3 for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 08:20:13 -0700 (PDT)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 8B692131CFE for <tls@ietf.org>; Thu, 20 Jul 2017 08:20:13 -0700 (PDT)
Received: by mail-ua0-x22a.google.com with SMTP id 80so25640819uas.0 for <tls@ietf.org>; Thu, 20 Jul 2017 08:20:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=67J3j0/nzb49wKQDf6RRM0kFk8fln9Y998LPZRt1Wv8=; b=rSRZIJNaV4cdVRbU0gtwHy39RCdlKPtmLwrXlRN2t97r4mCebcdbXOV6knug/W+gge Hq9kpkg9SgkOPXDto6/R5XQ0vNOCLVuMjv6uxxTaejLQuvQGZDKFCeL3JgGiZGK8ZyuN 0yZ8d15Ks3syJAnnb1lBP1KtdEOVbZK4VMBDs=
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:content-transfer-encoding; bh=67J3j0/nzb49wKQDf6RRM0kFk8fln9Y998LPZRt1Wv8=; b=uWJeNL1ivjhYoAS9GdRqGAFp1Oi8ABWL5hJvFKMUhbbEjGdJc06fSvFJviFTe9JYzP GGVr7nY8fVH0m7WvUuU9Qc4amM51DCFJQqwtrSnx/1cGdolzNL79ZljfWSntqu1NfgFM XtYejx9KXRAcRlllpD+DYYiNGwpB52PNRGNTHn+hy2nF36GzqPwzeUTVpGhIPYuOwFK8 uODaqpYqqwPeU24L1qUPifWWtJiCLXrP5qTLp3H2VxK06omTgwlzGYjdkmePX3l+4hvf X7t1+YJA4oM4AS2/gk4ybFgYCX2eRM9BAGw56mOMa3fOVidKI+iXpNZKj+zSy/09VNxw C+Tw==
X-Gm-Message-State: AIVw111zrhnXp6dk1nK0uO+NWWoVhEeIN9pRPFFo5IIMvSRWQMYPnzIy 1f8nINGoaD76d/V5QKTk3JE/7ZmrGUhGz4Q=
X-Received: by 10.159.37.100 with SMTP id 91mr2511853uaz.147.1500564012515; Thu, 20 Jul 2017 08:20:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.65.195 with HTTP; Thu, 20 Jul 2017 08:19:51 -0700 (PDT)
In-Reply-To: <01a201d30169$f8c68530$ea538f90$@equio.com>
References: <E6D7DDCD-FDE6-4784-ACE8-0F5AC8E2CEDF@vigilsec.com> <CAPt1N1ka=vuoZMB58LXfkJ_qafohf08WeoUs2y4kaCxBtCx29Q@mail.gmail.com> <EEBF938A-234C-43E3-B058-4AE443C66EF0@vigilsec.com> <EF9F84E0-2C71-4A73-989E-1EC6B86861ED@gmail.com> <CA+cU71kM-u4JxJU8_9ogK0MbnNcy=y5-y-5FzkL8TEV_JaAK8Q@mail.gmail.com> <01a201d30169$f8c68530$ea538f90$@equio.com>
From: Tom Ritter <tom@ritter.vg>
Date: Thu, 20 Jul 2017 10:19:51 -0500
Message-ID: <CA+cU71myamTTsmWUaO7DfzS_3-L1PQzrs03PgmseNjrKwdhHbQ@mail.gmail.com>
To: Paul Turner <pturner@equio.com>
Cc: Yoav Nir <ynir.ietf@gmail.com>, IETF TLS <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lEO6YNc6JDS84iidSi9KjRO2Ako>
Subject: Re: [TLS] Is there a way forward after today's hum?
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: Thu, 20 Jul 2017 15:20:18 -0000

On 20 July 2017 at 10:07, Paul Turner <pturner@equio.com> wrote:
> It seems like that problem exists today with TLS 1.3. If a government is
> powerful enough to mandate key escrow, wouldn’t they also be power enough to
> mandate implementing static DH with TLS 1.3 (so that they key escrow is
> possible). In addition, based on this level of influence, couldn’t they
> alternatively require TLS server owners to provide them unencrypted data.


Anything's possible, but it there's a difference between:

"I demand you implement a new mechanism to securely ship me crypto
keys or plaintext, do something for which there is no standard
mechanism or agreement."

and

"If you flip this existing setting right here in OpenSSL, and stick
this public key right here, it will automatically satisfy our
requirements."

I recall one of the arguments that Apple made against the FBI was that
they were asking them to do something novel that required significant
amounts of work, testing, had never been done before, etc. IANAL but I
think this is standard argument to show the request is unreasonable
and overly burdensome. Removing that argument concerns me.
(US-centric view if that isn't apparent.)

-tom