Re: [dane] Middlebox DANE validation for HTTPS

Andrew McConachie <> Fri, 07 July 2017 15:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C43F713154C for <>; Fri, 7 Jul 2017 08:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SUaAAROpKgec for <>; Fri, 7 Jul 2017 08:45:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF1E4131544 for <>; Fri, 7 Jul 2017 08:45:11 -0700 (PDT)
Received: by with SMTP id 77so52248299wrb.1 for <>; Fri, 07 Jul 2017 08:45:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=wFsotNSR+qXyJsP6ouPpX5hTNHk5iHLO/M6LmrGr6AA=; b=ke9Xr6Pt4Q9F+Ddi6g3DjmQxa94+btGnHB7loXX2pVx7fTCz2AnuLeLQQ1C4ooon4g fTafjubKGElODih9zTPvQ8aPQotC5quXr2Mn2T+MXJmud0bEF2tZzJ1eJxu83HwgYgRW KosPNdDYn6gJlrYYUx43pYClyhPGofmvcVMqtcA5WCbgDmVtRUyIe5mbbseOFQmMr6Ko H9cB27Q59XxczQZBtd4yzAkp6vhUDKYALXmZJ+oPuh5VzX//M9/kZFlqaZG7nvTS4NX6 pCh4hMBqRE18WzKgkqqR9QfYIYbnduRei1DWi4VqA8nGwF+5Ua2tnO8Wz+m32fg0rgEJ Lu1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=wFsotNSR+qXyJsP6ouPpX5hTNHk5iHLO/M6LmrGr6AA=; b=p5eDe8whnmCZySyO9v8+JrdGdq5dD3rwTvgdvwRnYwmUu73vKA2mo8XpgPot/C0mIR 1ZpCY4RhKj4ppEd6Zw68S0swN2nEtFFPI3RFfHxMz/1j5w0IqiDV4tDkVBiMUoozOYXh Nhm0vilODMy3DRMHnAEPf5IOOl21DDdIhgVL/W1CJvLAbVtzEtz+Ex1TUoA/Ar2fnjdI 5bN7tjY3zR4STeJ56qlpii4G7qWYI9qEy0NlnRsOXlP5fqfSU+C4J/C6tL7OQWx7axzK mASaI2V+0EPjRf/UuqWCFnOdvr9q1+VCm+k/RGZOYgUJ3Ofa9AfJlLKJQFFIkNUMaMzI rG5A==
X-Gm-Message-State: AIVw110rgy7P3yGCnWXuGqZEegApjbuogCoSH0y8SL/XkXZyXs9vBvVz LCs0+1+++EWWLCl9lww=
X-Received: by with SMTP id 138mr2786201wmi.8.1499442309923; Fri, 07 Jul 2017 08:45:09 -0700 (PDT)
Received: from ANMC-3678.local ([2601:143:8003:2fd0:8045:b9eb:5e8d:e612]) by with ESMTPSA id w30sm4202681wrb.49.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 08:45:08 -0700 (PDT)
To: "A. Schulze" <>,
References: <> <>
From: Andrew McConachie <>
Message-ID: <>
Date: Fri, 7 Jul 2017 11:45:05 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [dane] Middlebox DANE validation for HTTPS
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Jul 2017 15:45:14 -0000

On 7/6/17 18:04, A. Schulze wrote:
> 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...
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 

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.