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

Paul Turner <PAUL.TURNER@venafi.com> Thu, 20 July 2017 15:29 UTC

Return-Path: <PAUL.TURNER@venafi.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 C5DD21318A3 for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 08:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
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 764VbsBFJJNB for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 08:29:06 -0700 (PDT)
Received: from mail.venafi.com (unknown [198.190.131.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544F5131746 for <tls@ietf.org>; Thu, 20 Jul 2017 08:29:06 -0700 (PDT)
Received: from AWS-EXG01.res.venafi.com (10.50.110.17) by SLC-EXG01.res.venafi.com (10.1.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Thu, 20 Jul 2017 09:29:04 -0600
Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by AWS-EXG01.res.venafi.com (10.50.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Thu, 20 Jul 2017 09:29:02 -0600
Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 20 Jul 2017 09:29:01 -0600
From: Paul Turner <PAUL.TURNER@venafi.com>
To: Tom Ritter <tom@ritter.vg>
CC: Yoav Nir <ynir.ietf@gmail.com>, IETF TLS <tls@ietf.org>
Thread-Topic: [TLS] Is there a way forward after today's hum?
Thread-Index: AQFQKzWnJzH4JA3szzi/CxpFoIjfXQF3s++XAXyk/AwCMzwq1AFKohfsAST5QOECNGnt5aMUJTCQ
Date: Thu, 20 Jul 2017 15:29:01 +0000
Message-ID: <6153a25746a246f9be26350adbc58213@venafi.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> <CA+cU71myamTTsmWUaO7DfzS_3-L1PQzrs03PgmseNjrKwdhHbQ@mail.gmail.com>
In-Reply-To: <CA+cU71myamTTsmWUaO7DfzS_3-L1PQzrs03PgmseNjrKwdhHbQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [70.197.8.30]
Content-Type: multipart/alternative; boundary="_000_6153a25746a246f9be26350adbc58213venaficom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ya9oDsCLGpgqdVLu8DEyg3gsBLE>
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:29:08 -0000




-----Original Message-----
From: Tom Ritter [mailto:tom@ritter.vg]
Sent: Thursday, July 20, 2017 11:20
To: Paul Turner <pturner@equio.com>
Cc: Yoav Nir <ynir.ietf@gmail.com>; IETF TLS <tls@ietf.org>
Subject: Re: [TLS] Is there a way forward after today's hum?



On 20 July 2017 at 10:07, Paul Turner <pturner@equio.com<mailto: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."



Thanks for this clarification. I agree that anything is possible in both directions. Russ opened this discussion by asking about an alternative to static DH. In this model, I’ve assumed the client would need to explicitly opt-in by including an extension in its ClientHello. There are obviously details to work out but if it were possible to provide a method like that, it seems like it would thwart the second option. Would it?



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