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

Ryan Sleevi <> Tue, 16 October 2018 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C7BC130DC7 for <>; Tue, 16 Oct 2018 10:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FMeKe28tktpU for <>; Tue, 16 Oct 2018 10:28:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0797C130E01 for <>; Tue, 16 Oct 2018 10:28:02 -0700 (PDT)
Received: by with SMTP id 134-v6so34156409itz.2 for <>; Tue, 16 Oct 2018 10:28:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TgKEqplqFjKdK+VfcTyRYFw7Am9jUbekHScbuD0+ql8=; b=nXojmh0jtJoyp9OPH2WnCnrzwVONqCG1Q2slmgSqX4f1QA2GVacUq3r+9eRZ8z6Wff 7gTK8CW/tCKvjEBBvCcplfUgi036ZEoQSceN7E88ZUs2vjOhkf5buVOKCyxiJ0RjuzV3 QhEdKod39XZUcPm11RW5rEapC8gFHpW8T4yk+W3BqPfGzzStFIjYMyOpZ0aaqdxOauYT 8mTOmThXkl9WLhSRSD6X2aLtc3qRmY/Xz2xLOByyOXQOallZxC6Pn/IN9u1Gimim6Zl6 aedfLzpmRWYnqN36eFeFVadgNzXAVj9FA1+VIvdBaOFMxfMUfrlPoaW8axLaojetUaO0 u2Yg==
X-Gm-Message-State: ABuFfoh5uVHSLw8O8npl44GJJkLGWbugDQzoJpYLVsKd017Mck9ws3vN byCHHDYUmBqhJ+0GzXhAblUMua6pkLE=
X-Google-Smtp-Source: ACcGV61yA9VpAQ62+HJWm8m63nrhF8YCo7mtmMD5thHLJPHqMj8hzqe/DPEWAXyKfEwDzVAVD/rc0A==
X-Received: by 2002:a02:b14a:: with SMTP id s10-v6mr18641862jah.38.1539710880745; Tue, 16 Oct 2018 10:28:00 -0700 (PDT)
Received: from ( []) by with ESMTPSA id u4-v6sm4291016iob.0.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Oct 2018 10:28:00 -0700 (PDT)
Received: by with SMTP id 134-v6so34156329itz.2 for <>; Tue, 16 Oct 2018 10:28:00 -0700 (PDT)
X-Received: by 2002:a24:9ed7:: with SMTP id p206-v6mr15678988itd.39.1539710879680; Tue, 16 Oct 2018 10:27:59 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Tue, 16 Oct 2018 13:27:48 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000000a53dd05785be058"
Archived-At: <>
Subject: Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Oct 2018 17:28:04 -0000

On Tue, Oct 16, 2018 at 11:00 AM Rene 'Renne' Bartsch, B.Sc. Informatics
<> wrote:

> I haven't found the article with 150,- $, yet, but this isn't good either:
> and Mozilla makes it worse:

I'm afraid that taking that article and extrapolating that it undermines
SSL is, unfortunately, a bit unsupported.

It's certainly true that "bad actors" are able to misrepresent and
circumvent a number of CAs' "Extended Validation" practices. This can range
from CAs using unreliable datasources (like Dun & Bradstreet) or to CAs
having poor practices regarding acceptable documentation. However, in the
examples mentioned in that article (and related, as I recall when that came
out), the attack is not that the attacker bypasses the domain name
verification process. Instead, the attacker fully controls their own domain
name, and they fool the CA into providing additional assertions about that
domain name that aren't legitimate - such as what company or entity is
operating that domain name. The same applies for EV Code Signing
certificates (which aren't bound to domains, but organizations) - by
fooling the organization vetting process, systems that rely on the
organization information - not the domain name - are the ones put at risk.

DANE/DNSSEC would not address that concern, because its largely orthogonal
to such extended validation. Indeed, what DANE/DNSSEC would address is
exactly the thing that's working and not been compromised - the domain
validation part (especially in light of CAA).

If your goal is to minimize risk, then I think a key takeaways would be not
to rely on organization information in certificates - and instead focus on
the domain name. Similarly, rather than promoting DANE/DNSSEC in browsers,
you could encourage browsers to adopt solutions like Apple has done in
Safari on macOS Mojave - no longer present extended validation UI to users
( ), so
that they can instead reliably use the domain name.