Re: [TLS] Enforcing Protocol Invariants

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 12 November 2018 23:14 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 8066E130E77 for <tls@ietfa.amsl.com>; Mon, 12 Nov 2018 15:14:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 Gk0jFG2K21ru for <tls@ietfa.amsl.com>; Mon, 12 Nov 2018 15:14:00 -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 A8B46130E68 for <tls@ietf.org>; Mon, 12 Nov 2018 15:14:00 -0800 (PST)
Received: from [10.200.18.148] (unknown [38.27.161.17]) (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 94C593108DF for <tls@ietf.org>; Mon, 12 Nov 2018 18:13:59 -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: <CAHOTMVKrfbmxJ-gk+dR_XaozjX=BJqmEpmHEFAs2GuMi4MBMMA@mail.gmail.com>
Date: Mon, 12 Nov 2018 18:13:58 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: "<tls@ietf.org>" <tls@ietf.org>
Message-Id: <2168AD22-D717-48B5-9370-26E72B4ECF86@dukhovni.org>
References: <CAO7N=i0g9d9x5RdF_guKm3GDAxVRHSV+eHffs6kiJm6dWO7tvw@mail.gmail.com> <CAHOTMVKrfbmxJ-gk+dR_XaozjX=BJqmEpmHEFAs2GuMi4MBMMA@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/y3UbEaGSTsbVnVPG1l_0X6XXvXw>
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: Mon, 12 Nov 2018 23:14:03 -0000

[ I agree that this thread is off topic for this WG, thus below
  just a short OT aside on some oft-repeated critiques of DNSSEC. ]

> On Nov 12, 2018, at 2:15 PM, Tony Arcieri <bascule@gmail.com> wrote:
> 
> The cryptography employed by the X..509 PKI is substantially more modern than what's in DNSSEC. Much of DNSSEC's security comes down to 1024-bit or 1280-bit RSA ZSKs.

It is true that while the KSKs tend to be 2048-bit RSA, ZSKs are typically
1024-bits or 1280-bits.

	http://stats.dnssec-tools.org/#keysize

That said, all the TLDs are using 2048-bit KSKs, and we're seeing
increasing adoption of ECDSA in DSSSEC:

	http://stats.dnssec-tools.org/#parameter

and the .CZ and .BR TLDs switched to ECDSA this year, and more will likely follow.

Furthermore, the weakest link in the chain for both WebPKI and DNSSEC is not the
cryptography.  Rather it is operational weaknesses in the enrollment processes.

For WebPKI, we basically have TOFU by the CA based on apparent unauthenticated
control of a TCP endpoint as the basis of certificate issuance, occasionally
strengthened via DNSSEC(!) validated CAA records and/or ACME challenges.

For DNSSEC, the domain administrator actually has login credentials at the
registrar, and domain control does not require a leap of faith, it is a
fundamental fact of the registrant/registrar bilateral relationship, there's
no third-party trying to bootstrap trust from indirect evidence.

What's more anyone who can compromise the registrar account and take over your
DNS can quickly obtain a WebPKI certificate as a trophy of their accomplishment. :-)

So the WebPKI picture isn't especially better, there pros and cons in each
space.

> Furthermore DNSSEC deployment in general lags behind the X.509 PKI significantly.
> In general attempts to bolster browser security with DNSSEC have failed due to
> DNSSEC misconfigurations or outages.

Certificate renewals are also botched from time to time, but we've not abandoned
the WebPKI.  The main barriers to DNSSEC are last-mile issues, and poor support
for DS record enrollment at some registrars.  Zone signing tools have been difficult
to use, but are much improved lately.

-- 
	Viktor.