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
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
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
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
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 of
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
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
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 the
13 matches
Mail list logo
