Re: IAB statement on the RPKI.
Noel Chiappa wrote: > >> What DNSsec will provide is ... data origin authentication and data > >> integrity protection. > ??? There is clearly something here I don't understand. No, you don't. > How does the UDP checksum plus a cookie (nonce) protect against > a MITM attack, > on the path from the server back to the querying entity? As DNSSEC is not protected from MitM attacks on zones on the path between client and server zones, how can you expect plain old DNS is better protected? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
> From: Masataka Ohta >> What DNSsec will provide is ... data origin authentication and data >> integrity protection. > That is already offered with plain old DNS with UDP checksum, cookie > and return routability, though UDP checksum is optional and cookie of > message ID is a little bit too short. ??? There is clearly something here I don't understand. How does the UDP checksum plus a cookie (nonce) protect against a MITM attack, on the path from the server back to the querying entity? Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Masataka Ohta wrote: > > Martin Rex wrote: > > > DNSsec, as far as I can see, does not use a PKI in the traditional > > sense. There are _NO_ persons involved in the process, > > FYI, zones are operated by people. That is missing the point. >From what I've seen, the whole architecture of DNSsec is based on assertions of keys being authorized to sign keys being authorized to sign RRs. The blobs of data that are being used in the signatures look very similar to "RSASSA-PKCS1-V1_5-SIGN" (PKCS#1 v1.5 signature scheme) to me. If you look at rfc-2437 (PKCS#1 v2.0) http://tools.ietf.org/html/rfc2437 it does _NOT_ use the term "digital signature" anywhere throughout that document, simply because there are no digital signature described in that specification. "digital signature" is a term that has been picked up and used by legislators to describe things that are equivalents to real/natural signatures that represent legal entities, and where they attach legal liabilities and contractual obligations. The things used in DNSsec are just "signatures", they are definitely _NOT_ "digital signatures" in any legal sense. And btw. the reason why dnssec-gost needs to be a MAY, and why the IETF _standards_ ought to require all DNSsec-signed zones to include signatures with a mandatory to implement algorithm is described in BCP-61, Section 6 as "the Danvers Doctrine": http://www.rfc-editor.org/bcp/bcp61.txt http://tools.ietf.org/html/rfc3365#section-6 -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Martin Rex wrote: > What DNSsec will provide is what is described in rfc-4033 section 3.1 > data origin authentication and data integrity protection. That is already offered with plain old DNS with UDP checksum, cookie and return routability, though UDP checksum is optional and cookie of message ID is a little bit too short. > In order to obtain any level of "trust", you would not only have > to configure the keys for specific zones that you trust, > but also create an out-of-band trust relationship > (person-to-person, audit) of the registry administrating the > relevant DNS-zones you want to trust, their equiment and > adminstrative procedures, > > *PLUS* > > you will need to create an out-of-band trust relationship to > the adminstrator(s) who operate(s) the server(s)/service(s) > for which you want to resolve the names through DNSsec and > their network admins and the operational procedures that they use. > > That might be a time-consuming, expensive and error-prone effort > that by itself get outdated, and it scales nowhere considering > the size of the DNS. Right. So, DNSSEC is no better than plain old DNS. > I have set up my DSL router to register the IP assigned by the ISP > with dyndns.org (builtin feature of the DSL-router). But whenever > the connection is dropped, that DNS entry with dyndns.org is > inaccurate until my router re-connects and updates it with the new IP. It partially is a problem of unnecessarilly long TTL, which means poor administration of related zones. That is, DNS is not fully responsible for the problem. However, it is almost certain that the zones will have poor administration and, thus, poor security even if DNSSEC were deployed. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Masataka Ohta wrote:
>
> Ignore DNSSEC.
>
> Technically, it is poorly designed unnecessarily causing a lot of
> technical problems such as large message sizes.
>
> But, the most serious defect of DNSSEC, or PKI in general, is that,
> despite a lot of hypes, it is not cryptographically secure.
> Social attacks on trusted third parties makes the parties
> untrustworthy, which means PKI is merely socially or weakly
> secure.
DNS has always contained highly dynamic, quickly or already outdated
and non-negligable amounts of incorrect information.
But the inaccuracies used to be primarily of the out-dated and
accidentally wrong kind, not of the maliciously inaccurate ("fake")
kind.
When DNSsec is used, the data in DNS will continue to be loosely
inaccurate or outdated. But inserting maliciously inaccurate ("fake")
data will hopefully become more difficult.
Personally, I firmly believe that any assumption that data in the DNS
could be trusted, is fatally flawed. And that any security architecture
that relies on DNS data being accurate, is fatally broken.
What DNSsec will provide is what is described in rfc-4033 section 3.1
data origin authentication and data integrity protection.
You can get some level of assurance that the successful result from
DNSsec name resolution will provide you an answer from the
entity that has been authorized to administrate a particular zone
and that this data was not modified in transit (network communication)
or at rest (on the nameserver or in caches).
One should *NOT* make any assumptions about the accuracy of that
information in any kind or form. The information could be
outdated, it could be inaccurate and it could have been
created by subverting the administrative procedures of
the registry -- or e.g. by hacking the database which sources
the nameserver's DNSsec zones.
In order to obtain any level of "trust", you would not only have
to configure the keys for specific zones that you trust,
but also create an out-of-band trust relationship
(person-to-person, audit) of the registry administrating the
relevant DNS-zones you want to trust, their equiment and
adminstrative procedures,
*PLUS*
you will need to create an out-of-band trust relationship to
the adminstrator(s) who operate(s) the server(s)/service(s)
for which you want to resolve the names through DNSsec and
their network admins and the operational procedures that they use.
That might be a time-consuming, expensive and error-prone effort
that by itself get outdated, and it scales nowhere considering
the size of the DNS.
At home I'm using ADSL (~3500/500 KBps), get an IP-Address
dynamically assigned by my ISP whenever my DSL-router reconnects.
I'm using it with a flatrate and VoiP, so it's online 24h, but
the connection is dropped at least once per day -- and I *ALWAYS*
get a new IP assigned on re-connect!
I have set up my DSL router to register the IP assigned by the ISP
with dyndns.org (builtin feature of the DSL-router). But whenever
the connection is dropped, that DNS entry with dyndns.org is
inaccurate until my router re-connects and updates it with the new IP.
Anyone who thinks that information in the DNS could be trusted
is either using a funny definition of trust or has no clue how
DNS is actually used and what kind of data it contains (and
how that data is created and maintained).
There are a few things currently being done that will potentially
no longer work when DNSsec is used. Currently, some countries seem
to ask ISP for blackholing or "redirecting" (=faking) DNS-requests for
particular sites. Blackholing in the form of NXDOMAIN may not longer
work, Blackholing by dropping the request may result in clients
walking the list of authoritative Nameservers instead of contining
to pull the ISPs nameserver, and faking will also no longer work
as soon as the relevant zone has DNSsec enabled and the ISP has
no adminstrative control over that zone (the most common case).
Not having read all of the relevant RFCs, I don't know what the
situation will be for companies running with their own DNS universe,
private IPv4 address spaces (10.x.x.x, 192.168.x.x) and potentially
non-official TLD (company.corp). It probably depends whether
and how these companies have made real-world DNS information
available on their internal networks.
DHCP and DNS dynamic update also appears to create interesting
challenges for the use of DNSsec for involved DNS zones.
-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
Phillip Hallam-Baker wrote: > The point is that the particular obsession with 'end to end' solutions > means that we loose the ability to deploy architectures that provide > greater protection against the attacks that actually matter. FYI, there is no point to insist on 'end to end' here, because DNS, including plain old one not necessarilly DNSSEC, is not end to end. DNS servers are intermediate intelligent entities betweeen peers, though the servers are operated zone administrators between peers, which are, in general, not ISPs between peers. The lack of end to end property makes DNS, including DNSSEC, vulnerable to MitM attacks at intermediate zones. Though DNS resolvers can be, to avoid cache poisoning, implemented end to end between client hosts and DNS servers without intermediate resolvers, it's end to end merely between the client hosts and the DNS servers and not between the clients and application servers of the clients. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
If people want to prevent their TCP/IP enabled lightswitches from viewing porn as well as stopping them from accessing malware sites, then I guess they could use this mechanism. I do not consider stopping my computer from accessing malware or crimeware sites to be 'censorship'. Censorship is what people do to other people. I have never heard of a anti-porn crusader who says that they need to be protected from porn, they always worry about what it would do to other people. The fact that the DNS can be used as a censorship point only reinforces the need for the endpoint to be more careful in their choice of resolution service. The current DNS model was conceived when a VAX 11/780 only just fit in a standard elevator and cell phones were considered futuristic spy gadgets. Had the need for endpoints to move about been considered I don't think the default of taking DNS resolution service from your local network provider would have been acceptable. For a whole host of reasons it is a really bad idea for ICANN or any other single point authority to be in the business of filtering domain name issue. Since it is also a bad idea to route packets to names controlled by the Russian Business Network it follows that most end points should not be using the authoritative DNS name space. Given that the vast majority of medium to large sized businesses seem to already have some form of restriction on Internet access, I don't see that trying to enforce this by making the DNSSEC protocol issue failure reports is going to change anything. If the technical measures were effective then the businesses would simply turn off DNSSEC. But it is rather more likely that they won't work at all because nobody has yet worked out what a Web browser should do if it is told that the site exists but the resolution of the DNS request is blocked. Perhaps they could send a request for the missing packets by carrier pigeon. On Thu, Feb 18, 2010 at 8:59 PM, Paul Wouters wrote: > On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote: > >> The key point is choice. Just as some people CHOOSE to install >> products such as Norton Anti-Virus that stop certain applications >> running on their machine, the typical Internet user should probably >> CHOOSE to use a DNS service that has the known crimeware sites >> eliminated. > > Should they also CHOOSE for a porn filter. And a filter on politically > sensitive words? Where does our job end to let the user CHOOSE their > censorship? And again, you make it sound like DNSSEC is taking away that > choice, which is clearly not the case. > >> The point is that the particular obsession with 'end to end' solutions >> means that we loose the ability to deploy architectures that provide >> greater protection against the attacks that actually matter. > > It prevents hacking the protocol (for good AND for evil). And that is > a good thing. > >> DNS hijacking is a very rare type of attack. > > No it is not. It depends on your environment. I'll grant you that its > more likely you'll end up on a phising side then caught in a DNS spoof, > but that does not validate your opinion of not rolling out stronger > security just so people can play games with protocols. > > And as Mark showed, there are legitimate ways of piggypacking filtering > services with DNS using EDNS options. > >> Securing the mapping of >> DNS names to IP addresses will not provide a major reduction in >> expected losses due to attacks. > > It will greatly improve security by providing a hierarchical distributed > signed database. You will see many new applications leveling this new > option. > >> We already have domain validated SSL >> certificates that meet that need quite adequately. > > You haven't been around in the last year? When we had SSL attack after SSL > attack? A 2 second email verification for a "valid for the entire world" > certificate is not what I would call "quite adequately". > >> The value in DNSSEC lies in being able to establish a coherent network >> based system of security policy distribution. > > Sorry, I am not sure what this means. But if it is another application of > distributed signed data, then yes, it is another case for the adoption of > DNSSEC, not for critisism that it would block some filtering technique, > which it doesn't) > > Paul > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
more ad hominem and irrelevant comparisons. The key point is choice. Just as some people CHOOSE to install products such as Norton Anti-Virus that stop certain applications running on their machine, the typical Internet user should probably CHOOSE to use a DNS service that has the known crimeware sites eliminated. The point is that the particular obsession with 'end to end' solutions means that we loose the ability to deploy architectures that provide greater protection against the attacks that actually matter. DNS hijacking is a very rare type of attack. Securing the mapping of DNS names to IP addresses will not provide a major reduction in expected losses due to attacks. We already have domain validated SSL certificates that meet that need quite adequately. The value in DNSSEC lies in being able to establish a coherent network based system of security policy distribution. On Thu, Feb 18, 2010 at 7:41 PM, Paul Wouters wrote: > On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote: > >> The point is not to protect the DNS. The point is to protect the >> people. And that means that maybe you don't want your machine to >> resolve every domain name. > > That sounds very much like the tapping/crypto debate. "You may not > secure your communications because we're using its weaknesses for your > protection". > > Not securing DNS because some people are using it for something completely > different, namely a filtering service, is not an acceptable solution. > > But besides that, services like opendns can still fetch and validate DNS, > and then continue strip it and rewrite it for those endusers that prefer > such a service. DNSSEC does not change that at all. > > Paul > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
The point is not to protect the DNS. The point is to protect the people. And that means that maybe you don't want your machine to resolve every domain name. The typical attack these days is to direct a user to a malware site. This is usually spam but can easily be a malicious redirect or inline on a hacked Web site. Once the user is on the malware site they are either asked to install the malware or the site does a driveby download on them. Other sites we would like to avoid visiting are identified phishing sites. Sending the malware through email pretty much fails these days as very few email services will deliver executable attachments. Thus the need for the malware site approach. On Thu, Feb 18, 2010 at 6:53 PM, Paul Wouters wrote: > On Wed, 17 Feb 2010, Phillip Hallam-Baker wrote: > >> One of the big fallacies of DNSSEC is the idea that providing clients >> access to the unfiltered authoritative DNS source is the same as >> securing the DNS. That was the case when DNSSEC was designed, today >> most endpoints would prefer to opt to connect to some sort of filtered >> DNS with malware and crimeware sites removed. > > "most"? That's quite the claim. If so, then opendns and friends would be > much busier rewriting our DNS packets. > >> The biggest DNS security vulnerability is in the information that is >> input to the DNS publication service. Most hijacking schemes have been >> due to attacks on registrars. > > I thought the most used hijacking schemes used dancing hamsters or nude > Britney > Spears promises to install a new version of SYSTEM32\etc\hosts. In fact, it > was > so bad that Microsoft even hardcoded their own update servers IP's in their > own DLL's. > > I have only heard of 2 or 3 attacks via registrar accounts. I've heard of > many > more compromised caches and hosts files. > > But I look forward to your substantiation that "most" of us prefer our DNS > to > be rewritten for security and saving us from typos by redirecting us to > advertisement servers (malicious or not) > > Paul > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
"useful security is binary". thats great stuff. says nothing - means even less. theres another great term I've seen the Isociety cabal use whenever their stuck - "it does not scale". There are better solutions to the DNS security escapades that are simple and involve no economic cost to the users at large. DNSSEC is not the answer. DNSSEC is the nightmare. The solution lies with DNScurve - http://bit.ly/cjmH2n The Internet already is a security nightmare - why contribute to it with DNSSEC. Fix the UDP problem once and for all with DNSCurve. Or something like it. DNSSEC is old technology 1024 is a juvenile encryption standard. DNSSEC does not solve the UDP problem. DNSCurve will. And I remind IETF members that Dr. Bernstein was the first to address the UDP port problem. DNScurve will take the DNS to the next step. Ensure the machine you contacted is the machine you want to speak too. At least members do something. Because the DNSSEC joke must end. We need solutions to address the problem that don't end up being a make work project. cheers joe baptista On Thu, Feb 18, 2010 at 3:08 PM, Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > David Conrad wrote: > > > I'm not sure why you are pretending that useful security is binary. > > I'm afraid you are saying "DNSSEC or die", while I'm saying > "reasonable security is good enough". Which, do you think, > is binary? > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote: The key point is choice. Just as some people CHOOSE to install products such as Norton Anti-Virus that stop certain applications running on their machine, the typical Internet user should probably CHOOSE to use a DNS service that has the known crimeware sites eliminated. Should they also CHOOSE for a porn filter. And a filter on politically sensitive words? Where does our job end to let the user CHOOSE their censorship? And again, you make it sound like DNSSEC is taking away that choice, which is clearly not the case. The point is that the particular obsession with 'end to end' solutions means that we loose the ability to deploy architectures that provide greater protection against the attacks that actually matter. It prevents hacking the protocol (for good AND for evil). And that is a good thing. DNS hijacking is a very rare type of attack. No it is not. It depends on your environment. I'll grant you that its more likely you'll end up on a phising side then caught in a DNS spoof, but that does not validate your opinion of not rolling out stronger security just so people can play games with protocols. And as Mark showed, there are legitimate ways of piggypacking filtering services with DNS using EDNS options. Securing the mapping of DNS names to IP addresses will not provide a major reduction in expected losses due to attacks. It will greatly improve security by providing a hierarchical distributed signed database. You will see many new applications leveling this new option. We already have domain validated SSL certificates that meet that need quite adequately. You haven't been around in the last year? When we had SSL attack after SSL attack? A 2 second email verification for a "valid for the entire world" certificate is not what I would call "quite adequately". The value in DNSSEC lies in being able to establish a coherent network based system of security policy distribution. Sorry, I am not sure what this means. But if it is another application of distributed signed data, then yes, it is another case for the adoption of DNSSEC, not for critisism that it would block some filtering technique, which it doesn't) Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
In message , Paul Wouters writes: > On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote: > > > The point is not to protect the DNS. The point is to protect the > > people. And that means that maybe you don't want your machine to > > resolve every domain name. > > That sounds very much like the tapping/crypto debate. "You may not > secure your communications because we're using its weaknesses for your > protection". > > Not securing DNS because some people are using it for something completely > different, namely a filtering service, is not an acceptable solution. > > But besides that, services like opendns can still fetch and validate DNS, > and then continue strip it and rewrite it for those endusers that prefer > such a service. DNSSEC does not change that at all. DNSSEC can even be used to secure reputation data to allow different applications on the same box to make different decisions about whether or not to trust the data returned from the DNS even if it is signed using DNSSEC or not. One could also use EDNS options to tell the recursive resolver whether to filter or not a particular query or to pass back a recommendations to filter the response. The data itself would still be signed and verifiable. The recommendation itself can be secured with TSIG/SIG(0). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote: The point is not to protect the DNS. The point is to protect the people. And that means that maybe you don't want your machine to resolve every domain name. That sounds very much like the tapping/crypto debate. "You may not secure your communications because we're using its weaknesses for your protection". Not securing DNS because some people are using it for something completely different, namely a filtering service, is not an acceptable solution. But besides that, services like opendns can still fetch and validate DNS, and then continue strip it and rewrite it for those endusers that prefer such a service. DNSSEC does not change that at all. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
On Wed, 17 Feb 2010, Phillip Hallam-Baker wrote: One of the big fallacies of DNSSEC is the idea that providing clients access to the unfiltered authoritative DNS source is the same as securing the DNS. That was the case when DNSSEC was designed, today most endpoints would prefer to opt to connect to some sort of filtered DNS with malware and crimeware sites removed. "most"? That's quite the claim. If so, then opendns and friends would be much busier rewriting our DNS packets. The biggest DNS security vulnerability is in the information that is input to the DNS publication service. Most hijacking schemes have been due to attacks on registrars. I thought the most used hijacking schemes used dancing hamsters or nude Britney Spears promises to install a new version of SYSTEM32\etc\hosts. In fact, it was so bad that Microsoft even hardcoded their own update servers IP's in their own DLL's. I have only heard of 2 or 3 attacks via registrar accounts. I've heard of many more compromised caches and hosts files. But I look forward to your substantiation that "most" of us prefer our DNS to be rewritten for security and saving us from typos by redirecting us to advertisement servers (malicious or not) Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
Recursive to stub is the piece where you need to have Apple and Microsoft provide platform integration. And they have the longest lead times. So that is the piece that you need to prioritize. If we move to a mode where most people have transitioned from ISP provided recursive DNS to some form of managed recursive DNS service, the managers of those services may employ other strategies to provide a significant improvement in DNS security even without DNSSEC adoption. One of the big fallacies of DNSSEC is the idea that providing clients access to the unfiltered authoritative DNS source is the same as securing the DNS. That was the case when DNSSEC was designed, today most endpoints would prefer to opt to connect to some sort of filtered DNS with malware and crimeware sites removed. The biggest DNS security vulnerability is in the information that is input to the DNS publication service. Most hijacking schemes have been due to attacks on registrars. On Wed, Feb 17, 2010 at 1:48 PM, Tony Finch wrote: > On Wed, 17 Feb 2010, Phillip Hallam-Baker wrote: > >> One mechanism that was unfortunately pushed asside as a result of the >> fixation on end to end DNSSEC would be to for the resolver to use >> DNSSEC (and other methods) to authenticate the data it receives and to >> use some modification of TSIG to authenticate the communication >> between client and resolver. > > I don't think that has been pushed aside. There's not much interest in it > at the moment because the focus is on authoritative-to-recursive DNSSEC. > Maybe attention will turn to recursive-to-stub security once there is more > assurance that the recursive server's answers are authentic. > >> It would not take a great deal of effort to graft a Kerberos like scheme >> on to effect key exchange. > > Or use SIG(0). > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. > MODERATE OR GOOD. > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
David Conrad wrote: >>OK. You are saying that any network with intermediate intelligence >>to modify DNS responses is not a part of the Internet. > No. I'm afraid you have lost your point. > Attempting to redefine the world to meet your odd definitions > doesn't seem to be a particularly useful exercise. So? > I'm not sure why you are pretending that useful security is binary. I'm afraid you are saying "DNSSEC or die", while I'm saying "reasonable security is good enough". Which, do you think, is binary? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
On Feb 18, 2010, at 11:40 AM, Masataka Ohta wrote: > OK. You are saying that any network with intermediate intelligence > to modify DNS responses is not a part of the Internet. No. > That is, we agree that ISPs in your first statement are not really ISPs. Attempting to redefine the world to meet your odd definitions doesn't seem to be a particularly useful exercise. >> there have been MITM attacks against the telephony system. > > There will be MITM attacks (by a man who operate a CA in the middle > of a CA chain) against DNSSEC. So? I'm not sure why you are pretending that useful security is binary. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
David Conrad wrote: > You are aware, of course, that some ISPs are actively engaging > in DNS response modification, right? > Ignoring for a second that the Internet isn't the telephony system > (intelligence in the network is in different places), OK. You are saying that any network with intermediate intelligence to modify DNS responses is not a part of the Internet. I agree with you. That is, we agree that ISPs in your first statement are not really ISPs. Note that it does not affect resemrance of weak security models of the Internet and the telephone network. > there have been MITM attacks against the telephony system. There will be MITM attacks (by a man who operate a CA in the middle of a CA chain) against DNSSEC. So? > Cache poisoning is ALSO a result of the fact that the path > between source and destination is not protected. OK. As cache poisoning can occur with poorly implemented DNSSEC (e.g. with implementations which imprecisely check signatures) that you should conclude that DNSSEC dose not protect the path between source and destination. DNSSEC does not give any protection to the CA path between source and destination, anyway. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
On Feb 18, 2010, at 12:10 AM, Masataka Ohta wrote: > For you, your ISP is, representing the Internet, responsible for the proper > delivery. Your point? You are aware, of course, that some ISPs are actively engaging in DNS response modification, right? > To your surprise, reasonable security by network operators is > not so new. Highly commercial telcos have been offering it for > about 100 years. Ignoring for a second that the Internet isn't the telephony system (intelligence in the network is in different places), there have been MITM attacks against the telephony system. > Cache poisoning is a problem of poor implementations to handle > additional information including glue. No. Cache poisoning is ALSO a result of the fact that the path between source and destination is not protected. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Basil Dolmatov wrote: >>Your and my ISPs are loosely connected by a chain of social trust >>relationships between adjacent ISPs, which is why we can exchange >>packets over the Internet >> > Yes. >>with reasonable security. > No. Without any security at all. > No garanties of delivery, no origin validation, no path validation, etc. H, you seemingly do not know anything about reasonable security over the current Internet such as "return routability", on which many protocols depend. > "social trust relationship" can arrange packet delivery but cannot arrange > any > responsibility for proper delivery. BGP is the mechanism for ISPs to exchange information on which ISPs are responsible for proper delivery of packets destined to which address ranges. For you, your ISP is, representing the Internet, responsible for the proper delivery. > I as have said before the picture you are drawing reflects > Internet 20 years ago, when all participants cooperated and > worked on the benefit of the network. To your surprise, reasonable security by network operators is not so new. Highly commercial telcos have been offering it for about 100 years. That is, if you dial my phone number, you can reasonably expect to reach my phone. > With no security at all. Otherwise we would have never heard about "cache > poisoning". Cache poisoning is a problem of poor implementations to handle additional information including glue. > P.S. Just to mention: I liked Internet 20 years ago much more and a bit > nostalgic about it. See above for more than 100 years of history. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Martin Rex wrote: DNSsec, as far as I can see, does not use a PKI in the traditional sense. There are _NO_ persons involved in the process, I can see some... ;) Any operation which is placed out-of-band of DNSSec requires some trusted manual intervention. Just for example: First person - zone administrator who manually creates KSK pair and, private part of it in secure place and ensure that no unauthorized use of it is probalbe. Second person - the administrator of upper zone, who receives DS record from lower zone, manually ensures that it came from authorized source and decides to place it in the zone file. Lot of persons (all resolvers administrators) - who should manually change the root zone KSK, when rollover occurs, manually ensuring beforehand that new KSK has came from authorized source. Yes, the plain X.509 certificates are not used in DNSSec, but the overall system design is the PKI-style. dol@ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Masataka Ohta пишет: Basil Dolmatov wrote: There are a lot of deficiencies in PKI, but at present time I can see no alternative for establishing trust in loosely connected and large systems. If there is one, please advise. The problem of PKI is that its security socially depends on a loose connection of a chain of adjacent CAs. In other word, PKI, including DNSSEC, is not secure end to end. As the chain is breakable at component CAs (trusted third parties are not very trustable), there is no point to work unreasonably hard to cryptographically strengthen links between adjacent CAs. So, PKI is useless when there already are loose but reasonable social security. There are no trust relationships between my ISP and your ISP. Your and my ISPs are loosely connected by a chain of social trust relationships between adjacent ISPs, which is why we can exchange packets over the Internet Yes. with reasonable security. No. Without any security at all. No garanties of delivery, no origin validation, no path validation, etc. "social trust relationship" can arrange packet delivery but cannot arrange any responsibility for proper delivery. I as have said before the picture you are drawing reflects Internet 20 years ago, when all participants cooperated and worked on the benefit of the network. No _not_all_ participants have this paradigm in the network and the share of those who do not participate in any "social trust relationships" but simply use the network in the manner they feel good for achieving their goals (sometimes criminal ones) is increasing continuously. Adjacent zones have reasonable social trust relationships between them, through which network, your resolver and my server are loosely connected with reasonable security. With no security at all. Otherwise we would have never heard about "cache poisoning". dol@ P.S. Just to mention: I liked Internet 20 years ago much more and a bit nostalgic about it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
The DNSSEC nightmare continues Re: Securing DNS Re: IAB statement on the RPKI.
so much simpler to solve DNS vulnerabilities with dnsCurve http://bit.ly/cjmH2n :) 2010/2/17 Phillip Hallam-Baker > One mechanism that was unfortunately pushed asside as a result of the > fixation on end to end DNSSEC would be to for the resolver to use > DNSSEC (and other methods) to authenticate the data it receives and to > use some modification of TSIG to authenticate the communication > between client and resolver. > > This model does not make much sense if you stick to the model where > hosts pick up their DNS service from the local host. But it makes a > great deal of sense when you are using a service like Google's DNS. It > would not take a great deal of effort to graft a Kerberos like scheme > on to effect key exchange. > > > The real problem with DNSSEC is that it has taken so long that the > Internet has changed since. And rather than go back and redesign we > are always told that so much time and effort has been spent already > that we cannot possibly take any time to look at the issues that might > prevent deployment or use. And so instead of the opt-in fix taking six > months as it should have done it took six years and instead of the > zone walking/privacy issue taking six months it took four years. > > I am thinking of retitling my RSA talk '2010 The Year of DNSSEC'. > > > I am not trying to beat up people and say do it the way we did it. > What I am trying to say here is DON'T REPEAT OUR MISTAKES. Look at the > solution that we were forced to adopt when the single rooted hierarchy > proved undeployable. > > > On Wed, Feb 17, 2010 at 10:01 AM, Basil Dolmatov wrote: > > Masataka Ohta пишет: > >> > >> But, the most serious defect of DNSSEC, or PKI in general, is that, > >> despite a lot of hypes, it is not cryptographically secure. > >> Social attacks on trusted third parties makes the parties > >> untrustworthy, which means PKI is merely socially or weakly > >> secure. > >> > >> > > > > There are a lot of deficiencies in PKI, but at present time I can see no > > alternative for establishing trust in loosely connected and large > systems. > > If there is one, please advise. > >> > >> For security of interdomain routing, social security of trust > >> relationship between ISPs is just enough to which additional > >> social security by PKI is not helpful. > >> > > > > There are no trust relationships between my ISP and your ISP. > > How my ISP can trust routing announce, which I have got over the network > and > > which has your ISP mentioned as the origin? > > > >> For security of DNS, social security of trust relationship between > >> ISPs and between zones are just enough to which additional social > >> security by PKI is not helpful. > >> > >> > > > > Same question applies to DNS. My resolver have no trust relationships > with > > your server. > > How I can trust DNS-answer which I have got over the network? > > > > Unfortunately, Internet 20 years ago and Internet today are two > > significantly different networks. > > > > 20 years ago I trusted to nearly all network participants and undoubtedly > > trusted to all network administrators. > > > > Now, the necessity to build the chains of trust is obvious, otherwise you > > will lose a lot. The methods, which are being implemented are definitely > not > > ideal (I knew a lot of flaws and weaknesses in systems, which are using > > PKI), but at the same time I do not know anything better. > > > > > > dol@ > > > > > > > >>Masataka Ohta > >> > >> > >> > > > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > > > > -- > -- > New Website: http://hallambaker.com/ > View Quantum of Stupid podcasts, Tuesday and Thursday each week, > http://quantumofstupid.com/ > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
On Wed, Feb 17, 2010 at 11:01:38AM -0500, Phillip Hallam-Baker wrote: > One mechanism that was unfortunately pushed asside as a result of the > fixation on end to end DNSSEC would be to for the resolver to use > DNSSEC (and other methods) to authenticate the data it receives and to > use some modification of TSIG to authenticate the communication > between client and resolver. Whatever made you think that had been "pushed aside"? And it seems to me SIG(0) will work better. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Sabahattin Gucukoglu wrote: >>>DNSsec, as far as I can see, does not use a PKI in the traditional >>>sense. There are _NO_ persons involved in the process, >> >>FYI, zones are operated by people. >> >>I can forge a key of your zone. I can, then, ask a person operating a >>parent zone of yours to issue a valid signature over the forged key. > Yeah, but at least now we know the difference between the subversion > of the "Chain of trust" and some bloke with a packet sniffer. It merely means that DNS depends on two chains of trust: one with zones and another with ISPs. As we know, ISPs are reasonablly trustable. > The point here is, we now have a way to verify the technical > functions we depend on today are working properly. That's pointless. Indeed, DNSSEC technically verifies keys have valid signatures. However, DNSSEC does not technically verify the valid signatures are obtained legitimately. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
On 17 Feb 2010, at 22:24, Masataka Ohta wrote: > Martin Rex wrote: >> DNSsec, as far as I can see, does not use a PKI in the traditional >> sense. There are _NO_ persons involved in the process, > > FYI, zones are operated by people. > > I can forge a key of your zone. I can, then, ask a person operating a > parent zone of yours to issue a valid signature over the forged key. Yeah, but at least now we know the difference between the subversion of the "Chain of trust" and some bloke with a packet sniffer. As soon as the "Integrity" of the "Chain of trust" becomes obviously broken, for whatever reason, it's totally within our power to do what we do now, and ignore it. The point here is, we now have a way to verify the technical functions we depend on today are working properly. It isn't about reputation or the trust of any given person or entity, any more than it is now. I can *still* find ingenious ways to bribe or subvert or otherwise make your registrar publish records of my control and design that pertain to your domains, with or without that verification function. Well, I could if I were sitting at the top with lots of money and nothing else to do. But when the data we receive is authentic from the intended, authenticated source, we have a chance to assign our own trust policies as we see fit (and it may be, though I doubt it, that I find the bloke with a packet sniffer a more reliable source than ICANN). The utility of online banking and shopping, as certified by some sort of certification authority about whom we know next to nothing, suggests that we prefer some - any - degree of accountability, and the result of some CA being s loppy has always (and will continue to be) grounds for distrust. And the same has applied as well to webs of trust, like those of PGP, where some degree of fuzzy logic is applied to make multiple vouches constitute more solid evidence of "Trustworthiness". Single roots may present problems when there is no other root, but never to the extent of being an unchallenged authority, and certainly not to the degree that the Internet would experience an irreparable divide. The problems only really show up when people get involved, and that's why certification authorities are so rich. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Martin Rex wrote: > DNSsec, as far as I can see, does not use a PKI in the traditional > sense. There are _NO_ persons involved in the process, FYI, zones are operated by people. I can forge a key of your zone. I can, then, ask a person operating a parent zone of yours to issue a valid signature over the forged key. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Basil Dolmatov wrote: > There are a lot of deficiencies in PKI, but at present time I can see no > alternative for establishing trust in loosely connected and large > systems. If there is one, please advise. The problem of PKI is that its security socially depends on a loose connection of a chain of adjacent CAs. In other word, PKI, including DNSSEC, is not secure end to end. As the chain is breakable at component CAs (trusted third parties are not very trustable), there is no point to work unreasonably hard to cryptographically strengthen links between adjacent CAs. So, PKI is useless when there already are loose but reasonable social security. > There are no trust relationships between my ISP and your ISP. Your and my ISPs are loosely connected by a chain of social trust relationships between adjacent ISPs, which is why we can exchange packets over the Internet with reasonable security. > Additional loose connection by a PKI chain does not help. > How my ISP can trust routing announce, which I have got over the network > and which has your ISP mentioned as the origin? That should be an argument against PKIs. How can you trust my CA, which you have got over a network of CAs? Socially compromising a CA in the network is as easy as socially compromising an ISP. > Same question applies to DNS. My resolver have no trust relationships > with your server. Adjacent zones have reasonable social trust relationships between them, through which network, your resolver and my server are loosely connected with reasonable security. If you argue zones are not managed very securely, it means CAs of PKI, a.k.a. zones of DNSSEC, are not managed very securely. > How I can trust DNS-answer which I have got over the network? How can you trust DNSSEC-answer which you have got over a network of poorly managed CAs (zones)? > Now, the necessity to build the chains of trust is obvious, Unless the chains are not already there. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
On Wed, Feb 17, 2010 at 06:48:37PM +, Tony Finch wrote: > On Wed, 17 Feb 2010, Phillip Hallam-Baker wrote: > > > One mechanism that was unfortunately pushed asside as a result of the > > fixation on end to end DNSSEC would be to for the resolver to use > > DNSSEC (and other methods) to authenticate the data it receives and to > > use some modification of TSIG to authenticate the communication > > between client and resolver. > > I don't think that has been pushed aside. There's not much interest in it > at the moment because the focus is on authoritative-to-recursive DNSSEC. > Maybe attention will turn to recursive-to-stub security once there is more > assurance that the recursive server's answers are authentic. There is also the camp that thinks that stubs should do validation themselves. > > It would not take a great deal of effort to graft a Kerberos like scheme > > on to effect key exchange. > > Or use SIG(0). > > Tony. Yeah, I kinda like SIG(0) myself. If you want to use Kerberos for symmetric key management, there is GSS-TSIG. But there is a bootstrapping problem -- Kerberos clients commonly use DNS SRV records to locate Kerberos servers. Most stub resolvers can't do any of this today (HMAC-MD5/SHAxxx TSIG, GSS-TSIG, SIG(0), etc) as far as I can tell. --Shumon. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Noel Chiappa wrote: > > > From: Dmitry Burkov > > > I think that it is not a constructive way to discuss this issue > > following some conspiracy theories. > > Understood, but at the same time there may be some value to being curious as > to why the Russian authorities have mandated the use of a local standard. The problem is that the explanation given is so universal that it can only be wrong. There may be a mandate for specific algorithms for particular uses, but it is completely unbelievable that it is _as_universal_as_stated_. And since the problem that is quoted is a political or contractual one, and _NOT_ a technical one, it makes no sense to discuss technical solutions for a presumably completely misunderstood political or contractual issue. Pretty much all of the software from outside of russia contains implementations of some cryptographic algorithms. And a lot of software uses these algorithms, i.e. most software vendors (Microsoft, Unix players, Linux Distros and network gear (Cisco?) use it for the distribution of their software. > > Is it just some sort of 'not invented here', or some other similar cause > (which is, I agree, not very interesting); or is there a desire to use a > different algorithm because there some sort of weakness to the standard > algorithm most countries are using, a weakness which has only been detected > by some entity somewhere in Russia? I assume it is the fear about backdoors. They know that nobody else besides themselves was given the a chance to plant back doors into their algorithms, for design flaws it is a level playing field for all, and for attacks, they currently have the same "nice" advantage that firefox has over MSIE with regards to probability of attacks. So from pure a risk management perspective mandating GOST provides some benefit, in theory. Their symmetric cipher with a blocksize of 64 bits and a key size of 256 bits is less convincing (because of the small blocksize). -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
> From: Dmitry Burkov > I think that it is not a constructive way to discuss this issue > following some conspiracy theories. Understood, but at the same time there may be some value to being curious as to why the Russian authorities have mandated the use of a local standard. Is it just some sort of 'not invented here', or some other similar cause (which is, I agree, not very interesting); or is there a desire to use a different algorithm because there some sort of weakness to the standard algorithm most countries are using, a weakness which has only been detected by some entity somewhere in Russia? Needless to say, if there _is_ such a weakness (and I am not saying there is, this is a pure hypothetical), we'd all like to know, so we could switch to something more secure (perhaps the GOST algorithm.. :-). Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
On Wed, 17 Feb 2010, Phillip Hallam-Baker wrote: > One mechanism that was unfortunately pushed asside as a result of the > fixation on end to end DNSSEC would be to for the resolver to use > DNSSEC (and other methods) to authenticate the data it receives and to > use some modification of TSIG to authenticate the communication > between client and resolver. I don't think that has been pushed aside. There's not much interest in it at the moment because the focus is on authoritative-to-recursive DNSSEC. Maybe attention will turn to recursive-to-stub security once there is more assurance that the recursive server's answers are authentic. > It would not take a great deal of effort to graft a Kerberos like scheme > on to effect key exchange. Or use SIG(0). Tony. -- f.anthony.n.finchhttp://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Basil Dolmatov wrote: > > > But, the most serious defect of DNSSEC, or PKI in general, is that, > > despite a lot of hypes, it is not cryptographically secure. > > Social attacks on trusted third parties makes the parties > > untrustworthy, which means PKI is merely socially or weakly > > secure. > > There are a lot of deficiencies in PKI, but at present time I can see no > alternative for establishing trust in loosely connected and large > systems. If there is one, please advise. DNSsec, as far as I can see, does not use a PKI in the traditional sense. There are _NO_ persons involved in the process, it is a pure authorization hierarchy of signing keys, and the distribution of that keys could be coupled to the lease of DNS domains from registries but is technically independent. > > For security of interdomain routing, social security of trust > > relationship between ISPs is just enough to which additional > > social security by PKI is not helpful. > > There are no trust relationships between my ISP and your ISP. > How my ISP can trust routing announce, which I have got over the network > and which has your ISP mentioned as the origin? Current DNS comes without any kind of protection and without any kind of trust. Get rid of your trust idea and adopt DNSsec only for the possibility to add some level of integrity protection and data origin authentication into the system. There are going to be so many keys and so many entities, so many key renewals and so many fully automatic signature operations in place that it will be impossible to come up with a universal set and number of "trusted authorties" that will make the entire DNS trusted and secure for everyone. The best you can come up with is to individually manage risks for specific zones to match individual threat scenarios, and you can do that completely indepent of how many "roots" there are. Going for one single root is an arbitrary choice, but it happens the one that is the easiest to deploy and the one with the lowest risk of operational problems (interferences among roots is a problem that can not exist then). Sensible DNSsec risk management can only work at the level of individual zones. It is not going to work with a single or a set of roots alone. Therefore discussing how many roots there should be and who should run them is a complete waste of time. The initial adoption rate of PGP and SSH was never crippled by discussions of which roots you want to trust. Otherwise they would have failed just as badly as S/MIME. TLS only became popular because the vendors decided to completely ignore risk management and selection and management of trusted roots. The choices are completely arbitrary and hardly anyone cares about the complete lack of risk management. When I use my Web-Browser to connect to some bank or online-shop under protection of SSL/TLS, then I don't have any trust to that bank or shop, not to their ISP and not to the CA that issued the cert for the server. Although the entire architecture is pretty insecure because of a complete lack of trust in many involved parties, it is far from being useless. Would the change from traditional DNS to DNSsec have a security impact on that scenario? No, NONE at all. But it could make the communication infrastructure more robust against infrastructure attacks. Managing risks would mean to manually check the server certificate and compare it to some out-of-band verification information. Browsers are quite hostile to risk management, because they don't naturally support concious trust decisions in the traditional SSH-style, which makes individual risk management extra painful. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Securing DNS Re: IAB statement on the RPKI.
One mechanism that was unfortunately pushed asside as a result of the fixation on end to end DNSSEC would be to for the resolver to use DNSSEC (and other methods) to authenticate the data it receives and to use some modification of TSIG to authenticate the communication between client and resolver. This model does not make much sense if you stick to the model where hosts pick up their DNS service from the local host. But it makes a great deal of sense when you are using a service like Google's DNS. It would not take a great deal of effort to graft a Kerberos like scheme on to effect key exchange. The real problem with DNSSEC is that it has taken so long that the Internet has changed since. And rather than go back and redesign we are always told that so much time and effort has been spent already that we cannot possibly take any time to look at the issues that might prevent deployment or use. And so instead of the opt-in fix taking six months as it should have done it took six years and instead of the zone walking/privacy issue taking six months it took four years. I am thinking of retitling my RSA talk '2010 The Year of DNSSEC'. I am not trying to beat up people and say do it the way we did it. What I am trying to say here is DON'T REPEAT OUR MISTAKES. Look at the solution that we were forced to adopt when the single rooted hierarchy proved undeployable. On Wed, Feb 17, 2010 at 10:01 AM, Basil Dolmatov wrote: > Masataka Ohta пишет: >> >> But, the most serious defect of DNSSEC, or PKI in general, is that, >> despite a lot of hypes, it is not cryptographically secure. >> Social attacks on trusted third parties makes the parties >> untrustworthy, which means PKI is merely socially or weakly >> secure. >> >> > > There are a lot of deficiencies in PKI, but at present time I can see no > alternative for establishing trust in loosely connected and large systems. > If there is one, please advise. >> >> For security of interdomain routing, social security of trust >> relationship between ISPs is just enough to which additional >> social security by PKI is not helpful. >> > > There are no trust relationships between my ISP and your ISP. > How my ISP can trust routing announce, which I have got over the network and > which has your ISP mentioned as the origin? > >> For security of DNS, social security of trust relationship between >> ISPs and between zones are just enough to which additional social >> security by PKI is not helpful. >> >> > > Same question applies to DNS. My resolver have no trust relationships with > your server. > How I can trust DNS-answer which I have got over the network? > > Unfortunately, Internet 20 years ago and Internet today are two > significantly different networks. > > 20 years ago I trusted to nearly all network participants and undoubtedly > trusted to all network administrators. > > Now, the necessity to build the chains of trust is obvious, otherwise you > will lose a lot. The methods, which are being implemented are definitely not > ideal (I knew a lot of flaws and weaknesses in systems, which are using > PKI), but at the same time I do not know anything better. > > > dol@ > > > >> Masataka Ohta >> >> >> > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost [Was: Re: IAB statement on the RPKI. ]
Martin, (Apparently, the subject lines have been messed up entirely on this list these days. I tried to return to the actual subject, GOST signatures for DNSSEC.) I fear you are in danger of drawing the wrong conclusions based on incomplete information. (1) non-protocol issues > ... that Zones can carry both, a mandatory to implement signature > (algorithm) and interoperable world-wide, and one that might > be prefered in particular regions (or legislations) and can > be evaluated in those areas by those who care (or which are > obliged to care). If I understand correctly, the basic issue of those under GOST-related regulatory restrictions is that they are legally constrained to "MUST NOT use other algorithms than GOST to produce digital signatures". That makes your smart proposal moot, AFAICS. :-( I have no idea whether or not geo-diversity of secondary servers and/or anycast server instances providing signatures with a generally accepted signature algorithm on the same zone content could be an option ... -- routing might do the "right" thing, and the necessary details for the root could be worked out ... (2) protocol issues > (are signatures and DNS KEYs in DNSsec really designed to be > "highlanders", i.e. there can only be one?) No, DNSSEC can use and carry multiple signatures. That's necessary for rekeying and algorithm agility (phased introduction of new signature algorithms) anyway. The drawbacks are twofold: - The protocol does not allow the clients to select what they would like to get; they only can set a flag to say "I do understand DNSSEC, please send the DNSSEC records you have with the answer." So the authority or cache needs to send all signatures to every DNSSEC-aware client. - Keys and signatures add significantly to the size of DNS responses, and there (still) are lots of obstacles out there in the wild to proper use the protocol mechanisms standardized long ago to cope with responses longer than 512 octets: EDNS, and DNS transport over TCP. Too many network elements raise sad hurdles, and IP fragmentation is a minefield. Thus, widespread practice of regular double- (or triple-)signing of DNS RRsets would most likely increase the order of magnitude of failures to receive answers that lead to DNSSEC-verifiable results. Hard luck. Sigh! Kind regards, Alfred Hönes. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Masataka Ohta пишет: But, the most serious defect of DNSSEC, or PKI in general, is that, despite a lot of hypes, it is not cryptographically secure. Social attacks on trusted third parties makes the parties untrustworthy, which means PKI is merely socially or weakly secure. There are a lot of deficiencies in PKI, but at present time I can see no alternative for establishing trust in loosely connected and large systems. If there is one, please advise. For security of interdomain routing, social security of trust relationship between ISPs is just enough to which additional social security by PKI is not helpful. There are no trust relationships between my ISP and your ISP. How my ISP can trust routing announce, which I have got over the network and which has your ISP mentioned as the origin? For security of DNS, social security of trust relationship between ISPs and between zones are just enough to which additional social security by PKI is not helpful. Same question applies to DNS. My resolver have no trust relationships with your server. How I can trust DNS-answer which I have got over the network? Unfortunately, Internet 20 years ago and Internet today are two significantly different networks. 20 years ago I trusted to nearly all network participants and undoubtedly trusted to all network administrators. Now, the necessity to build the chains of trust is obvious, otherwise you will lose a lot. The methods, which are being implemented are definitely not ideal (I knew a lot of flaws and weaknesses in systems, which are using PKI), but at the same time I do not know anything better. dol@ Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Dmitry Burkov wrote: > As you know we have some national regulation in crypto. > To implement DNSSEC we should > or to use GOST (at this moment) and to comply regulations > or to ignore DNSSEC (no comments) > or try to change national laws (also no comments). > If someone can give us an advice - what to do else - you are welcome. Ignore DNSSEC. Technically, it is poorly designed unnecessarily causing a lot of technical problems such as large message sizes. But, the most serious defect of DNSSEC, or PKI in general, is that, despite a lot of hypes, it is not cryptographically secure. Social attacks on trusted third parties makes the parties untrustworthy, which means PKI is merely socially or weakly secure. For security of interdomain routing, social security of trust relationship between ISPs is just enough to which additional social security by PKI is not helpful. For security of DNS, social security of trust relationship between ISPs and between zones are just enough to which additional social security by PKI is not helpful. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost [Was: Re: IAB statement on the RPKI. ]
Alfred =?hp-roman8?B?SM5uZXM=?= wrote: > > (Apparently, the subject lines have been messed up entirely > on this list these days. I tried to return to the actual > subject, GOST signatures for DNSSEC.) > > > I fear you are in danger of drawing the wrong conclusions based > on incomplete information. > > (1) non-protocol issues > > > ... that Zones can carry both, a mandatory to implement signature > > (algorithm) and interoperable world-wide, and one that might > > be prefered in particular regions (or legislations) and can > > be evaluated in those areas by those who care (or which are > > obliged to care). > > If I understand correctly, the basic issue of those under GOST-related > regulatory restrictions is that they are legally constrained to > "MUST NOT use other algorithms than GOST to produce digital signatures". > > That makes your smart proposal moot, AFAICS. :-( But they don't need to create "digital signatures"! They only need to provide RRSIG RRs with MACs that the rest of the world can use to perform integrity checks and data origin authentication based on a common asymmetric crypto algorithm for the purpose of interoperability when validating DNS records. None of registries in Russia needs to provide official "digital signatures" (in any legally binding sense) in order to make DNSsec work at the technical level. The GOST-signed RRSIG RRs can be the officially signed records, the other is just a provision for technical interop of the MAC scheme with DNSsec for the rest of the internet. Any other approach just doesn't scale. IIRC, IPsec decided somewhere around 1995 that sacrificing interop to accomodate crypto export regulation was a dead-end road and not appropriate for an international standardization body. Although, I might have missed that the IETF reverted its attitude and is today catering everone and his dog's personal crypto preferences in their protocols, dropping the burden on the implementors of the technology, I think it would be the wrong approach. What is the situation in IPsec with regards to GOST these days? > > (2) protocol issues > > > (are signatures and DNS KEYs in DNSsec really designed to be > > "highlanders", i.e. there can only be one?) > > No, DNSSEC can use and carry multiple signatures. > > That's necessary for rekeying and algorithm agility (phased > introduction of new signature algorithms) anyway. That's what I assumed (and I found it in rfc-4033 3.1). > > The drawbacks are twofold: > >- The protocol does not allow the clients to select what > they would like to get; they only can set a flag to say > "I do understand DNSSEC, please send the DNSSEC records > you have with the answer." So the authority or cache > needs to send all signatures to every DNSSEC-aware client. That looks like a defect in the protocol. > >- Keys and signatures add significantly to the size of > DNS responses, and there (still) are lots of obstacles > out there in the wild to proper use the protocol mechanisms > standardized long ago to cope with responses longer than > 512 octets: EDNS, and DNS transport over TCP. > Too many network elements raise sad hurdles, and IP > fragmentation is a minefield. > > Thus, widespread practice of regular double- (or triple-)signing > of DNS RRsets would most likely increase the order of magnitude of > failures to receive answers that lead to DNSSEC-verifiable results. > > Hard luck. Sigh! Probably the biggest mistake in DNSsec was to describe the data that is used to verify RRs as "digital signatures" instead of simply MACs based on asymmetric crypto algorithms. All of the politics and flawed assumptions around PKI have prevented the existing DNS registries to add RRSIGs to their zones many many years ago -- which otherwise would have helped to iron out the problems around the size of the DNS responses over the last decade. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Dmitry Burkov wrote: > > On 16.02.10 4:21, Phillip Hallam-Baker wrote: > > deploy as at present does not seem to have occurred to them. It is > > quite possible that what is driving the GOST issue is that the GRU > > really has a thing about vanity crypto. But I think it much more > > likely that they are going to use it as part of a series of > > regulations that effectively require Russian ISPs chain their DNSSEC > > off the GRU approved root. > > > > I think that it is not a constructive way to discuss this issue > following some conspiracy theories. > I want to refer you to origin of this discussion on ietf lists > http://dnssec-deployment.org/pipermail/dnssec-deployment/2009-April/thread.html#2932 > > and want to remind what was initial reason for us to follow this way and > to propose GOST as one of standard algorithms for DNSSEC. With respect to supporting regionally favoured crypto-algorithm, the solution should be different. DNSsec should allow for the presence of more than one signature (differing in algorithm), so that Zones can carry both, a mandatory to implement signature (algorithm) and interoperable world-wide, and one that might be prefered in particular regions (or legislations) and can be evaluated in those areas by those who care (or which are obliged to care). The obvious benefit is that only those living in regions or legislations with an extreme bias towards certain crypto algorithms have to bear the burden of creating and verifying the optional signatures with that algorithm, while the others can continue to use the single common and mandatory algorithm. I don't have a problem if DNS-Zones like ".ru", ".su" include GOST-based signatures in their Zones. But to me it looks like a serious problem if they do _NOT_ include signatures of a common worldwide algorithm (which can be used by all others that verify zones from .ru and .su). (are signatures and DNS KEYs in DNSsec really designed to be "highlanders", i.e. there can only be one?) -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
On 16.02.10 4:21, Phillip Hallam-Baker wrote: deploy as at present does not seem to have occurred to them. It is quite possible that what is driving the GOST issue is that the GRU really has a thing about vanity crypto. But I think it much more likely that they are going to use it as part of a series of regulations that effectively require Russian ISPs chain their DNSSEC off the GRU approved root. I think that it is not a constructive way to discuss this issue following some conspiracy theories. I want to refer you to origin of this discussion on ietf lists http://dnssec-deployment.org/pipermail/dnssec-deployment/2009-April/thread.html#2932 and want to remind what was initial reason for us to follow this way and to propose GOST as one of standard algorithms for DNSSEC. As you know we have some national regulation in crypto. To implement DNSSEC we should or to use GOST (at this moment) and to comply regulations or to ignore DNSSEC (no comments) or try to change national laws (also no comments). If someone can give us an advice - what to do else - you are welcome. After series of dicussions and consultations with many participants of this list we agreed with recommendations and began this process to move forward GOST as one of mandatory standards. Otherwise - we can't achieve "the goal is: (1) for their zones, e.g. .ru, .su, and any new ones they get, to be signed with GOST, (2) for everyone to be able to validate their signatures, and (3) for them to be able to validate everyone else's signatures. For (2), they need to promulgate their algorithms into the standard crypto libraries and have an algorithm identifier assigned through IANA. I believe both of these are in progress. For (3), they simply need to use the standard algorithms in their own resolvers, and I believe they will be able to do this comfortably. We're talking about checking, not signing, signatures, not encrypting." Just a quote from this list. Dima ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Phillip Hallam-Baker wrote: > > It is now generally accepted that PEM was undeployable because the > single root model is not workable. Nobody was going to trust IANA as > the ultimate root of trust, nor were they going to trust RSA. > > ICANN has accepted responsibility for the DNS infrastructure. > Unfortunately they don't seem to understand what that means for their > interactions with the IETF. At the very least, ICANN needs to be > issuing operational requirements documents that itemize the protocol > support that is required for deployment. The real problem is that a lot of people attribute too much trust of all the wrong kind into a security architecture, creating a huge pile of flawed assumptions -- that is neither appealing nor robust, so there is little surpise when it fails in the marketplace. DNSsec should _NOT_ do anything besides confirming the assignment/lease of DNS zones to lessees. Any kind of trust decision by applications based on DNS delegation of zones is completely inappropriate. The signature on a DNS zone is the result of a contract between the organization that adminstrates a zone to lessees/subscribers for delegated subdomains, nothing else. It is a simple technical fact that the DNS zones are technically organized in a hierarchical fashion and that administrators of a zone can delegate adminstration of subdomains to others. DNSsec will hopefully make the insertion of fake data into DNS zones more difficult, but it will not make Cybersquatting or disputes about domain ownership/assignment go away. DNSsec is technically still DNS, after all. Which DNS domains actually belong to specific state, corporate or private entites is an entirely seperate question, and no application should ever confuse the authority to delegate DNS domains with authority to "certify" legal entities (governmental,corporate or private). If the .com registry leases&delegates the domain "ietf.com" to somebody, that does not imply that this somebody therefore represents the Internet Engineering Task Force (IETF). and any kind of assumption within applications to that effect are fatally flawed. All of the existing security protocols are using a different trust model already (like TLS), and I do _not_ think that existing trust models (independent of how broken the TLS trust model with >100 preconfigured and completely interchangable trusted roots is) should be piggy-backed onto, or keyed from DNSsec, ever. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
No, you think that you have a unitary root. Actually you have separation of powers. ICANN is not currently in sole control. There is a marked difference between the ICANN view of its authority and the RIRs and national TLDs Removing the ambiguity means a very large change in the ability of ICANN to enforce its authority. Now it could be that this will be acceptable to the French, Egyptian, Brazilian ministries etc. But not objecting to a change in the Internet governance that results in a major loss of sovereignty would be rather out of character. 2010/2/16 Patrik Fältström : > On 16 feb 2010, at 03.11, David Conrad wrote: > >> On Feb 15, 2010, at 5:21 PM, Phillip Hallam-Baker wrote: >>> It is now generally accepted that PEM was undeployable because the >>> single root model is not workable. >> >> And this is the fault of IANA and/or ICANN how? > > Philip, yes, because people did not think strongly enough on how to create > the one single root. Because a single root among other things created a > problem for the various business models out there. > > For domain names and IP addresses, we already have a root, so that problem > does not exist. And that is exactly what IAB states. > > Patrik > > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
It is now generally accepted that PEM was undeployable because the single root model is not workable. Nobody was going to trust IANA as the ultimate root of trust, nor were they going to trust RSA. ICANN has accepted responsibility for the DNS infrastructure. Unfortunately they don't seem to understand what that means for their interactions with the IETF. At the very least, ICANN needs to be issuing operational requirements documents that itemize the protocol support that is required for deployment. ICANN was well aware that the lack of opt-out would prevent deployment of DNSSEC in .com as early as 2000. They had a responsibility to tell the IETF that this was a non-negotiable requirement and that failure to meet it would mean that ICANN would be unable to deploy DNSSEC. Instead they insisted that no deviation from the IETF standard was permissible. Ten years later the only part of ICANN that seems to interest them is the idea that they will have sole control of the root zone. The fact that others are going to filibuster DNSSEC rather than to allow it to deploy as at present does not seem to have occurred to them. It is quite possible that what is driving the GOST issue is that the GRU really has a thing about vanity crypto. But I think it much more likely that they are going to use it as part of a series of regulations that effectively require Russian ISPs chain their DNSSEC off the GRU approved root. Otherwise the Russian concerns make absolutely no sense. They certainly understand PKI well enough that control of the root key is a much bigger deal than the remote possibility that the NSA has tricked up the made in the US crypto with some backdoor that only the NS has noticed in the past three decades. On Mon, Feb 15, 2010 at 7:45 PM, David Conrad wrote: > On Feb 15, 2010, at 4:40 PM, Phillip Hallam-Baker wrote: >> PEM (Five years and counting before the project faded away without a >> definitive declaration of failure) >> DNSEC (Ten years and counting) > > So, you're blaming IANA and/or ICANN for the failure to deploy both PEM and > DNSSEC. > > Seriously? > > Regards, > -drc > > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
PKI is all politics. A PKI is a political infrastructure. Saying that politics and business rules are out of scope when you propose a PKI design is basically saying that you aren't going to look at any of the issues that are relevant to the design. Sandra Murphy is right when she says that political and business fears don't have to be rooted in 'technical truth' (whatever that is). They do not have to be grounded in any form of reality. They can be completely and utterly unreasonable. And they can be held by people who have the ability to totally block any chance of deployment. 'Trust me' is not a convincing argument in this context. Unless you hadn't noticed, cyber-conflict is now real. Back during the last US Presidential election I was advised that both campaigns had been penetrated in attacks originating from a Chinese government agency. The examples that are making the press are only some of the attacks taking place. Attacks originating in the US do not get as much attention. In this environment it seems rather naive to believe that these parties can be persuaded to acquiesce to the deployment of a PKI that requires their participation. Not changing the political or business relationships of the parties has to be a criteria in the design of any global information infrastructure if deployment is going to have a chance of success. On Mon, Feb 15, 2010 at 7:01 PM, SM wrote: > At 16:50 14-02-10, Masataka Ohta wrote: >> >> Perhaps, a threat will be by an ISP trying to advertise someone >> else's address range as its own. > > Quoting Sandra Murphy [1]: > > "Political and business fears don't have to be rooted in technical > truth, unfortunately." > > At 19:48 14-02-10, Phillip Hallam-Baker wrote: >> >> I don't think that any member of the IAB would claim that their >> expertise in the PKI field precluded debate. > > Your message did not make it to the IETF mailing list. > > I am not privy to all the details to argue against an IAB statement. This > should not be read as a licence to kill. :-) > >> This is not a technical issue, it is a political issue. IANA and ICANN >> have a really, really bad record when it comes to setting up root >> authorities. Any plan that requires their involvement is going to take >> considerably more time and effort than one where their involvement is >> optional. > > Any long-term consequence will be of a political nature. It goes beyond the > IANA function and ICANN. The conventional world is used to having some form > of authority for regulation. The "routing by rumor" approach does not fit > that view. Some considerations may seem far-fetched. I'll leave it as > such. > >> There are five RIRs, this number is not going to increase in the short >> term. Participation of the RIRs is critical for an authoritative >> system. Participation of ICANN is not. > > It's up to the interested parties to work out the details. > >> The risk of including ICANN is that misguided or not, there are lots >> of people who have concerns as to the power that the US exercises over >> the Internet through their defacto control of ICANN. One common >> concern is that the US could use such control to ensure that US ISPs >> were favored in the distribution of the remaining IPv4 blocks. > > I don't think that the distribution of the remaining IPv4 blocks is that > much of an issue. > > I would not draw parallels between DNS and IDR as the dynamics are > different. I don't assume that the goal is always about wrecking havoc. > These are classic threats that RPKI can address. > > Regards, > -sm > > 1. http://www.ietf.org/mail-archive/web/sidr/current/msg01099.html > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
PEM (Five years and counting before the project faded away without a definitive declaration of failure) DNSEC (Ten years and counting) They have yet to succeed in setting up a single PKI. Signing the root of the DNSSEC scheme will not change anything, I asked for details of the proposed registrar key authentication process three months ago and I am still waiting. I doubt that they exist. On Mon, Feb 15, 2010 at 7:19 PM, David Conrad wrote: >> At 19:48 14-02-10, Phillip Hallam-Baker wrote: >>> IANA and ICANN have a really, really bad record when it comes to setting up >>> root authorities. > > Oh? Examples please. > > Regards, > -drc > > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
There are two separate functions in the routing layer. There are security issues in both cases. The first function is to map IP address ranges to AS numbers. This is a global mapping, if an IP address range maps to an AS number in France the same mapping will be good in Brazil. The second function is to establish rooting maps for AS numbers, effectively setting up mappings of the AS numbers to Internet endpoint networks. This mapping is not global. The best route to London is going to be very different in France and Brazil. The upshot is that the first problem maps very cleanly to standard PKI approaches. You can use X.509 certs with extensions, you could use SAML assertions, the statements are global and work very well. The second problem is a much harder one to address using PKI. It is quite possible that PKI is not the right tool at all. The problem is that if A, B and C are exchanging routing information and Mallet introduces a bogus route to A, the message A then sends to B advertising a better route will genuinely have come from A. There are certainly ways round this problem, if indeed it really is a persistent problem. There are non cryptographic controls already in place to verify route quality. It may be that these are sufficient. It may be that we can employ an accountability based approach to pinpoint the introduction of bogus routes. On Sun, Feb 14, 2010 at 7:50 PM, Masataka Ohta wrote: > SM wrote: > >> The most important factor in choosing a security mechanism is the threat >> model. > > Right. > >> That is, who may be expected to attack what resource, using what >> sorts of mechanisms? (RFC 3631). > > Perhaps, a threat will be by an ISP trying to advertise someone > else's address range as its own. > > However, protections against the threat does not prevent the > ISP advertise the range as someone elses'. > > That is, the ISP can attach its own AS number to a legitimate AS > path for the range. Then, the ISP can capture packets destined > to addresses within the range, against which, there is no > protection. > > Masataka Ohta > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
On Sun, Feb 14, 2010 at 4:54 AM, SM wrote: > Hello, > At 02:55 12-02-10, IAB Chair wrote: >> >> IAB statement on the RPKI. >> >> = RPKI as a prerequisite for improving the security of the global >> routing system. > > It would be preposterous of me to disagree with the opinion of the learned > members of the IAB. I don't think that any member of the IAB would claim that their expertise in the PKI field precluded debate. This is not a technical issue, it is a political issue. IANA and ICANN have a really, really bad record when it comes to setting up root authorities. Any plan that requires their involvement is going to take considerably more time and effort than one where their involvement is optional. The substantive statements being issued in the PKI are going to consist of a RIR issuing an assertion of the form 'The holder of the key X has the authority to assign AS numbers to the IP address space Y through Z'. There are five RIRs, this number is not going to increase in the short term. Participation of the RIRs is critical for an authoritative system. Participation of ICANN is not. The risk of including ICANN is that misguided or not, there are lots of people who have concerns as to the power that the US exercises over the Internet through their defacto control of ICANN. One common concern is that the US could use such control to ensure that US ISPs were favored in the distribution of the remaining IPv4 blocks. The people who hold these views are not stupid, they just hold a completely different world view. A world view that is not going to be overturned by rational arguments based on the world view largely shared by the IAB. And some of those people hold positions of authority that can pretty much ensure that any ICANN sponsored root never happens. In the diplomatic world, you do not accept a position based on 'trust me'. The original DNS emerged by accident because nobody was looking. X.500 died because everyone was watching and there was a sufficiently large number of parties who prefered no system to an unacceptable system. As most people here are aware, the Internet has become a forum for proxy-warfare and symbolic warfare. There will be considerable opposition even with the changes I propose: certain parties do not want this system to be secure. A better alternative to a single root structure would be for each RIR to cross certify with the other RIRs. This eliminates the objection to 'US dominance', eliminates ICANN as a roadblock and provides for redundancy. The security difference between the two scheme is that a single root system headed by ICANN could in theory prevent 'defection' by a RIR. In practice this would require a lot more technical mechanism. ICANN would have to certify each mega-block allocation. I don't think it is very likely that end entities are going to be checking the block allocations on every transaction absent an expectation that the RIRs might defect. But the possibility that they might will mean that the RIRs will lose authority should they co-operate with such a scheme. In conclusion, I strongly recommend that we do not repeat the disastrous political mistakes of DNSSEC that have blocked deployment for over a decade and will still continue long after the DNSSEC root is deployed. Deployment of infrastructure on this scale requires that we make a commitment to deployment a higher priority than the realization of a specific technical architecture. -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
On 16 feb 2010, at 03.11, David Conrad wrote: > On Feb 15, 2010, at 5:21 PM, Phillip Hallam-Baker wrote: >> It is now generally accepted that PEM was undeployable because the >> single root model is not workable. > > And this is the fault of IANA and/or ICANN how? Philip, yes, because people did not think strongly enough on how to create the one single root. Because a single root among other things created a problem for the various business models out there. For domain names and IP addresses, we already have a root, so that problem does not exist. And that is exactly what IAB states. Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Phillip Hallam-Baker wrote: > There are two separate functions in the routing layer. There are > security issues in both cases. "interdomain routing security", for which SIDR WG was scoped, is the second one, though its charter is totally confused. > The second problem is a much harder one to address using PKI. It is > quite possible that PKI is not the right tool at all. PKI is not, which means it is confirmed again that IETF, including IAB, is brain dead. It's not an issue specific to IANA or ICANN and IPv6 is a better evidence than PEM or DNSSEC. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
On Feb 15, 2010, at 5:21 PM, Phillip Hallam-Baker wrote: > It is now generally accepted that PEM was undeployable because the > single root model is not workable. And this is the fault of IANA and/or ICANN how? > ICANN was well aware that the lack of opt-out would prevent deployment > of DNSSEC in .com as early as 2000. Even if "ICANN" was aware (doubtful), do you really think the DNSEXT working group would value ICANN's position more than, say, VeriSign's? > They had a responsibility to tell > the IETF that this was a non-negotiable requirement and that failure > to meet it would mean that ICANN would be unable to deploy DNSSEC. Do you honestly believe ICANN can dictate to the IETF community (or anybody else with the exception of contracted parties) how to do much of anything? You have a very odd view of how ICANN works. > Ten years later the only part of ICANN that seems to interest them is > the idea that they will have sole control of the root zone You are aware, of course, that ICANN isn't even the party that is going to be signing the root zone, right? And how the root KSK is being managed? Sounds to me like you just want to bash ICANN. This gets boring after a while. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
On Feb 15, 2010, at 4:40 PM, Phillip Hallam-Baker wrote: > PEM (Five years and counting before the project faded away without a > definitive declaration of failure) > DNSEC (Ten years and counting) So, you're blaming IANA and/or ICANN for the failure to deploy both PEM and DNSSEC. Seriously? Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
> At 19:48 14-02-10, Phillip Hallam-Baker wrote: >> IANA and ICANN have a really, really bad record when it comes to setting up >> root authorities. Oh? Examples please. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
At 16:50 14-02-10, Masataka Ohta wrote: Perhaps, a threat will be by an ISP trying to advertise someone else's address range as its own. Quoting Sandra Murphy [1]: "Political and business fears don't have to be rooted in technical truth, unfortunately." At 19:48 14-02-10, Phillip Hallam-Baker wrote: I don't think that any member of the IAB would claim that their expertise in the PKI field precluded debate. Your message did not make it to the IETF mailing list. I am not privy to all the details to argue against an IAB statement. This should not be read as a licence to kill. :-) This is not a technical issue, it is a political issue. IANA and ICANN have a really, really bad record when it comes to setting up root authorities. Any plan that requires their involvement is going to take considerably more time and effort than one where their involvement is optional. Any long-term consequence will be of a political nature. It goes beyond the IANA function and ICANN. The conventional world is used to having some form of authority for regulation. The "routing by rumor" approach does not fit that view. Some considerations may seem far-fetched. I'll leave it as such. There are five RIRs, this number is not going to increase in the short term. Participation of the RIRs is critical for an authoritative system. Participation of ICANN is not. It's up to the interested parties to work out the details. The risk of including ICANN is that misguided or not, there are lots of people who have concerns as to the power that the US exercises over the Internet through their defacto control of ICANN. One common concern is that the US could use such control to ensure that US ISPs were favored in the distribution of the remaining IPv4 blocks. I don't think that the distribution of the remaining IPv4 blocks is that much of an issue. I would not draw parallels between DNS and IDR as the dynamics are different. I don't assume that the goal is always about wrecking havoc. These are classic threats that RPKI can address. Regards, -sm 1. http://www.ietf.org/mail-archive/web/sidr/current/msg01099.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
SM wrote: > The most important factor in choosing a security mechanism is the threat > model. Right. > That is, who may be expected to attack what resource, using what > sorts of mechanisms? (RFC 3631). Perhaps, a threat will be by an ISP trying to advertise someone else's address range as its own. However, protections against the threat does not prevent the ISP advertise the range as someone elses'. That is, the ISP can attach its own AS number to a legitimate AS path for the range. Then, the ISP can capture packets destined to addresses within the range, against which, there is no protection. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Hello, At 02:55 12-02-10, IAB Chair wrote: IAB statement on the RPKI. = RPKI as a prerequisite for improving the security of the global routing system. It would be preposterous of me to disagree with the opinion of the learned members of the IAB. = Implementation considerations The notion of having a certification hierarchy with multiple equally trusted roots may be appealing from a social and political perspective because of 'fairness' and 'equality' arguments. But that notion allows different organizations to make inconsistent and conflicting assertions about to whom a particular address block has been allocated. In the case of conflicting assertions, the conflict would need to be solved by each relying party, requiring each relying party to have their own security policy and the associated increased complexity. Such an approach does not provide any guarantee that the outcome would lead to a globally coherent view of which resources have been allocated to whom. The most important factor in choosing a security mechanism is the threat model. That is, who may be expected to attack what resource, using what sorts of mechanisms? (RFC 3631). What follows is a work of fiction. The taller man shut the folder and smiled. "This is a wonderful statement. Just Perfect." "Thank you," said the white-haired man seated across from him. "The author is a very good writer." He shifted slowly, uncrossing his legs. He leaned forward, causing the leather seat to groan. "Along with this afternoon's briefing, this is really going to accelerate matters. You know that, don't you?" "Of course," the taller man said. He put his coffee mug on a small table, rose, and walked to the fireplace. He picked up a poker. "Does that scare you?" "A little," the white-haired man admitted. "Why?" the taller man asked as he threw the folder into the flames". It caught fire quickly. "Our tracks are covered." "It is not us I'm worried about. There will be a price," the white-haired man said sadly. "We've discussed this before," the taller man said. "The policy people will love it." This is an edited version of the text from Divide and conquer written by Jeff Rovin, Tom Clancy and Steve R. Pieczenik. The quoted text should not be considered as an IETF Contribution as the author of this message does not control the rights to the material. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
Hello All, On Fri, 12 Feb 2010, IAB Chair wrote: IAB statement on the RPKI. = RPKI as a prerequisite for improving the security of the global routing system. To date, the Internet has operated without a secure means to certify the allocation of Internet number resources, particularly Autonomous System (AS) numbers and IP addresses. The pending exhaustion of the IPv4 address space, coupled with a pressing need to improve the security of the global Internet routing system, has given impetus to the development of a resource certification infrastructure for the Internet. A consistent shared view around the world of which number resources are allocated to whom is essential for the reliable operation of the Internet as it continues to grow. The IETF Secure Inter-domain Routing (SIDR) Working Group (WG) has been working with the various stakeholders to specify a Resource Public Key Infrastructure (RPKI) system that can be used to certify these resource allocations in order to substantially improve the security of the routing system. The IAB considers a properly designed and deployed RPKI to be an absolute prerequisite to having a secure global routing system, which is in turn a prerequisite to having a reliable worldwide Internet. In its absence, there is no formally verifiable authoritative source to determine the allocation for any Internet number resource. Consequently, before originating, propagating, or accepting an IP address prefix, each routing domain must individually assess the consistency of that prefix with whatever information can be obtained about actual allocations. This loose "routing by rumor" approach provides considerable flexibility to each routing domain, but the negative consequences are severe. The global routing system is vulnerable to large-scale disruptions through both misconfiguration and malice. These vulnerabilities can be substantially reduced through the use of an RPKI. Through proper design and wide-scale deployment, an RPKI enables network operators to generate their routing policies from securely verifiable allocation data, providing much higher confidence in the authenticity of routing information. = Technical considerations with respect to the design of the PKI For any PKI, a certification hierarchy must exist that allows parties to ascertain the validity of a given certificate. The SIDR architecture uses a certification hierarchy, and relying parties must explicitly place trust in the top-level of the hierarchy, commonly called a trust anchor. The SIDR architecture and protocols have been designed to support a single trust anchor as well as multiple trust anchors. The IAB however, is in strong agreement with the Number Resource Organization (NRO) (made up of the five Regional Internet Registries (RIRs)) regarding the number of trust anchors as well as what and whom they represent: 1. the RPKI should have a single authoritative trust anchor 2. this trust anchor should be aligned with the registry of the root of the allocation hierarchy The reasoning is of a technological nature and is as follows. A single root for the certification hierarchy significantly reduces the risk of two or more parties accidentally (or maliciously) issuing conflicting certifications for the same address block, because a single authoritative entity at the top-level of the allocation hierarchy is authoritative for both (a) the allocation of the address block and (b) the cryptographic certification of the fact that it did indeed allocate that address block. Thus, the IAB strongly recommends a single root aligned with the root of the address allocation hierarchy (now part of the IANA function). Doing so will minimize unnecessary complexity in the system, in particular virtually eliminating the possibility of resource conflicts in the system, reducing substantially the likelihood of errors as the allocation and certificate generation can be done together by the same operator. I for one do not see the need for a 'Single' point of failure nor a placement of another financial gaining point for some large company/government or what have you . There are protocols which can be used and some are in discussion which would be far better than this particular methodology . The only way this could be even fathomable would be for a World wide orginasation to be formed that manages & monitors this AND we all know where that will head the minute it gets started . = Implementation considerations The notion of having a certification hierarchy with multiple equally trusted roots may be appealing from a social and political perspective because of 'fairness' and 'equality' arguments. But that notion allows different organizations to make inconsistent and conflicting assertions about to whom a particular address block has been allocated. In the case of conflicting assertions, the conflict would need to be solved by each relying party, re
