I just want to remind everyone that a DNScurve draft is on the table.
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(_at_)gmail(_dot_)com>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(_at_)xelerance(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf