Re: [tlug] SSH Issues

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

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

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

Well, yes, that's precisely what lwres is for: doing what BIND does
except that it doesn't maintain a persistent database or provide a
server.  Those are both complex tasks, justifying calling lwres
"lightweight".

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

True.  That doesn't matter, except to make you overconfident that you
are the only person who understands what this conversation is about.

 > You might consider doing a bit of cost/benefit analysis on this
 > before coming up with so strong an opinion.

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

 > > 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 already told you my sad Smail story.  People will see the feature,
assume it works, and take a big one up the wazoo, and that will be
blamed on the distros and glibc.  If the feature is not implemented,
it's not the glibc maintainers' problem.  I don't much like that in
terms of professional ethics, but OSS poses some interesting questions
in respect to ethics.

 > Well, if "some thought required" is a barrier, drop any ideas about
 > touching anything related to security via cryptography.

*sigh*  Please, think about what we're discussing.  Where it's
technical detail, I readily concede your expertise.  However, you were
complaining that glibc is dragging its feet, while in NetBSD you could
put this patch through immediately.  Since it's already *in* NetBSD,
this is no longer a technical question; the glibc maintainers are
quite capable of porting or otherwise implementing features that exist
in rival systems.  It's now managerial/political, and I think it's
reasonable to suppose we're on at least equal footing there.

 > 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".  Validation, as you know, is merely a mechanical
procedure of checking the result of running an algorithm on data.
Cf. "validating XML process."  Authentication is similar, but includes
the additional semantics that a successful validation implies that the
some claim about the data is verified (not necessarily the source!)

You write "N.B.: this source is *not* the authoritative server. It's
the administrator of the zone."

So, evidently your claim is that "If the 'ad' flag is set in the reply
received by the originating client, the records received are authentic
in the sense that it is confirmed they were provided by the zone
administrator."  I do not believe that the DNSSEC standard makes such
a strong claim.

If that's not your claim, precisely what do you claim?

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

Heh.  I evidently understand them better than you can explain them,
for sure.

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

What do you mean by "correct"?  "Valid" or "authentic"?  And if
"authentic", do you mean that the authentic source is the zone admin,
or that the authentic source is an IP address, or that some other
claim about the data has been authenticated?