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.
On Wed, Jun 10, 2009 at 09:18:22AM +0900, Masataka Ohta wrote:
With DNSSEC, a security aware resolver will want to check the signature.
Except for glue A.
That's not a vector for attack. Glue records from the parent side of
the cut are not authoritative data in the parent zone, because the
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
Andrew Sullivan wrote:
With DNSSEC, a security aware resolver will want to check the signature.
Except for glue A.
That's not a vector for attack.
Glue is the vector for most, if not all, attacks including
Kaminsky's and DNSSEC with forged certificates.
If you are validating data, why
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
Hi,
[ASRG removed, since I cannot see even a little bit how this is
on-topic there. But if you think it is, feel free to republish this
as you like.]
On Tue, Jun 09, 2009 at 08:54:48AM +0900, Masataka Ohta wrote:
As has been discussed in the thread, DNSSEC is NOT a protection
against cache
On Tue, 2009-06-09 at 08:54 +0900, Masataka Ohta wrote:
DNSSEC provides two things. Firstly, it provides the means to
digitally
sign RRsets. This provides data origin authentication and data
integrity.
The provision is through hops of certificate authorities,
As I clearly stated, the
On Tue, 2009-06-09 at 08:54 +0900, Masataka Ohta wrote:
This origin authentication and integrity is precisely what is
required
to avoid the DNS cache poisoning which is the kind of vulnerability
which prompted this discussion.
As has been discussed in the thread, DNSSEC is NOT a
in 2001 with PROPERLY IDENTIFIED end points. In the
paper, certificate authorities are identified to be third
parties.
With the discussion, there is no point denying DNSSEC is NOT
secure end to end.
It would be nice if the paper was available in unencumbered form.
Both of the papers
David Wilson wrote:
As has been discussed in the thread, DNSSEC is NOT a protection
against cache poisoning, because caches poisoned with forged
certificate breaks the security.
I think you need to explain how this happens in detail.
In detail??? See below.
With DNSSEC, a security aware
David Wilson wrote:
The provision is through hops of certificate authorities,
As I clearly stated,
As we are discussing on concepts described in two papers, your
own statement without proper quotation from the papers does
not mean anything.
the actual signing is end to end,
The security
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.
On Sat, 2009-06-06 at 13:09 +0900, Masataka Ohta wrote:
David Wilson wrote:
However, I think there is some difference in the way people are using
some terms.
According to the terminology of David Clark, PKI including DNSSEC
is not secure end to end.
DNSSEC provides two things. Firstly
On Mon, 2009-06-08 at 14:22 +0900, Masataka Ohta wrote:
As you say IN NETWORKING, I'm afraid you haven't read his original
paper END-TO-END ARGUMENTS IN SYSTEM DESIGN, which is on system
design in general and not necessarily in networking. For example,
in the original paper, RISC (Reduced
David Wilson wrote:
According to the terminology of David Clark, PKI including DNSSEC
is not secure end to end.
DNSSEC provides two things. Firstly, it provides the means to digitally
sign RRsets. This provides data origin authentication and data
integrity.
The provision is through hops
David Wilson wrote:
As you say IN NETWORKING, I'm afraid you haven't read his original
paper END-TO-END ARGUMENTS IN SYSTEM DESIGN, which is on system
design in general and not necessarily in networking. For example,
in the original paper, RISC (Reduced Instruction Set Computer) is
given as an
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
of the end to end
argument to PKI including DNSSEC is discussed in his latter
paper in 2001 with PROPERLY IDENTIFIED end points. In the
paper, certificate authorities are identified to be third
parties.
With the discussion, there is no point denying DNSSEC is NOT
secure end to end.
It would be nice
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
Bill Manning wrote:
If you are so interested in transport layer security, then
by all means, encourage, promote, and develop solutions.
The discussion of the paper of David Clark about public key is not
on a transport but on an administrative layer.
The paper says:
However, there is
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
On Tue, 2009-06-02 at 22:38 +0900, Masataka Ohta wrote:
Yes, security of DNSSEC is totally hop by hop.
I am nervous of adding to this debate (and should it really be on ASRG?)
However, I think there is some difference in the way people are using
some terms. My understanding of the terms
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
David Wilson wrote:
However, I think there is some difference in the way people are using
some terms.
According to the terminology of David Clark, PKI including DNSSEC
is not secure end to end.
End-to-end security means that the security of that data item does not
depend
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
and not secure end
to end.
I don't think any DNSSEC expert ever claimed differently.
I am the DNSSEC expert and see some people having a lot less
expertise than me says DNSSEC secure end to end.
They are incorrect or using different terminology on end to end
not acceptable to the Internet community
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.
To the IETF mailing list subscribers:
The US government involvement in DNSSEC operations is almost certainly
not in-scope for the ietf mailing list. Thus, it would be
counterproductive to start a discussion based on Mr. Baptista comments
on this topic (hence no in-line comments in the
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
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 and faith in ICANN. The
U.S. Government is the only government that has been bamboozled into
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
Mark Andrews wrote:
In a general PKI you need a third party to validated the
name to certificate mapping because there is not natual
method to do this.
With DNSSEC the naming authority is the introducing authority.
Read the paper.
Your attempt to modify the meaning
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
97 matches
Mail list logo
