http://tools.ietf.org/html/draft-dempsky-dnscurve-01
There is an urgent need to solve the DNS security issues within a reasonable period of time.
Please remember the Kaminsky dns bug did not identify a security problem with the DNS but the UDP transport. DNScurve fixes the problem today without having to spend 15 more years getting it right.
And it does not cost a fortune to implement. DNSSEC is more of a make work project then it is a solution. And DNSSEC does not solve the UDP issue. And that is the problem DNScurve fixes NOW.
If there is any common sense left at the IETF. And I think there are sparks here and there. Then I strongly recommend IETF members get DNScurve established as RFC. We need leadership - not more DNSSEC blah blah blah.
Together let's exercise some common sense and support draft-dempsky-dnscurve-01.
regards
joe baptista
On Thu, Feb 25, 2010 at 3:01 PM, Phillip Hallam-Baker <hallam@xxxxxxxxx> wrote:
Who are these 'security researchers' of whom you speak? I am a
principal in the security field, if you want to contradict me then you
should either say that something is your personal opinion or you
should specify the other parties you are referring to.
The reason that I want to see what the key registration process is
going to look like is precisely because the validation process
matters. It is the reason that I sent out the invitations to the
original meeting that started the process that created EV
certificates.
Moving to DNSSEC, regardless of the technical model does not eliminate
the need for certificates or CAs. The purpose of EV certificates is to
re-establish the principle of accountability.
You can design a PKI to meet many different needs. Identity is one
purpose, but not a very useful one. Which is the real reason that
identity systems are so hard to deploy. If you want security from a
PKI you will do better with a validation system that provides
accountability.
I use words very carefully. I know that you can use SSH keys protected
by DNSSEC. But at the moment there is not a complete proposal for a
Secure DNS system. Key parts of that system are being left to chance
and that is why the prospects for an alternative system are much
better than you imagine.
On Thu, Feb 25, 2010 at 11:55 AM, Paul Wouters <paul@xxxxxxxxxxxxx> wrote:
> On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote:
>
>> But SSH would be much better if we could integrate the key
>> distribution into a secured DNS.
>
> See previous post. Already done and running.
>
>> And self-signed SSL certs would be
>> better if we could use hash values distributed through a secured DNS
>> to verify them.
>
> Yes. The CERT/CERTQ record is still a bit of a problem and needs some
> work.
>
>> If DNSSEC succeeds, the domain validated certificate business will
>> have to either transform or eventually die. I think that for most CAs,
>> the business opportunities from SSL+DNSSEC are greater than the
>> opportunities from the current DV SSL business. DNSSEC cannot deploy
>> unless the registrars have cryptography expperience, the CAs have that
>> experience.
>
> If you ask security researchers, it has been proven that CA's sacrificed
> security for profitability. The CA model has failed to work. 2 second
> validation based on email, md5 based * root certificates signed, etc etc.
> The last two years saw a significant amount of attacks against CA's, and
> CA's have seen their profit margin fall to near zero, so even if they
> wanted to, they cannot increase security (you ask me a confirmation for
> my cert, I'll go to this other ssl provider that doesn't).
>
> CERT's in DNS(SEC) put the responsibility of the cert within the domain of
> the customer. If they care, they can do their security. The time of
> outsourcing security to CA's is over.
>
> Paul
>
--
--
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