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.
- [TLS] Enforcing Protocol Invariants Ryan Carboni
- Re: [TLS] Enforcing Protocol Invariants Salz, Rich
- Re: [TLS] Enforcing Protocol Invariants Ryan Carboni
- Re: [TLS] Enforcing Protocol Invariants Eric Rescorla
- Re: [TLS] Enforcing Protocol Invariants Viktor Dukhovni
- Re: [TLS] Enforcing Protocol Invariants Jim Reid
- [TLS] Enforcing Protocol Invariants Ryan Carboni
- Re: [TLS] Enforcing Protocol Invariants Eric Rescorla
- Re: [TLS] Enforcing Protocol Invariants Dmitry Belyavsky
- Re: [TLS] Enforcing Protocol Invariants Viktor Dukhovni
- Re: [TLS] Enforcing Protocol Invariants Patrick Mevzek
- Re: [TLS] Enforcing Protocol Invariants Ryan Carboni
- Re: [TLS] Enforcing Protocol Invariants Eric Mill
- Re: [TLS] Enforcing Protocol Invariants Eric Rescorla
- Re: [TLS] Enforcing Protocol Invariants Daniel Kahn Gillmor
- Re: [TLS] Enforcing Protocol Invariants Tony Arcieri
- Re: [TLS] Enforcing Protocol Invariants Viktor Dukhovni
- Re: [TLS] Enforcing Protocol Invariants Hubert Kario
- Re: [TLS] Enforcing Protocol Invariants Lanlan Pan
- Re: [TLS] Enforcing Protocol Invariants Viktor Dukhovni
- Re: [TLS] Enforcing Protocol Invariants Salz, Rich
- Re: [TLS] Enforcing Protocol Invariants Viktor Dukhovni
- Re: [TLS] Enforcing Protocol Invariants Salz, Rich
- Re: [TLS] Enforcing Protocol Invariants Christopher Wood
- Re: [TLS] Enforcing Protocol Invariants Viktor Dukhovni
- Re: [TLS] Enforcing Protocol Invariants Hannes Tschofenig