I was attempting to refer to the fact you considered the break
noteworthy rather than that you were the source, my apologies if that
was not clear.
I think we do need to change the DNS model. But not necessarily as
drastically as DNScurve and not to get rid of caching.
I would like to see us create an assumption that a given machine will
only use recursive resolution services from a specific trusted source.
This in turn requires us to add some features to the protocol as we
need to add mechanisms for access control. We also need to make some
changes to get around widespread DNS hacks used to support roaming
WiFi provision.
[Oh we are so not close to being done with deployment here. If turning
on DNSSEC means the typical Web surfer cannot get their WiFi access at
Panera without reconfiguring their machine then DNSSEC is stone cold
dead.]
Rather than using the approach in DNScurve, I would want to see
something like the following:
* When a new machine is brought up the configurer is asked which
network they want it to be a part of, identified by a DNS name. This
will be the place that the system will use to look for the trusted DNS
resolution service. Since I use 8.8.8.8 I would enter 'google.com'.
The default could be taken from DHCP
* New RR to allow a machine to locate a trusted resolution service for
the network and authentication protocols supported. The initial
bootstrap could be taken from the DHCP service.
* Key agreement mechanism that allows the client to establish a
persistent binding represented by a kerberos style ticket
* Packet encapsulation mechanism that enables a kerberos style ticket
to be entered into client request packets.
The situation we have at the moment is similar to the one you get with
a large tub of lego. We have all the pieces we need, but they are
mixed in with a much larger amount of stuff that we don't really need.
Telling people they can build this from IPSEC, Kerberos and SASL is
like telling people they can do brain surgery if they read some
wikipedia articles.
On Wed, Feb 24, 2010 at 2:29 PM, Steven M. Bellovin
<smb(_at_)cs(_dot_)columbia(_dot_)edu> wrote:
On Wed, 24 Feb 2010 12:44:10 -0500
Phillip Hallam-Baker <hallam(_at_)gmail(_dot_)com> wrote:
The problem here is not that you might infringe the patent, the
problem is that if a patent suit is brought against you, it will cost
a minimum of about $5 million to defend. Just to get to the point of
having an opinion on the matter you would have to engage a competent
expert witness who was willing to work on patent stuff rather than
building stuff. Then they have to do maybe a months work on research
and explain the results to a group of lawyers. You are going to have
five or more people and rack up several thousand hours at lawyer
rates.
Those costs buy a lot of crypto accelerator boards.
I kept trying to explain this situation to the various people who
tried to sell their 'efficient CRL' hacks. Even if your system is the
greatest ever and you give it to me for free, it will cost more to
work out if it is legally safe than it costs to solve the problem with
raw CPU power.
If the 512 byte limit really is a problem, then the logical answer
would be to use DSA-SHA256 since the signatures generated in DSA are
not a function of the key size. DSA also allows for offline
calculation of the signature data which would address performance
issues for companies like Akamai.
There are also reasons to beware of DSA. Steve Bellovin pointed out
that if the random number generator is bad the private key can leak
out. But RSA is not without similar issues, companies that can't
generate a good random seed for DSA will probably not create secure
keypairs for RSA either.
I've pointed it out in the IETF, but I'm certainly not the one who came
up with that observation in the first place; please do not give me
credit for other folks' work.
More on-topic: unless I'm very much mistaken, DNScurve relies on
transmission security rather than object security; in turn, that
requires a pretty fundamental change in how the DNS works. (Well, not
completely, but you wouldn't gain any security benefit against most of
the threats from cache contamination if you didn't change it.) Maybe
the DNS can work that way or should work that way -- but I haven't seen
any analysis to show that the load is manageable without caching and
with lots of banging on the authoritative servers.
--
--
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