Re: [tlug] SSH Issues

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > Which is why we run Linux and our "local" server is the one running on
 > our own laptop.

Yeah, but I still lose because I can't get out (legitimately) except
through the apparently broken servers.

 >     2. Authoritative servers should never resolve anyway;

What do you mean by "resolve"?  They shouldn't serve requests except
from authorized and authenticated secondaries?

 > > ...implying you were looking in the known_hosts file, and I mistakenly
 > > assumed that is populated with all the keys in the domain.
 > 
 > No, normally my known_hosts file never has any cynic.net. records in it.

Yah, but I didn't know that until you told me.

 > Hm, so add RRSIG validation to OpenSSH? That's a thought.

No, to lwres, the lightweight resolver daemon, or to libresolv.

 > Well, one of the reasons [admins] perhaps haven't bothered to
 > [implement DNSSEC] is issues like this.

Nonsense.  They just haven't bothered.

 > Had I been on Linux boxes instead of NetBSD boxes back when I was
 > setting all this up, I almost certainly would have bailed on the effort.

Oh, c'mon.  First of all, it's not an accident that you were on NetBSD
back when you were setting all this up.  Second, you say yourself that
you patched it in a day---that's why we're having this discussion.

 > I am a) not sure that it didn't work correctly, since I'm not sure of
 > the exact details of what you did,

Go read your message, then you'll know what I did. ;-)  It's not that
hard.  I tried

dig repo.starling.cynic.net
dig repo.starling.cynic.net +dnssec
dig repo.starling.cynic.net @ns1.cynic.net +dnssec

among other things, but those are the results I reported.

 > and b) even if something was wrong, I'm not sure it was the
 > resolver library's fault.

Er, who said it was the library's "fault"?  My main point is precisely
that even if the library is correct, that doesn't guarantee anything
is going to work.  Sure, you could just impose the change on the world
and let them deal.  "It's not my fault, my code is correct."  *snort*

 > I thought DNSSEC did a lot of things in suboptimal ways, too, when I
 > first started with it.

I didn't say "suboptimal".  I said "unobvious".  TOOWTDI is an
essential principle in interface design, but not always so in
implementation.  Still, "some thought required" does make it hard for
a lot of people to get behind the idea of actually doing something.

 > > The authoritative server cannot authenticate the data it sends itself,
 > > that's axiomatic.
 > 
 > Sure it can. So long as it has the public key, it can check the signatures.

That's "validation" (not to mention useless in context, so presumably
I meant something else).  Authentication implies trust.  What I meant
was that the server cannot guarantee authenticity of the data it
sends, it can only make sure it arrives intact.

 > > Either you trust it (eg, because you have its key-signing key through
 > > a trusted channel and you validate the record-signing key with that),
 > > or you don't.  If you don't trust it, then it is trivial for that
 > > server to simply change its data in any way it likes and then sign it.
 > 
 > This embodies a fairly major misunderstanding of DNSSEC. Authoritative
 > servers don't sign anything; they serve already signed records. They
 > have no need for the private key, and it would be considered very poor
 > practice to leave your signing key lying around on your authoritative
 > servers.

*sigh*  I never claimed to understand DNSSEC.  In fact, I had *zero*
knowledge of it until I started reading RFCs a few days ago.

However, you're misreading what I wrote.  I didn't say when or where a
"real" DNS system would sign things; I was describing why DNSSEC is
only meaningful if you trust that you've reached the right server in
the first place.