[getdns-users] GetDNS use case: Kerberos Realm Crossover

[Rick van Rein]

Hello,

This is to let you know that a student of mine finished his MSc thesis
work using GetDNS.  I thought it might be an interesting case study.

What he's done is prototype a mechanism for automatic / in-situ realm
crossover with Kerberos, based on mutual authentication between KDCs
with DNSSEC / DANE.  More details, in increasing level of detail, is on

http://realm-xover.arpa2.net/kerberos.html
http://k5wiki.kerberos.org/wiki/Projects/Realm_Crossover_between_KDCs
http://research.arpa2.org/library/bellatriu-2016-kerberos-realm-crossover.pdf


What may be interesting for GetDNS is to learn about our timing
concerns, and how GetDNS' asynchronous handling may help here.

To establish a remote site's identity, we need to go through a
sequential DNS lookup:
 1. based on a DNS name, we need to lookup the Kerberos realm name in
DNS using a _kerberos TXT record;
 2. based on the realm, mapped to a DNS name, we locate the SRV record
for the KDC;
 3. based on the KDC location, we can (a) contact it and (b) formulate
its TLSA record location
We then continue to compare TLSA to the KDC certificate, and so on.

The thing is, this sequence takes quite a bit of time and Kerberos
clients, which usually prod their KDC over UDP, tend to wait only for a
small timeout.  In Heimdal, a default of 1 second is compiled-in. 
Compare that to the complex DNSSEC-based procedure above, and realise
that this should be done on both sides, and we're clearly in trouble.

One way out of this predicament would be if we would first ask for DNS
data and then add the authenticity information later.  So, we'd take a
stab at the data that we may reasonably assume to be correct, and while
still checking, we already progress to the next stage.  That would
result in the DNSSEC validation of phases 1, 2 and 3 all taking place in
parallel.  The sequence of 1, 2, 3 is only as slow as three plain DNS
lookups and we can withhold the final conclusion (and relaying it back
to the client) until the three DNSSEC phases have cleared as well.  Only
when DNSSEC returns Bogus or Insecure would we scratch behind our ears,
and perhaps restart.

This is only one application, but at least the sequence 2,3 is going to
be commonplace, I'd expect.  And the agony of delays, though not always
as obstructive as with timeout-based UDP protocols, is going to
devastate things like TLS performance as well.  So... I'd say that an
eager DNS resolver may want to take these concerns into account, judging
whether it is to be expected to be a common user requirement.

Willem, note that this might mingle nicely with the suggestions I've
done about having a "current state" object for DNS data.  One would
simple first ask_data() and later await_dnssec(SECURE).

I hope this is useful; it is written in the assumption that GetDNS is
still looking for ways to be useful.

Cheers,
 -Rick