Re: [tlug] SSH Issues

[Curt Sampson <cjs@example.com>]

On 2008-11-21 22:38 +0900 (Fri), Stephen J. Turnbull wrote:

> 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.

Just have your server forward its requests through them. It's worth
doing anyway, for the caching, unless you have a specific reason to
avoid them.

>  >     2. Authoritative servers should never resolve anyway;
> 
> What do you mean by "resolve"?  They shouldn't serve requests except
> from authorized and authenticated secondaries?

Sorry, I meant "recursively resolve queries." They should return
requests for records for which they have an authoritative answer, and
for anything else return "request refused" (i.e., go do the recursion to
find it yourself).

>  > Hm, so add RRSIG validation to OpenSSH? That's a thought.
> No, to lwres, the lightweight resolver daemon, or to libresolv.

Well, for reasonable performance, one wants to add caching as well so
one doesn't have to do a cryptographic validation of every single lookup
in the domains in question. Ideally, caching across all processes. Oops!
We've just implemented the existing infrastructure, with bind9 doing the
validation and setting the AD bit!

Doing the validation only in OpenSSH and only there for SSHFP records,
would be an acceptable performance hit, given the alternative of no
validation.

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

You've demonstrated enough lack of knowledge of the details of DNSSEC
implementation that I'm going to venture to guess that you've not done
it. You might consider doing a bit of cost/benefit analysis on this
before coming up with so strong an opinion.

> 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.

Will it break things? In what way?

>  > 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.

Well, if "some thought required" is a barrier, drop any ideas about
touching anything related to security via cryptography. It's often a
little bit tricky, and it's very easy to break the system in unobvious
ways through being naive. (Take a look at the recent debian RNG debacle
for a particularly spectacular example.)

I'm sorry that this DNSSEC stuff is not obvious to you, but there's no
way to make it simple to those who don't understand what's going on
underneath the hood.

>  > > 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).

It's authentication, in the technical sense of the term. And it's
exactly what any client server does as well; if the authoratative server
is doing "validation" in your unusual terminology, the clients are doing
no more and and no less.

> Authentication implies trust.

As does your "validation"; in both cases you trust that the data were
generated by some particular source. (N.B.: this source is *not* the
authoritative server. It's the adminstrator of the zone.)

Authorization, of course, also implies trust, though of the "I trust you
to let you do these things," variety, which authentication does not.
Authorization depends on authentication in the sense that it doesn't
make sense to trust a random entity to do some set of things; you need
to be certain they are who you think they are, first.

I would highly recommend studying the basics of security and
cryptography to the point where you understand these sorts of concepts
and the standard terminology for them; you are not likely to understand
most explanations of DNSSEC (in particular, the RFCs) without them.

Also, note that DNSSEC, for reasons of efficency, state and the way
DNS itself works, is a rather tricky implementation of a cryptographic
system. It took me quite some time to understand why things are done the
way they are, and I have been studying cryptographic protocols for many
years.

> What I meant was that the server cannot guarantee authenticity of the
> data it sends, it can only make sure it arrives intact.

I'm sorry, but this is entirely wrong, on both counts. The server *can*
indeed authenticate the data it sends, in exactly the same way the
client can. The server cannot make sure it arrives intact at the client,
which is why the client performs authentication on the data.

>  > > 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.

And I'm telling you again, that is entirely wrong. When it comes to
DNSSEC validation (i.e., the authentication of the records), you do not
care in the slightest from what server the records came; you do not
trust the server. All you are doing is checking to see if the records
are correct or not, regardless of the server whence they came.

This is a very important, nay, critical, part of the DNSSEC security
model.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com