Subject: Multiple roots & E2E PKI trust discovery, chain management & capabilities exchange

From: Francois Menard <[email-masked]>
Date: Fri, 22 Jul 2005 07:31:48 -0400 (EDT)

IETF-ers,

What is the latest state-of-the-art thinking at the IETF about a 
distributed multiple-root systems for name discovery based on end-to-end 
peer-to-peer PKI-based trust discovery and trust chain management 
& properties/capabilities exchange (I can sign you, you can sign me, I can 
do 4096 bits but you'll only parse 2048, etc.)

Is it permissible to think that this could be an alternative to the DNS at 
some point in time in the future or does the DNS needs to remain as it is?

I am thinking on figthing on the policy front to force a Tier1C 
implementation of ENUM with a distributed registry based on 
the use of registries at the NPA-NXX-XXXX (Co-code) level in Canada while 
the USA would remain with a flat file per NPA (Tier 1B)

However, there is more generality to my question ... I need a quick 
rundown of the latest thinking (RFCs, ID's, IESG & IAB directives, IRTF 
experiments) regarding:

1) distributed multiple roots
2) E2E P2P PKI-based trust discovery and trust chain management
3) capabilities and properties exchange in an E2E PKI environment.

You can tell me to RTFM with reason since I have been out of touch for the 
last 5 years, and I will not take it personally, but any investment of 
time and energy into providing me some good warnings of "DO NOT GO THERE" 
would be very appreciated.

-=Francois=-
--
[email-masked]
819 692 1383

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 22 Jul 2005 13:49:50 +0200

On Fri, Jul 22, 2005 at 07:31:48AM -0400,
 Francois Menard <[email-masked]> wrote 

> 1) distributed multiple roots

I would certainly be interested in any scientific and technical papers
about this issue. This is a very interesting and challenging problem.

But I think that we can safely say that you canNOT have multiple roots
IF you want to keep the present semantics of the DNS. (For instance,
the current semantics is "If I send an email to
[email-masked], it will arrive in the same malibox,
irrespective of my current email provider". See
http://www.finee.com/travel_tld.htm.)

It is not a limit of the current protocols. It is a limit forced upon
us by the requirments: if you want the above semantics for
[email-masked], you canNOT have multiple roots, because
something (the root) will have to decide who manages
".travel". Otherwise, you will not arrive in Paris for the next IETF
:-)

[You can compare with distributed file systems or distributed
databases: you typically have to give in some requirments.]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 22 Jul 2005 14:08:46 +0200

You have of course read RFC 2826, "IAB Technical Comment on the Unique DNS 
Root"?

Of course, this is specifically about the DNS, and doesn't answer your 
question as it pertains to non-DNS systems....

--On fredag, juli 22, 2005 07:31:48 -0400 Francois Menard 
<[email-masked]> wrote:

> peer-to-peer PKI-based trust discovery and trust chain management &
> properties/capabilities exchange (I can sign you, you can sign me, I can
> Is it permissible to think that this could be an alternative to the DNS
> at some point in time in the future or does the DNS needs to remain as it
> is?
>
> implementation of ENUM with a distributed registry based on the use of
> registries at the NPA-NXX-XXXX (Co-code) level in Canada while the USA
> would remain with a flat file per NPA (Tier 1B)
>
> You can tell me to RTFM with reason since I have been out of touch for
> the last 5 years, and I will not take it personally, but any investment
> of time and energy into providing me some good warnings of "DO NOT GO
> THERE" would be very appreciated.
>
> -=Francois=-
> --
> [email-masked]
> 819 692 1383
>

---

From: Francois Menard <[email-masked]>
Date: Fri, 22 Jul 2005 10:08:03 -0400 (EDT)

> http://www.finee.com/travel_tld.htm.)

Wouldn't you be able to resolve to a primary-ness state for a given TLD 
(domain names is just an example of the name resource you could resolve 
to), through a trust relationship.

I would for example not trust .travel from new.net if ICANN had assumed 
control over .travel ... I should be able to pick this from a PKI-based 
P2P trust chain, would I not?

> ".travel". Otherwise, you will not arrive in Paris for the next IETF

It would not be the root, it would be the trust chain you build in your 
resolver...

> databases: you typically have to give in some requirments.]

I have not seem trust chain management in any type of DFS... but I am not 
a specialist in DFS... though I cannot wait to see the day that Ethernet 
interfaces start to ship for SATA drives...

-=Francois=-

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 22 Jul 2005 16:16:58 +0200

On Fri, Jul 22, 2005 at 10:08:03AM -0400,
 Francois Menard <[email-masked]> wrote 
 a message of 42 lines which said:

  You, not everybody
  v
> P2P trust chain, would I not?

Since other people would have a different trust chain, this will be a
significant move from the current semantics of the DNS. Today,
"airfrance.travel" is the same for me and for you. With your system,
they may be different.

I do not say that it is good or bad, just that it is a different
system than the one users are accustomed to.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 22 Jul 2005 08:44:46 -0700

At 10:08 AM -0400 7/22/05, Francois Menard wrote:
>I would for example not trust .travel from new.net if ICANN had 
>assumed control over .travel ... I should be able to pick this from 
>a PKI-based P2P trust chain, would I not?

