Re: [TLS] Draft updates: tls-dnssec-chain

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 28 April 2018 19:21 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 0FE9E12D96A for <tls@ietfa.amsl.com>; Sat, 28 Apr 2018 12:21:58 -0700 (PDT)
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 YeSxojt7NsJs for <tls@ietfa.amsl.com>; Sat, 28 Apr 2018 12:21:56 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5879C124205 for <tls@ietf.org>; Sat, 28 Apr 2018 12:21:56 -0700 (PDT)
Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 409267A3309 for <tls@ietf.org>; Sat, 28 Apr 2018 19:21:55 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAHPuVdVy=exrjXB+QyA5CLij_sXvrdoaGm0X_McTc_TFqG=1hw@mail.gmail.com>
Date: Sat, 28 Apr 2018 15:21:54 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <26F2AEF3-EE90-40E7-90F9-1B4D6A94CFFE@dukhovni.org>
References: <CAHPuVdW4kJQ5-mhCGR9BW6dDaN25Lv_Dsr9ygoNwrDsC=c7vuA@mail.gmail.com> <8C791467-A81E-499F-A437-E573C925C125@dukhovni.org> <CAL02cgTkx-F0K++XdjA-DS4Kdh_BsB+zWUQB=Sp0ojSKs0u+vw@mail.gmail.com> <CAHPuVdVy=exrjXB+QyA5CLij_sXvrdoaGm0X_McTc_TFqG=1hw@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MuHH5I9WgcUqzh67OyishfVUCRc>
Subject: Re: [TLS] Draft updates: tls-dnssec-chain
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: Sat, 28 Apr 2018 19:21:58 -0000


> On Apr 28, 2018, at 3:04 PM, Shumon Huque <shuque@gmail.com> wrote:
> 
> This mean "additive" mandatory or non-mandatory, I assume. Viktor opposes 
> the latter case, I assume based on his (unproven) assertion that there will no
> incentive to deploy this.. I don't agree. Lots of sites already publish DANE for 
> HTTPS records even before browsers can use them (IETF, freebsd, debian,
> torproject, defcon, ripe, etc). Once code is implemented/deployed they will be
> using it.

My arguments are sound.  Would you care to estimate what fraction of
published _443._tcp TLSA records actually match the site's certificate
chain?  What non-hobbyist sites publish such records?

It may be cool to play DANE for HTTPS when nobody is verifying, and
there's no operational burden of keeping the records correct, (the
one BENEFIT listed in my cost/benefit list), but real deployments
need real incentives.

With Let's Encrypt available, and no downgrade protection for
HTTPS with DANE (via this extension) the incentive to support
it is nil.

-- 
	Viktor.