🚀 go-pugleaf

 In <9209252236.1.20681@cup.portal.com> a-boyles@cup.portal.com writes:

>I think Terry Ritter is underestimating the effort needed to successfully
>carry out the spoofing attack he describes.

 Look, I really want to get out of this discussion, but this is
 really quite outrageous.  We're talking about computers here.
 Once a decent spoofing program is written, how much does it "cost"
 to get it running on a bunch of nodes?  Perhaps the expense of
 visiting the various node owners and pulling out badges?


>As others have pointed out, the spoofer, to attack me, must filter out
>*all* messages which would allow me to receive someone else's public key.
>(That is, the spoofer must, for each such message, generate his own
>"fake" version of the sender's key, and substitute it in the message.)

 Well, no.

 To attack you, all a spoofer must do is get you to accept one of
 his keys as valid.  Then you have a secure channel to the spoofer,
 and he may pass the information along to make you think you have
 a secure connection to someone else.

 One way to get you to accept one of the spoofed keys is to
 "always" translate a news-signature key to one of his.  (Always?
 How often do you check each character in such a key?)  If this
 is done at or near the sending node, it shouldn't be too
 difficult at all.

 Another way to do it is to send: "Emergency, I had to change
 my key.  Here is my new one!", preferably to both ends.  If
 the users didn't validate their keys originally, why should
 they bother later?  And the spoofer is in (like Flint?).


>Otherwise, if I do get an accurate key for someone else, the spoofer
>can't tell what I might be sending to him.

 Right.  Once we *assume* that we have at least one valid key
 (that is, we *assume* validation), then we can leverage the world.


>Also, any message which that
>person *signs* and sends to me cannot be altered by the spoofer without
>being detected.

 Right.  *After* we have a valid key.  The whole discussion here
 is about *how to get that key*.


>A corollary to this is that if I validate *any* other key through a
>non-email channel, such as the telephone or a personal meeting, the jig
>is again up.  If the key has been spoofed (and all keys must be spoofed
>if any are), it will be detected.

 I believe I mentioned this.


>(Of course, an even simpler measure is to call someone up and ask what my
>public key .sig was at his site.  If I am being attacked as above,
>it must be different from my actual public key.)

 Yes, you are attempting to *validate* your key by a separate
 channel, as I have advocated.

 But when you find out it is different, what do you do?  Do you
 move to another node?  Can you?

 As I see it, it is more desirable to be in a position where you
 *do not care* what the network does, as long as they deliver your
 messages.  Then we don't have to say "Spoofing must be hard, so
 it can't happen to us, so it's silly to worry about it."  If we
 do it right, we just don't care how easy it is.

 We get to this envious position by designing a *secure* protocol
 for key distribution.  Right now, a reasonable ad-hoc approach is
 separate-channel validation.  But email .sig delivery is a poor
 approach because, *if there is* a spoofer, we could be affected.
 That is hardly a ringing endorsement of security.


>Ritter makes much of "validated" keys using a Certification Authority.

 As far as he can remember, Mr. Ritter has mentioned CA's in two
 contexts:

    1)  As a form of key distribution far more secure than
        email .sig delivery.  (We *assume* that the government
        will have access.  But at least CA's would tend to
        keep the riff-raff out.)

    2)  As the basis for key-distribution in most of the
        academic papers on the subject.  Why is this?
        General incompetence and stupidity?  Conspiracy?
        Let's think about it . . . .


>I
>will note that it will be cheaper to subvert the CA than to crack RSA,
>so one of Ritter's arguments against decentralized public key use applies
>to the bureaucratic approach he favors as well.

 Yes, this is my point.  No, I do not favor CA's.


>Plus, any system which
>involves a national monopoly arrangement for CA's (as we may have on a
>de facto basis in the U.S. due to the patent protection of RSA) is, IMO,
>going to be *more* vulnerable to government pressure than a decentralized
>system.  A compromised CA is far more dangerous than a single compromised
>net node.  (And thus, far more valuable to the attacker.)

 I do not like CA's.  But, to return to the question, why is it
 that they are so often used as the basis for key-distribution
 protocols?  Is it some sort of government PLOT?

 Or is it simply because any crypto corporation or academic who
 has addressed the issue sees that the obvious trivial approach
 (e.g., .sig delivery) does not maintain security?


