:)
2010/2/17 Phillip Hallam-Baker <hallam@xxxxxxxxx>
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 <dol@xxxxxxxxxxxx> 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@xxxxxxxx
> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf