Ted Lemon wrote:
> Ohta-san, if you want to comment on the protocol, you really ought to
> learn how it works first.
I really hope you can learn how to read mails before sending yours.
>> The problem, then, is that the validation is indirectly hop by
>> hop, not end to end.
> This is not how
Ted Lemon wrote:
>> If you and your peer already have secure channel, you have no
>> reason to use DNSSEC for secure identification nor communication
>> with the peer.
> Ohta-san, this is clueless in so many ways. It's inspiring.
>
> First of all, perhaps you do have a secure channel to your
Mark Andrews wrote:
>>To exchange the trust anchors, you need cryptographically secure
>>end to end security, which is not provided by DNSSEC.
>>
>>If you and your peer already have secure channel, you have no
>>reason to use DNSSEC for secure identification nor communication
>>with the peer.
>
On Aug 20, 2008, at 7:32 PM, Mark Andrews wrote:
How about years of operation (going back to 9.1.0) without
people even noticing that DO is set. If DO caused non
recoverable problems we would have seen them long before
now.
It would be helpful to have some hard data
> On Aug 20, 2008, at 6:56 PM, Mark Andrews wrote:
> >DO is not controlled by dnssec-enable or dnssec-validation.
> >
> >DNSSEC is designed to be validator to authoritative server.
> >If you introduce caches then you need to ensure that your
> >cache is doing someth
> Mark Andrews wrote:
>
> >>Because DNS is not end to end, DNSSEC is not secure end to end.
> >>
> >>Root, TLD and other zones between you and a zone of your peer
> >>are the targets of MitM attacks on DNSSEC.
>
> > Which can be removed if needed by exchanging trust anchors
> > with peer
On Aug 20, 2008, at 6:57 PM, Masataka Ohta wrote:
If you and your peer already have secure channel, you have no
reason to use DNSSEC for secure identification nor communication
with the peer.
Ohta-san, this is clueless in so many ways. It's inspiring.
First of all, perhaps you do have a secu
On Aug 20, 2008, at 6:56 PM, Mark Andrews wrote:
DO is not controlled by dnssec-enable or dnssec-validation.
DNSSEC is designed to be validator to authoritative server.
If you introduce caches then you need to ensure that your
cache is doing something sensible. This
Mark Andrews wrote:
>>Because DNS is not end to end, DNSSEC is not secure end to end.
>>
>>Root, TLD and other zones between you and a zone of your peer
>>are the targets of MitM attacks on DNSSEC.
> Which can be removed if needed by exchanging trust anchors
> with peers.
You can't.
> On Aug 20, 2008, at 6:00 PM, Mark Andrews wrote:
> >Caches will cope with all of the above. There may be some
> >retries. The retries will be logged by some caches. The
> >broken middle boxes will get fixed/replaced.
>
> Mark, is it the case that BIND is setting the D
> Mark Andrews wrote:
>
> >>BTW, DNS is definitely not end-to-end, because it relies on
> >>intelligent intermediate eitities of name servers.
>
> > Actually it doesn't. It can be configured that way but
> > there is no requirement to actually use a caching nameserver.
>
> I'm not talk
On Aug 20, 2008, at 6:00 PM, Mark Andrews wrote:
Caches will cope with all of the above. There may be some
retries. The retries will be logged by some caches. The
broken middle boxes will get fixed/replaced.
Mark, is it the case that BIND is setting the DO bit and then n
> Francis,
>
> On Aug 20, 2008, at 3:17 PM, Francis Dupont wrote:
> > as you know the DO bit means DNSSEC RRs are accepted, so an
> > implementation which supports them should set the DO bit.
>
> Mumble.
>
> So, DO=1 by default will result in DNSSEC-related RRs being returned,
> regardless of
Mark Andrews wrote:
>>BTW, DNS is definitely not end-to-end, because it relies on
>>intelligent intermediate eitities of name servers.
> Actually it doesn't. It can be configured that way but
> there is no requirement to actually use a caching nameserver.
I'm not talking about cachi
In your previous mail you wrote:
Now, I'm saying, for these 10 years, that PKI is broken.
=> what is broken? Crypto, trust model, architecture (including
the RA/CA stuff), etc. There should be many ways to be broken (:-).
That signature generation mechanism is accessible on line does n
In your previous mail you wrote:
If a caching server is required to perform public key computation to
verify RRs before caching, it can't support much clients...
=> the common assumption that public key computation is slow or
expensive is *wrong*. According to 'openssl speed rsa', My old
2
> Florian Weimer wrote:
>
> >>Caching servers not validating the response?
>
> > Yes, this is still a widely-held view. To be honest, I don't think it
> > makes much sense. We need DNSSEC right now, not at some unknown
> > future date when operating system vendors have shipped security-aware,
In your previous mail you wrote:
nobody to complete or champion T/TCP
=> it seems T/TCP is dead because of some security issues.
In another thread about fragmentation (vs firewalls) someone proposed DCCP.
At least, it avoids RFC 1035 4.2.2 (:-)!
[EMAIL PROTECTED]
___
Francis,
On Aug 20, 2008, at 3:17 PM, Francis Dupont wrote:
as you know the DO bit means DNSSEC RRs are accepted, so an
implementation which supports them should set the DO bit.
Mumble.
So, DO=1 by default will result in DNSSEC-related RRs being returned,
regardless of whether those RRs wil
In your previous mail you wrote:
Yes. I've just been told by a fairly authoritative source that BIND
9.5.1 (at least) sets the DO bit on by default, regardless of whether
DNSSEC is configured. This would explain the high number of queries
coming in with DO set.
=> as you kn
In your previous mail you wrote:
So please consider other options before repeating the holy mantra 'DNSSEC is
the only solution'.
=> it is not a mantra but the reality:
- transaction protection is not enough if we want to keep caching
in the middle
(the argument is it has to be a
At 10:30 AM -0700 8/20/08, David Ulevitch wrote:
Paul Vixie wrote:
no hop-by-hop solution can address the problem of a MiTM who can see
and/or alter your queries and responses.
If you have a malicious man in the middle, he will do bad things to you.
DNSSEC will not stop that.
DNSSEC will st
> > no hop-by-hop solution can address the problem of a MiTM who can see
> > and/or alter your queries and responses.
>
> If you have a malicious man in the middle, he will do bad things to you.
>
> DNSSEC will not stop that.
please explain how i can get undetectably bad data in a dnssec environ
David,
On Aug 20, 2008, at 10:30 AM, David Ulevitch wrote:
Paul Vixie wrote:
no hop-by-hop solution can address the problem of a MiTM who can see
and/or alter your queries and responses.
If you have a malicious man in the middle, he will do bad things to
you.
Yep. Question is, how many o
David Ulevitch wrote:
Paul Vixie wrote:
no hop-by-hop solution can address the problem of a MiTM who can see
and/or alter your queries and responses.
If you have a malicious man in the middle, he will do bad things to you.
DNSSEC will not stop that.
Too many pronouns...
DNSSEC provides the
Paul Vixie wrote:
no hop-by-hop solution can address the problem of a MiTM who can see
and/or alter your queries and responses.
If you have a malicious man in the middle, he will do bad things to you.
DNSSEC will not stop that.
___
DNSOP mailing li
Florian Weimer wrote:
> No, because DNSSEC, as it will be deployed, is not a PKI. There is no
> registration process which is universally agreed upon.
A PKI with a universally agreed registration process of "it depends"
is still a PKI.
However, a problem of PKI is that, even if such a process i
At 5:36 PM +0200 8/20/08, Florian Weimer wrote:
* Masataka Ohta:
Now, I'm saying, for these 10 years, that PKI, including DNSSEC,
is broken.
Can't you simply believe me?
No, because DNSSEC, as it will be deployed, is not a PKI.
Masataka is right that PKI as it is widely used (PKIX) is b
Florian Weimer wrote:
>>Caching servers not validating the response?
> Yes, this is still a widely-held view. To be honest, I don't think it
> makes much sense. We need DNSSEC right now, not at some unknown
> future date when operating system vendors have shipped security-aware,
> validating s
* Masataka Ohta:
> Now, I'm saying, for these 10 years, that PKI, including DNSSEC,
> is broken.
>
> Can't you simply believe me?
No, because DNSSEC, as it will be deployed, is not a PKI. There is no
registration process which is universally agreed upon. As a result, a
DNSSEC signature carries
i answered this on namedroppers, where the thread actually belongs.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listi
Mark Andrews wrote:
> The current DNSSEC essentially matches "Simple Secure DNS".
Well, mostly. Thank you for your pointer to RFC4035 I ignored.
And, congratulations that the WG has wasted only 10 years of
implementation and operational experiences to reach the
conclusion that the original
> * Masataka Ohta:
>
> > Caching servers not validating the response?
>
> Yes, this is still a widely-held view. To be honest, I don't think it
> makes much sense. We need DNSSEC right now, not at some unknown
> future date when operating system vendors have shipped security-aware,
> validatin
* Paul Vixie:
[QTYPE=ANY deprecation]
> so, can you explain what you mean by "breaks", both for sendmail and
> qmail?
I thought deprecation means that responders (especially resolvers) are
free to discard such queries. At least that's how the binary label
deprecation was interpreted by some fol
> > ... let's deprecate these bit patterns altogether for OP=QUERY:
> >
> > QTYPE=255
>
> Breaks some sendmail versions and qmail.
i once hacked sendmail internals, and what i remember is that it would try
a QTYPE=ANY to see if it could get both the MX and its A in one shot, on the
hopeful as
> David Conrad wrote:
>
> > So far, I have seen what appears to be a lot of FUD from Masataka and
> > the usual concerns/complaints about DNSSEC from folks who haven't
> > implemented it in their products or services.
>
> Unlike me, you have no implementation expertise.
>
> I did implement
On Tue, Aug 19, 2008 at 11:15:12PM -0400, Dean Anderson wrote:
> I don't know if anyone noticed, but in fact, according to RFC4035 the
> delegation records and the glue records are not signed. A verifying
> DNSSEC cache can be poised with bad glue records using the poisoning
> attack, with only a
Paul Vixie wrote:
> that depends on the problem statement, really. if the problem statement is
> "how can we secure hop-by-hop" then there are other solutions on the table
> right now besides DNSSEC.
Wrong.
PKI, including DNSSEC, does require hop-by-hop security between CAs,
which is no differ
On Aug 20, 2008, at 6:16 AM, Masataka Ohta wrote:
Unlike me, you have no implementation expertise.
Um. Right.
Regards,
-drc
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Florian Weimer wrote:
>>Anyway, the other problem of DNSSEC is that PKI, as a concept, is
>>fundamentally broken, against which no PKI protocol can be useful.
> I think we need to recast DNSSEC as mere transport protection measure.
> It might be a overengineered for this purpose, but
DNSSEC is t
[EMAIL PROTECTED] (Paul Vixie) writes:
> my chosen problem statement is "how can we secure end-to-end" because i am
> worried about corruption inside servers not just between them, and i want
> to defend against provider-in-the-middle attacks (including several that
> opendns currently monetizes.)
* Masataka Ohta:
> Caching servers not validating the response?
Yes, this is still a widely-held view. To be honest, I don't think it
makes much sense. We need DNSSEC right now, not at some unknown
future date when operating system vendors have shipped security-aware,
validating stub resolvers
[EMAIL PROTECTED] (David Ulevitch) writes:
> ... -- My goal is not to derail DNSSEC. It does that on its own. My
> goal is to make sure people don't buy into the kool-aid being poured
> that DNSSEC is the only solution. It isn't.
that depends on the problem statement, really. if the problem
Mark Andrews wrote:
> DO says that you *understand* DNSSEC and that it is ok to
> send a DNSSEC response. It does not mean that you will be
> validating the response.
>
> named in all production versions of BIND 9 (9.1.0 onwards)
> has set DO on all EDNS queries. BI
Dean Anderson wrote:
>>A property of Kaminsky's attack that it is effective against a single
>>target is useful, here.
> I don't know if anyone noticed, but in fact, according to RFC4035 the
> delegation records and the glue records are not signed.
Really? (I am not interested in reading RFC4035
* Masataka Ohta:
> Anyway, the other problem of DNSSEC is that PKI, as a concept, is
> fundamentally broken, against which no PKI protocol can be useful.
I think we need to recast DNSSEC as mere transport protection measure.
It might be a overengineered for this purpose, but it's what we've got
n
David Conrad wrote:
> So far, I have seen what appears to be a lot of FUD from Masataka and
> the usual concerns/complaints about DNSSEC from folks who haven't
> implemented it in their products or services.
Unlike me, you have no implementation expertise.
I did implement server code for my
DO says that you *understand* DNSSEC and that it is ok to
send a DNSSEC response. It does not mean that you will be
validating the response.
named in all production versions of BIND 9 (9.1.0 onwards)
has set DO on all EDNS queries. BIND 9.1.1 onwards name
* Alexander Gall:
> More data points from two authoritative servers for the ch ccTLD:
> 40-50% (I've attached the relevant DSC graphs for the past month).
>
> I looked more closely on one of the servers. Out of about 22 million
> queries in the past 11 hours, about 10 million from 161000 differen
2008/8/19 kevin graham <[EMAIL PROTECTED]>:
>
> On Tue, 19 Aug 2008, David Conrad wrote:
>
>> On Aug 19, 2008, at 6:40 AM, Masataka Ohta wrote:
>>>
>>> So what? NAT at airport must be, unlike NATs in enterprises,
>>> consumer friendly. Unlike highe end NAT, low end NAT won't
>>> bother to interfere
On Tue, 19 Aug 2008 15:43:14 -0400, Andrew Sullivan <[EMAIL PROTECTED]> said:
> On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote:
>> it in their products or services. Peter Koch did provide an interesting
>> data point that warrants further investigation (20-35% of queries having DO
Jaap Akkerhuis wrote:
> On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote:
>
> > it in their products or services. Peter Koch did provide an
> interesting
> > data point that warrants further investigation (20-35% of queries
> having DO
> > bit on seems a bit hi
* Paul Vixie:
> better still, let's deprecate these bit patterns altogether for OP=QUERY:
>
> QTYPE=255
Breaks some sendmail versions and qmail.
> QCLASS=255
QCLASS != IN seems more reasonable to me.
> RA=1 AND RD=0
By the responder or the initiator?
> and let's also make e
On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote:
> it in their products or services. Peter Koch did provide an interesting
> data point that warrants further investigation (20-35% of queries having
DO
> bit on seems a bit high to me) and someone else responded
54 matches
Mail list logo
