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

[Eric Osterweil <[e-mail]>]

> On Aug 25, 2019, at 4:40 PM, Erik Sy <[e-mail]> wrote:
> 
> 
> On 8/25/19 20:03, Eric Osterweil wrote:
>>> 
>>> 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?
>> 
> Here is a quote from Chris Palmer on this issue[1]:
> 1:
> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ <https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ>
> 
> "The strength of PKP ― run-time enforcement with hard-fail — is also
> exactly its weakness. Some people are OK with the risk, but overall I
> think the market has spoken: HPKP has seen close to no adoption. People
> don't want to brick their sites.
> 
> As for DANE, it would at best have the same strength/weakness of HPKP,
> but with the additional problems of DNSSEC.”

I think this consideration is fundamentally too narrow.  As I pointed out (elsewhere in the previous message), DANE is part of an architectural solution ( https://cs.gmu.edu/~eoster/doc/2015-08-US-Telecom-DANE.pdf <https://cs.gmu.edu/~eoster/doc/2015-08-US-Telecom-DANE.pdf> ).  While browser security is a very important space, it is just one potential application.  While DANE does offer an elegant security solution for HTTPS connections, that does not mean its benefits are limited to that venue.

To reiterate earlier points: DANE securely binds associations to names in a generalized architecture.  The architecture is composed of a non-stationary suite of solutions.  In regards to TLS, its protections go beyond just for the browser.  For instance, consider opportunistic transport layer cert/key learning for SMTP (RFC-7672: https://tools.ietf.org/html/rfc7672 <https://tools.ietf.org/html/rfc7672> ).  The deployment numbers for this use are up-and-to-the-right ( http://secspider.net/pix/tlsa-growth.png <http://secspider.net/pix/tlsa-growth.png> ).  However, what I think really illustrate's DANE’s true potential (my own 0.02 here) is the fact that it also enables certificate/key learning for object security suites like S/MIME and PGP ( https://cs.gmu.edu/~eoster/doc/2015-03-24-ietf92-libsmaug.pdf <https://cs.gmu.edu/~eoster/doc/2015-03-24-ietf92-libsmaug.pdf> ).

> In total, it seems like Chrome does not want to deploy DANE.

It continues to be a shame, but there’s always time for people to see look at growing evidence and reconsider previous decisions. ;)

Eric