On Wed, Feb 17, 2010 at 06:48:37PM +0000, Tony Finch wrote:
On Wed, 17 Feb 2010, Phillip Hallam-Baker wrote:
One mechanism that was unfortunately pushed asside as a result of the
fixation on end to end DNSSEC would be to for the resolver to use
DNSSEC (and other methods) to authenticate the data it receives and to
use some modification of TSIG to authenticate the communication
between client and resolver.
I don't think that has been pushed aside. There's not much interest in it
at the moment because the focus is on authoritative-to-recursive DNSSEC.
Maybe attention will turn to recursive-to-stub security once there is more
assurance that the recursive server's answers are authentic.
There is also the camp that thinks that stubs should do validation
It would not take a great deal of effort to graft a Kerberos like scheme
on to effect key exchange.
Or use SIG(0).
Yeah, I kinda like SIG(0) myself.
If you want to use Kerberos for symmetric key management, there
is GSS-TSIG. But there is a bootstrapping problem -- Kerberos
clients commonly use DNS SRV records to locate Kerberos servers.
Most stub resolvers can't do any of this today (HMAC-MD5/SHAxxx
TSIG, GSS-TSIG, SIG(0), etc) as far as I can tell.
Ietf mailing list