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

Tom Ritter <tom@ritter.vg> Thu, 20 July 2017 14:44 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 C38E0131CAE for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 07:44:06 -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 OJAULMcIYepe for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 07:44:03 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 BC440131C83 for <tls@ietf.org>; Thu, 20 Jul 2017 07:44:03 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id w45so24702192uac.5 for <tls@ietf.org>; Thu, 20 Jul 2017 07:44:03 -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=bhHpa1yoWhq2Ky6UdDsd/Y9o+7VC54gnz3H7k/bf3Cs=; b=AlubfjFToRWL/0RBAcwx7Q2ftYD81wPlbxrbNcdQQAca54fcioIWOyeTBKndNDIIQz taatq5dzQtouJZvJeRlQDCyLCAaQADVRUn/tf/sYhKh/wu/KPJXezjq0yThqjMaYiTT8 qWiMTfB4CzseFyQMd1i0FQyoI1dSsDpc6cBug=
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=bhHpa1yoWhq2Ky6UdDsd/Y9o+7VC54gnz3H7k/bf3Cs=; b=QulPl4gKsk1aol+Nop+r4cfO9aJrDfABZyfJZ+GM5BzxuVU4iwpAs2aVgl2TL9IlPh VjyPtk2iv3bsZdHzSRWlvhkHFc4fucWGfDzy8HEEBnXFPDJU9G5JHobIyAwnsQCpuxU6 Ds4Z32IvgqypGcrUORrKEYJFmlyiKjeXWiFrfKpStprfkALtr1mzM3142cDoESSKG3h9 nDhpSgcQn7JbdCyxWnWAioEwZyNpPpV5SHEi+/poqAe5frrM7U44H7ejfd7E7vLNMJfc uNu+Xe5gTzlRpk5PDJucMokR9TVraL83NKuwkLXD4H3Aq4BkDyymVrHhY7BZgr6ck6Pb oRAQ==
X-Gm-Message-State: AIVw112EjJg8vKBe4cJcMFivZFoDEiiXYPgQAQXN+QMhUllXqkRwHLTw 5mYWgAUf4pw7HM3G2fUs54NKl1zu23KR
X-Received: by 10.159.37.100 with SMTP id 91mr2439756uaz.147.1500561842600; Thu, 20 Jul 2017 07:44:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.65.195 with HTTP; Thu, 20 Jul 2017 07:43:41 -0700 (PDT)
In-Reply-To: <EF9F84E0-2C71-4A73-989E-1EC6B86861ED@gmail.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>
From: Tom Ritter <tom@ritter.vg>
Date: Thu, 20 Jul 2017 09:43:41 -0500
Message-ID: <CA+cU71kM-u4JxJU8_9ogK0MbnNcy=y5-y-5FzkL8TEV_JaAK8Q@mail.gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: Russ Housley <housley@vigilsec.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/LwhSQMJ14GON9g_8CZoOTmQm27o>
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 14:44:07 -0000

On 20 July 2017 at 01:53, Yoav Nir <ynir.ietf@gmail.com> wrote:
>
> On 20 Jul 2017, at 8:01, Russ Housley <housley@vigilsec.com> wrote:
>
> Ted, if we use a new extension, then the server cannot include it unless the
> client offered it first.  I am thinking of an approach where the server
> would include information needed by the decryptor in the response.  So, if
> the client did not offer the extension, it would be a TLS protocol violation
> for the server to include it.
>
>
> So we also add an alert called “key-export-needed” in case the client does
> not include it.
>
> That way a browser (as an example) can show the user why the connection was
> broken (“server requires wiretapping to be enabled. Go to about:config if
> that is OK and change the allow-wiretap setting to True”)


I previously expressed that I could support the extension mechanism -
I'm sympathetic to regulatory requirements and unhappy with, although
understanding of, what has become the 'standard mechanism' (breaking
crypto) to achieve them. I've looked at more than one 'end to end'
encrypted messenger that tosses in the 'third end' of key escrow.

But to suggest such a mechanism might ever be implemented in a web
browser throws my hackles up. The discussion has always been about
datacenter - the people concerned say "We don't want your datacenter
stuff in our protocol and the proponents say "No really, we only care
about the datacenter."

The concerns around some future government-mandated key escrow is very
real and very concerning.

-tom