Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS
Ryan Sleevi <ryan-ietftls@sleevi.com> Tue, 16 October 2018 17:28 UTC
Return-Path: <ryan.sleevi@gmail.com>
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 2C7BC130DC7
for <tls@ietfa.amsl.com>; Tue, 16 Oct 2018 10:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id FMeKe28tktpU for <tls@ietfa.amsl.com>;
Tue, 16 Oct 2018 10:28:02 -0700 (PDT)
Received: from mail-it1-f177.google.com (mail-it1-f177.google.com
[209.85.166.177])
(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 0797C130E01
for <tls@ietf.org>; Tue, 16 Oct 2018 10:28:02 -0700 (PDT)
Received: by mail-it1-f177.google.com with SMTP id 134-v6so34156409itz.2
for <tls@ietf.org>; Tue, 16 Oct 2018 10:28:01 -0700 (PDT)
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=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 mail-it1-f179.google.com (mail-it1-f179.google.com.
[209.85.166.179])
by smtp.gmail.com with ESMTPSA id u4-v6sm4291016iob.0.2018.10.16.10.28.00
for <tls@ietf.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 16 Oct 2018 10:28:00 -0700 (PDT)
Received: by mail-it1-f179.google.com with SMTP id 134-v6so34156329itz.2
for <tls@ietf.org>; 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: <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>
<5b069d31-4ddc-5905-3458-2a8b365e0c7b@bartschnet.de>
In-Reply-To: <5b069d31-4ddc-5905-3458-2a8b365e0c7b@bartschnet.de>
From: Ryan Sleevi <ryan-ietftls@sleevi.com>
Date: Tue, 16 Oct 2018 13:27:48 -0400
X-Gmail-Original-Message-ID: <CAErg=HHLM_yGFND_QLxoXNmzf2qfUmJHYyPO-+y4J__Uz1emRA@mail.gmail.com>
Message-ID: <CAErg=HHLM_yGFND_QLxoXNmzf2qfUmJHYyPO-+y4J__Uz1emRA@mail.gmail.com>
To: ietf=40bartschnet.de@dmarc.ietf.org
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000a53dd05785be058"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HEyGJ99g9HyyoEGMbcTHmLv2AAM>
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 17:28:04 -0000
On Tue, Oct 16, 2018 at 11:00 AM Rene 'Renne' Bartsch, B.Sc. Informatics <ietf=40bartschnet.de@dmarc.ietf.org> wrote: > 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/ 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 ( https://www.troyhunt.com/extended-validation-certificates-are-dead/ ), so that they can instead reliably use the domain name.
- [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS Rene 'Renne' Bartsch, B.Sc. Informatics
- Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for … Viktor Dukhovni
- Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for … Ryan Sleevi
- Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for … Ted Lemon
- Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for … Rene 'Renne' Bartsch, B.Sc. Informatics
- Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for … Richard Barnes
- Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for … Ted Lemon
- Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for … Rene 'Renne' Bartsch, B.Sc. Informatics
- Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for … Ryan Sleevi