Re: [Resolverless-dns] Paper on Resolver-less DNS

[Eric Osterweil <[e-mail]>]

> On Aug 23, 2019, at 10:27 AM, Erik Sy <[e-mail]> wrote:
> 
> 
> On 8/23/19 14:05, Vittorio Bertola wrote:
>>> Il 23 agosto 2019 13:50 Erik Sy <[e-mail]> ha scritto:
>>> 
>>> Do you think the bullet point "There is a risk of rendering a site
>>> unusable." does apply to DANE TLSA?
>> Sure, but it also applies to normal HTTPS certificates without pinning. How many times did you try to access an HTTPS website and were stopped by the browser, because the certificate was expired and the owner forgot to renew it, or because the certificate was self-signed, even if the site had not been attacked? It happens every day, but it's not a good reason to stop using certificates and validating them properly - it's rather a good reason for the site owner to get a better webmaster. 
>> 
> Chrome establishes trust in a certificate if it is issued by a valid CA
> and included in the Certificate Transparency (CT) logs. Here, the CT
> allows to monitor the certificates issued by the CAs. In this ecosystem,
> it is unlikely that valid CAs issue illegitimate certificates because
> the trust in misbehaving CAs can be revoked at any time.

The past is prolog:
	https://threatpost.com/final-report-diginotar-hack-shows-total-compromise-ca-servers-103112/77170/ <https://threatpost.com/final-report-diginotar-hack-shows-total-compromise-ca-servers-103112/77170/>
DANE keeps the control of associating TLS certificates with a domain in the hands of the domain holder/operator.

CT is not a panacea, and concerns about it are still evolving.  For example, it exposes all certs from all participating CAs, and this has been shown to have negative consequences when people do not want all of their domain names (such as internal names) necessarily exposed for discovery:
	https://dl.acm.org/citation.cfm?id=3278562 <https://dl.acm.org/citation.cfm?id=3278562>

> 
> Additional pinning of certificates provides the benefit that an
> illegitimate certificate can be detected during the server
> authentication. Note, that CT can detect this only in the aftermath. As
> a drawback of pinning, a misconfiguration of this mechanism always leads
> to a fatal error. The trade-off at hand is catching misbehaving CAs
> before the connection establishment and accepting hard failures due to
> possible misconfiguration versus catching the malicious CA only in the
> aftermath of the connection establishment. I think that Chrome decided
> for the latter one.

If I follow your logic here, then I think this is a statement that is at least break-even for (but likely actually in favor of) DANE.  If a certificate that is proffered over a TCP connection does not match the TLSA record, it is proactively detected and the session initiation fails, yes?

Eric