Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS

"Rene 'Renne' Bartsch, B.Sc. Informatics" <ietf@bartschnet.de> Tue, 16 October 2018 14:59 UTC

Return-Path: <ietf@bartschnet.de>
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 DFC98130DE9 for <tls@ietfa.amsl.com>; Tue, 16 Oct 2018 07:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level:
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bartschnet.de
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 fcsYwG8qYVOm for <tls@ietfa.amsl.com>; Tue, 16 Oct 2018 07:59:54 -0700 (PDT)
Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC26712D4EE for <tls@ietf.org>; Tue, 16 Oct 2018 07:59:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bartschnet.de; s=2018030201; h=Content-Transfer-Encoding:MIME-Version:Date: Message-ID:From:Subject:to:content-disposition; bh=wk7VvHA8aCDfslIzAdrIwJ4auoHnW7Ci1moEB+LNGks=; b=VZYxdZRHNCijHFLLcgahgVXPOM gtz5HdRp/z5asYWNL1k458Hs4r1PPgIpPK2gs0LkOIl0IGXdvNzwS1SVx4VvCTrbnJO78VU94++YP vIcHVmwc+ZWlfBHk4gUUpcsPYuONpoHDruQ+l8rU6e6+OunUZD2o3I38wrnL3Shukxqi9X9dYF2Tg ZRdO/yFO+WY+7sYVNRu5TKZc6Fd+5zv7T7V9C8hjavNugGragH8SJhgzwNGFvS4HhEB5UhUuuDNbg p1+tpPMniHFMRaPz/WxXCw+zY7kfJ5mq2d2ecNUoOZOAjOm8ZpZT17t5C+Z6cy3fKy80MqjcGtfRJ 3aQDujrKUm2KGDy8vVQ9HdfPslZKn6fS4wI8QrXI+E/6q6EhTQMr2hzrgc9Fq9a3G+7NbgUPd1jZM I6dR9VsOiA8hUt135ws38T+qjtYJNLSYj5p/SBLjD/Zpe7qo76Mu0F7oWBAgiyTXcYMNeQ1XT4Uzf VsIPQc9SkNbomHYW/vRxPvs9FxLkpM8Vt0CX+GjImLc+k8Ch9Ioku1uYI/XqnMHMyL9esALic6F2P 0XhAi+9bGIGt5FAWDWHX/LIZxLHPOt1euh2oq+cUyPWTZq7T2KGFYyRAc5WPymL7jJO/Bp00UG7IP rr3/XY1Bl65nI6WFmtdsxIaxZesPK7apKTqH1BRvA=;
Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1gCQp2-0002Ws-Mf with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for tls@ietf.org; Tue, 16 Oct 2018 16:59:52 +0200
Cc: "<tls@ietf.org>" <tls@ietf.org>
References: <90e2851e-6469-226c-b2bd-63efebdfd796@bartschnet.de> <9700FD81-5DDF-4A14-B740-1216A749510D@dukhovni.org> <652234d7-55da-fea0-e185-6f1264b3fb28@bartschnet.de> <CAPt1N1nPSoDU1ek3QQ+hHMEArjFSC7-p+QKwftGcdOdpgZQ6dA@mail.gmail.com>
From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <ietf@bartschnet.de>
Message-ID: <5b069d31-4ddc-5905-3458-2a8b365e0c7b@bartschnet.de>
Date: Tue, 16 Oct 2018 16:59:47 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <CAPt1N1nPSoDU1ek3QQ+hHMEArjFSC7-p+QKwftGcdOdpgZQ6dA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-DE
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/a8eq8v9TD899Ki5wkgSw0nFCs64>
Subject: Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS
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: Tue, 16 Oct 2018 14:59:56 -0000

I haven't found the article with 150,- $, yet, but this isn't good either:

https://www.bankinfosecurity.com/study-finds-custom-market-for-bogus-tls-certificates-a-10680

and Mozilla makes it worse:

https://blog.mozilla.org/security/2018/10/10/delaying-further-symantec-tls-certificate-distrust/


Am 16.10.18 um 16:06 schrieb Ted Lemon:
> Can you provide a citation for that statement?   Not doubting you, particularly, but this is news to me, and probably to some others on this list, if true.
> 
> On Tue, Oct 16, 2018 at 4:01 PM Rene 'Renne' Bartsch, B.Sc. Informatics <ietf=40bartschnet.de@dmarc.ietf.org <mailto:40bartschnet.de@dmarc.ietf.org>> wrote:
> 
>     Unjust certificates can be bought for 150,- $ in the darknet which makes TLS snake-oil. And you never know if the internet provider is hostile or hacked.
>     So we should act in the favor of end-users. If we don't have the position to make DANE mandatory, yet, we should at least try to encourage browser vendors
>     to support DANE. Just think about all the online-banking websites without DNSSEC/DANE protection.
> 
> 
>     Am 15.10.18 um 22:49 schrieb Viktor Dukhovni:
>      > Though I am generally an advocate for DANE, and have done much work to
>      > further its adoption, this is not a realistic proposal.  DANE adoption
>      > in TLS will be incremental and will not be accomplished via a mandate.
>      >
>      >> On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics <ietf=40bartschnet.de@dmarc.ietf.org <mailto:40bartschnet.de@dmarc.ietf.org>> wrote:
>      >>
>      >> TLS is prone to Man-In-The-Middle attacks with unjustly obtained intermediate certificates (e.g. firewall appliances).
>      >> The DNSSEC KSK-rollover worked like a charm.
>      >>
>      >> So I suggest to make DANE-TLS mandatory for TLS to prevent Man-In-The-Middle attacks with unjustly obtained intermediate certificates.
>      >
>      > If you want to see more DANE deployment, work on tooling to ease
>      > DNSSEC deployment, convince registries to support CDS and CDS0,
>      > simplify zone signing and key rollover interfaces in nameserver
>      > implementations, develop monitoring tools, ...  Get efforts to
>      > improve the tools funded, ...
>      >
>      > There is much work to be done, before we can expect ubiquitous
>      > DNSSEC support, let alone DANE.  DNSSEC deployment is concentrated
>      > at domains hosted by providers who have invested in automating it.
>      > To bring it to the masses, it must be something that works out of
>      > the box.
>      >
>      > Until then it should be possible to use DNSSEC and DANE with TLS,
>      > but we're quite far from being in a position to mandate their use.
>      >
> 
>     _______________________________________________
>     TLS mailing list
>     TLS@ietf.org <mailto:TLS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tls
>