Re: [TLS] Enforcing Protocol Invariants

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 17 November 2018 20:45 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 B020C12872C for <tls@ietfa.amsl.com>; Sat, 17 Nov 2018 12:45:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sABbFZyXZ0sL for <tls@ietfa.amsl.com>; Sat, 17 Nov 2018 12:45:44 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B641F126BED for <tls@ietf.org>; Sat, 17 Nov 2018 12:45:44 -0800 (PST)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id CE569326535 for <tls@ietf.org>; Sat, 17 Nov 2018 15:45:42 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CANLjSvXD9_u1UDkRkaNc8fnr=iQYKq73c8j9huMEPnH0XzuU0Q@mail.gmail.com>
Date: Sat, 17 Nov 2018 15:45:41 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: "<tls@ietf.org>" <tls@ietf.org>
Message-Id: <D880B51B-ECAB-4158-A0EE-8FF67F9247EC@dukhovni.org>
References: <CAO7N=i0g9d9x5RdF_guKm3GDAxVRHSV+eHffs6kiJm6dWO7tvw@mail.gmail.com> <CANLjSvXD9_u1UDkRkaNc8fnr=iQYKq73c8j9huMEPnH0XzuU0Q@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/INTWt1LE8Wdf_WszoVI219M3RSg>
Subject: Re: [TLS] Enforcing Protocol Invariants
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 17 Nov 2018 20:45:47 -0000

> On Nov 17, 2018, at 6:07 AM, Lanlan Pan <abbypan@gmail.com>; wrote:
> 
> And TLS's distribute certificate exchange maybe better than DNSSEC's centralized trust anchor.

In principle, yes, when one carefully selects just the appropriate
trust anchor(s) for a given task.  Some applications do use specific
trust-anchors (internal corporate CAs) at least some of the time.

[ FWIW, TLS is trust-model agnostic, it is the WebPKI that uses the
  usual panoply of CAs. ]

In practice, one generally uses the Mozilla or similar trust bundle,
and so it is still centralized, except that now the attacker has a
choice of multiple central authorities to compromise.

So most of the time the WebPKI is weaker, but you sometimes have
a choice when you can limit the set of peers with which you need
to communicate.

With DNSSEC validating resolvers can also configure trust-anchors
at any point in the tree, which also allows for internal corporate
trust-anchors, and if some TLD or similar followed the RFC5011 key
rollover process used at the root, one could also track the TLD's
keys independently of the delegation from ICANN, but AFAIK this is
not presently a common TLD practice.

-- 
	Viktor.