On Thu, May 30, 2013 at 05:18:42PM +0100, Ben Laurie wrote:
> >> > What specific problems do you anticipate with DANE TLSA that make
> >> > it unsafe to "hard-fail"?
> >>
> >> See above [ I moved it below, so see below ]
> >
> > You have not yet mentioned anything that makes it unsafe to hardfail
> > when TLSA RRs don't match, or DNSSEC replies are bogus. Otherwise,
> > DANE does not hard fail. I really don't want to be oppositional,
> > sorry if it seems that way, difficult to seem otherwise in email.
> >
> > It seems there may be some misconceptions about the DANE TLSA PKI
> > validation model, are you open to exploring this possibility?
So is your concern that at this time DNSSEC lookup are too likely to
return "bogus" (rather than with anything specific in DANE itself)?
If so, then indeed we're relatively early on the DNSSEC adoption
curve, and some issues remain to be addressed in hostile environments
such as Hotel/Cafe/Airplane/... public Wifi hotspots that MITM DNS
for the terms-of-use click-through and/or customer authentication.
The state of the art here is regrettable, we need to have better
mechanisms than that for joining public networks, ideally ones that
authenticate not only the customer, but also the provider.
> >> Our experiments suggest that a _large_ percentage of clients cannot
> >> see DNSSEC records at all.
> >
> > This is fine, they can continue to use legacy PKI. DANE does not
> > apply when the client has no DNSSEC support. DANE is not intended
> > to "hard fail" when the client can't use DNSSEC. It only hardfails
> > when it can and the returned RRs are "bogus".
>
> The issue is not that the clients can't use DNSSEC, the issue is that
> they cannot retrieve DNSSEC records.
Well, there's always 8.8.8.8:
$ drill -D -t ns com. @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 25827
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; com. IN NS
;; ANSWER SECTION:
com. 21033 IN NS a.gtld-servers.net.
...
com. 21033 IN NS m.gtld-servers.net.
com. 21033 IN RRSIG NS 8 1 172800 20130603042012
20130527031012
35519 com.
nETo/p1pX2mJo+BHZI20iQkgIGVTgbnqZ8vNf+CDy3w4/LJwrtP/r0NLBVzaQ/xpSLrxnkoxY9aRGtuwJp7oTOdTcq9gCN/QYyPuLK4gZT6BwjnOZmlVvyIQK8GKpafpsLniYX2xVGg07f7lpYdmRpMMZS4t5HXo46WZABXyYYU=
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 42 msec
;; EDNS: version 0; flags: do ; udp: 512
;; SERVER: 8.8.8.8
;; WHEN: Thu May 30 12:24:24 2013
;; MSG SIZE rcvd: 419
and while some clients can't get to 8.8.8.8 either (WiFi hot-spot
browser MITM use-terms click-through), one simply uses HTTP for
that, it is an MITM attack regardless of PKI model.
The browser's DNS requests can include the "CD" bit when connecting
to non-HTTPS sites, or for mobile devices the O/S can provide a
suitable UI for joining mobile networks with the browser employing
"CD" just for that context.
[ The "CD" bit is "checking disabled" and solicits raw results from
the validating cache. ]
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
