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

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Mon, 15 Oct 2018 22:20:22 +0200

Hi,

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.

Regards,

Renne

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 15 Oct 2018 16:49:21 -0400

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=[email-masked]> wrote:
> 

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.

-- 
	Viktor.

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 15 Oct 2018 21:44:10 -0400

On Mon, Oct 15, 2018 at 4:50 PM Viktor Dukhovni <[email-masked]>
wrote:

> > On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics
> <ietf=[email-masked]> wrote:
> >
> > TLS is prone to Man-In-The-Middle attacks with unjustly obtained
> intermediate certificates (e.g. firewall appliances).
> > So I suggest to make DANE-TLS mandatory for TLS to prevent
> Man-In-The-Middle attacks with unjustly obtained intermediate certificates.
>

I think there's another criticism to be leveled at this proposal, and it's
suitability for this WG - the motivation stated (firewall appliances) is a
question about local policy. I admit my own ignorance here, in that I'm not
sure how https://tools.ietf.org/html/draft-nottingham-for-the-users has
been progressing as a comparable alternative to the HTML Priority of
Constituencies. However, as engineers, we need to recognize that no matter
what is memorialized by the IETF, if you have control over the machine - as
these enterprises inevitably do to install their firewall appliance - all
bets are off. We should not pretend we will prevent that, nor should we
increase costs for the ecosystem in pursuit of that effort.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Oct 2018 10:32:49 +0200

Not an argument in favor of the proposal, but the issue with firewall certs
is not that we would want to override local security policy, but that
firewall certs *can* in principle override local security policy, and in
principle DANE could be used to prevent that.   What is meant by a firewall
cert is a cert that's able to sign for any domain; such certs can in
principle be obtained by entities other than the operator of the local
firewall.   We're calling them firewall certs because that's the ostensible
reason for their existence, but we shouldn't assume that the name has any
power to restrict how they are used. :)

On Tue, Oct 16, 2018 at 3:45 AM Ryan Sleevi <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Tue, 16 Oct 2018 16:01:04 +0200

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.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Oct 2018 10:05:49 -0400

On Tue, Oct 16, 2018 at 10:02 AM Rene 'Renne' Bartsch, B.Sc. Informatics
<ietf=[email-masked]> 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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Oct 2018 16:06:36 +0200

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=[email-masked]> 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.

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Tue, 16 Oct 2018 16:59:47 +0200

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=[email-masked] <mailto:[email-masked]>> wrote:
> 
>      >> On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics <ietf=[email-masked] <mailto:[email-masked]>> wrote:
>      >>
>     [email-masked] <mailto:[email-masked]>

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 16 Oct 2018 13:27:48 -0400

> 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.