So we have totally abandoned the idea of doing DNSSEC in the end point client?
Trust roots have to be valid for at least a decade to be acceptable to
the application vendor community.
And even though the current model of network administration is to
constantly fiddle with everything, I think
I agree the resources are non-trivial
But it creates a put-up or shut-up point for the non-US objectors to
the sole US controlled root. What it does not do is to address the
state dept concerns that the root is a liability. And the cost of
setting up an apex authority are much less than the cost
On Thu, Jun 11, 2009 at 10:34 PM, Mark Andrewsma...@isc.org wrote:
In message a123a5d60906111838t460ca168l9cf797a486ec1...@mail.gmail.com,
Phill
ip Hallam-Baker writes:
So we have totally abandoned the idea of doing DNSSEC in the end point clie=
nt?
Trust roots have to be valid for at
These are assertions, not facts.
PKI is demonstrated to be effective in the reduction and management of
risk, that is what it is designed to do and that is how I define the
term 'security'.
On Fri, Jun 12, 2009 at 8:19 AM, Masataka
Ohtamo...@necom830.hpcl.titech.ac.jp wrote:
Phillip
Past history is no guarantee of future performance.
A pattern we see repeated over and over again is that a new control on
some form of Internet crime leads to a dramatic short term reduction
even though the control merely increases the cost of crime, not
eliminates the capability. This is the
Past history is a good indicator of problems that may arise.
Past history is a very bad guarantee that problems will not arise in the future.
On Fri, Jun 12, 2009 at 7:54 PM, Masataka
Ohtamo...@necom830.hpcl.titech.ac.jp wrote:
Phillip Hallam-Baker wrote:
Past history is no guarantee of
Or alternatively,
Be liberal in anticipating repeat of past problems, be conservative in
your expectation that new problems will not arise.
On Fri, Jun 12, 2009 at 8:21 PM, Phillip Hallam-Bakerhal...@gmail.com wrote:
Past history is a good indicator of problems that may arise.
Past history is
It is very clear that at least part of this discussion is due to your
unfamiliarity with English.
Looking at past failures is a very good way to predict the possibility
of similar failures in the future. History is a very good guide to
setting a lower bound on risk.
History is a very poor guide
* Phillip Hallam-Baker:
OK, how do you do that if the ICANN root is baked into your broadband
router? How about a light switch?
Nowadays, there are software update protocols for broadband routers,
too.
You can change the signing key, but distributing and embedding the
verification key is a
Phillip Hallam-Baker wrote:
Past history is a very bad guarantee that problems will not arise in the
future.
So, you mean your statement:
: Trust roots have to be valid for at least a decade to be acceptable to
: the application vendor community.
hardly guarantee anything.
Be liberal in
* Joe Baptista:
DNSCurve encrypts all DNS packets.
Ahem, this part of the protocol has not been specified so far.
Encryption is not mentioned on the dnscurve.org pages, only key
exchange, and even that is not fully disclosed.
___
Ietf mailing list
Phillip Hallam-Baker wrote:
It is very clear that at least part of this discussion is due to your
unfamiliarity with English.
As you said
: Please learn to express your opinions in a manner that is appropriate
: to a professional forum rather than a bar room brawl.
: You are entitled to your
At 10:32 PM -0400 6/11/09, David Conrad wrote:
Hi,
On Jun 11, 2009, at 8:35 PM, Stephen Kent wrote:
But, in a DNSSEC environment, IANA performs two roles:
- it coordinates the info from the gTLDs and ccTLDs and constructs
the authoritative root zone file
- it signs
Phillip Hallam-Baker wrote:
Trust roots have to be valid for at least a decade to be acceptable to
the application vendor community.
? ? ? ?That's a unproved assumption.
It is an observation backed by fifteen years of experience and direct
conversations with the principals for cryptographic
Phillip Hallam-Baker wrote:
These are assertions, not facts.
The fact is that since 1987, DNS has been mostly secure.
that is what it is designed to do and that is how I define the
term 'security'.
You did not simply say security but said cryptographic security.
Phillip Hallam-Baker wrote:
Past history is no guarantee of future performance.
Is your argument applicable to the following statement you just made
yesterday?
: Trust roots have to be valid for at least a decade to be acceptable to
: the application vendor community.
A pattern we see
At 10:41 AM +1000 6/11/09, Mark Andrews wrote:
In message p06240803c65430cf6...@[10.10.10.117], Stephen Kent writes:
Joe,
You have argued that DNSSEC is not viable because it requires that
everyone adopt IANA as the common root.
Which isn't even a requirement. Alternate root providers
Phil,
That's a specious argument. As several others have noted on this list,
it's perfectly feasible for any relying parties (sovereign nations or
otherwise) to not use the IANA root, simply by creating their own root.
This is a little more complicated than just redirecting IP traffic,
but
It is possible for people set their own roots, but it is not very
practical to maintain them. And this is going to be particularly
difficult if we ever get DNSSEC deployed in platform distributions and
end-entities are configured to check their own DNS chains up to a
baked-in ICANN root.
It is
OK, how do you do that if the ICANN root is baked into your broadband
router? How about a light switch?
Yes in theory I can reverse engineer the code. In practice this is not
practical. In theory the music industry could set up their own
alternative to iTunes, in practice they have no choice but
In message a123a5d60906110800i58353c99wc6b16a50395dc...@mail.gmail.com, Phill
ip Hallam-Baker writes:
OK, how do you do that if the ICANN root is baked into your broadband
router? How about a light switch?
Given that the ICANN root servers have a history of changing
address I
Phil,
The examples you give about backed-in trust anchors are valid, but
they point to decisions by vendors to simplify their designs at the
cost of secruity and functionality. I've been told that it is very
hard, if not impossible, to permanently remove some vendor-supplied
TAs in a popular
Hi,
On Jun 11, 2009, at 8:35 PM, Stephen Kent wrote:
But, in a DNSSEC environment, IANA performs two roles:
- it coordinates the info from the gTLDs and ccTLDs and
constructs
the authoritative root zone file
- it signs the records of that file
Nope. Just to
In message a123a5d60906111838t460ca168l9cf797a486ec1...@mail.gmail.com, Phill
ip Hallam-Baker writes:
So we have totally abandoned the idea of doing DNSSEC in the end point clie=
nt?
No. Recursive nameserver need to validate the answers
returned from the DNS for their own uses.
Joe,
You have argued that DNSSEC is not viable because it requires that
everyone adopt IANA as the common root. I agree that under the
current IANA management situation many folks may be uncomfortable
with IANA as the root. However, in practice, the world has lived
with IANA as the root
Steve,
The sovereign nations that object to US control of the root are
willing to accept the current status quo preciely because they have an
exit option. Should the US defect on its obligations and order ICANN
to drop Cuba or Palestine out of the root or to take any other action
that was
In message p06240803c65430cf6...@[10.10.10.117], Stephen Kent writes:
Joe,
You have argued that DNSSEC is not viable because it requires that
everyone adopt IANA as the common root.
Which isn't even a requirement. Alternate root providers just need
to get copy of the root zone with DS
Masataka-san
Please learn to express your opinions in a manner that is appropriate
to a professional forum rather than a bar room brawl.
You are entitled to your opinion but not to converse in the abusive
and insulting manner you have chosen to use if you wish to receive a
reply.
The link you
Andrew Sullivan a...@shinkuro.com writes:
On Fri, Jun 05, 2009 at 08:10:55AM +0900, Masataka Ohta wrote:
In general, registries welcome DNSSEC, no matter how secure it is,
as long as its complicated operation works as an excuse to increase
(or not to reduce) registration charge and
Shane Kerr wrote:
If you mean COM zone, it is not necessary to inject any data into
the zone.
You, instead, can inject a forged certificate into some cache used
by your victim.
You said transport security can help. How can it in this case?
With plain old DNS, zone administrators have to make
Subject: Re: DNSSEC is NOT secure end to end Date: Mon, Jun 08, 2009 at
11:25:36AM +0200 Quoting Simon Josefsson (si...@josefsson.org):
The organization operating .SE charges for DNSSEC. According to [1] it
costs 250 SEK annually (~22 EUR or ~30 USD) extra per year to protect a
domain name
Simon Josefsson wrote:
Andrew Sullivan a...@shinkuro.com writes:
In general, registries welcome DNSSEC, no matter how secure it is,
as long as its complicated operation works as an excuse to increase
(or not to reduce) registration charge and registries' revenue.
That is a serious charge.
Mans Nilsson mansa...@besserwisser.org writes:
Subject: Re: DNSSEC is NOT secure end to end Date: Mon, Jun 08, 2009 at
11:25:36AM +0200 Quoting Simon Josefsson (si...@josefsson.org):
The organization operating .SE charges for DNSSEC. According to [1] it
costs 250 SEK annually (~22 EUR
I was at a dinner with Dave Clarke last week. Those who invoke his
name in these arguments rarely seem to have read his paper on the end
to end principle IN NETWORKING.
The end to end security argument came earlier, it is referenced as an
antecedent to lend support to the then novel idea of
Ohta-san,
On Sat, 2009-06-06 at 12:04 +0900, Masataka Ohta wrote:
Shane Kerr wrote:
I think we all understand that it is possible to inject bad data into
the DNS at the parent.
I the parent in the same sense as in RFC 1034 - the delegating level.
So, for EXAMPLE.COM this would be COM.
Phillip Hallam-Baker wrote:
Please learn to express your opinions in a manner that is appropriate
to a professional forum rather than a bar room brawl.
The link you gave was to a paywalled version of the paper. I did not
bother to read the authors once I discovered it was paywalled.
Thank
Phillip Hallam-Baker wrote:
I was at a dinner with Dave Clarke last week. Those who invoke his
name in these arguments rarely seem to have read his paper on the end
to end principle IN NETWORKING.
Which paper is, are you saying, his paper? The original one or
latter one (published in 2001)
Mark Andrews wrote:
Thus, we must, anyway, protect cache.
Then, where is the point to introduce DNSSEC only to have another
possibility of security holes?
We still lock doors and windows despite the possiblity of people
breaking in by lifting tiles.
I'm afraid DNSSEC people have been arguing
On Fri, Jun 05, 2009 at 08:10:55AM +0900, Masataka Ohta wrote:
In general, registries welcome DNSSEC, no matter how secure it is,
as long as its complicated operation works as an excuse to increase
(or not to reduce) registration charge and registries' revenue.
That is a serious charge. I've
Shane Kerr wrote:
I think we all understand that it is possible to inject bad data into
the DNS at the parent.
What do you mean the parent?
Do you mean master zone file of the parent or some caching server
expected by a client to have parent data?
What I do not understand about this comment
On Fri, Jun 5, 2009 at 8:32 AM, Masataka Ohta
mo...@necom830.hpcl.titech.ac.jp wrote:
So, let's throw away DNSSEC and the broken-from-the-beginning
idea of bailiwick. Let's move on to lock the doors and windows.
Words of wisdom. I however propose we do not throw it away. I propose it
be
Yes, security of DNSSEC is totally hop by hop.
Thus, you imply a definition of hop by hop along digital signature
relationships. Indeed, DNSSEC security is limited to the weakest link
along the chain from the bottom to the top of the DNS hierarchy. Nothing
new there. I don't think any
Ohta-san,
On Fri, 2009-06-05 at 21:32 +0900, Masataka Ohta wrote:
I mention transport security merely because it is still required
with DNSSEC, because administrative security of DNSSEC is
cryptographically weak.
I think we all understand that it is possible to inject bad data into
the DNS at
Ohta-san,
On Fri, 2009-06-05 at 22:15 +0900, Masataka Ohta wrote:
I think we all understand that it is possible to inject bad data into
the DNS at the parent.
What do you mean the parent?
Do you mean master zone file of the parent or some caching server
expected by a client to have
On Wed, 3 Jun 2009, Christian Huitema wrote:
Also, it is actually possible to improve on DNSSEC by introducing additional knowledge.
If two domains have an establish relation, their servers can memorize the relevant public
keys. If a host has a relation with a domain, it can memorize that
On Jun 3, 2009, at 12:23 AM, Christian Huitema wrote:
Yes, security of DNSSEC is totally hop by hop.
Thus, you imply a definition of hop by hop along digital signature
relationships. Indeed, DNSSEC security is limited to the weakest
link along the chain from the bottom to the top of the
Shane Kerr wrote:
I think we all understand that it is possible to inject bad data into
the DNS at the parent.
I the parent in the same sense as in RFC 1034 - the delegating level.
So, for EXAMPLE.COM this would be COM.
If you mean COM zone, it is not necessary to inject any data into
the
On Wed, Jun 03, 2009 at 03:27:42PM +0900, Masataka Ohta wrote:
Though we have to trust the zone administration put correct referral
and glue data in a master zone file, unless we use DNSSEC, we don't
have to trust the zone administration never issue certificates over
forged keys of child
So, there is no point to deploy DNSSEC.
no ?
http://jprs.co.jp/en/topics/081125.html
regards
Marc
--
Les enfants teribbles - research / deployment
Marc Manthey
Vogelsangerstrasse 97
D - 50823 Köln - Germany
Vogelsangerstrasse 97
Geo: 50.945554, 6.920293
PGP/GnuPG: 0x1ac02f3296b12b4d
Marc Manthey wrote:
So, there is no point to deploy DNSSEC.
no ?
No, no point.
http://jprs.co.jp/en/topics/081125.html
FYI, JPRS, which is a commercial entity to administrate JP domain,
is commercially motivated not to admit it merely an untrustworthy
third party.
In general, registries
Andrew Sullivan wrote:
Though we have to trust the zone administration put correct referral
and glue data in a master zone file, unless we use DNSSEC, we don't
have to trust the zone administration never issue certificates over
forged keys of child zones.
If an attacker can get its bogus data
On Jun 3, 2009, at 8:35 PM, Masataka Ohta wrote:
The problem is that the accuracy and integrity of DNSSEC is not
cryptographically, but socially secure.
DNS over UDP is prone to port/transaction-id guessing, where
cryptography could play a protective role. The risk of these values
In message 4a285750.9010...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes:
Andrew Sullivan wrote:
Though we have to trust the zone administration put correct referral
and glue data in a master zone file, unless we use DNSSEC, we don't
have to trust the zone administration never issue
Mark Andrews wrote:
A problem of blindly believing a zone administration is that it is
only as secure as blindly believing an ISP administration.
Attacking a router of a large ISPs is as easy/difficult as attacking
a signature generation mechanism of a large zone.
The difference is we
Christian Huitema wrote:
NAT routers come to mind. DNSSEC
is immune to such attacks, a big advantage in practice.
I'm afraid DNSSEC and some NAT interact terribly.
Also, it is actually possible to improve on DNSSEC by introducing
additional knowledge. If two domains have an establish
On Tue, Jun 02, 2009 at 10:38:28PM +0900, Masataka Ohta wrote:
Christian Huitema wrote:
That is, security of DNSSEC involves third parties and is not end
to end.
That is indeed correct. An attacker can build a fake hierarchy of
secure DNS assertions and try to get it accepted. The
Bill Manning wrote:
i think the distinction here might be characterised by
the use of terms:
-channel security
Don't try to confuse the terminology.
With the terminology of channel, the paper addresses the issue
that security by channels between zones or zone
Christian Huitema wrote:
That is, security of DNSSEC involves third parties and is not end
to end.
That is indeed correct. An attacker can build a fake hierarchy of
secure DNS assertions and try to get it accepted. The attack can
succeed with the complicity of one of the authorities in the
Masataka Ohta wrote:
Christian Huitema wrote:
That is, security of DNSSEC involves third parties and is not end
to end.
That is indeed correct. An attacker can build a fake hierarchy of
secure DNS assertions and try to get it accepted. The attack can
succeed with the complicity of one
This debate has nothing to do with the security properties of DNSSEC.
A basic assumption of the DNS is that what the authoritative server for
zone says is, well, authoritative. The structure of DNS itself entitles
JPNIC to point ac.jp wherever they want; by using a name within the .jp
Richard Barnes wrote:
This debate has nothing to do with the security properties of DNSSEC.
A basic assumption of the DNS is that what the authoritative server for
zone says is, well, authoritative. The structure of DNS itself entitles
JPNIC to point ac.jp wherever they want; by using a
Richard Barnes wrote:
(That is: You already trust the zones above you to maintain the
integrity of the zone on the *server*;
This assumption does not stand universally. For some DNS users/usage,
DNSSEC signature verification will be a must. The discussion implicitly
referred to such
On Tue, 2 Jun 2009, Masataka Ohta wrote:
For my domain: necom830.hpcl.titech.ac.jp, hierarechy of zones
have hops of ., jp, ac.jp, titech.ac.jp and
hpcl.titech.ac.jp. The authority hops are IANA, JPNIC, my
university, and my lab. Though you may have direct relationship
with IANA, JPNIC is the
Thierry Moreau wrote:
That is, security of DNSSEC involves third parties and is not end
to end.
This is exactly like a chain of PKI CA's (replacing the path from bottom
to top of zone hierarchy):
Exactly the same with a compromised intermediate CA.
Exactly the same with a private key
Thierry Moreau wrote:
(That is: You already trust the zones above you to maintain the
integrity of the zone on the *server*;
This assumption does not stand universally. For some DNS users/usage,
DNSSEC signature verification will be a must. The discussion implicitly
referred to such
Paul Wouters wrote:
I can't preload 50 million keys. I cannot build trust relations
with 50 millions domains. Just like we could not preload 50
million nameserver pointers.
That is the essential point of the paper of David Clark:
These certificates are principal components of
On Wed, 3 Jun 2009, Masataka Ohta wrote:
You can, for example, bribe a personnel or two, against which there
is no cryptographical protection, which means PKI is weakly secure.
You have never heard of a Hardware Security Module?
Paul
___
Ietf
In message 4a25b8ef.70...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes:
Thierry Moreau wrote:
(That is: You already trust the zones above you to maintain the
integrity of the zone on the *server*;
This assumption does not stand universally. For some DNS users/usage,
DNSSEC
In message alpine.lfd.1.10.0906022034140.22...@newtla.xelerance.com, Paul Wou
ters writes:
On Wed, 3 Jun 2009, Masataka Ohta wrote:
You can, for example, bribe a personnel or two, against which there
is no cryptographical protection, which means PKI is weakly secure.
You have never
On Wed, 3 Jun 2009, Mark Andrews wrote:
You can, for example, bribe a personnel or two, against which there
is no cryptographical protection, which means PKI is weakly secure.
You have never heard of a Hardware Security Module?
HSM doesn't stop the wrong data being signed. It just
In message alpine.lfd.1.10.0906022057560.22...@newtla.xelerance.com, Paul Wou
ters writes:
On Wed, 3 Jun 2009, Mark Andrews wrote:
You can, for example, bribe a personnel or two, against which there
is no cryptographical protection, which means PKI is weakly secure.
You have never
At 09:09 PM 6/2/2009, Mark Andrews wrote:
HSM's
are better than just having the private component of a
public key sitting on a disk somewhere but in most operational
enviornments they don't add that much more security to the
process.
It depends on the HSM. For
On Mon, Jun 1, 2009 at 12:30 AM, Mark Andrews ma...@isc.org wrote:
If you believe that I have a bridge to sell you.
Keep the bridge - it's all yours. Remember - in order to sell the bridge
you first have to own it. Your convenced you have something to sell. I am
not.
Totally
In message 874c02a20906010608p3e7fbdd3wa31c9ea5452a7...@mail.gmail.com, Joe
Baptista writes:
On Mon, Jun 1, 2009 at 12:30 AM, Mark Andrews ma...@isc.org wrote:
If you believe that I have a bridge to sell you.
Keep the bridge - it's all yours. Remember - in order to sell the
As a disinterested third party...
On Mon Jun 1 16:09:39 2009, Mark Andrews wrote:
Totally different from DNSSEC which indeed uses chains of trust -
i.e. root
to tld to sld etc.etc.
And DNSCurve uses chains of trust from root servers to tld
servers to sld servers etc. etc.
In your previous mail you wrote:
= not only this is very arguable (for instance about the resource
exhaustion) but no hop-by-hop/channel security, even something as
strong as TSIG, can provide what we need, i.e., end-to-end/object
security (*).
PS (*): I use the common
In message 874c02a20905311802r2b9b4544j374bb374eb7a7...@mail.gmail.com, Joe
Baptista writes:
DNSSEC indeed violates the end to end principle. It's simply that simple.
And it asks us to put our trust in the root a.k.a. ICANN. I don't think
governments world wide are going to put their trust
I disagree. DNSCurve has nothing to do with trust. It simply ensure the
system you are connected to is in fact the system that gives you the
answer. DNSCurve addresses the UDP issues without the need for a root or
any other third party enjoying any degree of trust.
Totally different from
In message 874c02a20905312100g120b83c7ufbfc13b2849a4...@mail.gmail.com, Joe
Baptista writes:
I disagree. DNSCurve has nothing to do with trust. It simply ensure the
system you are connected to is in fact the system that gives you the
answer. DNSCurve addresses the UDP issues without the
Francis Dupont wrote:
= not only this is very arguable (for instance about the resource
exhaustion) but no hop-by-hop/channel security, even something as
strong as TSIG, can provide what we need, i.e., end-to-end/object
security (*).
Unless your meaning of end-to-end differs from that of
80 matches
Mail list logo