Re: [tlug] SSH Issues

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

Curt Sampson writes:
 > On 2008-11-24 16:14 +0900 (Mon), Stephen J. Turnbull wrote:

 > > IMO, this is not an issue of cost/benefit; this is a professional
 > > ethics issue.

 > Which is, in turn, a cost/benefit issue. It's not professional to
 > spend a lot of time on something that gives little value to the
 > client, and in turn ignore other things that would give the client
 > more value.

You have a strange understanding of *professional* ethics.  It is of
course unethical, whether you are a professional or not, to misuse
others' resources.

What makes one an ethical professional is going beyond the simple
provision of value for money to use your special knowledge to advise
the client to do things they may not want to do, to do things that
they don't want to do, and in some (rare, and I don't claim this is
one) cases to act against the client's expressed wishes.

 > Indeed. So, you have anecdotal evidence that something broke in a
 > completely different situation, and you've decided based on that, and
 > admittedly very little knowledge of DNSSEC, that supporting the AD bit
 > in queries is a highly risky move.

You write this, and *then* accuse me of lacking charity?  You claim to
be the expert here, a little noblesse oblige might be in order, ne?

 > >  > As does your "validation"; in both cases you trust that the data were
 > >  > generated by some particular source.
 > > 
 > > Of course it *doesn't*!  That's precisely why I used the term
 > > "validation". [...]
 >
 > Well, "duh."
 > 
 > I was, here, assuming that in our example we had the rest of the
 > cryptographic system set up.  Without giving you exact
 > configuration files and pages of details about key management

Ah, thank you.  So I'm supposed to have a public key *in advance* and
install it in software under my control.  That clears everything up.
So DNSSEC is really about not about the public Internet, but rather
about communication within organizations, in the sense that the
parties have to cooperate *before* they can use it.

Sure, you mentioned keys in your original post.  But something this
important bears stating clearly and repeating, maybe?

 > That is not my claim at all. Blinded by your ignorance of DNSSEC
 > and your wish to "win" here, your are picking the most uncharitable
 > interpretations of my words.

I am not "blinded" by my ignorance of DNSSEC, I'm simply ignorant
... for the moment.  And the only thing uncharitable about it was
collecting most of what you wrote in one place, and paraphrasing it in
a relatively precise way.  What I was missing was that having the key
installed locally in advance is necessary for it to work at all.  (No,
that's not obvious on the face of it: Diffie-Hellman and all that.
Doesn't work in this case, I guess, but you'd need more specialized
knowledge than I have to know that, eh?)

 > I think at this point that no further enlightenment will come of me
 > trying to run a DNSSEC tutorial for you on this list, and it would
 > cost me a lot of time.

I don't need a tutorial; what I need to know I can get from the RFCs
and other sources if and when I need it.  However, you have a deserved
reputation here for understanding network admin, security in particular,
and I think it's a damn shame that you don't work a little harder to
be precise in your statements.