Subject: Revised LINK -07 now online

From: Phil Karn <[email-masked]>
Date: Tue, 20 Nov 2001 16:29:23 -0800 (PST)

Hi. At long last, the Advice for Subnetwork Designers document has been
revised with new text in the Security Considerations section. The main
change was the addition of paragraphs on traffic analysis. There are
a few other rewordings that should help clarify the consensus points
reported by Aaron Falk from the London WG meeting.

As usual, the URL is

http://people.qualcomm.com/karn/pilc.txt

--Phil

---

From: Dan Grossman <[email-masked]>
Date: Wed, 21 Nov 2001 14:35:31 -0500

Sigh...

Once again we get to the I-D deadline and once again there are concerns that 
need to be addressed.

  Several security mechanisms that can be used end-to-end have already
   been deployed in the Internet and are enjoying increasing use. The
   most important are the Secure Sockets Layer (SSL) [SSL2] [SSL3] and
   TLS [RFC2246] primarily used to protect web commerce; Pretty Good
   Privacy (PGP) [RFC1991], primarily used to protect and authenticate
   email and software distributions; the Secure Shell (SSH), used for
   secure remote access and file transfer; and IPSEC [RFC2401], a
   general purpose encryption and authentication mechanism that sits
   just above IP and can be used by any IP application. (IPSEC can
   actually be used either on an end-to-end basis or between security
   gateways that do not include either or both end systems.)

Dan:  This paragraph is too long. This is a document about subnets, not 
applications. To the extent subnet designers are ignorant about these things, 
it also creates false expectations about widespread deployment and usage.  
Generally it is fair to say that  mechanisms that are not bundled with the 
dominant operating system and/or browsers and/or web servers and/or mail 
clients cannot be said to be broadly deployed (sorry PGP, SSH and IPSEC).  

   Nonetheless, end-to-end security mechanisms are not used as widely as
   might be desired. However, the group could not reach consensus on
   whether subnetwork designers should be actively encouraged to
   implement mechanisms to protect user data.

   The majority of the working group held that subnetwork security

Dan: > Since when does the IETF have majorities and minorities!!!   Did we 
take a vote ;-)? This is an extremely prejudicial statement.  The previous 
wording was something to the effect of one point of view held (or something 
like that).  If we insist on using adjectives, we could refer this as the 
purist point of view (versus the pragmatic point of view), but I think our 
audience can make up their own minds when presented with facts rather than 
opinions.

   mechanisms, especially when weak or incorrectly implemented [BGW],
   may actually be counterproductive.  The argument is that subnetwork
   security mechanisms can lull end users into a false sense of
   security, diminish the incentive to deploy effective end-to-end
   mechanisms, and encourage "risky" uses of the Internet that would not
   be made if users understood the inherent limits of subnetwork
   security mechanisms.

   The other point of view actively promotes subnetwork security
   mechanisms on the principle that they can't hurt. The argument is
    that while subnetwork security is admittedly inferior to end-to-end
   security, subnetwork security doesn't preclude the use of end-to-end
   security.  Furthermore, many users are unwilling or unable to
   implement end-to-end security, so subnetwork security is better than
   no security at all. This viewpoint calls for subnetworks to implement
   mechanisms to achieve a degree of security commensurate with a series
   of concatenated, physically protected point-to-point links. This
   approach is especially applicable to wireless links and wired links
   where physical security is impractical.  It is the rationale for
   802.11's "wire-equivalent privacy" (WEP) scheme and the privacy
   schemes in DOCSIS modems for cable TV networks.

Dan: No, that is not the other point of view, or at least not my point of 
view, and I've been the most vocal advocate.  It is also worded in a 
dismissive and prejudicial fashion, reflecting the editor's negative opinion 
rather than the views of its advocates.  Please replace this text, in its 
entirety, with the following, and please don't make editorial "improvements" 
that dilute or disparge the point.  I'm also going to make a direct request 
that chairs intervene here to ensure that the editor faithfully captures the 
points raised without injecting his personal opinions.

"The other point of view encourages subnetwork security on the principle that 
it is better than the default situation, which all too often is no security at 
all.  Users of especially vulnerable subnets (such as consumers who have 
wireless home networks and/or shared media Internet access) often have control 
over at most one endpoint -- usually a client -- and therefore cannot enforce 
the use of end-to-end mechanisms. However, subnet security can be entirely 
adequate for protecting low-valued assets against the most likely threats.  In 
any event, subnet mechanisms do not preclude the use of end-to-end mechanisms, 
which are typically used to protect high valued assets.  This viewpoint 
recognizes that many security policies  implicitly assume that the entire 
end-to-end path is composed of a series of concatenated links that are 
nominally physically secured.  That is, these policies assume that all 
endpoints of all links are trusted and that access to the physical media by 
attackers is difficult.  To meet the assumptions of such policies, explicit 
mechanisms are needed for links (especially shared media links) that lack  
physical protection.  This, for example, is the rationale that underlies Wired 
Equivalent Privacy (WEP) in the IEEE 802.11 wireless LAN standard, and the 
Baseline Privacy Interface in the DOCSIS data over cable television networks 
standards." 

   We therefore recommend that subnetwork vendors who choose to
                                          ^^^
subnetwork designers:  this document is also directed to standards bodies, and 
this is the terminology we've used throughout the draft

   implement security mechanisms to protect user data be as candid as
   possible with the details of such security mechanisms and the
   inherent limits of even the most secure mechanisms when implemented
   in a subnetwork rather than on an end-to-end basis.

<SNIP> 
   Another potential role for subnetwork security is to protect users
   against traffic analysis, i.e., identifying the communicating parties
   and determining their communication patterns and volumes even when
   their actual contents are protected by strong end-to-end security
   mechanisms.  Lower-layer security can be more effective against
   traffic analysis due to its inherent ability to aggregate the
   communications of multiple parties sharing the same physical
   facilities while obscuring higher layer protocol information that
   indicates specific end points, such as IP addresses and TCP/UDP port
   numbers.

   However, traffic analysis is a notoriously subtle and difficult
   threat to understand and defeat, far more so than threats to
   confidentiality and integrity.  We therefore urge extreme care in the
   design of subnetwork security mechanisms specifically intended to
   thwart traffic analysis.

What does this add?  Suggest removing this paragraph.

Dan

---

From: Phil Karn <[email-masked]>
Date: Wed, 21 Nov 2001 12:41:42 -0800 (PST)

>it also creates false expectations about widespread deployment and usage.  

The whole purpose of this document is to educate the designers of
subnetworks about the Internet environment in which they are expected
to operate. I started this effort because I perceived many subnetwork
designers to be working in a vacuum. I therefore think it entirely
within scope to enumerate the end-to-end security mechanisms that are
already available in the Internet architecture to help the subnetwork
designer decide the importance of providing similar features.

This is *exactly* analogous to the discussion of how the end-to-end
reliability provided by Internet transport protocols obviates the need
for "total" reliability in a subnetwork. Otherwise we have unnecessary
duplication of function.

>take a vote ;-)? This is an extremely prejudicial statement.  The previous 

Quite frankly, Dan, I'm being quite charitable here. The "minority"
consists of one person: you. Otherwise it would have been a clear
consensus.  And you didn't even show up in London to make your case; I
had to make it for you as best I could, and I am still trying to
present both points of view in the document as best I can.

I'm still digesting your substitute text. I may put it in just to get
this over with.

Nevertheless, I suspect you will never be satisfied with the result,
so all I can suggest at this point is that you document your point of
view in your own document and publish it as an informational RFC with
your name on it.

[section on traffic analysis]

>What does this add?  Suggest removing this paragraph.

You weren't in London, so you missed the discussion about the utility of
subnetwork security to thwart traffic analysis. I suggested, and the group
agreed, to add language addressing this point with the caveat that traffic
analysis is a very difficult and subtle threat.

Phil

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 21 Nov 2001 20:57:40 +0000 (GMT)

> Once again we get to the I-D deadline and once again there are concerns that 

well, yes.

I've sent off my usual long list of mostly-minor editing nits on -07
to Phil (Date: Wed, 21 Nov 2001 19:48:36 +0000 (GMT) 8K of text) -
this long draft took several hours to read and comment on, I struggled
to find the time today, and if my herculean polishing efforts aren't
taken into account in the limited remaining time while Phil and Dan
battle it out I'll be slightly peeved.

This last-minute stuff and compressing all editing/revision/peer
review of changes to a WG draft as close as possible to the submission
deadline really isn't fun for supposedly-involved listed contributors
like Dan and me. Earlier availability of Phil's -07 draft would have
been helpful.

and the worst thing is, I could see all this coming. I predicted to
the chairs, like, WEEKS ago that all this would happen. I must be,
like, _psychic_ or something.

> clients cannot be said to be broadly deployed (sorry PGP, SSH and IPSEC).  

It's only fair to the vendor of the dominant operating system to say
that.

(I understand Windows XP has IPSec bundled.
Might not be enabled by default, mind.)

These mechanisms are widely deployed. Multiple implementations. Freely
available.

> take a vote ;-)?

wasn't it hummed in London after a zillion IPSec mafia advocates had
taken the mike?

> This is an extremely prejudicial statement.  The previous 

If the audience can make up its own mind, you can then have no
objection to that 'prejudicial statement'. Like it or not, it _is_ a
majority view in the WG, and both viewpoints are carefully framed in
identical 'the argument is' formats.

Earlier discussion of this revised text would have been good...

> This viewpoint 
> attackers is difficult. 

You're not willing to critique the set of security policies that the
text you present advocates? Doesn't use of a subnetwork include
specification of an appropriate security policy? In fact, doesn't the
subnetwork create the policy?

(and doesn't Lessig write reams about this stuff?)

I do have a problem with this prejudicial presentation of these
'many security policies'.

> Please replace this text, in its entirety, with the following, and
> please don't make editorial "improvements"  that dilute or disparge
> the point.  I'm also going to make a direct request that chairs
> intervene here to ensure that the editor faithfully captures the

It could be argued that you're attempting to inject your personal
opinions without editing or review, and I'd have a problem with that
too.

> this is the terminology we've used throughout the draft

yup.

(I do think there should be an earlier and perhaps more mention of
traffic analysis; it's going to become more and more significant, and
it's imo still underplayed in this draft.)

L.

compromise: commutative.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Dan Grossman <[email-masked]>
Date: Wed, 21 Nov 2001 16:14:42 -0500

> designer decide the importance of providing similar features.

Available, yes.  In ubiquitous use, no.

> for "total" reliability in a subnetwork. Otherwise we have unnecessary

Bad analogy.  TCP is an integral part of the architecture, has been there from 
the beginning.  All these other mechanisms were kinda added on over the years, 
but are still not ubiquitously deployed and used.

> present both points of view in the document as best I can.

I'm not going to engage in a defend/attack.  See RFC 3184 concerning personal 
attacks and RFC 2026 on a variety of other matters, including the use of 
meetings and mailing lists. 
> I'm still digesting your substitute text. I may put it in just to get

Thank you.
> view in your own document and publish it as an informational RFC with

This is a working group document, and subject to working group consensus.

> analysis is a very difficult and subtle threat.

I was filled in afterwards. I agree with the first paragraph.  It's only the 
second that seems unnecessary.

---

From: Phil Karn <[email-masked]>
Date: Wed, 21 Nov 2001 13:19:27 -0800 (PST)

>This is a working group document, and subject to working group consensus.

Exactly. And the WG consensus was *clearly* opposed to your
position. So I still feel I'm being charitable by even including your
point of view at all.

>second that seems unnecessary.

I added the second paragraph after seeing comments by Bill Summerfeld
and others who wanted to stress the difficult nature of traffic analysis.
It still seems reasonable to me.

Phil

---

From: Dan Grossman <[email-masked]>
Date: Wed, 21 Nov 2001 16:55:11 -0500

> It's only fair to the vendor of the dominant operating system to say

Well, like it or not, there is a monopoly in desktop OSes, at least under US 
law. Most people use only those mechanisms that are supplied with the 
operating system they have, as well as with other applications that are 
bundled with it (such as browsers and mail clients).  
 
> Might not be enabled by default, mind.)
As I understand it, IPSec is bundled with XP Professional Edition only, for 
VPNs.  The consumer edition does not have IPSec.

> These mechanisms are widely deployed. Multiple implementations. Freely
Multiple implementations, freely available, yes.  Widely deployed (in 
operational use on the vast majority of hosts) no.

Just as an example of how little deployment PGP has, the September 11 villians 
communicated with each other and their masters in the clear.  The likely 
rationale is that had they used PGP, those messages would have called 
attention to themselves by standing out in a sea of in-the-clear messages.  
It's called hiding in plain view.
> wasn't it hummed in London after a zillion IPSec mafia advocates had
See RFC 2026.  In any event, I could not make it to London.

> identical 'the argument is' formats.

See RFC 2026.

> subnetwork create the policy?

Hummm.  Maybe I didn't make clear _whose_ security policy is in question.  The 
problem is that use  of end-to-end mechanisms (or not) in client/server 
environments -- especially the Web -- is under the control of the server's 
security.  So, for example, no matter how much I might prefer to use SSL in 
communicating with Webmail from my browser,  there's no way to make it so.  
Bad enough with dialup and DSL. Ditto with cable, since CableLabs ignored the 
"majority's" advice.  But I sure don't plan to use it over the 802.11b in Salt 
Lake City.  Maybe when 802.11i gets deployed... assuming that the 802.11i 
Working Group doesn't take the "majority's" advice and disband.  

So in light of Lloyd's comments, try "that many servers' security policies" 
> 'many security policies'.
Show me that even a simple majority of web sites that offer even moderately 
sensitive content use end-to-end mechanisms and I'll shut up.  One SSL-secured 
form doesn't count.

> opinions without editing or review, and I'd have a problem with that
I have no problem with open discussion and group review.  I do have a problem 
when there is no consensus, the group agrees to publish both views, and the 
editorial priviledge is used to disparage and inaccurately represent one of 
the views.  
> it's imo still underplayed in this draft.)

How so?  I can see some secondary threats... spreading it 'round the 
neighborhood that Mr. Jones (or Congressman/MP Jones) visits sex.com, for 
example.  Or things that look like encrypted emails between the homes of the 
CEO of company X and the CEO of company Y might lead to some interesting 
speculation.  You seem to be concerned about something bigger?

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 21 Nov 2001 22:05:18 +0000 (GMT)

On Wed, 21 Nov 2001, Phil Karn wrote:

> for "total" reliability in a subnetwork. 

The only comment gorry and I have had so far on ARQ being last-called
is that transport reliability does not provide end-to-end reliability;
it's still point-to-point, though networking types tend not to see it
that way.

Applications must still defend themselves against buggy transport
stacks and include their own message-checking. Users must defend
themselves against buggy applications and will e.g. ring to check an
email got through...

> consists of one person: you. 

A minority of one (and a half - I'm not fully convinced by either of
you, and I'm beginning to suspect IPSec is an overly subtle joke on
the rest of the planet, since it's too complex to get working. See
Schneier's critique of same.)

> Otherwise it would have been a clear
> consensus.  And you didn't even show up in London to make your case;

damn unfair, Phil, unless you paid for your all of your London trip,
meeting fees, and accommodation yourself. Alas, I'm not able to fly to
Salt Lake City to make this particular point to you in person.

> I'm still digesting your substitute text. I may put it in just to get

Do that, and *I'll* go to the chairs and scream blue murder just as
Dan was threatening to.

> view in your own document and publish it as an informational RFC with

That's a reasonable suggestion, and one I believe I've made to Dan
previously.

> analysis is a very difficult and subtle threat.

A difficult threat to counter, you mean. passive traffic
analysis is not difficult at all. You just sit there, picking the
stuff up, and you can spend the rest of eternity analysing it or
correlating it with other information to use it to your advantage.

L.

---

From: Phil Karn <[email-masked]>
Date: Wed, 21 Nov 2001 14:26:01 -0800 (PST)

>themselves against buggy applications and will e.g. ring to check an

Quite correct. The only problem with relying on the transport layer
for error checking is that the transport layer may not be end-to-end
"enough". Clark et al talked about this a long time ago when they
introduced the concept of "fate sharing". Problem is, whether the TCP
"shares fate" with an application depends on the implementation, yet
it affects the whole internet architecture.

>Schneier's critique of same.)

I will not defend IPSEC. I will cite it as a prime example of how the
IETF has declined from a small, lean-and-mean organization that got
things done quickly and effectively to a conventional, bloated,
standards body.

>Salt Lake City to make this particular point to you in person.

As far as I know, Dan works for Motorola and travels on an expense
account, just as I do. We're on a level playing field here.

>Do that, and *I'll* go to the chairs and scream blue murder just as

Well, then I guess you'll have to scream blue murder at me, because I
put in Dan's text.  I just didn't see that much difference between it
and what I had already said to be willing to put up with more of his
sniping.  I just want this to be over.

Now if I can just fix my local webserver problem that's
keeping me from updating my web page, you can see it.

>correlating it with other information to use it to your advantage.

More or less exactly what I believe I said in the document.

Phil

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 21 Nov 2001 22:30:28 +0000 (GMT)

> It's called hiding in plain view.

That's not a workable syllogism. And you've invoked US law and
RFC2026, too. Is there _any_ adhominem attack or rhetorical defence
that you _won't_ try to use?

> > identical 'the argument is' formats.

The audience is this mailing list, where there is a majority view. I
don't see anyone leaping to your defence and agreeing with you.

> communicating with Webmail from my browser,  there's no way to make it so.  

Then don't use Webmail. The invisible hand will supposedly take care
of this in the long run - ask any economist.

> I have no problem with open discussion and group review. 
> I do have a problem when there is no consensus,

well, can other non-consenting adults please speak up?

> the group agrees to publish both views, and the 

you're welcome to your opinion about what constitutes disparagement.

> speculation.  You seem to be concerned about something bigger? 

Yes.

L.

---

From: Dan Grossman <[email-masked]>
Date: Wed, 21 Nov 2001 17:33:37 -0500

> account, just as I do. We're on a level playing field here.

In case you hadn't noticed, there's a recession on.  Budgets have been cut.  I 
could not justify going to London under those circumstances.  If I went, it 
would have been on my own nickel.

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 21 Nov 2001 22:53:42 +0000 (GMT)

On Wed, 21 Nov 2001, Phil Karn wrote:

> put in Dan's text.

Sheesh. This last-minute grandstanding between two people wanting the
last word of this bit of text that has taken up so much of the WG's
time and attention is, frankly, unacceptable. I don't see how proper
editorial decisions can be taken at last minute like this.

> I just didn't see that much difference between it

Well, you have had months to submit this draft (we revised the ARQ
draft in August while I could still vaguely remember what we were
doing), and if it wasn't so deliberately last-minute to avoid any
further discussion there'd probably be more reasoned debate and less
sniping. Well, I'd like to think so.

I suggest that a further revision of the draft add a second editor.
This will give Phil a much-needed break and reassure Dan and anyone
else concerning personal viewpoints, in that the editorial bias won't
be just one person.

Obviously, Dan, Phil, and I are disqualified for this task.

> More or less exactly what I believe I said in the document.

...but not what you said in the previous email that my comments
responded to.

L.

---

From: Phil Karn <[email-masked]>
Date: Wed, 21 Nov 2001 15:04:43 -0800

>speculation.  You seem to be concerned about something bigger? 

This raises an interesting distinction that I don't think is made
often enough. Many (if not most) people's Internet privacy concerns
have less to do with maintaining the confidentiality of the contents
than with maintaining their anonymity in receiving or sending it.

The contents of sex.com, for example, are hardly secret.  Any
interested party can obtain them, perhaps after paying a fee. It's the
fact that **Mr. Jones is requesting the contents of sex.com** that
Mr. Jones would like kept private.

The same is true for encrypted emails between the homes of the CEOs of
companies X and Y.

Both examples fall squarely into the category of traffic analysis
threats, and as I said in the -07 and -08 drafts, this may turn out to
be the one function (aside from protecting the subnetwork itself) that
subnetwork security may be able to do better than end-to-end security.
In fact, it is the only potential counter-example to the end-to-end
argument that I can think of.

I would go so far as to say that confidentiality is a completely
solved problem, at least in comparison to the much more difficult
issues of thwarting traffic analysis and protecting user anonymity.

Phil

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 21 Nov 2001 23:22:55 +0000 (GMT)

Yes.

This is why I spent so much time grumbling on [email-masked] about
BEEP's 'tuned for privacy' profiles, which were no such
thing. Tuned for transport security, more like.

What a waste of effort THAT was.

L.

---

From: Phil Karn <[email-masked]>
Date: Wed, 21 Nov 2001 15:26:27 -0800 (PST)

>else concerning personal viewpoints, in that the editorial bias won't

If this is what the WG wants, I'd be quite happy to oblige. I'd like
to think that the document is now done in the WG, though, and that
more people can be reached (and more good comments received) by
putting it out as an RFC.

Part of the problem is that for several cycles now LINK has seemed
like it was ready for last call. Then somebody starts a major
discussion on some specific point that primarily rehashes old
arguments.

This time was no exception; my intention for this cycle was to make
only a minor addition to cover the comments about traffic analysis
that were discussed in London.  Yet even this triggered a big debate.

I'm not talking about your editorial revisions, btw; they were
entirely appropriate, easily made and much appreciated. I'm talking
about an apparent inability to follow the principle I suggested (and
the WG adopted) when I first proposed LINK: when consensus on a
particular point cannot be reached, state that fact, give both (or
all) points of view and move on. Appellate courts have done the same
thing for years; that's why they publish majority and minority
opinions.  Sometimes the minority opinions later become majority
opinions.

We may not have all the answers, but that's not an excuse to debate
this forever in the WG. As I said, getting it out as an RFC will
expose it to many more people and quite likely result in some good
suggestions and comments that can go into a future revision of the
document.

I leave it up to the chair to determine what to do next.

Phil

---

From: Phil Karn <[email-masked]>
Date: Wed, 21 Nov 2001 15:53:46 -0800

I'll go even further and respond to Dan's question earlier about the
prevalance of end-to-end encryption on the web. I'd say I've *never*
wanted or needed to protect the confidentiality of something I've sent or
received on the web but have been unable to use SSL to do so.

My bank, my broker and my home web server all support SSL, as do all
the various commerce sites from which I have bought products or
services with my credit cards. I'd say SSL is quite a success story.

But that's an entirely different issue from being able to hide which
publicly-accessible web sites I surf to. That problem remains largely
unsolved. Even end-to-end SSL wouldn't solve it if the URLs are
substantially the same to everyone and SSL merely encrypts the
contents of public web pages that anyone else can also fetch.

I've experimented with surfing over a SSH tunnel to a public caching
proxy, but that's still vulnerable to traffic analysis that correlates
the plaintext going into the proxy with the encrypted traffic going
back out to me. It's hard.

Phil

---

From: Dan Grossman <[email-masked]>
Date: Mon, 26 Nov 2001 11:36:34 -0500

> services with my credit cards. I'd say SSL is quite a success story.

Yes, it's a success story but no, it's not ubiquitous.

Finanicial services institutions use SSL with strong encryption very 
consistently.  Their auditors would not tolerate otherwise, and their 
regulators and underwriters read the auditors' reports.

Almost all E-commerce sites always use SSL for forms that contain credit card 
numbers and usually for forms containing personally identifying information.  
They rarely do for catalog browsing, adding to shopping carts and the like 
(I've only come across one site that does).  As I've mentioned before, 
sometimes one's browsings and purchases need to be kept private.  

There are other sites that don't but should.  For example, several sites that 
I use regularly do not use SSL for passwords.  I've complained, but it's like 
complaining to a brick wall.  A particularly annoying one is a site which 
partners with my (personal) ISP to allow me to tunnel email through HTTP and 
HTML.  No use of SSL at all, even for password.  Lloyd suggests not using 
them.  I don't make it a point to cut off my nose to spite my face: there are 
times when the alternative is no access to personal email at all.

> back out to me. It's hard.

The attack you describe would be a difficult one to mount.  It would require 
either physical access to the link(s) to the cacheing proxy, an attack on DNS 
to redirect you to a spoofed cacheing proxy, or an attack on the routing 
system to route the traffic to a monitoring point.  It would not be worth the 
effort to find out that (for the sake of argument) you visited sex.com.  
Perhaps if you were a politician or a celeb, it might be.  But there are so 
many more easily exploited vulnerabilities that this one seems relatively 
unimportant.

Of far greater relevance to this discussion is the simple act of snooping 
one's neighbor's wireless home network, or a cable TV data system or a 2.5/3G 
cellular system.   The assets that you want to protect are trivial to obtain 
without any kind of subnet encryption, and difficult to a degree proportionate 
to the strength of the mechanisms deployed otherwise.   Malicious gossip and 
even petty blackmail -- except, perhaps, of public figures -- have a value to 
most attackers that is proportionate to simple attacks, but not to highly 
sophisticated ones.  

Perhaps one point that I've tried, but failed, to get across in this debate 
has been that perfect security is obtained only by not trying to communicate.  
The challenge is to see to it that mechanisms are proportionate to the assets 
being protected and the perceived threats to those assets.
Dan

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 26 Nov 2001 22:30:02 +0000 (GMT)

On Mon, 26 Nov 2001, Dan Grossman wrote:

> them.  

see below.

> I don't make it a point to cut off my nose to spite my face: there are 
[..]

so you've evaluated the risks and you judge them acceptable. as anyone
else can do.

> has been that perfect security is obtained only by not trying to communicate.  

that was exactly the point I was making to you. If you know a site you
use regularly is insecure, do not communicate with it... voila, you
have achieved perfect security with respect to that site.

Simple, no?

> being protected and the perceived threats to those assets.

in the global commons of an internetworked environment, that statement
becomes bunk. For example, an open mail relay does not pose much of a
problem to colocated assets that it normally delivers mail to, but to
everyone else on the planet as forged spam surges through it, even
though everyone else's assets don't show up on your balance sheet.

(unless, of course, you're treating intangibles like your reputation
as assets, so being real-time-blackholed would be the perceived
threat to be protected against.)

Remember that any shared link is a (privileged/limited/scope/local)
commons; as an asset the link itself generally has little intrinsic
value - it's merely an access mechanism - and the value of the asets
on the local subnetwork is as nothing compared to the value of the
internetwork as a whole.

Claude Bastiat's "What is seen and not seen" is imo a far more
perceptive and relevant take on the whole thing than a limited-scope
military/commercial asset-protection doctrine, and has a far better
sense of proportion.

L.

---

From: Dan Grossman <[email-masked]>
Date: Mon, 26 Nov 2001 17:59:48 -0500

One more reply on the list, then I suggest we take this private.  Unless there 
are specific points that directly affect PILC links.

> so you've evaluated the risks and you judge them acceptable. as anyone

No, I judge them acceptable for some subnets but not others.  So, for example, 
I'll use webmail when hardwired or dialled in to the corporate Intranet.  
Sparingly over an Ethernet at a hotel somewhere. But definitely not over the 
802.11b subnet at IETF.

> have achieved perfect security with respect to that site.

The point is not to let the quest for perfection be the enemy of the merely 
good enough.

> threat to be protected against.)

The bandwidth of the link is an asset, your (non)compliance with your ISP's 
AUP is an asset...

From a global perspective, the email architecture failed to take into account 
that uncontrolled relays, lack of mandatory authentication and IP address 
spoofing created an easily exploited vulnerability, and that there would be a 
threat that unscrupuluous entrepreneurs would take advantage of "free" 
anonymous email delivery.

Also, I wasn't there, but can easily imagine a conversation whose conclusion 
was that since perfect security would be hard, they'd do no security at all 
and get back to it "later".

> value

I think that certain Operators who've recently broken the bank for 3G spectrum 
might take issue with that :-)

> - it's merely an access mechanism - and the value of the asets

Reference??

Again, this is getting off-topic and should be concluded privately.

Dan

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 26 Nov 2001 23:18:01 +0000 (GMT)

On Mon, 26 Nov 2001, Dan Grossman wrote:

> No, I judge them acceptable for some subnets but not others.  

again, a personal choice. As anyone else can have.

> The point is not to let the quest for perfection be the enemy of the merely 

heh. that's never stopped you thus far.

> might take issue with that :-)

as operators, they sell services. they broke their bank (well, the
first time - UK; later bidding processes oddly wound up with the same
number of coalitions as there were licences) because they thought the
the cost of being able to enable those services was worthwhile.

> > military/commercial asset-protection doctrine, and has a far better

http://www.google.com/
or your local library.

> Again, this is getting off-topic and should be concluded privately.

it's concluded here. this has already taken too much of my time...

L.