IETF Logo Mail Archive

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

"David A. Cooper" <david.cooper@nist.gov> Wed, 25 October 2017 16:43 UTC

Return-Path: <david.cooper@nist.gov>
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 4B14C13F419 for <tls@ietfa.amsl.com>; Wed, 25 Oct 2017 09:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.488
X-Spam-Level:
X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 lZXIZjyjDRUA for <tls@ietfa.amsl.com>; Wed, 25 Oct 2017 09:43:07 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889C613941E for <tls@ietf.org>; Wed, 25 Oct 2017 09:43:07 -0700 (PDT)
Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 25 Oct 2017 12:42:58 -0400
Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Wed, 25 Oct 2017 12:43:05 -0400
Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v9PGgrjt021302 for <tls@ietf.org>; Wed, 25 Oct 2017 12:42:53 -0400
To: "tls@ietf.org" <tls@ietf.org>
References: <cde0e322-797c-56e8-8c8d-655248ed7974@nist.gov> <FB95CAC8-C967-4724-90FB-B7E609DADF45@akamai.com> <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com> <f741b067-e7af-5231-4bb1-a0c2d151e6bf@nist.gov> <E775B188-59A0-4D87-A70F-638A2AD4C307@akamai.com> <4f1b6a8d-688b-a286-6d0e-46f7f6a3cdd6@nist.gov> <EE940D69-7137-4957-8118-42DAFB173500@akamai.com> <CAL02cgQ-fd=LbwBqdrbDzeYDadMKW8S=o5t4BH6JOh00AUBdTg@mail.gmail.com>
From: "David A. Cooper" <david.cooper@nist.gov>
Message-ID: <3e91ea92-5d25-3467-c2b8-977a15b28daf@nist.gov>
Date: Wed, 25 Oct 2017 12:42:53 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAL02cgQ-fd=LbwBqdrbDzeYDadMKW8S=o5t4BH6JOh00AUBdTg@mail.gmail.com>
Content-Type: text/html; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-NIST-MailScanner-Information:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0gJzKp5CFMM42qesU6ceTPL8Uxw>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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, 25 Oct 2017 16:43:10 -0000

No, they would not prevent those other mechanisms. Where is your evidence that they would?

If the "attacker" controls the software that the client is using, then it would set up the software to not check public-key pinning or CT, if necessary. As Richard noted, this may not even require developing custom software. It may be as simple as distributing a standard browser with its own CA added as a "user-installed" root certificate.

In the case that the "attacker" has the cooperation of the server, and the client is using unmodified software, then the data sent between the client and server (including the server's certificate) would be no different than if the server wasn't allowing the "attacker" to have access to the data. There would be no information available to the client at all that would distinguish between scenarios in which the server either is or isn't allowing another party to have access to the data being transmitted over the TLS session.

If public-key pinning and CT would prevent other mechanisms from working, please explain in detail how they would do so. Or better yet, let's end this line of discussion and work on finding mutually agreeable solutions to the underlying problem.

On 10/25/2017 12:12 PM, Richard Barnes wrote:
On Wed, Oct 25, 2017 at 12:06 PM, Salz, Rich <rsalz@akamai.com> wrote:
> since those other means would be easier and more effective. You
    have done nothing to suggest otherwise.

Public-key pinning and CT seem like they would prevent those other mechanisms.  No?

Remember that non-default, user-installed root certificates are exempted from those mechanisms in all current browsers.

--Richard

 

_______________________________________________
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7Cdavid.cooper%40nist.gov%7C34fba4ba68ad4a98247b08d51bc32f07%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636445447487579558&sdata=Sw4WExpmZxWkGtjKnse9zimqJYQkL%2BM4OAPShHP%2FNmQ%3D&reserved=0" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/tls


v2.23.0 | Report a Bug | By Email