IETF Logo Mail Archive

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

"Paul Turner" <pturner@equio.com> Thu, 20 July 2017 15:08 UTC

Return-Path: <pturner@equio.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 A6DA7131CC2 for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 08:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 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_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=equio-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 PGvCA0QqSeIc for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 08:08:01 -0700 (PDT)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 16987131532 for <tls@ietf.org>; Thu, 20 Jul 2017 08:08:01 -0700 (PDT)
Received: by mail-pf0-x22d.google.com with SMTP id e199so13279710pfh.2 for <tls@ietf.org>; Thu, 20 Jul 2017 08:08:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=equio-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=ozcVyRaUw3ugqQ89yg0IcoEeWloioegbi9NLOJLS0kc=; b=MLamE9mPQHu4+PWer+l3tpCDxccngUHs2M8bNPpncIJBOq/xGfy4EidZPXrT3ym+JB 2dz29vpDqzWqpNqk/KjYIEOKlHQPf69Y9AREEvC4xqj7lhGZXNljRKvFbYGCfgjDKCOU vyU3mKMh9EvU//xBLCHnXNtBt1cBDWHn53NZK+HdhlaSZ19g8ckEDoMmfG6NGwgUQThF gBxkrJ2KkZRd1PGoWtsSj9qRbBgHxRxzDBBcKKbBD1JwXmwvxFAsUCF4g3LhoSLq5/8F V+kXWkDuoKgQvs4cYeDgjBzbjNdsM4dEP7hiVdCuIAfuVDME1j0UAREEMiD7LyUNPBHk 405Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=ozcVyRaUw3ugqQ89yg0IcoEeWloioegbi9NLOJLS0kc=; b=odQP9a/TZ/llp9W8uiktcCWNU68ciw8lTg2xqLcjuL/RuwpB9EZ2xJ1nwgscTYWEAY A99dFa9tGgprlvm+ZKfyrY95E7sbvA7UCj030IFF4BsnNsVXI4Bo4m4Zwp5gYf+Q5Eco jZNo3UGJLaC7tLAWRMAUfIaiyBBcugz6QqPSGJtGvrf1DRaBlmK4HrsX+j7AjrGLrua6 F0b1EFweGNkluSU9uJtToznB3EwuquHafCyXYYVwMw/dIHiU1HIq0HLrEwZ6jeEQPEAQ Nwn3I8Vl9V0DL4NDsRDxnIywARTbA6kvsYNEuAWMUKuA3wJRwruOSBrgs4MdkmXFRYPs 6jJA==
X-Gm-Message-State: AIVw110tmQtqFHE9qL5UulkgrPupg01y4EdFjazwSuuQ5k1ma5M2NrSg a6b6QEe9NxvDDNqaNstIfQ==
X-Received: by 10.99.102.68 with SMTP id a65mr4140966pgc.252.1500563280116; Thu, 20 Jul 2017 08:08:00 -0700 (PDT)
Received: from 07WKSWIN150119 (30.sub-70-197-8.myvzw.com. [70.197.8.30]) by smtp.gmail.com with ESMTPSA id j193sm5049131pfc.95.2017.07.20.08.07.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 08:07:58 -0700 (PDT)
From: Paul Turner <pturner@equio.com>
To: 'Tom Ritter' <tom@ritter.vg>, 'Yoav Nir' <ynir.ietf@gmail.com>
Cc: 'IETF TLS' <tls@ietf.org>
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>
In-Reply-To: <CA+cU71kM-u4JxJU8_9ogK0MbnNcy=y5-y-5FzkL8TEV_JaAK8Q@mail.gmail.com>
Date: Thu, 20 Jul 2017 11:07:52 -0400
Message-ID: <01a201d30169$f8c68530$ea538f90$@equio.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A3_01D30148.71B72F20"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQFQKzWnUe0W/VWuIePV8AuCJ9hOWgF3s++XAXyk/AwCMzwq1AFKohfsoy7plRA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fttnxrwosiwfj0yBMUu4w52u-sA>
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:08:03 -0000

 

 

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Tom Ritter
Sent: Thursday, July 20, 2017 10:44
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] Is there a way forward after today's hum?

 

On 20 July 2017 at 01:53, Yoav Nir < <mailto:ynir.ietf@gmail.com> ynir.ietf@gmail.com> wrote:

> 

> On 20 Jul 2017, at 8:01, Russ Housley < <mailto:housley@vigilsec.com> 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.

 

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. 

 

-tom

 

_______________________________________________

TLS mailing list

 <mailto:TLS@ietf.org> TLS@ietf.org

 <https://www.ietf.org/mailman/listinfo/tls> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email