[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNSOP] A different question
> -----Original Message-----
> From: dnsop-bounces at ietf.org [mailto:dnsop-bounces at ietf.org] On Behalf Of
> Masataka Ohta
> Subject: Re: [DNSOP] A different question
>
> There are intelligent intermediate entities of root, TLD and
> other servers between you and authoritative nameservers of your
> peer.
This is on data distribution path level, not infrastructure, nor data.
> Because DNS is not end to end, DNSSEC is not secure end to end.
I don't care if the infrastructure is TCP, UDP, Token ring or carier pigeons, I don't trust the infrastructure because it has a MITM (or pigeon in the middle) I don't know.
I even don't trust the data distribution, DNS, as it has a MITM as you say.
Trying to secure the infrastructure hop-by-hop is the bell-head solution, which, with an increase of operators has proven to be not scalable nor efficient.
Data is the ultimate end-to-end, from your brain into mine, whithout any dependency on the infrastructure in between.
> Root, TLD and other zones between you and a zone of your peer
> are the targets of MitM attacks on DNSSEC.
All these MITM are MITM in infrastructure, but not all in Data.
None of these infrastructure MITM can fiddle with the end-users data without the end-users cooperation or notice.
The only thing a MITM can do is revoke the data path to reach a trust anchor, which will trigger the flag that the data path is not secure anymore.
I agreFrom dnsop-bounces at ietf.org Thu Aug 21 02:30:14 2008
Return-Path: <dnsop-bounces at ietf.org>
X-Original-To: dnsop-archive at optimus.ietf.org
Delivered-To: ietfarch-dnsop-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id F1CCC3A6975;
Thu, 21 Aug 2008 02:30:13 -0700 (PDT)
X-Original-To: dnsop at core3.amsl.com
Delivered-To: dnsop at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 22FD63A6975
for <dnsop at core3.amsl.com>; Thu, 21 Aug 2008 02:30:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.523
X-Spam-Level: *
X-Spam-Status: No, score=1.523 tagged_above=-999 required=5 tests=[AWL=2.027,
BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id iDSw38nFkgzf for <dnsop at core3.amsl.com>;
Thu, 21 Aug 2008 02:30:12 -0700 (PDT)
Received: from gw.sidn.nl (gw.sidn.nl [193.176.144.134])
by core3.amsl.com (Postfix) with ESMTP id 0B7A33A6820
for <dnsop at ietf.org>; Thu, 21 Aug 2008 02:30:11 -0700 (PDT)
Received: by localhost.sidn.nl (TUNIX/Firewall Mail Server) with ESMTP id
454673ADCF
for <dnsop at ietf.org>; Thu, 21 Aug 2008 11:30:10 +0200 (CEST)
Received: by gw.sidn.nl (TUNIX/Firewall Mail Server) with ESMTP
for <dnsop at ietf.org>; Thu, 21 Aug 2008 11:30:10 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 21 Aug 2008 11:30:08 +0200
Message-ID: <850A39016FA57A4887C0AA3C8085F94908EA93 at KAEVS1.SIDN.local>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [DNSOP] A different question
Thread-Index: AckDJbFQ5wguPKR5SVy4s0on7uaE7gARPRMA
References: <200808202321.m7KNLcM8028693 at drugs.dv.isc.org>
<48ACB7CF.3020209 at necom830.hpcl.titech.ac.jp>
From: "Antoin Verschuren" <Antoin.Verschuren at sidn.nl>
To: <dnsop at ietf.org>
Subject: Re: [DNSOP] A different question
X-BeenThere: dnsop at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
<mailto:dnsop-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:dnsop at ietf.org>
List-Help: <mailto:dnsop-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
<mailto:dnsop-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsop-bounces at ietf.org
Errors-To: dnsop-bounces at ietf.org
> -----Original Message-----
> From: dnsop-bounces at ietf.org [mailto:dnsop-bounces at ietf.org] On Behalf Of
> Masataka Ohta
> Subject: Re: [DNSOP] A different question
>
> There are intelligent intermediate entities of root, TLD and
> other servers between you and authoritative nameservers of your
> peer.
This is on data distribution path level, not infrastructure, nor data.
> Because DNS is not end to end, DNSSEC is not secure end to end.
I don't care if the infrastructure is TCP, UDP, Token ring or carier pigeons, I don't trust the infrastructure because it has a MITM (or pigeon in the middle) I don't know.
I even don't trust the data distribution, DNS, as it has a MITM as you say.
Trying to secure the infrastructure hop-by-hop is the bell-head solution, which, with an increase of operators has proven to be not scalable nor efficient.
Data is the ultimate end-to-end, from your brain into mine, whithout any dependency on the infrastructure in between.
> Root, TLD and other zones between you and a zone of your peer
> are the targets of MitM attacks on DNSSEC.
All these MITM are MITM in infrastructure, but not all in Data.
None of these infrastructure MITM can fiddle with the end-users data without the end-users cooperation or notice.
The only thing a MITM can do is revoke the data path to reach a trust anchor, which will trigger the flag that the data path is not secure anymore.
I agree with ye with you that a data Parent can, without cooperation of a child, set up a new thrust-anchor, data path and data.
But parents are not the only MITM's. Parents are to be trusted, as you have accepted them in your data path. You are aware of their existence. Other MITM not in the data path, but present in the infrastructure path, aren't to be trusted.
Secure the data path not the infrastructure.
I believe that is what DNSSEC does.
Antoin Verschuren
Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands
T +31 26 3525500
F +31 26 3525505
M +31 6 23368970
E antoin.verschuren at sidn.nl
W http://www.sidn.nl/
_______________________________________________
DNSOP mailing list
DNSOP at ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ou that a data Parent can, without cooperation of a child, set up a new thrust-anchor, data path and data.
But parents are not the only MITM's. Parents are to be trusted, as you have accepted them in your data path. You are aware of their existence. Other MITM not in the data path, but present in the infrastructure path, aren't to be trusted.
Secure the data path not the infrastructure.
I believe that is what DNSSEC does.
Antoin Verschuren
Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands
T +31 26 3525500
F +31 26 3525505
M +31 6 23368970
E antoin.verschuren at sidn.nl
W http://www.sidn.nl/
_______________________________________________
DNSOP mailing list
DNSOP at ietf.org
https://www.ietf.org/mailman/listinfo/dnsop