Subject: [dane] Middlebox DANE validation for HTTPS

From: Andrew McConachie <[email-masked]>
Date: Thu, 6 Jul 2017 15:43:44 -0400

Attached is a presentation I gave at the ICANN 59 DNSSEC Workshop in 
Johannesburg last week. This is a project I've been working on for a few 
months and have been successfully running on a LEDE device. It currently 
has a deployment count of 1, but I'm curious to hear what this mailing 
list thinks of it.

I plan on continuing to work on this, and support should improve 
considerably once OpenWRT/LEDE moves to a version of OpenSSL that 
supports DANE. Right now it only supports TLSA records that do not 
require the parsing of any ASN.1 data.

Thanks,
Andrew McConachie

---

From: "A. Schulze" <[email-masked]>
Date: Fri, 7 Jul 2017 00:04:17 +0200

Am 06.07.2017 um 21:43 schrieb Andrew McConachie:
> Attached is a presentation I gave at the ICANN 59 DNSSEC Workshop in Johannesburg last week. This is a project I've been working on for a few months and have been successfully running on a LEDE device. It currently has a deployment count of 1, but I'm curious to hear what this mailing list thinks of it.

nice.

but that mode of operation could not inform the user/client about a problem. This may increase the support effort.
Users must be aware of such kind of protection. It's really hard to identify "website unavailable" as a DANE validation error...

Andreas

---

From: Andrew McConachie <[email-masked]>
Date: Fri, 7 Jul 2017 11:45:05 -0400

> Users must be aware of such kind of protection. It's really hard to identify "website unavailable" as a DANE validation error...
If a user is unable to reach a website because a TLSA record does not 
validate against the offered cert, the website in question is either 
misconfigured, or the user is being MITM'd. Either way the user will 
likely recognize that their Internet connection works while this website 
does not. Users don't have to know anything about DANE to make this 
distinction.

If your argument is that support calls to ISPs will increase if/when 
HTTPS DANE deployment accelerates then I agree with you. But that has 
nothing to do with Danish in particular, that's a consequence of DANE in 
general. And speaking even more generally, that's a trade-off with all 
security. It begets inconvenience.