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

Richard Barnes <rlb@ipv.sx> Tue, 16 October 2018 14:06 UTC

Return-Path: <rlb@ipv.sx>
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 AE0F4130DC9 for <tls@ietfa.amsl.com>; Tue, 16 Oct 2018 07:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
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 4LggROcaJPCP for <tls@ietfa.amsl.com>; Tue, 16 Oct 2018 07:06:10 -0700 (PDT)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA8012D4EE for <tls@ietf.org>; Tue, 16 Oct 2018 07:06:10 -0700 (PDT)
Received: by mail-oi1-x231.google.com with SMTP id l197-v6so18117955oib.8 for <tls@ietf.org>; Tue, 16 Oct 2018 07:06:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+usZpNddXNgkYUeqrfRZOK1r8VHCtAGjHAfle7tnVqE=; b=HlUMkqq9gdOWiMCaLIsFuf7k01SH94H+GCdhLPY6AXKX16PNMggB1tY4gDY8lZ9RB2 DGMICMUJ+Fd1n0+PoY+oDV94VDKFLuyhfuFJs+w0NRAQtJ4Yq3HoYaNjSYuVIYGngSZw EkEuPnEtJ2A2X/ciJ/Ls5nM/N+/Elqskzr/x7OFGqZ1ovxXOEBkhytT0TkPZ9tcej+ss G2ytYhZM0q1hkE/l2RWau0o9mjzQKYqfh0vl7Yl6mn66KgSOqcAoj2o5fLpPL8+xqK38 gpgAlbpGdvFx9qf99GIqEJHt5LzNd5TvxHmCz8820St7bPHgwZgVD1EpAyxsCjUV0vDg SHrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+usZpNddXNgkYUeqrfRZOK1r8VHCtAGjHAfle7tnVqE=; b=X7b4+hxra3N7UEuhiUei1qtR8z24GSwsb1NRxVTYXpVsbNUpRHd6Xtsr4XXnADSAqd kTHC2Sl0zc5vZe/dB43l4yzZlcipEvtJlxqS7seGLtKr3zdvqfzYkBf3OCSOF4I3NRm/ RwKcCHh8OPHK2m7vvEutkLj6tnuhTzU5Jq8U0hA3VvMNxsysnhbQCpZ49YgpDVC55gjm NrVUBUxlrd0TGM0uKRo6isEb2ALg6QnsGIN1UPurpmqqz5fG8ZZLax11eQ64GKs/cmY/ S5TYPjLdfTAwM8rqFwbq/PUQn2gFBlw2c7m3x7wI4RAASZaqX/KqLJrXSivS+UhBvsee 6m3A==
X-Gm-Message-State: ABuFfoiJ/pyM/QoHrH8GfhWg/mtl5W8BJNlMHPYSHsW2+RWQFpMcFPTw ZvH1XapQcmCNIkfCVtwBkqB3cZo269Pz3ptGiE2py3hSnMPL5g==
X-Google-Smtp-Source: ACcGV61a3R8T5t1BdJucMEZNeLoM6JZg/GqwU7QgiGD+58nDr668qBEJ2G4EYvGRuooK1c1WNAedaXLXxvtue2zfs6w=
X-Received: by 2002:aca:540c:: with SMTP id i12-v6mr12186820oib.49.1539698768170; Tue, 16 Oct 2018 07:06:08 -0700 (PDT)
MIME-Version: 1.0
References: <90e2851e-6469-226c-b2bd-63efebdfd796@bartschnet.de> <9700FD81-5DDF-4A14-B740-1216A749510D@dukhovni.org> <652234d7-55da-fea0-e185-6f1264b3fb28@bartschnet.de>
In-Reply-To: <652234d7-55da-fea0-e185-6f1264b3fb28@bartschnet.de>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 16 Oct 2018 10:05:49 -0400
Message-ID: <CAL02cgTQVZSa-1Lrz5Gz+7JU2b=v_E35dn1Z6gtHvgMuR3-0+w@mail.gmail.com>
To: ietf=40bartschnet.de@dmarc.ietf.org
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000023628b0578590e07"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZegzrHk1O4OdDBJaQL6C8FrXtxA>
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:06:13 -0000

On Tue, Oct 16, 2018 at 10:02 AM Rene 'Renne' Bartsch, B.Sc. Informatics
<ietf=40bartschnet.de@dmarc.ietf.org> wrote:

> Unjust certificates can be bought for 150,- $


[citation-needed]

https://xkcd.com/285/

I'm sure if you could produce such a certificates, the root programs would
be happy to investigate how it was caused to be issued.

--Richard


> 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> 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
> https://www.ietf.org/mailman/listinfo/tls
>