Then you have created a new root, namely a combined one that you have 
hand-crafted yourself. It might not sound like a root, but it truly 
is. With a traditional trust anchor, the people trusting it  also 
trust that the anchor will have unique names beneath it. In your 
proposal, you start with a group of trust anchors, and you 
hand-select where there are name conflicts of names beneath two of 
the anchors. In doing so, you elevate yourself to being root, and you 
hide the existence of the trust anchors in your new personal 
hierarchy.

At 4:16 PM +0200 7/22/05, Stephane Bortzmeyer wrote:
>significant move from the current semantics of the DNS.

Exactly right. In the current DNS, there is essentially no one saying 
"Trust Anchor A and Trust Anchor B differ on who are the name servers 
for .travel, so I'm going to pick the ones from Trust Anchor A." 
(FWIW, .travel just appeared in the root zone yesterday.)

>system than the one users are accustomed to.

Well, because it is both quite different than what we have today, and 
it would be really difficult to explain to the vast majority of 
internet users, I would say it would be "bad" to introduce it now. A 
similar model would be fine in other contexts, but not the DNS or the 
IP address space.

--Paul Hoffman, Director
--VPN Consortium

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jul 2005 22:54:36 +0200

> system than the one users are accustomed to.

I say it would be very bad. It would create golden opportunities for
fraud and deception, quite apart from immense confusion of the general
public.

[The fact that two versions of the same name were both cryptographically
connected to their respective roots wouldn't in the least prevent
fraud and confusion - it would rather give a fraudulent site a spurious
appearance of authenticity.]

Also, pity the poor computers. Humans might just be able to navigate
in a world of ambiguous names, but computers can't. Don't forget that
the uniqueness property of a domain name is used to guarantee uniqueness
in other, derived, namespaces, so it isn't only the direct use of DNS
that would be broken by ambiguity. XML namespaces would be broken too,
for example.

I wouldn't change a word in RFC 2826.

    Brian

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 23 Jul 2005 06:45:43 +0900

Brian E Carpenter wrote:

> Don't forget that
> in other, derived, namespaces,

How is it guaranteed? That is, who pays how much if the broken
uniqueness resulted in loss of, say, $1,000,000?

Without proper guarantee, based on the amount of money and risk
of each transaction, PKI (including SDNS) can not be used for
serious security purposes and is merely an overly complex way
for abstract security such as just checking IP addresses
through 3 way handshake.

						Masataka Ohta

PS

PKI has nothing to do with E2E.

As CAs and DNS servers are intermediate systems, neither PKI nor
DNS are E2E.

As intermediate systems, they don't have any information on
ongoing transaction that they can't give any real guarantee.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 23 Jul 2005 01:13:49 +0200

At 22:54 22/07/2005, Brian E Carpenter wrote:
I wouldn't change a word in RFC 2826.

The problem with RFC 2826 is that it links (for information) a unique 
domain name resolution (what we want) with a unique authoritative root file 
(we do not care it is "unique", we want the one we use to be pertinent). 
Confusing the description with the described space was a way to protect the 
name space, but it unfortunately lead to open roots confusion and to 
alt-root suspicion (I only know one: ICANN with .biz) and to the lack of 
preparation in front to PAD (private roots).

Now, I agree with Stephane and ICANN that a lot is/can to be done. We just 
have to remember IMHO the namespace is the same as geographical space: the 
map does not build the geography and no one thinks that geography depends 
on the map he uses.

Except may be politics.

But there may and is to be a lot of innovative thinking. ICP-3 is 
excellent, starting with a good review of RFC 2826, rooting into RFC 920 
which is the true basis of the DNS as we live it, and calling on 
experimentation and proposing avenues for the research and development with 
classes (the way to the externets).

jfc

---

From: Francois Menard <[email-masked]>
Date: Fri, 22 Jul 2005 23:56:44 -0400 (EDT)

> ongoing transaction that they can't give any real guarantee.

Masataka-San, your NOTASIP ID still rings in my mind after all these years 
and I see that your approach at providing consistency to a discussion 
continues to be as thoughtful as it ever has been.

This being said, in my question, I did knowingly imply that PKI as we know 
it from CAs is not end-to-end as CAs are intermediate systems.

In your opinion, what do you see as the latest state of the art thinking 
towards PKI that is true-er to an E2E environment, knowing that I am 
looking for an answer in the context of my need to catch up quick so that 
I can better defend the need for a multiple roots at the NXX level in the 
ENUM environment - my true goal being to tell carriers to screw it with 
Carrier-ENUM.  My argument is that you cannot subdomain a telephone number 
which can remain reachable from a telephone keypad, thus the need for 
competition at the registry level (if not, innovation will be restricted 
by the transaction costs of registering entries in Tier1B).

I have described my proposed Tier1C here in details: 
http://www.crtc.gc.ca/cisc/COMMITTE/C-docs/CNCO0004.doc

If pursuing this discussion gets too wild on IETF-discuss, I will agree to 
defer the ongoing discussion to the E2E-interest mailing list on 
postel.org and refer back once I have a better idea how stable is the 
ground.  However, true here is my ambition to frame the discussion in such 
a way that I can know how to tackle my Tier1C proposed framework into the 
broader perspective of where the IETF has been, where it can go and where 
it does not or no longer wants to go (at least in the short term).

-=Francois=-
819 692 1383