Re: [tlug] SSH Issues

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

Curt Sampson writes:

 > Yes. Just like every other cryptographic authentication system in
 > existence, you can't do authentication unless you start out with
 > some trusted key material of some sort.

Which was *my* whole point.  I mentioned it because it is not common
knowledge on TLUG.  Your continued assumption that I don't understand
that is really hard to understand, since that's the whole difference
between validation and authentication.

I think it's *you* who should give up on "winning" and start trying to
communicate, actually.

 > > 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.
 > 
 > In the same sense that https is, yes. In other words, no, if I'm
 > interpreting correctly these sense for which you seem to be
 > reaching.

Huh?  I'm not "reaching" for anything, except a clear enough statement
that we can agree on.

But no, HTTPS is *not* analogous to DNSSEC.  It serves many purposes
without need of authentication or prior communication of any kind.
(Eg, viewing material your neighbors shouldn't know you look at,
without being detected.  As the Supreme Court Justice said about porn,
"I know it when I see it"; some data is self-authenticating.)

So I don't understand your analogy.  What purpose does DNSSEC serve if
the data being received is not being authenticated?

 > or UDP to deal with latency issues. This is really, really basic stuff,
 > Stephen. If you're going to argue with me about the potential security
 > effects of enabling the AD bit in the resolver library, you need to be
 > starting at a much higher level than this.

Indeed, I did!  When talking about why glibc maintainers drag their
feet, I'm not arguing about the security of DNSSEC, or technical
aspects of security at all.  I'm arguing about defects in the larger
system containing DNSSEC that will get blamed on bugs in glibc or the
Linux distribution.  I gather that's a much higher level than you
intended to go, though.

 > As an example, I do note that we've had during this conversation
 > several discussions about dealing with SSH, and you've never either
 > brought up this exact same issue, nor complained about others not
 > stating it.

Huh?  SSH is a well-known, very commonly used protocol, and everybody
who uses it understands that they must explicitly distribute keys to
hosts they wish to contact via SSH even if they haven't a clue as to
how public key cryptography works.  If they don't install a key, they
will be prompted for a secret when they run ssh.  Key management is
very much in your face if you are an SSH user.

But DNSSEC is unfamiliar to us, and you're the expert, but you haven't
discussed the role of key management in DNSSEC until now.  As HTTPS
shows, authentication is not the only use of cryptography in network
security.  So the mere use of cryptography doesn't imply that users
have to deal with keys.  Granted, I hadn't thought about it carefully,
but at that superficial level the analogy to HTTPS is plausible.

 > 1. You perhaps need to go back and learn the very basics of
 > cryptography.

You perhaps need to go back and learn not to make unwarranted
assumptions.  What we're dealing with here on my part is simply a few
cc's of brain gas; if I'd thought it through I would have realized
that DNSSEC has to be about authentication, and so key management has
to be in there somewhere.

It still deserves mention, though, since there are a few ;-) TLUGgers
who aren't DNSSEC experts.

 > As I mentioned above, you simply cannot authenticate
 > cryptographically without some sort of pre-shared secret,
 > somewhere.

You keep insisting on what I pointed out very early on.  I could have
phrased it much more clearly than I did at the time, but at no time
have I disagreed with that general principle.

It happens that DNSSEC *is* used for authentication and *does* depend
on a pre-existing secret, and on that fact I was mistaken.  Understand
*that*, and the whole conversation becomes explicable.

 > > (No, that's not obvious on the face of it: Diffie-Hellman and all
 > > that. Doesn't work in this case....
 > 
 > That Diffie-Hellman requires just what I've been talking about above,

*sigh*  You talked about a "pre-shared secret" above, and its presence
or absence is the only difference between what I'm trying to say and
what you've been saying about your application and about DNSSEC's
working in general (but I misunderstood).  That's why I used Diffie-
Hellman as an example!  "Presence of a pre-shared secret" can't be
what you mean here, because *precisely stated* Diffie-Hellman's
contribution is to make construction of a shared secret possible
*without* previous communication of another secret.  No more (though
that is plenty!)

So what the Diffie-Hellman are you talking about?