Many people use an IM add-on called Off-the-Record. On top of encryption, it also provides deniability by not proving any digital signatures for the other party to present to a court, and the procol ensures everyone can make false messages in the past. How strong do you this technical protection would be from a legal perspective if one of the two parties has a logfile with all messages?
I strongly recommend using GKG.net, as they have the best (automated) XML interface that I know of. See their documentation
InternetX also has a good interface, but it is a little more complex to get going.
Those, as well as GoDaddy, which you can only process using ugly web scraping with BeautifulSoup and Mechanize, were the first ones we supported in our DNSSEC Signer product.
Powerdns was vulnerable to the Kaminsky attack, but in a different way. It was actually easier to spoof the server due to its more actively dropping certain DNS packets. So while it did perform source port randomization, it was not totally immune to the attack either.
All versions of PowerDNS before 2.9.21.1 do not respond to certain queries. This in itself is not a problem, but since the discovery by Dan Kaminsky of a new spoofing technique, this silence for queries PowerDNS considers invalid, within a valid domain, allows attackers more chances to feed *other* resolvers bad data.
Though it is phrased as "someone elses problem", in the DNS word of course nothing is "someone elses problem". DNS servers are chained in hierachies and one problem somewhere leads to problems elsewhere. DNS is all about protocol compliance to ensure interoperability. With the "someone elses problem" approach, we would have had no "reflection attack" and "amplification attack" problems either, it being "someone elses problem". Despite the nice phrasing, powerdns caused cache poisoning problems as a result of the Kaminsky attack that needed to be addressed.
In general, I have a problem with bug reports and changelogs writing things as "improved error handling", "made more robust" or "add security to" which are too often used to hide the real security impact of certain bugs. DJB's policy of "it is not my bug to fix, because it is an operating system bug" is also completely bogus from a system administrator point of view who still ends up with a security problem.
indeed. you can ignore what you want. You can only create your own "secure entry point" that override a parental DNSKEY if you would want to (Think China removing.tw entries). Anyone who controls a resolver can do this. It's a one line configuration change.
The only reason Network Solutions will stop domain tasting ("we will protect you for money, or else we will have your knee cap") is because ICANN is putting a stop to it. They never "protected" customers, they reamed in the profits of domain tasting.
and as long as people still pay $35/year to them for domains because they don't know the old monopoly has died, NetSol will play games like these to cash in on that. Just like they sent former customers those fake "renewal" invoices to try and fraud people into going back to them.
As Morrisey's song goes, "The world is not America". DNSSEC deployment is already happenening on Large Scale.
djdns refuses to fix his code to protect against OS errors as "not his job". That makes that DNS software pretty useless. powerdns is fuly mysql driven, and uses a record, not a zonefile as their basic unit. DNSSEC will break that. That's why they do not like it.
People say things will break, but things are broken already. If someone has a better fix, please step forward. Whining and doing nothing is not an option, and people who whine about DNSSEC not being the right solution have done nothing for 10 years, so they have become part of the DNSSEC solution as a result. Note that no one has broken the protocol or principles behind DNSSEC. At most people say "It's too hard". That's what people said about SSL too.
DNSSEC has been deployed, and will be the protocol protecting your DNS. Get over it.
Google has SPF records. Sourceforge seems to reject mail that seems spoofed (eg people 'pretending' to be allowed to send user@gmail.com mail without going through google.
It's neither sourceforge's fault not google's fault. It's the enduser's fault. You must send/receive email through google's gmail system.
raceroute to 208.67.222.222 (208.67.222.222), 30 hops max, 38 byte packets
1 router.openswan.xtdnet.nl (193.110.157.158) 256.697 ms 0.638 ms 0.318 ms
2 384.ae0.cr1.3d12.xs4all.net (82.94.242.233) 58.937 ms 22.735 ms 41.513 ms
3 0.so-1-2-0.xr1.3d12.xs4all.net (194.109.5.57) 0.856 ms 0.917 ms 75.493 ms
4 194.151.244.74 (194.151.244.74) 1.123 ms 2.135 ms 0.767 ms
5 195.190.233.248 (195.190.233.248) 1.572 ms 1.916 ms 1.542 ms
6 195.190.233.249 (195.190.233.249) 1.654 ms 2.047 ms 1.504 ms
7 asd2-rou-1021.NL.eurorings.net (134.222.228.14) 1.318 ms 1.820 ms 1.359 ms
8 nyk-s1-rou-1001.US.eurorings.net (134.222.231.230) 86.985 ms 87.364 ms 87.055 ms
9 nyk-s1-rou-1003.US.eurorings.net (134.222.230.98) 87.026 ms 87.584 ms 87.066 ms 10 sl-gw40-nyc-0-0.sprintlink.net (160.81.182.129) 82.005 ms 82.046 ms 81.675 ms 11 sl-bb20-nyc-3-0.sprintlink.net (144.232.13.51) 82.030 ms 82.309 ms 81.963 ms 12 204.255.174.225 (204.255.174.225) 83.129 ms 83.374 ms 82.873 ms 13 0.ge-5-0-0.XL4.NYC4.ALTER.NET (152.63.3.117) 83.387 ms 83.487 ms 83.134 ms 14 0.so-6-0-0.XL2.NYC4.ALTER.NET (152.63.20.214) 83.444 ms 83.459 ms 83.202 ms 15 POS7-0.GW2.NYC4.ALTER.NET (152.63.19.225) 83.602 ms 83.376 ms 83.120 ms 16 splicetelecom-NewYork-gw.customer.alter.net (157.130.14.214) 83.863 ms 83.907 ms 83.902 ms 17 resolver1.opendns.com (208.67.222.222) 86.260 ms 86.110 ms 88.797 ms
It doesnt seem to actually terminate somewhere in Europe at all.
Traceroute from Canada:
1 brick (209.112.44.1) 0.195 ms 0.108 ms 0.107 ms
2 216.191.140.37 (216.191.140.37) 1.169 ms 1.047 ms 0.986 ms
3 syn (216.13.88.149) 667.916 ms 630.618 ms 602.319 ms
4 fe11-0-0.hcap2-tor.bb.allstream.net (216.191.48.1) 648.830 ms 621.588 ms 659.484 ms
5 srp2-0.gwy1-chi.bb.allstream.net (199.212.160.243) 726.753 ms 654.081 ms 599.996 ms
6 POS5-0.GW5.CHI1.ALTER.NET (157.130.115.117) 656.960 ms 769.177 ms 793.922 ms
7 0.so-1-0-0.XL1.CHI1.ALTER.NET (152.63.70.78) 854.671 ms 26.646 ms 121.226 ms
8 0.so-3-1-0.XL1.NYC4.ALTER.NET (152.63.1.50) 35.634 ms 53.774 ms 48.509 ms
9 POS6-0.GW2.NYC4.ALTER.NET (152.63.19.221) 36.545 ms 175.197 ms 141.500 ms 10 splicetelecom-NewYork-gw.customer.alter.net (157.130.14.214) 224.545 ms 651.278 ms 553.703 ms 11 resolver1.opendns.com (208.67.222.222) 613.281 ms 645.959 ms 678.715 ms
Not too good either. And they both end at the same server, wit hthe same ip and similar hops, so it doesn't look like it is anycast at all.
And no mentioning whatsoever on how they blacklist typo/squat/phishing DNS.
I'll put my trust in my ISP now, and in DNSSEC in the near future.
Dutch courts assign legal costs. It is never more then a few thousand. It does not mean that any party involved hired a fucking expensive laywer. Those are not reimbursed. It's like renting a hellicopter to go to court. You only get travel expenses paid based on normal transportation.
It makes sense, Scientology has gotten millions of theoretical damages just in legal fees. It denies a citizen the right to use the legal system.
DNSSEC is long overdue. We not only need to secure our domains, we also need a secure placeholder for cryptographic information that's hierarchical. DNSSEC is the answer for that.
If you think DNSSEC is vapourware, your information is outdated. As I presented in various talks this year at BlackHat, DefCon and CCC this year, DNSSEC is ready to be deployed, and IS deployed.
We are currently running over 150 domains in DNSSEC, using bind9 and some perl tools written by RIPE. We are using this to accomplish IPsec Opportunistic Encryption, which means massive deployment of IPsec tunnels by using secured DNS information for key material. Please see:
DNSSEC is not vapourware. It will happen, and you want it to happen. Think about VOIP using the ENUM dnszone without DNSSEC. Do you WANT your phonecalls to be hijacked?
You do not have to trust anyone you dont trust. You can use truted-key statements to create "Secure entry points". You can trust.nl's key for.nl and you can decide not to trust the key for "." or ".com" if you don't trust them.
Funny that. Currently, a whole/24 is tunneled over a completely dynamic IP for use at IETF next week. I am tunneling that/24 to a key, or a FQDN name with a KEY or TXT record. On top of that, we're about to roll out DNSSEC in.nl, and adding freeswan.nl to it.
So, if the "dynamic ip" issue is the only reason to use Aggressive Mode, then surely AM is obsoleted and indeed rightdully is not implemented.
If you had followed the entire debate, you know that these "relaxations" are declarations (yes, those like a King makes), and can be withdrawn by Bush at any time, without any democratic process. That's why Gilmore and Daniel are taking the stance they are taking.
Crypto is your fundamental right, not a fluffy allowance from your Emperor.
Too bad that full ipsec, such as provided by Freeswan is still not in the kernel. I find it a bit sad that Dave Miller and John Gilmore can't figure out a proper way to resolve their problem
(John wants no US hands on the code, Dave wants
no code he can't touch in the kernel)
But at least the beginning is there, and if the USAGI ipsec gets in, it should learn to talk to the userland tools, such as Freeswan, because Freeswan has extra features that "stock ipsec" doesn't have, such as Opportunistic Encryption.
It is about - Getting rid of Verisign in the.org deal - Getting rid of Verisign before they get the 3
year on.net and 5 year on.com names - Getting rid of a company that is going bankrupt
and is highly fraudulent (snapnames, bogus
invoices etc) - ICANN itself getting out of the spotlight for
firing its At Large Directors
Eric Raymond has written Bogofilter that implements Paul Graham's idea. I've created a
Badwords list for use with bogofilter seeded with my entire spam collection of four years.
I read the
CNN
article and went to the download site. I downloaded the file from thaiware.com.
I created a "testuser", chmod a+rw/dev/dsp* and ran the thing. It seems like it's doing absolutely nothing. Though I'm curious was the experts can say about the strace
Makes you wonder what the Windows version does. Too bad. I could use a working solution:(
Slashdot Mirror
Many people use an IM add-on called Off-the-Record. On top of encryption, it also provides deniability by not proving any digital signatures for the other party to present to a court, and the procol ensures everyone can make false messages in the past. How strong do you this technical protection would be from a legal perspective if one of the two parties has a logfile with all messages?
I strongly recommend using GKG.net, as they have the best (automated) XML interface that I know of. See their documentation
InternetX also has a good interface, but it is a little more complex to get going.
Those, as well as GoDaddy, which you can only process using ugly web scraping with BeautifulSoup and Mechanize, were the first ones we supported in our DNSSEC Signer product.
Paul Wouters, DNSSEC Evangelist at Xelerance
It's 4 out of 7 to get the key that can decrypt the backup. The backup is not in the hands of the 7,so they cannot do anything by themselves!
Three years to deploy RFC 4956 is not "technical reasons"
Powerdns was vulnerable to the Kaminsky attack, but in a different way. It was actually easier to spoof the server due to its more actively dropping certain DNS packets. So while it did perform source port randomization, it was not totally immune to the attack either.
http://doc.powerdns.com/security-policy.html itself states:
All versions of PowerDNS before 2.9.21.1 do not respond to certain queries. This in itself is not a problem, but since the discovery by Dan Kaminsky of a new spoofing technique, this silence for queries PowerDNS considers invalid, within a valid domain, allows attackers more chances to feed *other* resolvers bad data.
Though it is phrased as "someone elses problem", in the DNS word of course nothing is "someone elses problem". DNS servers are chained in hierachies and one problem somewhere leads to problems elsewhere. DNS is all about protocol compliance to ensure interoperability. With the "someone elses problem" approach, we would have had no "reflection attack" and "amplification attack" problems either, it being "someone elses problem". Despite the nice phrasing, powerdns caused cache poisoning problems as a result of the Kaminsky attack that needed to be addressed.
In general, I have a problem with bug reports and changelogs writing things as "improved error handling", "made more robust" or "add security to" which are too often used to hide the real security impact of certain bugs. DJB's policy of "it is not my bug to fix, because it is an operating system bug" is also completely bogus from a system administrator point of view who still ends up with a security problem.
that sounds more like Guild Heighliner technology where they Fold Space.
"travel to any part of the universe, without moving".
It also avoids the acceleration/deceleration with WARP speeds :P
I was not here, I did not say this.....
indeed. you can ignore what you want. You can only create your own "secure entry point" that override a parental DNSKEY if you would want to (Think China removing .tw entries). Anyone who controls a resolver can do this. It's a one line configuration change.
The root key is not Sauron's Ring
you want a 3-way handshake per dns lookup? Are you crazy? Do you even know how many dns lookups your browser creates on average.
You'd be looking at 10 seconds delay for a webpage like slashdot easilly
Stupid sensationalism.
You can right now use draft-vixie-dnsex-dns0x20 to protect against the kaminsky bug. This option is already available in the unbound nameserver.
Talking about totally talking out of context. Fools!
If IETF does something to mitigate, the unbelievers scream "see we dont need dnssec"
If IETF does not do something, the unbelievers scream "you're blackmailing us into dnssec"
Stop whining and put your foot where your mouth is.
The only reason Network Solutions will stop domain tasting ("we will protect you for money, or else we will have your knee cap") is because ICANN is putting a stop to it. They never "protected" customers, they reamed in the profits of domain tasting.
and as long as people still pay $35/year to them for domains because they don't know the old monopoly has died, NetSol will play games like these to cash in on that. Just like they sent former customers those fake "renewal" invoices to try and fraud people into going back to them.
As Morrisey's song goes, "The world is not America".
DNSSEC deployment is already happenening on Large Scale.
djdns refuses to fix his code to protect against OS errors as "not his job". That makes that DNS software pretty useless.
powerdns is fuly mysql driven, and uses a record, not a zonefile as their basic unit. DNSSEC will break that. That's why they do not like it.
People say things will break, but things are broken already. If someone has a better fix, please step forward. Whining and doing nothing is not an option, and people who whine about DNSSEC not being the right solution have done nothing for 10 years, so they have become part of the DNSSEC solution as a result. Note that no one has broken the protocol or principles behind DNSSEC. At most people say "It's too hard". That's what people said about SSL too.
DNSSEC has been deployed, and will be the protocol protecting your DNS. Get over it.
mirrored on Es3b-en.pdf
Google has SPF records. Sourceforge seems to reject mail that seems spoofed (eg people 'pretending' to be allowed to send user@gmail.com mail without going through google.
It's neither sourceforge's fault not google's fault. It's the enduser's fault. You must send/receive email through google's gmail system.
You get what you pay for.....
A traceroute from Amsterdam:
raceroute to 208.67.222.222 (208.67.222.222), 30 hops max, 38 byte packets
1 router.openswan.xtdnet.nl (193.110.157.158) 256.697 ms 0.638 ms 0.318 ms
2 384.ae0.cr1.3d12.xs4all.net (82.94.242.233) 58.937 ms 22.735 ms 41.513 ms
3 0.so-1-2-0.xr1.3d12.xs4all.net (194.109.5.57) 0.856 ms 0.917 ms 75.493 ms
4 194.151.244.74 (194.151.244.74) 1.123 ms 2.135 ms 0.767 ms
5 195.190.233.248 (195.190.233.248) 1.572 ms 1.916 ms 1.542 ms
6 195.190.233.249 (195.190.233.249) 1.654 ms 2.047 ms 1.504 ms
7 asd2-rou-1021.NL.eurorings.net (134.222.228.14) 1.318 ms 1.820 ms 1.359 ms
8 nyk-s1-rou-1001.US.eurorings.net (134.222.231.230) 86.985 ms 87.364 ms 87.055 ms
9 nyk-s1-rou-1003.US.eurorings.net (134.222.230.98) 87.026 ms 87.584 ms 87.066 ms
10 sl-gw40-nyc-0-0.sprintlink.net (160.81.182.129) 82.005 ms 82.046 ms 81.675 ms
11 sl-bb20-nyc-3-0.sprintlink.net (144.232.13.51) 82.030 ms 82.309 ms 81.963 ms
12 204.255.174.225 (204.255.174.225) 83.129 ms 83.374 ms 82.873 ms
13 0.ge-5-0-0.XL4.NYC4.ALTER.NET (152.63.3.117) 83.387 ms 83.487 ms 83.134 ms
14 0.so-6-0-0.XL2.NYC4.ALTER.NET (152.63.20.214) 83.444 ms 83.459 ms 83.202 ms
15 POS7-0.GW2.NYC4.ALTER.NET (152.63.19.225) 83.602 ms 83.376 ms 83.120 ms
16 splicetelecom-NewYork-gw.customer.alter.net (157.130.14.214) 83.863 ms 83.907 ms 83.902 ms
17 resolver1.opendns.com (208.67.222.222) 86.260 ms 86.110 ms 88.797 ms
It doesnt seem to actually terminate somewhere in Europe at all.
Traceroute from Canada:
1 brick (209.112.44.1) 0.195 ms 0.108 ms 0.107 ms
2 216.191.140.37 (216.191.140.37) 1.169 ms 1.047 ms 0.986 ms
3 syn (216.13.88.149) 667.916 ms 630.618 ms 602.319 ms
4 fe11-0-0.hcap2-tor.bb.allstream.net (216.191.48.1) 648.830 ms 621.588 ms 659.484 ms
5 srp2-0.gwy1-chi.bb.allstream.net (199.212.160.243) 726.753 ms 654.081 ms 599.996 ms
6 POS5-0.GW5.CHI1.ALTER.NET (157.130.115.117) 656.960 ms 769.177 ms 793.922 ms
7 0.so-1-0-0.XL1.CHI1.ALTER.NET (152.63.70.78) 854.671 ms 26.646 ms 121.226 ms
8 0.so-3-1-0.XL1.NYC4.ALTER.NET (152.63.1.50) 35.634 ms 53.774 ms 48.509 ms
9 POS6-0.GW2.NYC4.ALTER.NET (152.63.19.221) 36.545 ms 175.197 ms 141.500 ms
10 splicetelecom-NewYork-gw.customer.alter.net (157.130.14.214) 224.545 ms 651.278 ms 553.703 ms
11 resolver1.opendns.com (208.67.222.222) 613.281 ms 645.959 ms 678.715 ms
Not too good either. And they both end at the same server, wit hthe same ip and similar hops, so it doesn't look like it is anycast at all.
And no mentioning whatsoever on how they blacklist typo/squat/phishing DNS.
I'll put my trust in my ISP now, and in DNSSEC in the near future.
Nice to see Openbsd got previous warning, unlike other opensource implementations who got a 0day.......
Response from the Openswan team: Not vulnerable
It is valid!
Dutch courts assign legal costs. It is never more then a few thousand. It does not mean that any party involved hired a fucking expensive laywer. Those are not reimbursed. It's like renting a hellicopter to go to court. You only get travel expenses paid based on normal transportation.
It makes sense, Scientology has gotten millions of theoretical damages just in legal fees. It denies a citizen the right to use the legal system.
If you think DNSSEC is vapourware, your information is outdated. As I presented in various talks this year at BlackHat, DefCon and CCC this year, DNSSEC is ready to be deployed, and IS deployed.
We are currently running over 150 domains in DNSSEC, using bind9 and some perl tools written by RIPE. We are using this to accomplish IPsec Opportunistic Encryption, which means massive deployment of IPsec tunnels by using secured DNS information for key material.
Please see:
DNSSEC is not vapourware. It will happen, and you want it to happen. Think about VOIP using the ENUM dnszone without DNSSEC. Do you WANT your phonecalls to be hijacked?
You do not have to trust anyone you dont trust. .nl's key for .nl and you can decide not to trust the key for "." or ".com" if you don't trust them.
You can use truted-key statements to create "Secure entry points". You can trust
Funny that. Currently, a whole /24 is tunneled /24 to a key, or a FQDN .nl, and adding freeswan.nl to it.
over a completely dynamic IP for use at IETF next week. I am tunneling that
name with a KEY or TXT record. On top of that, we're about to roll out DNSSEC in
So, if the "dynamic ip" issue is the only reason to use Aggressive Mode, then surely AM is obsoleted and indeed rightdully is not implemented.
If you had followed the entire debate, you know
that these "relaxations" are declarations (yes,
those like a King makes), and can be withdrawn by Bush at any time, without any democratic process.
That's why Gilmore and Daniel are taking the stance they are taking.
Crypto is your fundamental right, not a fluffy
allowance from your Emperor.
Too bad that full ipsec, such as provided by
Freeswan is still not in the kernel. I find it a
bit sad that Dave Miller and John Gilmore can't
figure out a proper way to resolve their problem
(John wants no US hands on the code, Dave wants
no code he can't touch in the kernel)
But at least the beginning is there, and if the
USAGI ipsec gets in, it should learn to talk to the userland tools, such as Freeswan, because Freeswan has extra features that "stock ipsec" doesn't have, such as Opportunistic Encryption.
It is about .org deal .net and 5 year on .com names
- Getting rid of Verisign in the
- Getting rid of Verisign before they get the 3
year on
- Getting rid of a company that is going bankrupt
and is highly fraudulent (snapnames, bogus
invoices etc)
- ICANN itself getting out of the spotlight for
firing its At Large Directors
Leto
I created a "testuser", chmod a+rw /dev/dsp* and ran the thing. It seems like it's doing absolutely nothing. Though I'm curious was the experts can say about the strace
Makes you wonder what the Windows version does. Too bad. I could use a working solution :(