Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols

[Nicholas Weaver <[e-mail]>]

On Feb 21, 2014, at 6:42 AM, Phillip Hallam-Baker <[e-mail]> wrote:
> DANE has a last mile problem because you can't know if the DNSSEC record has been stripped out by an attacker or by some local network firewall.

The client can know.  It starts by asking for DNSKEY for ., etc.  Because you have NSEC/NSEC3 provable denial of existence, you can know if DNSSEC records are being stripped.


In particular, the problem for this tends to be internet cafes and the like.  Home networks tend to be atrocious on the DNS proxies, but the client can usually go around them and get things directly.  Business network firewalls may restrict client DNS, but they usually operate properly and the recursive resolver itself supports DNSSEC.

Its the net cafes, hotels, etc (basically, anything with a captive portal) which combines both a crappy DNS proxy AND DNS access restrictions that is the problem.

> The way to cut the Gordian knot here is to provide an efficient way to retrieve all the information necessary to set up a request in one lookup. That solves the last mile problem and the multiple lookup problem at the same time.

Agreed, with a minor caveat.  

The only disadvantage is that on the server side you need to get this data fairly frequently, since the timeout may be fast (first expiring RRSIG on the chain of validation from . to the DANE record), which means the very rarely updating certificate store model common to web servers isn't appropriate, but that's no real-big-deal.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[e-mail]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc