Subject: ITU takes over?

From: [email-masked] (Noel Chiappa)
Date: Mon, 8 Dec 2003 14:42:41 -0500 (EST)

Just saw this online, and it seem apropos to recent traffic:

  A controversial plan to grant governments broad controls over the Internet
  has stolen the spotlight of a United Nations conference on IT next week,
  where China and Cuba will be among its strongest supporters. 
  Leaders from nearly 200 countries will convene in Geneva for the World
  Summit on the Information Society (WSIS) Dec. 10-12, an inaugural
  conference with lofty goals to discuss bridging the digital divide and
  fostering press freedoms. 
  But a contentious political move to grant an international governing body
  such as the U.N.'s International Telecommunication Union (ITU) control over
  Internet governance issues -- from distributing Web site domains to the
  public to fighting spam -- has all but obscured the more virtuous aspects
  of the event. 
  ...
  .. many in the developing world believe a new approach is needed as the
  [Internet] enters its teen years, one that will see poorer countries
  harness new technologies to improve their competitive stance. 
  ...
  [ICANN] has been criticized roundly for adopting a pro-business approach
  that neglects the developing world. 
  The ITU .. has been put forth by the developing world as the governing body
  that will best address its needs. 
  "What we are looking at is the future management of the Internet. It's not
  about who owns it or who will be regulating the laws, but what is best way
  to manage what has become a natural resource for all of humanity,'' a
  summit official said.

    http://money.cnn.com/2003/12/08/technology/internet.reut/index.htm

Anyone know more about this?

	Noel

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Mon, 8 Dec 2003 23:51:32 +0100

> Anyone know more about this?

Since it is being discussed in secret (with even ICANN excluded,
apparently), it's hard to know more.

---

From: "vinton g. cerf" <[email-masked]>
Date: Mon, 08 Dec 2003 19:09:34 -0500

Noel:

1.  The Salt Lake Tribune: " U.S. Net dominance questioned"
<http://www.sltrib.com/2003/Dec/12082003/business/118003.asp>

2.  The Register: "Internet showdown side-stepped in Geneva"
<http://www.theregister.co.uk/content/6/34394.html>

3.  CNN Money: "A potentially tangled Web?"
<http://money.cnn.com/2003/12/08/technology/internet.reut/>

4.  The Washington Times: "U.N. control of Web rejected"
<http://washingtontimes.com/world/20031208-125717-6682r.htm>

5.  SeattlePi.com: "Talks seek global Internet ground rules"
<http://seattlepi.nwsource.com/business/aptech_story.asp?category=1700&slug= 
UN%20Tech%20Summit>

6.  The New York Times: "Digital Divide to Be Big Issue at U.N. Summit on
Internet"
<http://www.nytimes.com/2003/12/07/international/07CND-DIVI.html?ex=10714644 
00&en=1f0ead87b5fce559&ei=5062&partner=GOOGLE>

7.  Telecom.paper: "ITU nominated to monitor Internet governance"
<http://www.telecom.paper.nl/index.asp?location=http%3A//www.telecom.paper.n 
l/site/news_ta.asp%3Ftype%3Dabstract%26id%3D37965%26NR%3D122>

8.  TechWorld: "Battle for control of Internet postponed"
<http://www.techworld.com/news/index.cfm?fuseaction=displaynews&newsid=750>

9.  ARS Technica: "U.N. battle brewing over control of the Internet"
<http://arstechnica.com/news/posts/1070735373.html>

10.  BBC News: "Go ahead for UN internet summit"
<http://news.bbc.co.uk/2/hi/technology/3300071.stm>

At 02:42 PM 12/8/2003 -0500, Noel Chiappa wrote:
> <snip>

Vint Cerf
SVP Technology Strategy
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup

---

From: "vinton g. cerf" <[email-masked]>
Date: Mon, 08 Dec 2003 18:36:50 -0500

There have been fairly intense discussions in a series of meetings called "PrepComs" as in "preparatory committees" leading up to the World Summit on the Information Society (WSIS) taking place December 10-12 in Geneva. In the most recent meetings, a "government only" rule was invoked that excluded interested parties such as ICANN, among others, but the texts have been made visible. Of course, it remains to be seen whether these texts will be adopted by the summit meeting representatives.

The texts cover principles and action plans, respectively, for "realization" of the Information Society. 

The subject of "Internet Governance" has been a large focus of attention, as has been a proposal for creating an international fund to promote the creation of information infrastructure in the developing world. Internet Governance is a very broad topic including law enforcement, intellectual property protection, consumer protection, tax policies, and so on. It also happens to include some of the things that ICANN is responsible for. Unfortunately, the discussion has tended to center on ICANN as the only really visible example of an organization attempting to develop policy (which is being treated as synonymous with "governance"). ICANN's mandate is very limited and it would be helpful if the broad governance issues mentioned above could find other organizational homes. ICANN's work could be fitted into a larger framework but some people seem to think that if ICANN doesn't do all the things that might fall into "Internet governance" then ICANN should be replaced with, eg, an !
 ITU or
 UN body. 

This is, of course, a controversial matter with sovreignty of states mixed into a variety of political attitudes about the US, the Department of Commerce role with ICANN and so on. It should come as no surprise to anyone that I would prefer to see a solution to the broad governance problem that continues to limit the ICANN mandate and creates organizational homes for that which ICANN cannot or should not undertake. Just as plainly, I don't favor replacing ICANN with a UN-agency.

You may make a search on key words, like "internet governance" at that site www.wsis-online.net and will see all relevant meetings.

Hope this is helpful.

Vint Cerf

Vint Cerf
SVP Technology Strategy
MCI

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 08 Dec 2003 18:50:49 -0600

On 12/8/2003 5:36 PM, vinton g. cerf wrote:

> The subject of "Internet Governance" has been a large focus of
> attention, as has been a proposal for creating an international fund to
> promote the creation of information infrastructure in the developing
> world. Internet Governance is a very broad topic including law
> enforcement, intellectual property protection, consumer protection, tax
> policies, and so on.

Yay, another proposal to give control of $resource to $tyrant while having
the west pay for it.

What's the track record on those? Not gonna happen. Move along.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Ole J. Jacobsen" <[email-masked]>
Date: Mon, 8 Dec 2003 16:50:43 -0800 (PST)

See http://www.isoc.org/

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Tel: +1 408-527-8972   GSM: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj

---

From: Franck Martin <[email-masked]>
Date: 09 Dec 2003 13:01:13 +1200

Hmmm,

What is wrong with ISOC?

Cannot it be this body, we are looking for?

Cheers

> The subject of "Internet Governance" has been a large focus of attention, as has been a proposal for creating an international fund to promote the creation of information infrastructure in the deve…
  !

----
Franck Martin
[email-masked]
SOPAC, Fiji
GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9  D9C6 BE79 9E60 81D9 1320
"Toute connaissance est une reponse a une question" G.Bachelard

---

From: "vinton g. cerf" <[email-masked]>
Date: Mon, 08 Dec 2003 20:18:10 -0500

at the moment it is not well constituted to develop policy.

v

Vint Cerf
SVP Technology Strategy
MCI

---

From: Mark Atwood <[email-masked]>
Date: 08 Dec 2003 18:11:06 -0800

> at the moment it is not well constituted to develop policy.

This is a feature, not a bug.

-- 
Mark Atwood   | When you do things right,
[email-masked] | people won't be sure you've done anything at all.
http://www.pobox.com/~mra

---

From: shogunx <[email-masked]>
Date: Tue, 9 Dec 2003 05:37:18 -0500 (EST)

> at the moment it is not well constituted to develop policy.

No, but it well constituented to be.  Is it only necessary that it be
reconstituted.

Scott
> 22001 Loudoun County Parkway, F2-4115

sleekfreak pirate broadcast
world tour 2002-3
live from the pirate hideout
http://sleekfreak.ath.cx:81/

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Tue, 9 Dec 2003 04:32:48 +0100

> Cannot it be this body, we are looking for?

ISOC membership is open to anyone.  Very few governments are going to
support an organization that does not restrict its membership to elite
government representatives.

---

From: [email-masked]
Date: Tue, 09 Dec 2003 00:07:03 -0500

> No, but it well constituented to be.  Is it only necessary that it be

The fact that cats could swim for long periods underwater if only they were
fish is not by itself sufficient reason to attempt the conversion.

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 9 Dec 2003 00:22:43 -0800

At this time on this date, I cannot get a connection to http://www.isoc.org.

Have you ever gotten this connection?

Can you get it now?

Merry Christmas to all at your house;-)...\Stef

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Tue, 9 Dec 2003 09:28:16 +0100

> Have you ever gotten this connection?

It worked fine for me just now.

---

From: "Ole J. Jacobsen" <[email-masked]>
Date: Tue, 9 Dec 2003 00:32:35 -0800 (PST)

Yep, works fine for me, Stef. Time to switch providers?

:-)

Happy Holidays.

Ole

Ole J. Jacobsen

---

From: jfcm <[email-masked]>
Date: Tue, 09 Dec 2003 13:47:00 +0100

Dear Vint,
You may guess that I am deeply involved in that prepartory issues and I 
probably can help with some (I will try) unbiased understandings (I am 
sorry if this hurts some) of what happens, focusing on ICANN and IETF.

At 00:36 09/12/03, vinton g. cerf wrote:
>Content-Transfer-Encoding: 8bit
>There have been fairly intense discussions in a series of meetings called 
>"PrepComs" as in "preparatory committees" leading up to the World Summit 
>on the Information Society (WSIS) taking place December 10-12 in Geneva.

The main impact of these meetings has been the progressive understanding of 
the @large (in ICANN wording) reality. The entry of the civil society was 
very important at a time when "altermondialistes" became more cooperative 
and the US general policy pushed peoples to ally with their governments.

This helped many to understand that a network is first made of people and 
not of machines, bandwidth and protocols.

>In the most recent meetings, a "government only" rule was invoked that 
>excluded interested parties such as ICANN, among others, but the texts 
>have been made visible. Of course, it remains to be seen whether these 
>texts will be adopted by the summit meeting representatives.

This is technically true. Last meetings were "open" but only US/Europe and 
LMC (Linke-Minded countries) were allowed to speak to go faster and avoid 
confusion. Meetings were very often attended by private people who 
cross-polenized. ITU go by countries, this does not mean that ideas go by 
Govs.

It shown us that US lobbying is sometimes totally inneffective or counter 
productive when a few pros (the good and the bad scenario ...) are trying 
to overcome genuinely motivated people, all the more when one has to talk 
of the life of billions of people and incidently voters.

The Linke-Minded Country group was very determined - SA, Brazil, Saudia 
Arabia, China, Egypt and Malaysia. However the proposition of Gabon to 
quote ICANN by its name was not accepted.

>The texts cover principles and action plans, respectively, for 
>"realization" of the Information Society.

Yes. It can be said it is the world (as a customer) network project and 
specifications. The market of the century for leading technologies.

>The subject of "Internet Governance" has been a large focus of attention, 
>as has been a proposal for creating an international fund to promote the 
>creation of information infrastructure in the developing world. Internet 
>Governance is a very broad topic including law enforcement, intellectual 
>property protection, consumer protection, tax policies, and so on.

The internet is technically to be understood in the definition of 47 USC 
230 (f)(i) (all the connected computers of the world) and for most of the 
discussions in a purely brainware way: "what people think the internet is 
or shoud be".

Most never heard about TCP/IP. But they heard about the root and the surety 
problems we discussed in here, and more about the national security problem 
(ie; the errors that can be commited and the attacks they may suffer). This 
is NOT yet a widely expressed concern - by far - by delegations members. 
But it IS a serious (or main) and motivating unspoken (or spoken) key 
concern by Govs.

>It also happens to include some of the things that ICANN is responsible 
>for. Unfortunately, the discussion has tended to center on ICANN as the 
>only really visible example of an organization attempting to develop 
>policy (which is being treated as synonymous with "governance").

Let speak clearly. The ICANN governance is asimilated by most to a US 
dominance. Why? Because the way it carries its double ICANN job (No one 
forgot atthe GAC the mails where Joe Sims talked of the ICANN rules saying 
"like other US agencies". This was famously summarized by an European 
Member of the GAC as the "AmerICANN joke".

This is to the point that USA faught ICANN (the US rep refused to let the 
ICANN rep. [Anne Rachel Inne] to help her...). This surprised.

ICANN's role is to make sure the root systems works and the IANA parameters 
are managed.
- you expressed clearly here that ICANN thought that not interfering with 
root servers was the best for them to work. May be technically and humanly. 
But this is perceived as a way to protect them from accountability, what in 
turn does not help protecting them and from them.

- the way ICANN protects and propagates an old centralized status quo in 
naming and numbering is perceived as a way to control the network. IPv6.001 
and its unicity is going to be a genuine and important issue.

- the ccTLD handling is perceived (and who would contest that building the 
ccNSO through bylaws instead of an MoU does not go that way) as a way to 
replace RFC 920/1591 ccTLD independance by a contractual control, 
deliberately fighting the WSIS position without any technical groud? No one 
forgot ICANN's claim for axfr on ccTLDs. No one forgot post KPNQuest 
delays. No one forgot Louis Touton's attitude towards small states. You may 
see Paul Twomey's Cathage declarations as good strong support of ICANN. It 
is not. He paid it in Geneva. The bargain was summarized by the head of a 
prepcom II African delegation saying "how much for us to buy the root bluff?".

I do not say that I support all this. I try to make a clear report of the 
reasons why. Please also note that in this I concatenate many points. 
Things are much more complex. There are also a lot of supporters for ICANN, 
but they are usually considered as carrier minded or US afraid people. This 
is very worrying, because this kind of people quickly follow from where the 
wind blows. We need stability.

>ICANN's mandate is very limited and it would be helpful if the broad 
>governance issues mentioned above could find other organizational homes.

You keep saying that. And this is right. But it is NOT the image ICANN 
propagates to the world. If ICANN's real mandate is just that, why is it 
larger than two part time people (for back-up) and a secretary? How many 
hours a day did Jon Postel spend on IANA. What are Regional VP and offices 
for?

The more you say ICANN's mandate is very limited, people think. "then, what 
does he want such a big administration for?"

>ICANN's work could be fitted into a larger framework

Totally true. And it is URGENT to work it out. Again, ITU today is 
perceived by Govs and people as an UN body (and one calls on NY lawyers, or 
ITU lawyers absurdly explain that IDN are multilingual or even vernacular - 
John Klensin should be happy :-). But to fight or compose with something 
one has to know it weel. ITU is NOT an UN body.

ITU is a 136 (one hundred and thirty six) years old body. It is a 
cooperative insurrance by the Governements that e-networking would go on, 
whatever the situation. Technical evolution, war, catastrophy, economical 
and legal changes. bakruptcies, etc.

In that ITU there is NO place to welcome Internet. This is what is urgent 
for us to do. To make the need of the ITU-I accepted. The way to do it is 
http://i-sector.org. Let be clear, the situation has been confused by ICANN 
unilateralism and contract strategy. But we desesperately need ICANN. But 
NOT as a dominance, as a common servant. Somebody is to be the "net 
keeper". We will see the root server system blown in the comming years: who 
is to be the secretariat of the root matrix? ICP-3 ( 
http://icann.org/icp/icp-3.htm ) shows that ICANN can think well - once you 
remove the controversy.

Today ITU is ITU-T. T for telephone. We do not even speak the same 
language. They are as much afraid of us as we do not want them. They are a 
limited set of large operators like WorldCom. Not a bunch of free people 
like IETF. ICANN is an equilbrium that some very large US corporation 
(stakeholders) found together. This is what the world wants to reduce. But 
they have the same equilibrium built in the ITU-T. Just for a longer time. 
Let spell it out ITU-T is them.

Our chance is that ITU-T also means votes and that Europe is 25 and USA 1. 
So it is on this we should play to find a better, Internet oriented 
solution. Not the same however than the ICANN board. This is what the UN 
Secretary is to find. We have two years to have IETF to propose a way to 
organize itself within the ISOC/ITU-I framework, to protect what it wants 
to protect and to better what it wants to better.

This is why we need specialized WGs. Surety and ITU-I lobbying.

>but some people seem to think that if ICANN doesn't do all the things that 
>might fall into "Internet governance" then ICANN should be replaced with, 
>eg, an ITU or UN body.

Idealy that should be the ITU-IANA with three part-time staff. Why not in MdR?

>This is, of course, a controversial matter with sovreignty of states mixed 
>into a variety of political attitudes about the US, the Department of 
>Commerce role with ICANN and so on.

Yes. One must understand that this is nicknamed by some "nsicanntiab" NSI, 
ICANN, NTIA, IAB. It is not that easy for people whose job is people life 
and protection to understand the subtleties of all this.

NSICANNIAB also pays the price for the legend of the Internet building the 
International data network. It is felt that all this is a DoD continuation. 
All these subjective aspects are to be remembered.

NSICANNTIAB has obviously a PR problem. It is very common but if it is not 
addressed it will not solve by itself.

One very simple way would be to propose a technical solution to kill spam. 
This would be credited to IETF and the image would "the ones who killed 
spam" rather than "the US DoD project which wanted to conquer the world".

Another way, IETF/IAB could resume leadership in proposing (eventually) a 
network model everyone could use to support innovation. If there was an IAB 
model the way there is the OSI model, who would - among politicians and 
real decision makers - think IAB/IETF do not fit?

>It should come as no surprise to anyone that I would prefer to see a 
>solution to the broad governance problem that continues to limit the ICANN 
>mandate and creates organizational homes for that which ICANN cannot or 
>should not undertake.

This IS what we have to join forces to fight for. To help udnerstanding the 
way it is to work. The ways it worked before the Internet. The way it works 
with other technologies. The way it should work together with other 
technologies.

There is not a UN General Secretary work force on Telephone or Posts. 
This  really means that the world think ICANN - and to some extent - IETF 
with no spam solution, no clear model, centralized IPv6 numbering scheme is 
an urgent _danger_ for mankind.

>Just as plainly, I don't favor replacing ICANN with a UN-agency.

This is where ICANN is to urgently reorganize the way ERC could have 
permitted it:

- the IANA with an MoU with ITU - so we are the nets keeps stable.
- the GNSO, as the legacy TLD representative within a generaized name space 
concertation (European meaning - like the G8 under rotating Chair) 
toegether with other namespaces : ccTLDs, nomenclatures, ITU-T (T for 
telephone namespace), user networks name spaces, etc.
- the "cybercampus" I advocate where USA or multilateral efforts will 
welcome, support and cross-polenize the "mission creep".

>You may make a search on key words, like "internet governance" at that 
>site www.wsis-online.net and will see all relevant meetings.
>
>Hope this is helpful.

I too.
jfc

---

From: shogunx <[email-masked]>
Date: Tue, 9 Dec 2003 16:26:13 -0500 (EST)

> fish is not by itself sufficient reason to attempt the conversion.
Right, but if the survival of all cats as a whole depended on such
evolution, then there would be quite a few cats trying to grow gills.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 10 Dec 2003 00:51:16 +0900

Vint;

> Unfortunately, the discussion has tended to center on ICANN as the

To be practical, considering that ICANN never acted as the authority
of the Internet governance, what's wrong to make ICANN the scape goat
by giving ICANN governance, which has nothing to do with the Internet
governance, to some of the countries?

							Masataka Ohta

---

From: Simon Leinen <[email-masked]>
Date: Thu, 11 Dec 2003 16:23:08 +0100

> Yep, works fine for me, Stef. Time to switch providers?

Time to disable ECN?

    $ telnet www.isoc.org 80
    Trying 206.131.249.182...
    ^C
    : 130leinen@babar[leinen]; su
    Password: 
    # ndd -set /dev/tcp tcp_ecn_permitted 0
    # telnet www.isoc.org 80
    Trying 206.131.249.182...
    Connected to www.isoc.org.
    Escape character is '^]'.
    ^]

The Linux equivalent to `ndd -set /dev/tcp tcp_ecn_permitted 0' is
`echo 0 > /proc/sys/net/ipv4/tcp_ecn'.

See http://www.icir.org/floyd/ecnProblems.html
-- 
Simon.

---

From: Simon Leinen <[email-masked]>
Date: Thu, 11 Dec 2003 19:11:50 +0100

Stig Venaas writes:
> On Thu, Dec 11, 2003 at 04:23:08PM +0100, Simon Leinen wrote:
>> Ole J Jacobsen writes:

> Well, the real issue is who has a broken TCP implementation, or
> firewall or other device that mishandles those packets. It's a lot
> of work to fix that everywhere, but sites like www.isoc.org should
> be a reasonable place to start.

Yes, of course.  Stef's not at fault here - www.isoc.org should be
fixed to tolerate ECN (or, even better, support it).

Maybe ISOC should start an activity (with themselves :-) about the
benefits of a transparent Internet, and how "intelligent" middleboxes
prevent successful deployment of mechanisms such as ECN (Explicit
Congestion Notification) - which was designed to be simple and
backwards compatible, is well-understood and widely recognized as
beneficial for the Internet as a whole.

(I already submitted www.isoc.org:80 to the "ECN Hall of Shame" under
http://urchin.earth.li/cgi-bin/ecn.pl :-)
-- 
Simon.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Thu, 11 Dec 2003 19:42:07 +0100

Stig Venaas writes:

> firewall or other device that mishandles those packets.

The real issue is whether an ECN bit is reserved, or not reserved.  If
it is reserved, dropping connections that set it is appropriate
behavior; if it is not reserved, then properly processing the bit is
appropriate behavior.  However, the notion that software that considers
the bit reserved should just ignore it and keep on going is very
dangerous.  RFC 3360 takes this attitude, and it's a risky one, no
matter how useful it might be to Linux hobbyists.

It's not appropriate to simply ignore reserved bits on input, because,
if any of them are set, your correspondent is obviously using
functionality that you don't have, and you know the functionality is not
backwards compatible because reserved bits are being set.  Truly
backwards-compatible features will use reserved bits in ways that leaves
them unchanged (i.e., zero) in compatible modes.

So what is the "correct" behavior?  Well, ECN is not
backwards-compatible.  So a system that supports ECN should first
attempt to establish a connection that uses it, with the appropriate
bits set.  If the remote host understands this, the connection will
continue normally.  If the remote host does not understand ECN, then the
proper remote behavior is to DROP THE CONNECTION, at which point the
local host must REESTABLISH the connection, this time WITHOUT ECN, and
with the reserved bits all set to zero.

The principle of "liberal in what you accept, conservative in what you
expect" does indeed apply, but here people are applying it to the wrong
host.  It is prudent to drop connections that set reserved bits, because
you have no idea why those bits are set, or what the other end may
expect in consequence.  It is not prudent to set reserved bits and then
expect every other host to tolerate that; the entire world will not
upgrade at once and you must be able to deal with older implementations.
So the correct behavior is for the ECN-aware host to first attempt a
connection with ECN, then attempt again without it if the remote system
demonstrates that it is unable to support ECN (by resetting the
connection when it sees "reserved" bits mysteriously in use).

That's how compatibility is supposed to work, but apparently someone got
it wrong, and now the wrong parties are being blamed for the mistake.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Thu, 11 Dec 2003 19:51:21 +0100

> fixed to tolerate ECN (or, even better, support it).

No, Stef's system should be modified to establish connections without
ECN if a connection with ECN is immediately reset.

It should be obvious that correcting the local system allows access to
thousands of additional remote systems, whereas change one remote system
allows access only to that one additional remote system.

Expecting all systems to change to accept ECN is like expecting everyone
to jump to IPv6 just because one's local system uses it.

> ... such as ECN (Explicit Congestion Notification) - which
> was designed to be simple and backwards compatible ...

If it were backwards compatible, it would not be setting reserved bits
unconditionally. A backwards-compatible behavior is always 100%
transparent to hosts that do not understand or support that behavior.

Let's try an illustrative example.  Suppose you want some sort of login
that will work with both SSH and Telnet.  The proper way to do this is
to write a client that first attempts to connect with SSH (the
equivalent of setting reserved bits in the ECN example).  If the remote
host refuses the SSH connection, the proper behavior is to then fall
back to Telnet, and establish a Telnet connection.  This is fully
backwards-compatible.  If you build the client to establish only SSH
connections, it is NOT backwards-compatible, because remote hosts that
do not support SSH will be unable to communicate with your local system
at all.

ECN needs to work the same way.  First you try with ECN.  If the remote
host immediately resets the connection, you disable ECN completely and
try again.  You may not have ECN if you then succeed, but at least you
will have a connection.  That's backwards-compatibility.

In summary, the host that needs to be fixed here is the Linux or other
host that insists on ECN and tolerates nothing else.  Unless your system
MUST have ECN supported for all connections for some reason, trying to
force it unconditionally is very unfriendly and incompatible behavior.
Until and unless the entire planet upgrades to support ECN, you're
locking yourself out of a fair percentage of sites.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 11 Dec 2003 16:37:27 +0100

Well, the real issue is who has a broken TCP implementation, or
firewall or other device that mishandles those packets. It's a
lot of work to fix that everywhere, but sites like www.isoc.org
should be a reasonable place to start.

Stig

---

From: [email-masked] (Scott Bradner)
Date: Thu, 11 Dec 2003 14:47:03 -0500 (EST)

> The real issue is whether an ECN bit is reserved, or not reserved. 

it's not "reserved" -- the ECN bits are assigned by RFC 3168

i.e. ECN is a proposed standard and the bits that it uses in the IP header
are fully assigned

Scott

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Thu, 11 Dec 2003 21:02:45 +0100

> it's not "reserved" -- the ECN bits are assigned by RFC 3168

In that case, the only issue is one of backward compatibility.  Some
sites may not be conformant with recent changes to the TCP/IP standards.
The smart TCP/IP implementation allows for this.  Which in turn means
that a host implementing ECN must be prepared to deal with other hosts
that don't--and forcing the ECN bits upon the latter is not the way to
do this.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Thu, 11 Dec 2003 21:06:06 +0100

[email-masked] writes:

> The problem is that the most common failure mode is *not*
> getting an RST back, but getting NOTHING back because
> some squirrely firewall between here and there is silently
> dropping packets with bits it doesn't understand.

Ah ... that would definitely be a bug with the firewall, then.

However, a slight complication is that firewalls normally do not enter
into TCP/IP conversations as proxies for the true correspondents--so is
it really appropriate for a firewall to send a RST on behalf of some
other host?  If the firewall really is a legitimate proxy as well, no
problem, but if it is intended to be fairly transparent, holding
conversations with a distant host in a way that gives the latter the
impression that it is talking to someone else is risky business.

I also don't see why a firewall would drop packets just because reserved
bits are set, although I can see why it might be a configurable option
for the most paranoid users.

---

From: [email-masked]
Date: Thu, 11 Dec 2003 15:08:55 -0500

> i.e. ECN is a proposed standard and the bits that it uses in the IP header

Yes, but if you're a firewall that stepped into a temporal stasis box
before 3168 was published, you're still thinking that the bits are
reserved, and that the Japanese haven't surrendered, and you should
fight on, discarding evil packets that have the reserved bits set....

---

From: [email-masked] (Scott Bradner)
Date: Thu, 11 Dec 2003 15:12:51 -0500 (EST)

> reserved, 

woe be to new applications through such a firewall

Scott

---

From: [email-masked]
Date: Thu, 11 Dec 2003 14:15:31 -0500

> will have a connection.  That's backwards-compatibility.

The problem is that the most common failure mode is *not* getting an RST back,
but getting NOTHING back because some squirrely firewall between here and there
is silently dropping packets with bits it doesn't understand.

So you retransmit your SYN packet, and it gets swallowed by the ether, so you..

And finally you give up because you never saw any reply.

---

From: Franck Martin <[email-masked]>
Date: 12 Dec 2003 08:22:16 +1200

I cannot believe it !!!!!

I raised this thing to ISOC more than a year ago!!! I told them in
person at INET in Washington too...

They haven't done a dam thing since...

If you look on the Internet there is a list of organisations not ECN
compliant, you will find ISOC entry.

How can such a technically useless organisation be the copyright holder
of RFCs?

Cheers

----
Franck Martin
[email-masked]
SOPAC, Fiji

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 11 Dec 2003 13:31:08 -0700 (MST)

> From: [email-masked] (Scott Bradner)
>

Yes, such junk no doubt has worse defects than having been built by
idiots who can't understand the difference between "reseved for now"
and "must be zero forever."

Or perhaps charletans who want their marks to install new versions of 
their malware every few months...or weeks...or days.

Vernon Schryver    [email-masked]

P.S. Don't mind me.  I'm just peeved because some large cable modem
 providers seems to be following the "technical" advice of trade
 rag espurts and filtering all UDP packets above port 1024.  
 Why 1024?--I've no idea that's not an insult to whomever "thinks" it.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Thu, 11 Dec 2003 21:40:55 +0100

> woe be to new applications through such a firewall

It's important to understand that the Internet is not monolithic, and no
matter what the latest and greatest standards may be, there will always
be parts of the Net that run older software.  Expecting the entire Net
to upgrade to this morning's version of TCP/IP stacks in two hours is a
fantasy.

---

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 11 Dec 2003 15:48:44 -0500

> How can such a technically useless organisation be the copyright holder

Check the archives, this gets raised periodically, and ISOC is simply
perenially unable to fix it.  I think I raised some 12-18 months ago,
and there has still gotten no action by ISOC.  I think this falls in
the "so what else is new" catgegory --- the ISOC's I/T staff are
incompetent, "film at 11".

							- Ted

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Thu, 11 Dec 2003 22:10:44 +0100

Theodore Ts'o writes:

> There are a lot of really dumb, dumb, dumb firewall authors out there,
> that's why....

Actually, Sally Floyd's explanation makes a lot more sense.

The dumb authors, I think, are those who built Linux implementations
that doggedly attempt to negotiate ECN and are unprepared for cases
where it does not work, even though it's unreasonable to assume that the
entire world is equipped to handle ECN or that all other hosts will
cheerfully ignore the setting of bits that are supposed to be zero.  In
this context, Linux is beginning to remind me of Netscape in the early
days.

---

From: Einar Stefferud <[email-masked]>
Date: Thu, 11 Dec 2003 13:27:11 -0800

This exchange is rather interesting, since it seems to focus on my 
system, which failed to get a useful connection at one point in time, 
but did get one the next day when I tried it again, without making 
any changes.

So, now it is argued that I need to fix my system.  It has also been 
stated that it Is time for me to change ISP PROVIDER.  I can think of 
lots of reasons to do so, if I could find one that is worth the effort 
and disruption.

I don't really believe other IP providers are all that much better. 
I already pick up and post my mail with another small ISP, that I 
really trust.

So, what is this ECN stuff all about, that I should understand and 
deal with? Quite frankly, I am amazed at how much diagnosis you all 
have done without knowing much of anything about my system, or my 
connection and service provider.

Am I to understand that Verizon is engaged in some kind of dastardly 
business of unhinging the Internet?

It seems that my withdrawal from IETF participation after the Chicago 
meeting (which blessed ICANN -- For Shame!) leaves me at some kind of 
technical disadvantage, though I doubt that continued travel to IETF 
meetings would have been of any value at this point, so I do not plan 
to resume.  So, you can all relax;-)...  I am not coming back, not 
even to San Diego where I could just commute from home.

Now, I sometimes find that my use of an Opera Browser causes some of 
my connections to fail on my MAC OS.9.2.3 OS.  I am looking to update 
to a new OS-10... in the near future, but as I am retired, I am not 
rushing to spend the money;-)...  Certainly not because of this 
flapping discussion...

Cheers...\Stef

---

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 11 Dec 2003 15:47:03 -0500

- Ted

---

From: Tim Chown <[email-masked]>
Date: Thu, 11 Dec 2003 22:33:16 +0000

> incompetent, "film at 11".

It's as equally good as their IPv6 support for www.isoc.org...

---

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 11 Dec 2003 19:55:41 -0500

> this context, Linux is beginning to remind me of Netscape in the early

What Linux implemented was specifically what was specified by RFC
3168, no more no less.  This RFC was in fact designed to deal with
hosts that were not equipped for ECN.  The issue is whether or not
intermediate hosts are justified in dropping packets just because some
bits that were reserved for future use are no longer zero.  I would
argue no.

In fact, while many or most hosts do not support ECN, very few errant
firewalls and/or load balancing boxes were dropping packets that
support ECN.  Firmware updates have been available for over two years
to fix those firewalls are broken, including no doubt the ones used by
ISOC.  It's just that the ISOC firewall admins simply haven't had the
wit to upgrade their firewall firmware.  Pretty much all of the
commercial websites were fixed a long, long, LONG time ago.

						- Ted

---

From: Mark Smith <[email-masked]>
Date: Fri, 12 Dec 2003 12:56:12 +1030

On Thu, 11 Dec 2003 19:55:41 -0500

> bits that were reserved for future use are no longer zero.  I would

In summary, "Be liberal in what you accept, and conservative in what you send." ?

Firewalls could be considered to be performing QA for defined protocol fields. I agree that reserved fields shouldn't be "QA"'ed for their default values. I can't remember exactly where I saw the definition, I've understood reserved fields to mean "could change in the future, don't rely on this default value".

> commercial websites were fixed a long, long, LONG time ago.

This problem doesn't seem to be that uncommon, I can't seem to access one of the fathers of the Internet's home pages with ECN switched on either.

Regards,
Mark.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 12 Dec 2003 06:25:31 +0100

Mark Smith writes:

> Firewalls could be considered to be performing QA for defined
> protocol fields. I agree that reserved fields shouldn't be "QA"'ed for
> their default values.

Except that a change from default values can be an excellent indicator
that you are dealing with a software version different from what you
expected (and possibly incompatible).

> I can't remember exactly where I saw the
> definition, I've understood reserved fields to mean "could change in
> the future, don't rely on this default value".

That's what reserved means, but very often "reserved" is accompanied by
"must be zero."

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 12 Dec 2003 06:23:48 +0100

Theodore Ts'o writes:

> 3168, no more no less.

What FreeBSD implemented actually works.  Which is preferable?

> The issue is whether or not intermediate hosts are
> justified in dropping packets just because some
> bits that were reserved for future use are no longer
> zero.  I would argue no.

I doubt that arguing that it is someone else's fault will fix the
problem.

> support ECN.

But if one of them is in front of this site, you won't be able to get to
it from Linux.

> Firmware updates have been available for over two years
> to fix those firewalls are broken, including no doubt
> the ones used by ISOC.

But since ISOC's firewalls have not been updated, you won't be able to
get to their site from Linux.

> It's just that the ISOC firewall admins simply haven't had the
> wit to upgrade their firewall firmware.

It's just that Linux developers refuse to write code that will allow
communication with sites that don't mean Linux's lofty standards.

> Pretty much all of the commercial websites were fixed
> a long, long, LONG time ago.

Every site I try to access from FreeBSD is accessible, whether it has
been "fixed" or not.

Do you see the problem?  If it's still fuzzy, replace Linux with
Microsoft, and I'm sure that will provoke the usual visceral reaction
and call to arms.

---

From: Franck Martin <[email-masked]>
Date: 12 Dec 2003 18:25:53 +1200

Back to Reality:

The problem is that ISOC firewalls are not up to standards. Can someone
go to knock on ISOC door in Virginia and propose to help them to solve
this particular problem. And take some pictures too, I'm curious to see
what they really have...

This list is full of propeller heads, so there must be one close enough
to do some community work. Or do I have to put a bounty on this problem?

Cheers
----
Franck Martin
[email-masked]
SOPAC, Fiji

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 12 Dec 2003 07:46:01 +0100

Franck Martin writes:

> The problem is that ISOC firewalls are not up to standards.

Whose standards?

---

From: Franck Martin <[email-masked]>
Date: 12 Dec 2003 18:59:50 +1200

The IETF ones...

not supporting ECN

read previous e-mails...

Cheers

----
Franck Martin
[email-masked]
SOPAC, Fiji

---

From: [email-masked]
Date: Thu, 11 Dec 2003 23:03:18 -0800

> get to their site from Linux.

Nonsense.  I'm running Linux, several versions.  I can get to the ISOC
site from all of them.

-- 
Kent Crispin                               "Be good, and you will be
[email-masked],[email-masked]            lonesome."
p: +1 310 823 9358  f: +1 310 823 8649               -- Mark Twain
SIP: [email-masked]

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 12 Dec 2003 08:15:21 +0100

> not supporting ECN

But ECN has not always been a standard.  If all RFCs had been
simultaneously written forty years ago, it would be reasonable to speak
of one organization or another not respecting standards because it did
not adhere to a given RFC.  But in the real world, RFCs have been
written over time, and whether or not an entity is conformant cannot be
determined without a reference to time.  Publishing a new standard does
not automatically make the entire planet non-conformant.

I suspect that ISOC's site is conformant up to a certain point, but not
beyond ... like most sites on the Internet.  The wise developer allows
for the impossibility of instantaneous updates in the development and
implementation of new standards.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 12 Dec 2003 08:15:57 +0100

[email-masked] writes:

> Nonsense.  I'm running Linux, several versions.  I can
> get to the ISOC site from all of them.

Then what is preventing others from doing so?

---

From: Franck Martin <[email-masked]>
Date: 12 Dec 2003 19:18:14 +1200

It all depends if ECN is turned on on linux. Some distro do it by
default, some don't...

----
Franck Martin
[email-masked]
SOPAC, Fiji

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 12 Dec 2003 06:59:35 -0600

> That's what reserved means, but very often "reserved" is accompanied
by

Using the current definition of reserved fields as a proxy for
protocol versioning, especially as an indicator of
upward-compatible/non-upward-compatible, is just about the most
disgusting thing I can imagine.

Too bad it's the only alternative for some protocols, of course.

There was a public service commercial in the United States several
years ago that went something like "it's ten o'clock, do you know
where your children are?"

"It's 2003, do you know how you're going to tell other hosts that your
computer is running a new version of this protocol?"

Spencer

---

From: James M Galvin <[email-masked]>
Date: Fri, 12 Dec 2003 08:01:36 -0500 (EST)

On Fri, 12 Dec 2003, Franck Martin wrote:

    The problem is that ISOC firewalls are not up to standards. Can
    someone go to knock on ISOC door in Virginia and propose to help
    them to solve this particular problem. And take some pictures too,
    I'm curious to see what they really have...

I did, but I didn't take any pictures.

You should know that ISOC's web site is co-located at an ISP, so the
firewall/router is not theirs.  Nonetheless they will see what they can
do.

Jim

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 12 Dec 2003 08:39:42 -0800

vinton g. cerf wrote:
> ...
> Unfortunately, the discussion has tended to center on ICANN as the only
> really visible example of an organization attempting to develop policy
> (which is being treated as synonymous with "governance"

To further your point, an area completely outside of ICANN's purview, yet an
area requiring governance is PKI. We are at the point where deployment of a
PKI has moved beyond technical issues, becoming almost completely the policy
& politics of "trust". Until the politicians broker the trust relationships,
there is nothing technology can do.

Tony

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Dec 2003 11:56:04 -0500

>there is nothing technology can do.

Not everyone agrees that PKIs are all about trust :-). Still, even if 
one establishes PKIs based on who is authoritative for the data in 
certs, as I always suggest, I agree that the major remaining problems 
are business and political, not technical.

Steve

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 12 Dec 2003 09:05:28 -0800

>there is nothing technology can do.

s/politicians/politicians and business community/

Absolutely agree with this sentiment. Anyone who starts an anti-spam 
proposal with "All we need to do is digitally sign the {messages|SMTP 
transmissions}..." is completely unclear on how little governance 
there is in this area.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 12 Dec 2003 10:58:36 -0800

Stephen Kent wrote:
> only
> certs, 

Is there any other way? ;)  

> as I always suggest, I agree that the major remaining problems

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 12 Dec 2003 11:08:13 -0800

> transmissions}..." is completely unclear on how little governance

From a strictly mail technology standpoint, all we should ever do is enforce
signatures. Anything else is simply recreating technology we already have.
From the solution to spam standpoint, I agree the governance of trust plays
a much bigger role and will be the gating item in whatever technical
approach happens.

Tony

FWIW: I specifically left out the business community because they always
find a way to make money in whatever context the politicians create (even if
it takes influencing the politicians to create a favorable context).

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 12 Dec 2003 21:02:38 +0100

> it takes influencing the politicians to create a favorable context).

You should leave out politicians, too, then, since they always find a
way to enhance their personal power in whatever context the business
people or general population create.  And in the realm of
communications, that almost always equates to selective censorship.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 12 Dec 2003 20:52:03 +0100

> transmissions}..." is completely unclear on how little governance 

I agree, but isn't this what Yahoo has recently been talking about as
their magic solution to spam?  (None of the reports I've read has been
very clear on exactly what Yahoo has in mind.)

---

From: Keith Moore <[email-masked]>
Date: Sun, 14 Dec 2003 12:12:59 -0500

> there is nothing technology can do.

since when are politicians trustworthy enough to broker trust 
relationships?

I'd put this a different way.  Until PKIs are able to represent the 
rich diversity of trust relationships that exist in the real world, 
they are mere curiosities with marginal practical value.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 14 Dec 2003 10:16:39 -0800

At 12:12 PM -0500 12/14/03, Keith Moore wrote:
>since when are politicians trustworthy enough to broker trust relationships?
>

Oh, please. Describe a trust relationship that cannot be represented 
using current PKI technology (PKIX certs, S/MIME signed messages, 
OpenPGP certs, OpenPGP signed messages, or SPKI certs). The lack of 
ability to represent the trust relationship is not what is stopping 
the PKIs.

--Paul Hoffman, Director

---

From: Keith Moore <[email-masked]>
Date: Sun, 14 Dec 2003 14:14:56 -0500

> OpenPGP certs, OpenPGP signed messages, or SPKI certs).

I trust my boss to make statements about my job.
I trust my landlord to make statements about the house I rent from him.
I trust my mother and my siblings to make statements about my immediate 
family.
I trust my mother and my siblings to make statements about the 
identities of other family members.
I trust the State of Tennessee to make statements about the identities 
of state agencies.
I trust state agencies to make statements about which they have 
authority: (e.g. automobile licensing) but not to make statements about 
things that are outside of their purview.
I trust the United States government to make statements about the 
identifies of US government agencies.
I trust US government agencies to make statements about which the 
agency has authority: (e.g. aircraft licensing, federal income tax) but 
not to make statements about things which are outside of their purview.
I trust my employer to make assertions about the identities of its 
officers and/or other employees, for the purpose of establishing 
identity for work-related communications, but not for other purposes.

Now if you can show me a tool that will translate statements like the 
above (or other statements that ordinary humans can understand) into 
data structures that existing PKI-based tools will interpret reliably 
and correctly, I'll be extremely impressed.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 14 Dec 2003 11:33:23 -0800

At 2:14 PM -0500 12/14/03, Keith Moore wrote:
>>>I'd put this a different way.  Until PKIs are able to represent 
>>>the rich diversity of trust relationships that exist in the real 
>>>world, they are mere curiosities with marginal practical value.
>>
>>Oh, please. Describe a trust relationship that cannot be 
>>represented using current PKI technology (PKIX certs, S/MIME signed 
>>messages, OpenPGP certs, OpenPGP signed messages, or SPKI certs).
>
>I trust my mother and my siblings to make statements about my 
>immediate family.
>I trust the State of Tennessee to make statements about the 
>identities of state agencies.
>authority: (e.g. automobile licensing) but not to make statements 
>about things that are outside of their purview.
>agency has authority: (e.g. aircraft licensing, federal income tax) 
>but not to make statements about things which are outside of their 
>purview.
>Now if you can show me a tool that will translate statements like 
>the above (or other statements that ordinary humans can understand) 
>into data structures that existing PKI-based tools will interpret 
>reliably and correctly, I'll be extremely impressed.

All of those statements, assertions, and so on can be made in simple 
signed messages. When you get a message with statements about your 
job, you verify that the message has been signed using your boss' 
public key. What's the problem here?

--Paul Hoffman, Director

---

From: [email-masked]
Date: Sun, 14 Dec 2003 14:42:43 -0500

> I trust the State of Tennessee to make statements about the identities 

However, I'll bet a dinner that you most likely do *not* trust your mother and
siblings to make statements about State of Tennessee agencies, nor do you
trust said agencies to make statements about your family (barring direct knowledge
they may have).

> things that are outside of their purview.

Yes, it's that "but not to" that's the real problem to represent.

---

From: Keith Moore <[email-masked]>
Date: Sun, 14 Dec 2003 14:48:24 -0500

> public key. What's the problem here?

Some of the problems occur when I start trusting software to tell me 
whether to believe in the identity, authority, or role claimed by 
someone I don't know personally.  It gets worse if I start trusting 
software to make decisions based on the things that people I don't know 
personally tell me.

---

From: [email-masked]
Date: Sun, 14 Dec 2003 14:52:27 -0500

> public key. What's the problem here?

Please explain how you enforce that the signed part of the message *only*
contains statements about his job, and does not make any claims that he doesn't
trust his boss to make, but does trust his landlord to make?

Note that this isn't a hypothetical.  This message is signed, and it quotes you
quoting Keith.  Or at least it claims to.  Now what does the signature tell you
about the words that Keith is attributed with?  Absolutely nothing - you get to
rely on your judgment of how careful I am with attributing quotes.

At our site, we have multiple people who are authorized to sign purchase orders.
Explain a "simple signed message" format that explains to the vendor that the
digitally signed PO from Mary Smith for desktop computers is OK, because Mary
is authorized to buy those for us, and the PO from Richard James for concrete
for construction project #11934 is OK - but Richard isn't allowed to buy desktop
computers or concrete for other projects.

---

From: Keith Moore <[email-masked]>
Date: Sun, 14 Dec 2003 15:04:38 -0500

