So I lied. It wasn't my last response on the subject. Lutz Donnerhacke wrote on 02/16/2007 01:13:40 PM:
* Roy Arends wrote:
Lutz Donnerhacke wrote on 02/16/2007 11:40:14 AM:
You can't update the installed base quick enought to gain the benefits of DNSSEC. If the recursing resolvers do not validate, the whole DNSSEC effect is going to zero. You will find about 100000 validating resolvers at end user sites and nobody will sign a zone for this group of geeks.
Ah, you're assuming that folk will en-masse sign their zones for the handfull of validating resolvers ?
Yes. See the reactions to the last announcement of a Swedish ISP.
So folks with domains under '.se' are signing their zone en-masse ? Haven't seen those reactions.
Meanwhile, my OS/X and windows boxes are configured (by default) to update itself regularly. Some of my applications do that as well. My browsers have validation intergrated. Joe end user would not even see the difference.... but he's better off than before.
He will see a difference, if some spoofing attacks does not longer work.
Stub resolvers can be spoofed trivially. resolver code in dsl routers/cable modems can be spoofed trivially. So, unless the end-user has dnssec deployed locally, spoofing attacks work.
I don't really expect any demand from end-users in general.
I see a strong demand from commercial banking institutes (not really). Let's assume some major DSL-ISPs does switch on validating. This results in a trusted DNS for about 60% of there customers (may be more). Now consider the phishing buzzword.
security theater. Nothing really changes for the end user. Those who tried to spoof resolvers will now change their focus towards the end-users stub. Arms race.
That leaves us with pushing code to the end user, in applications and OS, which implies coorperation from and education to software developers.
Taking this road means: Redo from start.
It _is_ done from the start. We've put in the current standards. Applications can already use. My jabber server uses it. Validation on a stub.
Never get a reasonable deployment. Root will not be signed, because there are not enough installations. More installations will not come up, because the root is not signed and key maintainence is a mess. Catch-22.
That is the _current_ status quo. not enough installations have 'switched on' dnssec, so why bother signing. why bother switching on dnssec if not enough domains are signed.
I can't see your point here.
acl's, firewalls, etc, that decide on source ip address if it can query your resolver. I can circumvent that.
How do you want to do this?
I scan a range, a few boxes will do a reverse lookup. I control the specific reverse address space, hence your resolver is talking to me: window of opportunity. Another way is spraying spam around, antispam code resolve whatever I tell it to resolve. This reminds to finish my article about intrusion detection detection (sic) methods, and develop some anti intrusion detection dection (sic) methods.
Please respond by email directly, it's off-topic.
Well. Others might be interested in this as well, so, there.
You are a geek. But you spoke about end users. And they trust their ISP for the data they received from him.
I'd advice joe end user to validate locally.
They are free to do so. They are free to use any nameserver they want. But if they use the ISP's recursive resolver, this will be a validating one.
Just as I'd advice them validate certificates (which browsers do automagically). Are you saying that end users should blindly trust
http connection, just because it come via their ISP, or the ISP's
What is the use of seeing a bit set in the response that claims that the response is validated, when I can't trust the link !!!!!!! their proxy?
No, you confuse the source of the data.
eh ?
The ISP can validate the integrity of DNSSEC-signed zones, and it is good to do so.
The ISP can't validate the integrety of HTTPS certificates, because the protocols does not show
The ISP can validate the integrity, sure. To me that would be another middlebox fondling with the data. them to
him without serveral crude hacks.
So, basically, if the https protocol would allow it, ISP's like to validate the integrity of certificates as well.... so end users don't have to ? Roy