>Another corollary to the need for a successful spoofer to alter all
>incoming keys has been stated here as well: if such spoofing is a danger
>more of the future than of the present, then collecting keys *now*, before
>such spoofing begins, is a very good idea.

 Sure, you can have a good key out there as long as you don't
 change your key.  Too bad you have to change your key.

 As long as you keep the same key, there is an increasing
 probability that someone has penetrated your security.  If you
 have a security incident (fire, computer repair, fire an employee
 or divorce a spouse) you either keep the unspoofed key and accept
 a *probable* lack of security, or change the key and fall into the
 domain of the spoofer.

 But, in the real world, we are rarely aware that someone *has*
 penetrated our security, *even if they have*.  To foil this sort
 of thing, it is necessary to change keys *whether or not* we are
 sure we have been penetrated.

 Wouldn't it be easier to just accept the potential existence of
 a spoofer and then arrange things so that it doesn't matter?
 CHANGE YOUR PUBLIC KEYS FREQUENTLY!  VALIDATE EVERY PUBLIC KEY
 BEFORE USE!  It's a little more trouble to do it right, of
 course.  My, how we fight and complain to avoid it.


>If, ten years from now, a
>spoofer attacks me as above, and I've saved some of these currently-
>published keys, they can be used to expose the spoofing.  All it takes
>is for me to send a message encrypted with one of these old keys which
>includes my public key in the encrypted portion.  Since I collected these
>keys before the spoofer went into business, he can't tell what I am sending,
>and he can't change my public key in the encrypted part of the message.
>The difference between what everybody else thinks my public key is and
>what I think it is will again be exposed.

 You mean that you think that individuals can keep the secret portion
 of a public key secret to a high probability for the period of
 ten years?  Remember that once the secret part is exposed, *anybody*
 with that secret can use it to "sign."  Useful signatures are only
 possible with secret key portions which have never been exposed.
 And we only know that for sure when they have just been created.


>Hence, this practice of publishing keys now, which Ritter decries, may
>actually provide a foundation for preventing the spoofing attack in the
>future.

 Ritter "decries" things which just don't work.


>Ritter points out that even if I follow all of these precautions, there is
>no assurance that my correspondent is.  If he is the one being attacked,
>and, as a naive user, has not taken any of these elementary measures to
>prevent it, then my messages to him will be compromised.

 Without a quote to nail this down, I'm not even sure what you
 are referring to; I doubt it was something that obvious.

 Perhaps my point was this:  If your correspondent doesn't validate
 the key he *thinks* is yours, when he contacts you, *you* may be
 in trouble.  You get a message *in your valid key* with a key for
 you to use to reply.  A shame, isn't it, that that key came from
 a spoofer?  Who is being attacked here, the naive user, or the
 suave sophisticate who does not insist that his correspondents
 validate their use of his public key?


>But of course, any encrypted communication with a person inexperienced
>in the need for care must be viewed with caution.  There are plenty of
>other ways inexperienced users can compromise our conversation.

 Obviously.


>Failure
>to guard the secret key carefully is probably a far greater danger.

 Really?  How do you know this?  How do you measure a "greater"
 danger than something which costs almost nothing to install,
 and delivers intercepts forever at almost no cost?


>And
>no CA hierarchy will help with that.  The best approach is to enlighten
>my correspondent as to the need for the simple precautions I've outlined.

 The precautions you outlined are simple enough; they just
 don't preserve security.


>But hopefully, in an environment in which most email conversations are
>routinely encrypted (a practice I consider likely in a few years), the
>need for this kind of care will be widely understood.

 Yes.  In particular, people need to understand why they should
 validate public keys.  If this happens soon enough, perhaps we
 can avoid having the network overrun with spoofers.

 ---
 Terry Ritter   ritter@cactus.org

ritter@cactus.org (Terry Ritter) writes:
> In <9209252236.1.20681@cup.portal.com> a-boyles@cup.portal.com writes:

->I think Terry Ritter is underestimating the effort needed to successfully
->carry out the spoofing attack he describes.

> Look, I really want to get out of this discussion, but this is
> really quite outrageous.  We're talking about computers here.
> Once a decent spoofing program is written, how much does it "cost"
> to get it running on a bunch of nodes?  Perhaps the expense of
> visiting the various node owners and pulling out badges?

This entire argument has revolved around establishing the private key of
someone you haven't met, or can't meet, in person or by telephone.  Pray
tell, just why would you want to do that?  No matter how the person comes
across on newnews, he or she could be an agent provacateur or spy or...
I mean, the ultimate (and simplest) spoof is to just pretend to be someone
else when you are on the net.

Why would you attempt to set up a secret channel with someone you haven't
'vetted by other means?
-- 
Marc Kaufman (kaufman@CS.Stanford.EDU)