> trust said agencies to make statements about your family (barring 

you are of course correct.

>> about

or alternatively, it's a real problem to represent just exactly for 
what purposes someone is trusted.

---

From: Leif Johansson <[email-masked]>
Date: Sun, 14 Dec 2003 23:01:52 +0100

| All of those statements, assertions, and so on can be made in simple
| signed messages. When you get a message with statements about your job,
| you verify that the message has been signed using your boss' public key.
| What's the problem here?
|
| --Paul Hoffman, Director
| --Internet Mail Consortium
|

There are several subtle problems in practice (or at least in my
admittedly limited experience). The major problem is that pki's tend
to have high life-cycle costs mainly due to the lack of widely deployed
management protocols. Compare the cost per user of operating a pki
and a kerberos realm for instance.

This leads deployers to opt out of using the various extensions which
could be used to decide weather a given certificate chain is ok to
use with application X. "We can't afford to re-issue certificates
whenever a new application is introduced...". The large-scale PKIs I
have seen (again - I expect to be refuted on this point) are only used
as identification mechanisms and identification is, as Keith points out
an easy problem compared to the policy decisions which have to be made
*by the client* in order to establish trust for a given application.

	MVH leifj

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 14 Dec 2003 12:04:20 -0800

At 2:48 PM -0500 12/14/03, Keith Moore wrote:
>>All of those statements, assertions, and so on can be made in 
>>simple signed messages. When you get a message with statements 
>>about your job, you verify that the message has been signed using 
>>your boss' public key. What's the problem here?
>
>software to make decisions based on the things that people I don't 
>know personally tell me.

You're talking about a problem with software, not with the standards.

You started this thread with:

At 12:12 PM -0500 12/14/03, Keith Moore wrote:
>Until PKIs are able to represent the rich diversity of trust 
>relationships that exist in the real world, they are mere 
>curiosities with marginal practical value.

PKIs are able to represent the blah blah blah; your software isn't 
yet translating that into something that you want to use.

--Paul Hoffman, Director

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 14 Dec 2003 12:09:37 -0800

>trust his boss to make, but does trust his landlord to make?

As the person trusting something, I don't have to "enforce" anything: 
I look at it and make a trust judgement.

If you are assuming that this trust has to be made automatic, then 
you first need to scope the kind of statements that can be made. You 
then describe that scope in the boss' certificate.

>rely on your judgment of how careful I am with attributing quotes.

Exactly right. I don't trust you to quote Keith or me. So?

>computers or concrete for other projects.

All of that is describable, and many vendors have such products. 
There are no standards (or none that are significantly followed) for 
such assertions. So? Many different PKIs can handle such assertions, 
once you codify them.

--Paul Hoffman, Director

---

From: [email-masked]
Date: Sun, 14 Dec 2003 16:29:57 -0500

> such assertions. So? Many different PKIs can handle such assertions, 

I'm having a very hard time as reading this as anything except "Sure, the
PKI's out there could do it, if we only understood it well enough to come
up with a consistent way that would work for everybody.  And since the PKI
could deal with it if we knew what we wanted it to deal with, it's not a
problem for actual production use of a PKI now".

"Disingenious" would be charitable here....

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 14 Dec 2003 14:01:02 -0800

>problem for actual production use of a PKI now".

Try harder then. Maybe try "The PKI works fine for this, as does the 
signed messages, and we understand what we want, but we can't figure 
out how to trust the other humans in the process." You can't find "a 
consistent way that would would for everybody" if they can't define 
why and how they trust each other.

There are literally billions of dollars that can be saved if someone 
can figure out how to get the human trust part to work. Given that 
the technical end of the PKI world has not changed much in the past 
five years, it's pretty clear that if someone is leaving billions of 
dollars on the table, the problem is pretty difficult and not prone 
to a technical fix.

This has nearly nothing to do with the technical part of the PKI, and 
everything to do with the humans.

--Paul Hoffman, Director

---

From: Leif Johansson <[email-masked]>
Date: Mon, 15 Dec 2003 01:03:38 +0100

|
| You're talking about a problem with software, not with the standards.
|

We believe in running code.

	MVH leifj

---

From: [email-masked]
Date: Sun, 14 Dec 2003 17:22:50 -0500

> they are mere curiosities with marginal practical value. 

That's a true statement whether it's the PKI's fault or not.

The class of buildings known as 'a library' is, without books, a mere curiosity
as well.  It's not the library's fault that nobody is obtaining books to place
on its shelves.

Yes, we can probably make a PKI reflect a trust relationship, if we knew how
to do it.  Doesn't change the fact that until the PKI actually *does* it, it's
a curiosity.

---

From: Franck Martin <[email-masked]>
Date: 15 Dec 2003 10:55:39 +1200

>From a very recent article for the economist: (not sure about the exact
wording) Politicians have shown they are greedy and influenceable as to
see their priorities when it comes to Internet: Intellectual Property
pushed by the powerful music industry lobby against the privacy and
rights of millions of people.

----
Franck Martin
[email-masked]
SOPAC, Fiji

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 15 Dec 2003 08:52:11 +0900

Paul Hoffman;
 
> All of that is describable, and many vendors have such products. There 
> are no standards (or none that are significantly followed) for such 
> assertions. So? Many different PKIs can handle such assertions, once you 
> codify them.

Are you saying we need many different PKIs for all the different
purposes?

Then, I'm afraid they are PK structures, but not an infrastructure.

OTOH, the Internet is an infrastructure useful for many
different purposes.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 15 Dec 2003 09:03:45 +0900

Paul Hoffman;

>> relationships that exist in the real world, they are mere curiosities 
>> with marginal practical value.

> PKIs are able to represent the blah blah blah; your software isn't yet 
> translating that into something that you want to use.

It is not a software issue.

That you can construct a PK structure to represent a set of trust
relationships for some purpose does not mean that there is some
general purpose PKI.

There isn't.

That is, that you must construct a PK structure for every different
purpose is not a software issue but an operational problem too complex
and costly to be solvable.

							Masataka Ohta

PK

Shared key cryptography with KDC, either, does not offer the general
purpose infrastructure, though shared key structures are easier to
maintain.

---

From: Franck Martin <[email-masked]>
Date: 15 Dec 2003 12:47:43 +1200

Hmmm, we talked about some of it...

look in the IETF archives on "Global PKI on DNS?"

Cheers

----
Franck Martin
[email-masked]
SOPAC, Fiji

---

From: [email-masked]
Date: Sun, 14 Dec 2003 21:52:41 -0500

> look in the IETF archives on "Global PKI on DNS?"

Paul, Keith, and myself have bounced a few e-mails in private back and forth,
and unless I'm totally mis-forgetting that thread, what we're discussing is a
totally different problem.  As it turns out, Paul and I are actually in
somewhat of an agreement - we were playing "blind man and an elephant" for a
while, since Paul and I were approaching the same thing from different ends.

Paul is totally correct in that the currently understood methods of doing PKI
are totally sufficient for dealing with a bit string that represents a trust
relationship. All three of us seem to be in agreement that nobody truly
understands how to actually create said bit string for a general case - and
that's not the PKI's fault, because it's ready.  The problem is that the
liveware insists on using very fuzzy definitions of "trust" in the real world,
and we haven't figured out how to express those real world considerations into
a bit string.  Keith had a very nice set of "I trust" statements  a few
messages back, which exhibit the problem quite nicely - for instance, "I trust
state agencies to make statements about which they have authority" parses quite
nicely in English, and has semantics only because we understand 'state
agencies' and 'authority'. Therein lie the booby traps - although I can
understand Keith's statement, computer software that tries to deal with it in
my locality may get tripped up by the fact that technically, I live in a
commonwealth.  And that's just the tip of the semantic iceberg.

(Keith, Paul  - yell if I've misrepresented your positions.. ;)

As Masataka Ohta notes, the result is a lot of small PK structures that are
able to encode a very small, limited subset of trust relationships.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Mon, 15 Dec 2003 05:29:10 +0100

> ability to represent the trust relationship is not what is stopping 

Most widely advocated PKIs require certification authorities, but many
trust models are incompatible with a single party who is trusted by
everyone in the world.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Dec 2003 01:26:58 -0800

> That's a true statement whether it's the PKI's fault or not.

I think Keith has mixed up authentication with authorization.  It is 
true that I will only trust certain people in certain ways.  But whether 
those certain people are who they are, and whether a message from is in 
fact from them, is something we can determine with PKIs.  That having 
been said, they still don't work.

Why?  Because nobody actually has the patience for them, so far as I can 
  tell.  CRLs are not managed at ALL on the Internet, and so far as I 
know, every Tom, Dick, and Jane will ignore PKI warnings.

Eliot

---

From: Leif Johansson <[email-masked]>
Date: Mon, 15 Dec 2003 10:39:23 +0100

|
| I think Keith has mixed up authentication with authorization.  It is
| true that I will only trust certain people in certain ways.  But whether
| those certain people are who they are, and whether a message from is in
| fact from them, is something we can determine with PKIs.  That having
| been said, they still don't work.
|
| Why?  Because nobody actually has the patience for them, so far as I can
|  tell.  CRLs are not managed at ALL on the Internet, and so far as I
| know, every Tom, Dick, and Jane will ignore PKI warnings.

Actually I think it may be said that pki's confuse a with a.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 15 Dec 2003 21:21:52 +0900

Franck Martin;

> Hmmm, we talked about some of it...

Maybe. However there are other reasons why PKI is hopeless.

The other two problems are:

	CAs of PKI, if any, is just as reliable as ISPs. That is,
	if you can just rely on CAs, you can just rely on ISPs that
	your communication is just secure. Otherwise, you must
	assume that your or your peers CA, on which you have no
	control over, is compromised. So, virtual MitM in CAs
	between you and your peer is just as harmful as MitM
	in ISPs between you and your peer.

	PKIs, if any, is no useful for authentication on consumable
	credential. The only merit of PK with CA over shared key with
	KDC is that no communication with CAs is necessary for every
	transaction. However, it means that there is no entity to check
	the amount of remaining credential. So, if an attacker has a
	certificate to be used for 1,000USD of transaction, the attacker
	can use the certificate for 1,000 second 1,000 times a second
	from 1,000 different locations, total damage of which is
	1,000,000,000,000USD for personal benifit of the attacker or for
	economical terrorism to ruin the world wide economy.

In short, CAs are intermediate intelligent entities not knowing
the precise current state of communications (e.g. remaining
credential) that introduction of such CAs is the direct violation
of the end to end principle.

So, PKI is even less hopeful than IPv6.

							Masataka Ohta

---

From: [email-masked]
Date: Mon, 15 Dec 2003 04:37:29 -0800

> Then what is preventing others from doing so?

Apparently nothing.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 15 Dec 2003 21:55:05 +0900

> 	economical terrorism to ruin the world wide economy.

It should be noted that CRLs are, because of obvious operational
issues, expected to be updated weekly or monthly and quite unlikely
hourly, even in which case, CRLs can not prevent the attacks
above mentioned.

							Masataka Ohta

---

From: "Al Arsenault" <[email-masked]>
Date: Mon, 15 Dec 2003 09:35:21 -0500

Having worked in the "PKI" field for a loooonnnnggg time now, there are a
couple of points I'd like to make:

	- any system which relies on one entity to be globally "trusted" by
everybody for everything (or alternatively, one entity to be authoritative
for everything) is doomed to failure.

	- unfortunately, many people when hearing the phrase "public key
infrastructure" thinks that that is what is meant/required, even though most
of us working in the field know that it's not required.

Keith Moore had an outstanding list a number of transactions ago:

The word "trust" seems to be a hot button for a lot of people.  Put it
another way: Keith "trusts" those entities for those purposes because those
entities are AUTHORITATIVE for those purposes.

- The boss is AUTHORITATIVE for your job.  That's the way "employment"
works - within limits, what the boss says you do, applies to you and you do
it.
- The landlord is AUTHORITATIVE for the property you rent.  She owns it.
- Your mother and siblings are AUTHORITATIVE for the family members.
... and so on.

And this is as it should be.  Suppose you have a state agency called the
Motor Vehicle Administration or Department of Motor Vehicles or...  Their
job, by charter is to (a) determine what qualifications should be in order
to operate a motor vehicle on public roads; (b) determine that an individual
applicant meets those requirements and thus is allowed to operate certain
types of motor vehicles on public roads; (c) determine the "safety
standards" for a vehicle to be operated by anyone on public roads.  Now, do
you really want that same agency to issue credentials for, e.g., university
students, or issue you a credit card with a spending limit of X; or...?  Why
should they - it's not their job, and it's not their area of expertise.

Keith's list of "trusts" above is a reflection of the real world, and the
real world is that way for a whole series of good reasons.  It's not
perfect, but it works pretty well.  The problem with "PKI" is that many
people don't want it to reflect/represent the real world; they want it to
reflect some imaginary nirvana where everything is efficient and nothing
ever slips through the cracks because two organizations use different
identifiers. "PKI" is not the way to solve that; it never has been and it
never will be.

As Paul Hoffman notes, from a technical standpoint PKI (with some adjuncts
that enforce privilege management/authorization as well as
identification/authentication) can represent pretty much everything you
want, now.  It can do so using PKIX, using SPKI, or using XKMS, with varying
levels of difficulty/complexity.  The problem is in agreeing on what exactly
it is you want to do, and why you want to do it.

(From personal experience, my belief is that the single biggest failure of
PKI is the over-hyping and under-delivering of the technology.  People were
led to believe that once they had a PKI, their problems were solved.  That's
not the case. I used to hate working with people who had bought a PKI from
somebody, not understanding that all they really needed then were the
applications that let used the PKI/certificate stuff to do business they way
they wanted to do it.  The only thing worse was when I worked for a PKI
company, and had to work with a customer to whom our sales-critters had just
made a sale.  To start a conversation with "Joe didn't tell you you still
need..." wasn't fun.)

				Al Arsenault
				Senior Security Engineer
				BBN Technologies

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Dec 2003 10:03:39 -0500

Keith,

I've authored several papers that capture what I see as the essence 
of your characterizations, in a simple form. The central notion is 
that most of these relationships are NOT about trust, but rather 
about authority. if one views them in this fashion, then  it becomes 
apparent that the entities that are authoritative for identification 
and authorization assertions should be CAs, and we, as individuals 
with many distinct identities, should expect to hold many certs, each 
corresponding to one identity. This is what happens in the physical 
world with most physical credentials: passports, frequent traveller 
cards, etc.

Steve

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Dec 2003 04:14:56 +0900

Al Arsenault;

> Having worked in the "PKI" field for a loooonnnnggg time now,

Where can I find an authoritative reference on what "PKI", by
your definition, means?

> of us working in the field know that it's not required.

That's a fair statement, if you can clarify what, then, are required.

> made a sale.  To start a conversation with "Joe didn't tell you you still

It seems to me that you think PKI not only exists but also
can be purchased.

So, where can I find your definition of "PKI"?

URLs please.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Dec 2003 04:31:49 +0900

Stephen Kent;
 
> I've authored several papers that capture what I see as the essence of 
> your characterizations, in a simple form. The central notion is that 
> most of these relationships are NOT about trust, but rather about 
> authority. if one views them in this fashion, then  it becomes apparent 
> that the entities that are authoritative for identification and 
> authorization assertions should be CAs, and we, as individuals with many 
> distinct identities, should expect to hold many certs, each 
> corresponding to one identity.

The problem for such PKI is that, if we have certs based on
existing trust (e.g. I trust some organization have an authority
to issue passports) relationships, we can exchange shared secret
using the relationships that we don't need any public keys.

> This is what happens in the physical 

Our trust relationships in these cases are so strong that we
can be delivered not only PINs (shared secret) but also physical
credentials.

Then, who need public key cryptography?

Thus, many expect thatm once a PKI is formed, it can create any
trust relationship for anything.

We know a PKI does not.

The next question is, does a, two or millions of PKIs worth having?

I don't think they do.

						Masataka Ohta

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Dec 2003 14:51:28 -0500

At 4:31 +0900 12/16/03, Masataka Ohta wrote:
>>about authority. if one views them in this fashion, then  it 
>>becomes apparent that the entities that are authoritative for 
>>identification and authorization assertions should be CAs, and we, 
>>as individuals with many distinct identities, should expect to hold 
>>many certs, each corresponding to one identity.
>

In principle, yes, but in practice it is preferable to use public 
keys for a variety of security reasons, not to mention the existence 
of a lot of software that can make use of certs and public keys.

>
>>This is what happens in the physical world with most physical 
>>credentials: passports, frequent traveller cards, etc.
>

Yes, but it is cheaper to issue credentials in the form of certs and 
avoid postage and related physical credential costs. Also, PINs are 
meant to be remembered by users and thus are mire vulnerable to 
guessing than key pairs. So we have to put into place attack 
monitoring and response schemes, e.g., locking down an account after 
N bad login attempts, which creates DoS opportunities! So there are 
many reasons to prefer PKI here, although there are downsides too.

>trust relationship for anything.

agreed.

>The next question is, does a, two or millions of PKIs worth having?

I don't know how many we need. But, when I look in my travel bag I 
see about 30+ paper and plastic credentials, all of which could be 
turned into certs under the right circumstances, without creating new 
"trusted" organizations, and with the benefit of greater security and 
less bulk (bits are thin and light weight!).

Steve

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 15 Dec 2003 12:05:50 -0800

> everything to do with the humans.

Hence my original comment that the politicians need to broker the trust
relationships. There will clearly be multiple technical relationships, with
very different characteristics, just as there are for inter-personal trust
relationships outside the technical space. The fundamental point is that the
IETF is not capable of (nor in any position to) further the deployment of
PKI's until the non-technical aspects get resolved. On a global scale that
role has traditionally belonged to the ITU, so that would be a good place to
go as the next step. There are undoubtedly other organizations that need to
be involved on smaller scales, but this is a case where a top-down
consistent framework will probably make the technical job easier down the
road. Any way you want to define it, this is an aspect of Internet
governance, and it clearly doesn't belong to either ICANN or the IETF.

Tony

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Dec 2003 06:08:06 +0900

Stephen Kent;

I'm having a feeling that you call a set of software/hardware
to handle certs a PKI.

> In principle, yes, but in practice it is preferable to use public keys 
> for a variety of security reasons,

In practice, I see no security reason not to use shared key
cryptography. See below about the practice of the cases
you choose (passports, frequent traveller cards, etc.)

> not to mention the existence of a lot 
> of software that can make use of certs and public keys.

I'm afraid you are saying we should have PKI because we have PKI.

> avoid postage and related physical credential costs.

In all (passports and frequent traveller cards) cases, it is
required that applicants physically contact authorities.

In Japan, and maybe in other countries, use of material mail is
inevitable to get passport, because it is the way to confirm the
addresses of applicant.

One can pick up frequent travellor cards, at least paper ones, at
airport.

> Also, PINs are 
> meant to be remembered by users and thus are mire vulnerable to guessing 
> than key pairs. So we have to put into place attack monitoring and 
> response schemes, e.g., locking down an account after N bad login 
> attempts, which creates DoS opportunities! So there are many reasons to 
> prefer PKI here, although there are downsides too.

Here, we are talking about physical credentials optionally accompanied
by PINs. So, long PINs may be securely stored in the physical
credentials (maybe with additional short PINs to activate the physical
credentials, which is also the case for devices storing secret keys of
public key cryptography). DoS is to steal the physical credentials.

> I don't know how many we need. But, when I look in my travel bag I see 
> about 30+ paper and plastic credentials, all of which could be turned 
> into certs under the right circumstances, without creating new "trusted" 
> organizations,

I think we can, at least, agree that we need no "new trusted
organizations" or commercial CAs.

> and with the benefit of greater security and less bulk 
> (bits are thin and light weight!).

That you have paper and plastic credentials means that you don't
need much security.

That you have an IC card containing 30+ secret keys activated with
a short PIN does not mean so much security. How do you think about
an IC card erases all the secret information after N bad PINs, which
creates DoS opportunities?

							Masataka Ohta

---

From: "Al Arsenault" <[email-masked]>
Date: Mon, 15 Dec 2003 16:10:19 -0500

Comments in-line, prefaced by my initials "AWA".

		Al Arsenault

> -----Original Message-----
> From: Masataka Ohta [mailto:[email-masked]]
> Sent: Monday, December 15, 2003 2:15 PM
> To: Al Arsenault
> Cc: Franck Martin; Paul Hoffman / IMC; Keith Moore; [email-masked]
> Subject: Re: PKIs and trust
>
>
> Al Arsenault;
>

AWA:  See, for example
http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-09.txt

From Section 1.2:

	Public Key Infrastructure (PKI) - The set of hardware, software,
       people, policies and procedures needed to create, manage, store,
       distribute, and revoke PKCs based on public-key cryptography.

Note that there's nothing in there about USING the keys/certificates to
accomplish any particular (business or other) task.  In other words, the
applications are external to the PKI.

Section 2 of that draft has some more details.

> It seems to me that you think PKI not only exists but also

AWA:  Hmm - my terminology in my original posting was a bit suboptimal.
*Part* of the PKI can be purchased - namely, the hardware and software.  The
"people, policies, and procedures" bits get tricky - you generally cannot
buy them. (You can often buy "generic" policies and procedures manuals that
have to be tailored to your specific environment/rules, but you can't buy a
canned solution.) Those are also the parts over which many folk who have
tried to implement PKI have stumbled. In the original message, I should have
said "PKI hardware/software" or similar terms, rather than "a PKI".  Mea
culpa.

And, of course, the actual applications/business processes still have to be
provided from somewhere else.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Dec 2003 16:32:29 -0500

>I'm having a feeling that you call a set of software/hardware

no, there is a lot more to a PKI than hardware and software.

>>keys for a variety of security reasons,
>
>>not to mention the existence of a lot of software that can make use 
>>of certs and public keys.
>

why do we use browsers to access many databases where other 
mechanisms might be more appropriate? because we all have "free" 
browsers, users and developers are comfortable with the paradigm, ...

>>Yes, but it is cheaper to issue credentials in the form of certs 
>>and avoid postage and related physical credential costs.
>

True for an initial contact for a passport, not for renewal. When I 
referred to frequent traveller cards I had in mind the 
airline/hotel/car rental frequent traveller programs to which I 
belong, not credentials that get me through security with less 
examination.  (Although my frequent flyer cards DO get me into 
shorter lines in many airports.)

>inevitable to get passport, because it is the way to confirm the

The address of an applicant is not even printed on a US passport. It 
is not part of what the U.S. Department of State attests to when 
issuing a passport.

>One can pick up frequent travellor cards, at least paper ones, at

I can get my form of frequent traveller card via a web interaction, 
with no physical presence!

>
>>Also, PINs are meant to be remembered by users and thus are mire 
>>vulnerable to guessing than key pairs. So we have to put into place 
>>attack monitoring and response schemes, e.g., locking down an 
>>account after N bad login attempts, which creates DoS 
>>opportunities! So there are many reasons to prefer PKI here, 
>>although there are downsides too.
>

I think we are talking about different use models. If I have a 
frequent flyer account with web access, and if someone tries to break 
in by guessing my PIN, the airline will have to shut down the account 
after some small number of tries, to prevent an effective guessing 
attack. This denies ME access, and it imposes costs for the airline, 
because I may have to make a toll free call to someone to cause my 
account to be reactivated.  That is a DoS attack that could be 
avoided if we used crypto keys for auth.

>>turned into certs under the right circumstances, without creating 
>>new "trusted" organizations,
>

agreed!

>
>>and with the benefit of greater security and less bulk (bits are 
>>thin and light weight!).
>

not really. I rarely uses most of those credentials today. They are 
largely replaced by web accesses where knowledge of the account 
number and a PIN provides the authentication that used to be inferred 
by physical possession of the card.

>creates DoS opportunities?

I am not too worried about physical security for a crypto hardware 
token, because I am careful to not lose such tokens, just like I am, 
careful to not lose physical (paper/plastic) cards today. The 
advantage to using crypto for authentication is that the keys are 
longer and more random than PINs, and I don't have to remember all of 
them. The advantage to using public key crypto is that I can employ 
existing PKI features in browsers for authentication AND I don't have 
to worry that sloppy security procedures at the web sites will 
disclose private keys that could be used to impersonate me.

Steve

---

From: Keith Moore <[email-masked]>
Date: Mon, 15 Dec 2003 19:50:17 -0500

> > This has nearly nothing to do with the technical part of the PKI,
> > and everything to do with the humans.
> 
> Hence my original comment that the politicians need to broker the
> trust relationships. 

that's about like saying that Microsoft needs to provide diversity in
the marketplace.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Dec 2003 10:29:03 +0900

Al Arsenault;

> Section 2 of that draft has some more details.

OK. As the meaning of "people" vague, according to section 2,
they are not general public but users of a specific PKI.

The question, then, is, why do you call it "Infrastructure"?

PKI, as defined in the draft, is just a mission specific
structure, not an infrastructure.

> canned solution.)

Then, there can be no PKI standard, I'm afraid, though there can be
PKI software/hardware standard.

And I feel more difficult to call a PKI an infrastructure.

> provided from somewhere else.

In most, if not all, cases, actual applications/business processes
requires realtime communication with CAs that shared key cryptography
is just enough.

For example, if I use PK based certs for my bank account, I can
withdraw cash from my accunt as many times as I want, unless
remaining credential in my bank account is reduced in real time,
which means I must communicate with my bank as CA, which should
better be KDC.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Dec 2003 11:12:37 +0900

Stephen Kent;

> no, there is a lot more to a PKI than hardware and software.

Mmmm, OK.

> why do we use browsers to access many databases where other mechanisms 
> might be more appropriate? because we all have "free" browsers, users 
> and developers are comfortable with the paradigm, ...

No. We use browsers to access many databases, because there are free
search engines available to point to that many databases.

Browsers can be reasonably priced.

> True for an initial contact for a passport, not for renewal.

OK. It's easier in US than JP. But, it is merely that, in US,
initial physical contact is enough to update passport. So,
it is enough to have initial shared secret to update the
secret.

> When I 
> referred to frequent traveller cards I had in mind the airline/hotel/car 
> rental frequent traveller programs to which I belong, not credentials 
> that get me through security with less examination.

You can get physical credentials at airports, hotels or reta
car shops.

> The address of an applicant is not even printed on a US passport.

Neither on mine. But, in Japanese legislation, people are identified
by its name and address that it is leagally important to issue a
passport to an identified person.

> I can get my form of frequent traveller card via a web interaction, with 
> no physical presence!

So, you don't need any PKI for frequent traveller card.

> I think we are talking about different use models. If I have a frequent 
> flyer account with web access, and if someone tries to break in by 
> guessing my PIN, the airline will have to shut down the account after 
> some small number of tries, to prevent an effective guessing attack.

I'm flexible enough that I'm not restricted to any use models.

I just want applicaitons work with proper security.

That you are using PIN means that you are communicating with your
CA that shared key cryptography is a lot more than enough.

> This denies ME access, and it imposes costs for the airline, because I 
> may have to make a toll free call to someone to cause my account to be 
> reactivated.  That is a DoS attack that could be avoided if we used 
> crypto keys for auth.

What's wrong if you use IC card for challenge and response with shared
key cryptography?

> agreed!

An archievement.

>>> and with the benefit of greater security and less bulk (bits are thin 
>>> and light weight!).
>>
>>
> largely replaced by web accesses where knowledge of the account number 
> and a PIN provides the authentication that used to be inferred by 
> physical possession of the card.

Then, what is your problem solved by PKI?

Note that there is no reason that you think CAs more reliable
than ISPs. So, if you just believe CAs, you should just believe
ISPs.

> careful to not lose physical (paper/plastic) cards today.

I'm afraid that we are agreeing that we don't need much security.

> The advantage 
> to using crypto for authentication is that the keys are longer and more 
> random than PINs, and I don't have to remember all of them.

It merely means that IC card can hold long secret, which has
nothing to do with the difference between shared and public
key cryptography.

> The 
> advantage to using public key crypto is that I can employ existing PKI 
> features in browsers for authentication AND I don't have to worry that 
> sloppy security procedures at the web sites will disclose private keys 
> that could be used to impersonate me.

You feel secure merely because you don't think about a possibility
of sloppy security procedures at the web sites and the CAs which
would enable signing false public key, corresponding private key
of which could be used to impersonate you.

CAs are just as (un)trustworthy as ISPs.

Note that use of credit card over web is secure not because of
SSL, but because credit card companies are reducing credentials
of card holders in real time.

						Masataka Ohta

---

From: Neal McBurnett <[email-masked]>
Date: Mon, 15 Dec 2003 20:35:58 -0700

> governance, and it clearly doesn't belong to either ICANN or the IETF.

The rest of us clearly have our disagreements about what the term PKI
is currently used for, and how important public key technology is.

But I run into very very few people who are waiting for, or even
wanting, this sort of world-wide, top-down vision of it, as part of
some government-controlled infrastructure like roads and traditional
telephone systems.

Like most innovative and good things, productive use of public key
technology grows best from the ground up, with private infrastructures
that in time will be based on common forms of shared data.  That again
is where federations come in.  And it requires applications and tools
and policies that work well with lots of keys from lots of sources,
and allow users to control which keys are shown to which relying
parties.

Neal McBurnett                 http://bcn.boulder.co.us/~neal/
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60

---

From: "Al Arsenault" <[email-masked]>
Date: Tue, 16 Dec 2003 08:01:26 -0500

> structure, not an infrastructure.

AWA:

Well, from "The American HeritageR Dictionary of the English Language,
Fourth Edition
Copyright C 2000 by Houghton Mifflin Company.":  in fra struc ture:  (noun)
1. An underlying base or foundation especially for an organization or
system...

So a PKI is an "infrastructure" for an organization or system; namely, the
organization or system that uses it.  There's no requirement that a
particular "infrastructure" support the global internet, or any global
community for that matter.

So I call it an "infrastructure" because it meets the dictionary's
definition of an infrastructure.

> PKI software/hardware standard.

AWA: We agree.  Unless the laws, policies, personnel practices, etc. were
uniform for the entire world, there have to be differences between systems
set up according to, e.g., Hong Kong law vs. systems set up for Canadian law
vs. systems set up for Italian law.  Even within a single political entity,
there are often differences between systems set up for, e.g., Health Care
applications and systems set up for financial applications. Since the PKI
includes the "people, practices and policies", things will differ.  The
hardware and software may also differ, by the way:  some
environments/communities may require specific key generation/storage
parameters be met (e.g., keys are only on certified hardware tokens, vs.
keys in software on any computer system); different user authentication
standards (e.g., PIN vs. biometric vs. SecurID vs...); etc.

Now, that being said: there can be no single standard.  What there can be
(and is) is a framework of standards, which can then be selected/tailored
for the appropriate use.  The US Government and Canadian Government have
sets of different standards for PKI (e.g., "Rudimentary assurance", "basic
assurance", "medium assurance", "high assurance", ...; Class 1, Class 2,
Class 3, Class 4).  VeriSign and others offer different classes of PKI
support to their commercial customers.  You pick what's appropriate, given
your specific application, environment, personnel, physical security, other
requirements, and acceptable cost/benefit tradeoffs.

So, no, there will never be a "single PKI" for the Internet, the universe,
or likely for an entire nation.  Nor should their be, IMNSHO.

> which means I must communicate with my bank as CA, which should

AWA:  Well, Lynn Wheeler would be happy to hear that!  If you're not
familiar with Lynn, he works for First Data Corp. and is one of the prime
pushers behind the ANSI X9.59 standard, also known as "Account Authority
Digital Signatures" or AADS.  Basically, it assumes that for each account
you have (e.g., credit card account), there is an account authority (e.g.,
the credit card processor; like, say, his company) which holds the public
key for you, in your account record.  Whenever you want to execute a
transaction with your card, you digitally sign it.  The merchant sends the
whole transaction to the account authority, which verifies the digital
signature as part of the rest of the processing.  The account authority does
the real-time check of the digital signature, your account balance, purchase
limits, etc. and gives an approval or rejection based on the total picture.

My response to your point is the same as it is to Lynn: that's appropriate
for SOME applications.  If what I'm doing is exchanging S/MIME e-mail, which
has nothing to do with financial transactions, there's no reason to use the
AADS structure or anything else.  All I want to know is that the mail came
from you; not whether it's okay to ship you a new DVD player because the
money has been transferred to me.

Different solutions for different applications. Use what's appropriate. I
think that your comment about "most, if not all, cases,
applications/business processes requires realtime communications with CAs"
is thus incorrect.

				Al Arsenault

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Dec 2003 10:42:16 -0500

> true that I will only trust certain people in certain ways.  But > whether those certain people are who they are, and whether a message > from is in fact from them, is something we can determine with PKIs.  

No it's not, because the CAs aren't trustworthy for all purposes. 

The example I used to give was that I'd never trust the US government's
certificate of Phil Zimmerman's key, because the US government had plenty of reasons to misrepresent Phil Zimmerman.   Similarly I wouldn't
trust VeriSign's certificate to verify the signature on anything that had to do with DNS governance.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 17 Dec 2003 06:02:54 +0900

Al Arsenault;

> 1. An underlying base or foundation especially for an organization or

You should check the usage note section of the dictionary. It
eventually says the organization or system should be society
or, at least, large enough.

> community for that matter.

I didn't say it need to be "global" or world wide.

But, it should be large enough, trust relationships within which
is not single threaded and is complex.

> AWA: We agree.

OK.

> requirements, and acceptable cost/benefit tradeoffs.

The problem of people working for PKI is that they tend to
neglect easier alternatives.

Societies need infrastructures for security, not necessarily
public key ones.

When users have to have real time communication with CAs, which
is almost always the case, it is a lot easier, simpler, more
efficient (and, thus, a lot more secure) to use shared key
cryptography.

Shared key cryptography must also be tailored for each mission.
However, it is so simple that it does not need complex standard.
E.g., because it is real time, we don't need time stamps for certs
nor CRLs. We can just say, "use plain password" or "use challenge
and response", which is more useful than a complete, if ever, set
of some PKI standard.

Note that I know KDCs dedicated to KDC function is just as
useless as CAs dedicated to CA function. But, credit card
company is a KDC to manage user accounts.

> or likely for an entire nation.  Nor should their be, IMNSHO.

How do you think about "secure DNS" as a PKI? DNS may be
claimed to be an application by itself. However, as DNS is
used for many different real applications, I think it is too
generic to be useful.

> limits, etc. and gives an approval or rejection based on the total picture.

I don't know Lynn. But, he might feel unhappy to hear that, when
communication is required in real time, shared key cryptography
works a lot better and we already have the global infrastructure
of banks and credit card companies.

Can I have a mail address of him?

> money has been transferred to me.

I just presented a paper on Dec. 15th that, if an attacker have a
cert with which 1M JPY (100K USD) transaction is allowed, he can
use it 1,000 times a second for 1,000 second from 1,000 different
locations, without causing noticable amount of traffic (if a
transaction consumes 1KB, aggregated traffic is merely 8Mbps for
1,000 second) total damage of which is 100T USD, a lot more than
enough to ruin the world economy. Note, of course, that CRLs are
not expected to be issued so frequently.

And, it is just reported today that, on Dec. 14 in Germany, three
people performed false transactions of net auction for 2 hours,
total damage of which is 130M EURO.

So, it is dangerous to the world economy to have security
infrastructure without real time communication for things
with monetary values.

The problem of the world of capitalism almost everything has
monetary value.

> applications/business processes requires realtime communications with CAs"

If a case involves on-line money, real time communication is
always required. Most, if not all, cases do.

							Masataka Ohta

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Dec 2003 19:28:56 -0500

> liveware insists on using very fuzzy definitions of "trust" in the 

I suspect this is for a good reason - namely, that liveware insists on 
behaving according to very fuzzy definitions of "trustworthiness" in 
the real world, and these definitions are heavily reinforced by social 
and legal expectations that are themselves fuzzy (and they vary from 
one time and place to another).  Sometimes (not always) we have good 
reasons for this fuzziness.

The other problem is that people rarely understand why they choose to 
trust whom they do, to what degree, and for what purposes, at a 
conscious rational level - which makes it very hard for people to 
specify a formal policy for whom to trust in software, or to know 
whether software that implements a trust policy actually reflects their 
own choices.

But this is very much what I meant by PKIs not reflecting real world 
trust relationships.  I'm really not placing blame on those who have 
developed PKI - I'm instead saying that reflecting real world trust 
relationships is a very difficult problem.