Multiple roots E2E PKI trust discovery, chain management capabilities exchange
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- (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 PROTECTED] 819 692 1383 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Multiple roots E2E PKI trust discovery, chain management capabilities exchange
On Fri, Jul 22, 2005 at 07:31:48AM -0400, Francois Menard [EMAIL PROTECTED] wrote a message of 39 lines which said: 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 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 PROTECTED], 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 PROTECTED], 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.] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Multiple roots E2E PKI trust discovery, chain management capabilities exchange
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 PROTECTED] wrote: 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- (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 PROTECTED] 819 692 1383 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Multiple roots E2E PKI trust discovery, chain management capabilities exchange
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 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 PROTECTED], it will arrive in the same malibox, irrespective of my current email provider. See 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? 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 PROTECTED], 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 :-) It would not be the root, it would be the trust chain you build in your resolver... [You can compare with distributed file systems or distributed 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=- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Multiple roots E2E PKI trust discovery, chain management capabilities exchange
On Fri, Jul 22, 2005 at 10:08:03AM -0400, Francois Menard [EMAIL PROTECTED] wrote a message of 42 lines which said: You, not everybody v 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? 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Multiple roots E2E PKI trust discovery, chain management capabilities exchange
At 13:31 22/07/2005, Francois Menard wrote: 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? Dear François, I suggest first you read http://www.icann.org/icp/icp-3.htm. As you may recall the IANA function, name and number space management have been contracted by the USG to ICANN and the USG recently published a position on the root system, etc. You will find some useful links on the political aspects under http://nicso.org/iana.htm. ICANN has an obligation of insurring the stability of the DNS. The Part-5 of ICP-3 gives you fundamental elements. I asked several time that the IETF get involved in the requested test-bed and I just proposed ccTLD and national communities to build on the experience of the dot-root test bed we ran for two years according these rules. Some temporary elements could be found in a study we published on a paying basis (to cover our costs) in French. This study resulted in multiple propositions and efforts. From this I would not advise to consider multiple-root at all. There is only one real root file: the description of the existing TLD forest. But you can have multiple visions of that forest. And ways to build your root file. This actually results in a root-matrix rather than in a file. The way you use and conceive that matrix gives you various possible visions of the internet. Let consider your .travel. If New.net .travel and ICANN .travel are orthogonal we have an absurdity. No one can know who is name.travel. But if New.net and ICANN .travel are two versions of the same reality there is no conflicts. There only can be names which will not resolve or different _desired_ resolutions. There is no objection that air-france.travel resolves to two different sites if this is the decision of air-france. So, there is no fuzzy concept of trust, but a deliberate choice by the user to use a root where .travel is upported by ICANN and one where it is spported by New.net. Like when you visit Paris you can purchase two different Guides. Where trust can be considered it is in the building of the root itself, but not exactly as you conceive it. It is absurd to have ICANN building the root file with delays which may be of months. It would be far better that the root is build from the data published by the TLD Managers: everyone could build his root and _mutually_ correct in case of failure or attack. The problem is the trust you can have in this data as reflecting the decision of the TLD Manager. There is no major problem in having sites published by the TLD Manager where he displays his data: the data must be the same of 2/3 of them for being acceptable. However we need a public declaration procedure to know what are these sites. This can be achieved by a system of Trust as you refer. But a mutual system involving Govs, large gTLDs, etc. ICANN could then lead the system. But its role would not be to accept a delegation,. It would only be to make sure it is the origin of the new list is the same as the one who published it first. Such a system exists today we do not notice, it is the name of countries. Except about the recent conflict about Macedonia it works well. What you could do to is to use another class than IN at least initially. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Multiple roots E2E PKI trust discovery, chain management capabilities exchange
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: Since other people would have a different trust chain, this will be a 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.) I do not say that it is good or bad, just that it is a different 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Multiple roots E2E PKI trust discovery, chain management capabilities exchange
Stephane Bortzmeyer wrote: On Fri, Jul 22, 2005 at 10:08:03AM -0400, Francois Menard [EMAIL PROTECTED] wrote a message of 42 lines which said: You, not everybody v 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? 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Multiple roots E2E PKI trust discovery, chain management capabilities exchange
Brian E Carpenter wrote: Don't forget that the uniqueness property of a domain name is used to guarantee uniqueness 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Multiple roots E2E PKI trust discovery, chain management capabilities exchange
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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Multiple roots E2E PKI trust discovery, chain management capabilities exchange
On Sat, 23 Jul 2005, Masataka Ohta wrote: 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
