From owner-namedroppers@ops.ietf.org Wed Dec 1 02:40:31 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08313
for ; Wed, 1 Dec 2004 02:40:30 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CZP0z-000GpS-Eu
for namedroppers-data@psg.com; Wed, 01 Dec 2004 07:35:05 +0000
Received: from [193.0.0.199] (helo=postman.ripe.net)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CZP0y-000Gp1-NQ
for namedroppers@ops.ietf.org; Wed, 01 Dec 2004 07:35:04 +0000
Received: by postman.ripe.net (Postfix, from userid 8)
id 0FCC025BD3; Wed, 1 Dec 2004 08:35:04 +0100 (CET)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
by postman.ripe.net (Postfix) with ESMTP id 2DF0625A0D
for ; Wed, 1 Dec 2004 08:35:03 +0100 (CET)
Received: from x50.ripe.net (x50.ripe.net [193.0.1.50])
by birch.ripe.net (8.12.10/8.11.6) with ESMTP id iB17Z3LE019874
for ; Wed, 1 Dec 2004 08:35:03 +0100
Received: (from olaf@localhost)
by x50.ripe.net (8.12.10/8.12.6) id iB17Z2gq024861
for namedroppers@ops.ietf.org; Wed, 1 Dec 2004 08:35:02 +0100
Date: Wed, 1 Dec 2004 08:35:02 +0100
From: Olaf Kolkman
Message-Id: <200412010735.iB17Z2gq024861@x50.ripe.net>
To: namedroppers@ops.ietf.org
Subject: DNSEXT list policy
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00
X-RIPE-Spam-Status: N 0.000537 / -5.9
X-RIPE-Signature: 8f61f1c529b7d46e843fd7e54f2bf101
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Wed Dec 1 03:01:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13510
for ; Wed, 1 Dec 2004 03:01:44 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CZPNX-000KJM-TU
for namedroppers-data@psg.com; Wed, 01 Dec 2004 07:58:23 +0000
Received: from [193.0.3.29] (helo=fopje.dacht.net)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CZPNX-000KJ8-5p
for namedroppers@ops.ietf.org; Wed, 01 Dec 2004 07:58:23 +0000
Received: from ripe.net (unknown [193.0.3.28])
by fopje.dacht.net (Postfix) with ESMTP
id 11AFA2FC0C; Wed, 1 Dec 2004 08:58:21 +0100 (CET)
Message-ID: <41AD799F.7000509@ripe.net>
Date: Wed, 01 Dec 2004 08:58:23 +0100
From: "Olaf M. Kolkman"
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: namedroppers@ops.ietf.org
Cc: Olaf Kolkman
Subject: Re: DNSEXT list policy
References: <200412010735.iB17Z2gq024861@x50.ripe.net>
In-Reply-To: <200412010735.iB17Z2gq024861@x50.ripe.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Sorry for the empty message, I moved a directory and fortgot to update
my crontab.
See e.g.
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg02002.html
for the list policy.
--Olaf
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Wed Dec 1 14:26:48 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13825
for ; Wed, 1 Dec 2004 14:26:48 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CZa1t-000GCJ-Nw
for namedroppers-data@psg.com; Wed, 01 Dec 2004 19:20:45 +0000
Received: from [17.254.13.23] (helo=mail-out4.apple.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CZa1s-000GC7-Vj
for namedroppers@ops.ietf.org; Wed, 01 Dec 2004 19:20:45 +0000
Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225])
by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id iB1JS503015754
for ; Wed, 1 Dec 2004 11:28:05 -0800 (PST)
Received: from relay4.apple.com (relay4.apple.com) by mailgate1.apple.com
(Content Technologies SMTPRS 4.3.14) with ESMTP id for ;
Wed, 1 Dec 2004 11:21:41 -0800
Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119])
by relay4.apple.com (8.12.11/8.12.11) with SMTP id iB1JKRCh016288
for ; Wed, 1 Dec 2004 11:20:28 -0800 (PST)
Message-Id: <200412011920.iB1JKRCh016288@relay4.apple.com>
Subject: TCP response with truncated bit set?
Date: Wed, 1 Dec 2004 11:20:27 -0800
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire
To:
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
If you do a DNS query over UDP and get a response with the TC bit set,
the client retries using TCP.
If the response received over TCP also has the TC bit set, what does that
mean?
Stuart Cheshire
* Wizard Without Portfolio, Apple Computer, Inc.
* www.stuartcheshire.org
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Wed Dec 1 16:38:20 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28013
for ; Wed, 1 Dec 2004 16:38:20 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CZc6s-000Agt-J0
for namedroppers-data@psg.com; Wed, 01 Dec 2004 21:34:02 +0000
Received: from [204.152.187.5] (helo=farside.isc.org)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CZc6q-000Agc-TU
for namedroppers@ops.ietf.org; Wed, 01 Dec 2004 21:34:00 +0000
Received: from drugs.dv.isc.org (localhost [IPv6:::1])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id 69A2067503
for ; Wed, 1 Dec 2004 21:34:00 +0000 (UTC)
(envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB1LXsVY040931;
Thu, 2 Dec 2004 08:33:54 +1100 (EST)
(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200412012133.iB1LXsVY040931@drugs.dv.isc.org>
To: Stuart Cheshire
Cc: namedroppers@ops.ietf.org
From: Mark Andrews
Subject: Re: TCP response with truncated bit set?
In-reply-to: Your message of "Wed, 01 Dec 2004 11:20:27 -0800."
<200412011920.iB1JKRCh016288@relay4.apple.com>
Date: Thu, 02 Dec 2004 08:33:54 +1100
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
> If you do a DNS query over UDP and get a response with the TC bit set,
> the client retries using TCP.
>
> If the response received over TCP also has the TC bit set, what does that
> mean?
It means that the answer would not fit into the buffer used to
assemble the TCP response. Note not all implementations use /
have used 64k buffers.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Wed Dec 1 19:15:09 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13918
for ; Wed, 1 Dec 2004 19:15:09 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CZeWv-000BWN-35
for namedroppers-data@psg.com; Thu, 02 Dec 2004 00:09:05 +0000
Received: from [17.254.13.23] (helo=mail-out4.apple.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CZeWu-000BW8-H8
for namedroppers@ops.ietf.org; Thu, 02 Dec 2004 00:09:04 +0000
Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204])
by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id iB20GPiB025537
for ; Wed, 1 Dec 2004 16:16:25 -0800 (PST)
Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com
(Content Technologies SMTPRS 4.3.14) with ESMTP id for ;
Wed, 1 Dec 2004 16:09:03 -0800
Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119])
by relay2.apple.com (8.12.11/8.12.11) with SMTP id iB2091RG002433
for ; Wed, 1 Dec 2004 16:09:02 -0800 (PST)
Message-Id: <200412020009.iB2091RG002433@relay2.apple.com>
Subject: Re: TCP response with truncated bit set?
Date: Wed, 1 Dec 2004 16:09:01 -0800
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire
To:
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
> It means that the answer would not fit into the buffer used to
> assemble the TCP response. Note not all implementations use /
> have used 64k buffers.
>
> Mark
Presumably, even when both the client and authoritative server can handle
the RR Set, a caching server between them could introduce this behaviour?
Is there any reasonable action a client can take in this case, or is
giving up the only option?
Stuart Cheshire
* Wizard Without Portfolio, Apple Computer, Inc.
* www.stuartcheshire.org
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Wed Dec 1 19:41:33 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17133
for ; Wed, 1 Dec 2004 19:41:33 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CZezX-000GDZ-Co
for namedroppers-data@psg.com; Thu, 02 Dec 2004 00:38:39 +0000
Received: from [204.152.187.5] (helo=farside.isc.org)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CZezW-000GDF-Ix
for namedroppers@ops.ietf.org; Thu, 02 Dec 2004 00:38:38 +0000
Received: from drugs.dv.isc.org (localhost [IPv6:::1])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id 2F6D5677EF
for ; Thu, 2 Dec 2004 00:38:37 +0000 (UTC)
(envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB20cWiG089823;
Thu, 2 Dec 2004 11:38:32 +1100 (EST)
(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200412020038.iB20cWiG089823@drugs.dv.isc.org>
To: Stuart Cheshire
Cc: namedroppers@ops.ietf.org
From: Mark Andrews
Subject: Re: TCP response with truncated bit set?
In-reply-to: Your message of "Wed, 01 Dec 2004 16:09:01 -0800."
<200412020009.iB2091RG002433@relay2.apple.com>
Date: Thu, 02 Dec 2004 11:38:32 +1100
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
> > It means that the answer would not fit into the buffer used to
> > assemble the TCP response. Note not all implementations use /
> > have used 64k buffers.
> >
> > Mark
>
> Presumably, even when both the client and authoritative server can handle
> the RR Set, a caching server between them could introduce this behaviour?
Yes.
> Is there any reasonable action a client can take in this case, or is
> giving up the only option?
Give up at this point. There have been a number of proposals
to extend TCP handling to support answers bigger than 64k.
AXFR really should have been implemented this way rather
than the way it was. In other words we knew when the DNS
was being designed that answers to certian queries would
exceed 64k and we should have provided a mechanism to handle
those cases in a standard way.
> Stuart Cheshire
> * Wizard Without Portfolio, Apple Computer, Inc.
> * www.stuartcheshire.org
>
>
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive:
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Thu Dec 2 04:16:19 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22332
for ; Thu, 2 Dec 2004 04:16:19 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CZmyn-000GDr-QT
for namedroppers-data@psg.com; Thu, 02 Dec 2004 09:10:25 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CZmye-000GCd-N6
for namedroppers@ops.ietf.org; Thu, 02 Dec 2004 09:10:17 +0000
Received: from [196.7.13.97] (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id iB299t2T060214;
Thu, 2 Dec 2004 04:10:11 -0500 (EST)
(envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To: <200412020038.iB20cWiG089823@drugs.dv.isc.org>
References: <200412020038.iB20cWiG089823@drugs.dv.isc.org>
Date: Thu, 2 Dec 2004 11:09:53 +0200
To: namedroppers@ops.ietf.org
From: Edward Lewis
Subject: Re: TCP response with truncated bit set?
Cc: ed.lewis@neulevel.biz
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.48 on 66.92.146.160
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At 19:38 -0500 12/1/04, Mark Andrews wrote:
>> Stuart Cheshire :
>> Is there any reasonable action a client can take in this case, or is
>> giving up the only option?
>
> Give up at this point. There have been a number of proposals
> to extend TCP handling to support answers bigger than 64k.
Not being an implementer, but as a protocol wonk, I agree. There's
no fall back from that point within the DNS protocol.
'Course - there's a difference between there being "no fall back" and
"a fall back is not defined." The truth is the latter, pragmatically
this means you can't count on consistent implementation of such a
situation, hence there isn't a reliable "fall back."
One of the principles of protocol layering is that occasionally you
encounter an error that can't be handled within the plane and should
design to kick up a level. (I think this is expressed in
Tannenbaum's text, unfortunately mine is in two different hemispheres
from me now.) This is such a case.
If I encountered this and had all my tools available to me, etc., the
next layer up would be FTP. Okay, maybe SCP to the youngsters out
there.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
I think my jabber client and SMS phone are talking about me behind my back.
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Thu Dec 2 06:47:36 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04877
for ; Thu, 2 Dec 2004 06:47:36 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CZpNT-000CAv-E4
for namedroppers-data@psg.com; Thu, 02 Dec 2004 11:44:03 +0000
Received: from [204.152.187.5] (helo=farside.isc.org)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CZpNQ-000CAM-Um
for namedroppers@ops.ietf.org; Thu, 02 Dec 2004 11:44:00 +0000
Received: from drugs.dv.isc.org (localhost [IPv6:::1])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id 690C8677EF
for ; Thu, 2 Dec 2004 11:44:00 +0000 (UTC)
(envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB2BhpCx075214;
Thu, 2 Dec 2004 22:43:51 +1100 (EST)
(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200412021143.iB2BhpCx075214@drugs.dv.isc.org>
To: Edward Lewis
Cc: namedroppers@ops.ietf.org, ed.lewis@neulevel.biz
From: Mark Andrews
Subject: Re: TCP response with truncated bit set?
In-reply-to: Your message of "Thu, 02 Dec 2004 11:09:53 +0200."
Date: Thu, 02 Dec 2004 22:43:51 +1100
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
> At 19:38 -0500 12/1/04, Mark Andrews wrote:
>
> >> Stuart Cheshire :
>
> >> Is there any reasonable action a client can take in this case, or is
> >> giving up the only option?
> >
> > Give up at this point. There have been a number of proposals
> > to extend TCP handling to support answers bigger than 64k.
>
> Not being an implementer, but as a protocol wonk, I agree. There's
> no fall back from that point within the DNS protocol.
>
> 'Course - there's a difference between there being "no fall back" and
> "a fall back is not defined." The truth is the latter, pragmatically
> this means you can't count on consistent implementation of such a
> situation, hence there isn't a reliable "fall back."
>
> One of the principles of protocol layering is that occasionally you
> encounter an error that can't be handled within the plane and should
> design to kick up a level. (I think this is expressed in
> Tannenbaum's text, unfortunately mine is in two different hemispheres
> from me now.) This is such a case.
>
> If I encountered this and had all my tools available to me, etc., the
> next layer up would be FTP. Okay, maybe SCP to the youngsters out
> there.
Well there was always a full AXFR and extract the answer from
that.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Thu Dec 2 11:08:47 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03317
for ; Thu, 2 Dec 2004 11:08:46 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CZtO4-0003nf-Lp
for namedroppers-data@psg.com; Thu, 02 Dec 2004 16:00:56 +0000
Received: from [204.152.187.1] (helo=sa.vix.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CZtO2-0003nI-JQ
for namedroppers@ops.ietf.org; Thu, 02 Dec 2004 16:00:54 +0000
Received: from sa.vix.com (localhost [127.0.0.1])
by sa.vix.com (Postfix) with ESMTP id CBD4813E12
for ; Thu, 2 Dec 2004 16:00:53 +0000 (GMT)
(envelope-from vixie@sa.vix.com)
From: Paul Vixie
To: namedroppers@ops.ietf.org
Subject: Re: TCP response with truncated bit set?
In-Reply-To: Message from Mark Andrews
of "Thu, 02 Dec 2004 22:43:51 +1100."
<200412021143.iB2BhpCx075214@drugs.dv.isc.org>
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Date: Thu, 02 Dec 2004 16:00:53 +0000
Message-Id: <20041202160053.CBD4813E12@sa.vix.com>
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
> > >> Is there any reasonable action a client can take in this case, or is
> > >> giving up the only option?
> > >
> > > Give up at this point. There have been a number of proposals
> > > to extend TCP handling to support answers bigger than 64k.
> >
> > Not being an implementer, but as a protocol wonk, I agree. There's
> > no fall back from that point within the DNS protocol.
>
> Well there was always a full AXFR and extract the answer from that.
or try again with the MD feature originally proposed as part of EDNS1:
MD ``More data'' flag. Valid only in TCP streams where message
ordering and reliability are guaranteed. This flag indicates
that the current message is not the complete request or
response, and should be aggregated with the following
message(s) before being considered complete. Such messages are
called ``segmented.'' It is an error for the RCODE (including
the EXTENDED-RCODE), AA flag, or DNS Message ID to differ among
segments of a segmented message. It is an error for TC to be
set on any message of a segmented message. Any given RR must
fit completely within a message, and all messages will both
begin and end on RR boundaries. Each section in a multipart
message must appear in normal message order, and each section
must be complete before later sections are added. All segments
of a message must be transmitted contiguously, without
interleaving of other messages.
it still amazes me to look at the number of things that this WG decided
were too complex and unnecessary, many of which will therefore show up as
vendor-specific extensions.
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Mon Dec 6 08:59:49 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15231
for ; Mon, 6 Dec 2004 08:59:49 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CbJI1-000DUm-HB
for namedroppers-data@psg.com; Mon, 06 Dec 2004 13:52:33 +0000
Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CbJHz-000DUJ-Bz
for namedroppers@ops.ietf.org; Mon, 06 Dec 2004 13:52:31 +0000
Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218])
by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP
id 38F3613C1E; Mon, 6 Dec 2004 13:52:30 +0000 (GMT)
Message-ID: <41B46423.5000504@algroup.co.uk>
Date: Mon, 06 Dec 2004 13:52:35 +0000
From: Ben Laurie
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Olaf M. Kolkman"
Cc: namedroppers@ops.ietf.org
Subject: Re: NSEC+-epsilon (whitelies server) proof of concept.
References: <20041129122915.0c621b43.olaf@ripe.net>
In-Reply-To: <20041129122915.0c621b43.olaf@ripe.net>
X-Enigmail-Version: 0.89.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Olaf M. Kolkman wrote:
> By refusing queries for the
> names that contain the "maximum and minimum sort values" that have
> been inserted in the +-epsilon process, we "weasel" our way out of the
> question if these names are or are not in the zone, the client will
> just never be able to know because of our policy.
I don't understand this - which names do you think might not be in the zone?
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Mon Dec 6 09:12:18 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16020
for ; Mon, 6 Dec 2004 09:12:18 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CbJXG-000Fpv-U9
for namedroppers-data@psg.com; Mon, 06 Dec 2004 14:08:18 +0000
Received: from [193.0.0.199] (helo=postman.ripe.net)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CbJX6-000Fok-JO
for namedroppers@ops.ietf.org; Mon, 06 Dec 2004 14:08:08 +0000
Received: by postman.ripe.net (Postfix, from userid 8)
id 00B5424707; Mon, 6 Dec 2004 15:08:07 +0100 (CET)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
by postman.ripe.net (Postfix) with ESMTP
id 0E8E82401E; Mon, 6 Dec 2004 15:08:07 +0100 (CET)
Received: from x50.ripe.net (x50.ripe.net [193.0.1.50])
by birch.ripe.net (8.12.10/8.11.6) with ESMTP id iB6E87LE013694;
Mon, 6 Dec 2004 15:08:07 +0100
Message-Id: <200412061408.iB6E87LE013694@birch.ripe.net>
To: Ben Laurie
Cc: namedroppers@ops.ietf.org
Subject: Re: NSEC+-epsilon (whitelies server) proof of concept.
In-reply-to: Your message of Mon, 06 Dec 2004 13:52:35 GMT.
<41B46423.5000504@algroup.co.uk>
References: <41B46423.5000504@algroup.co.uk>
From: Olaf Kolkman
X-Organization: RIPE Network Coordination Centre
X-Phone: +31 20 535 4444
X-Fax: +31 20 535 4445
Date: Mon, 06 Dec 2004 15:08:07 +0100
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00
X-RIPE-Spam-Status: N 0.000070 / -5.9
X-RIPE-Signature: a07a541214afa7517ec2f8dd992a099c
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Ben Laurie writes:
* Olaf M. Kolkman wrote:
* > By refusing queries for the
* > names that contain the "maximum and minimum sort values" that have
* > been inserted in the +-epsilon process, we "weasel" our way out of the
* > question if these names are or are not in the zone, the client will
* > just never be able to know because of our policy.
*
* I don't understand this - which names do you think might not be in the zone?
*
At the risk of being to short I refer to
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg02066.html
as the background of this.
Essentially Simon said that those dynamically generated nsec+-epsilon
names are not part of the zone and one is violating the spec by
generating them (and he is correct).
On the other hand I think that this particular sentence in the
specification does not hinder deployment of NSEC+-epsilon. Clients
that try to enforce this part of the specs will never be able to proof
that the spec is violated.
And if they try to you can use the refuse hack that I put in as a
workaround. It is a silly optimization that is I think not needed.
--Olaf
no hats
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Mon Dec 6 12:47:37 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04005
for ; Mon, 6 Dec 2004 12:47:37 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CbMsY-000HjH-U0
for namedroppers-data@psg.com; Mon, 06 Dec 2004 17:42:30 +0000
Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CbMsW-000Hit-G7
for namedroppers@ops.ietf.org; Mon, 06 Dec 2004 17:42:28 +0000
Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218])
by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP
id BBB648B81E; Mon, 6 Dec 2004 17:42:27 +0000 (GMT)
Message-ID: <41B49A08.70203@algroup.co.uk>
Date: Mon, 06 Dec 2004 17:42:32 +0000
From: Ben Laurie
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Olaf Kolkman
Cc: namedroppers@ops.ietf.org
Subject: Re: NSEC+-epsilon (whitelies server) proof of concept.
References: <41B46423.5000504@algroup.co.uk> <200412061408.iB6E87LE013694@birch.ripe.net>
In-Reply-To: <200412061408.iB6E87LE013694@birch.ripe.net>
X-Enigmail-Version: 0.89.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Olaf Kolkman wrote:
> Ben Laurie writes:
> * Olaf M. Kolkman wrote:
> * > By refusing queries for the
> * > names that contain the "maximum and minimum sort values" that have
> * > been inserted in the +-epsilon process, we "weasel" our way out of the
> * > question if these names are or are not in the zone, the client will
> * > just never be able to know because of our policy.
> *
> * I don't understand this - which names do you think might not be in the zone?
> *
>
>
> At the risk of being to short I refer to
> http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg02066.html
> as the background of this.
>
> Essentially Simon said that those dynamically generated nsec+-epsilon
> names are not part of the zone and one is violating the spec by
> generating them (and he is correct).
>
> On the other hand I think that this particular sentence in the
> specification does not hinder deployment of NSEC+-epsilon. Clients
> that try to enforce this part of the specs will never be able to proof
> that the spec is violated.
>
> And if they try to you can use the refuse hack that I put in as a
> workaround. It is a silly optimization that is I think not needed.
I don't understand how clients would use the unhacked version to prove
the spec violation?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Mon Dec 6 16:20:19 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26214
for ; Mon, 6 Dec 2004 16:20:18 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CbQDN-000GA6-Ik
for namedroppers-data@psg.com; Mon, 06 Dec 2004 21:16:13 +0000
Received: from [17.254.13.22] (helo=mail-out3.apple.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CbQDJ-000G9n-Jq
for namedroppers@ops.ietf.org; Mon, 06 Dec 2004 21:16:09 +0000
Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204])
by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id iB6LN4VJ020217
for ; Mon, 6 Dec 2004 13:23:04 -0800 (PST)
Received: from relay1.apple.com (relay1.apple.com) by mailgate2.apple.com
(Content Technologies SMTPRS 4.3.17) with ESMTP id for ;
Mon, 6 Dec 2004 13:16:43 -0800
Received: from [17.202.45.224] (il0204a-dhcp96.apple.com [17.202.45.224])
by relay1.apple.com (8.12.11/8.12.11) with SMTP id iB6LG7S3009586
for ; Mon, 6 Dec 2004 13:16:07 -0800 (PST)
Message-Id: <200412062116.iB6LG7S3009586@relay1.apple.com>
Subject: Re: EDNS0 numbers
Date: Mon, 6 Dec 2004 13:16:06 -0800
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire
To:
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
> I would just write an ID and request a option code in
> IANA Considerations.
The two EDNS0 extensions in question are:
"Dynamic DNS Update Leases" (Garbage collection for Dynamic Update:
Added records have a lifetime, and are automatically deleted if not
renewed before expiration.)
"Long-Lived Queries for DNS" (Server notifies client when answer
to a given question changes, as an alternative to polling.)
They are documented at:
Stuart Cheshire
* Wizard Without Portfolio, Apple Computer, Inc.
* www.stuartcheshire.org
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Thu Dec 9 06:32:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14205
for ; Thu, 9 Dec 2004 06:32:13 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CcMQN-000Kbw-5A
for namedroppers-data@psg.com; Thu, 09 Dec 2004 11:25:31 +0000
Received: from [193.0.0.199] (helo=postman.ripe.net)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CcMQK-000Kbb-72
for namedroppers@ops.ietf.org; Thu, 09 Dec 2004 11:25:28 +0000
Received: by postman.ripe.net (Postfix, from userid 8)
id 8C32425896; Thu, 9 Dec 2004 12:25:27 +0100 (CET)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
by postman.ripe.net (Postfix) with ESMTP id 12E90244C2
for ; Thu, 9 Dec 2004 12:25:25 +0100 (CET)
Received: from x50.ripe.net (x50.ripe.net [193.0.1.50])
by birch.ripe.net (8.12.10/8.11.6) with SMTP id iB9BPPLE008034
for ; Thu, 9 Dec 2004 12:25:25 +0100
Date: Thu, 9 Dec 2004 12:25:24 +0100
From: "Olaf M. Kolkman"
To: namedroppers@ops.ietf.org
Subject: IETF61 DNSEXT Minutes
Message-Id: <20041209122524.2fab51f6.olaf@ripe.net>
Organization: RIPE NCC
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_05
X-RIPE-Spam-Status: U 0.220068 / -3.7
X-RIPE-Signature: 08466b3a4f53947f6d31cffbb63c0839
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
DNSEXT WG notes 11/10/04 @ 13:00
Washington DC, IETF 61
Scribe: Scott Rose
Jabber scribe: George Michaelson
- 2538bis Request for input
proxy: Olafur Gudmundsson
draft-josefsson-rfc2538bis-00.txt
RFC2538bis CERT RR Simon Josefsson has taken on the task of updating
and advancing the document along the standards track. Send him
comments on the document and reports of implementations. If no
changes, we can advance it, otherwise rev it and then advance it.
Goal: to finish this before next IETF meeting
- Key crypto
Donald Eastlake
draft-ietf-dnsext-ecc-key-05 and
draft-ietf-dnsext-tsig-sha-00
o ECC - Draft only defines key format, not RRSIG
format.
Questions for group:
- Include RRSIG format back into draft?
- Make format applicable to KEY/DNSKEY and IPSECKEY
There was a question if there are any crypto libraries that
contain ECC, at least one open source one was identified.
o TSIG-SHA: Specification of the SHA with various
http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-8/sld1.htm
sizes. includes specification for truncation to shorter MACs
Open questions that need to go to WG:
- Why go to SHA1 it it is no longer than MD5?
- Why not standardize on longer SHA1?
Donald's answer:Some crypto people like SHA1, and it is quicker
to compute.
Follow up
- why have to allocate all these names?
- take discussion to list
WGLC action to be issued soon
- QR clarification
Roy Arends
draft-arends-dnsext-qr-clarification-00.txt
Summary in one line: Servers must not answer an incoming message
with the QR bit set.
Room does not object if this document becomes a WG document.
Based on discussion Roy needs to update document to have slightly
better definition on what the scope is (ie. only about the Q/R
bits).
- Wildcard clarification
Ed Lewis
draft-ietf-dnsext-wcard-clarify-03.txt
New material (editorial concerns)
1. Drop "clarifying" from title
2. include text on "* IN DS"
presentation on what "* IN DS" could mean
RFC1034: if the query has a qname="*", the results should not be cached...
Example in presentation:
************************************************
Zone has *.example. IN 3600 NS bogon.example.
*.example. IN 3600 NSEC twn.example. NS NSEC RRSIG
twn.example. IN 3600 NSEC twp.example. ...
twn.example. IN 3600 RRSIG NSEC ... signed by example. ...
twp.example. IN 3600 NSEC example. ...
Query: two.example. IN NS
Answer has (?):
AA = 1, RCODE = 0 (not name error)
Answer: two.example. IN 3600 NS bogon.example.
Authority: twn.example. IN 3600 NSEC twp.example. ...
twn.example. IN 3600 RRSIG NSEC ... signed by example. ...
Suggested fixes:
a. outlaw loading zones with * NS
b. exempt certain types from wildcard processing
c. instruct DNSSEC validators to ignore "problem"
d. Specify * label can't have certain types and cannot be subdomained
Questions:
There where some statements that c. was the right way to go, but
need for a clear definition what that means. There was also
discussion that this is an answer not a referral but that needs to
be discussed on the mailing list.
- Requirements for future work on Denial of Existence (approx 20 minutes)
Olaf Kolkman
Chairs had a meetings with req. editors and others to prioritize
reqs and solution sets at the IETF to facilitate high bandwidth
exchanges.
Rip Loomis presentation on the priority of requirements"
http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-2/sld1.htm
Please read slides for full contents of this presentation) New ID
Will contain a list of the requirements as the priority: Required,
med-level desire, low-level desire, very low-level desire.
There was discussion on exposing online keys, not everyone is
concerned with zone enumeration, but some are. Some of the "don't
care" about zone walking may care about having keys online
In the discussion about "Universal signing": Which zones can (under
which conditions) not be signed?
Ans: some zones with long domain names may not be able to be signed
with hashed based schemes (over 255 label limit)
A comment was made that current NSEC design and DNSSEC does not
cover the RCODE in the message. Some of the proposed solutions to
zone walking cover RCODE.
Olaf K and proposals for zone walking:
http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-0.pdf (pages
9-11)
There are basicly two characteristics of proposals, hash-based or
online-signing both have various flavors, and they measure
differently against requirements/constraints. WG needs to evaluate
proposals against priority list of requirements and form plan for
possible long term solution.
The three main categories of solutions are
Epsilon signing (white lies)
New type for Negative answers that contains information from the
query (called magic type in the discussion, better name
needed)
Hash based solutions with varying flavors of Opt-in and wildcards
Proposed way forward:
o Fast track Epsilon Signing as that has minimal impact on
implementations (only authorative servers affected) and moves the
cost of deployment on the parties that can not live with NSEC;
o and work on a protocol change that does not need on-line keys.
Goal is to have at most one DNSSECter (ie solutions that require
changes in resolvers)
Question: Does this way forward make sense? Room seems to think so.
- DNSSEC keymanagement issues
Johan Ihren
draft-ietf-dnsext-trustupdate-threshold-00.txt
Mike StJohns
Ben Laurie
draft-laurie-dnssec-key-distribution-00.txt
DNSSEC key management issues
Johan Ihren (Threshold based trust update)
http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-3/sld1.htm
Possible IPR issues with schema editors will investigate.
Draft is better, implementation of version 00 is available
Changes in draft:
o Simplified Definition of M and N threshold params
o Documented the state machine better
o Fixed the replay attack that was possible before
No questions
Question: how long to complete?
Ihren: fairly complete with some issues. Priming stuff needs more
work. Overall it works. IPR issues are up in the air.
Mike St Johns (rolling over the trust anchor)
http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-4/sld1.htm
No major changes from prior version mainly related to timers and
DNSKEY removal from apex.
Question to group - is it worth pursuing an in-band mechanism?
Ben Laurie (DNS Key distribution)
new, individual submission
(draft-laurie-dnssec-key-distribution-00.txt) not a WG item yet:
need more readers/comments/etc! Islands of trust issues, some
people don`t like single auth. inband stuff is tricky. lots of keys,
lots of data Mechanism is cross-signing scheme. start with one,
fetch more. can recurse or stop
Closing remarks
Olafur Gudmundsson: WG is to consider which KEY mechanisms to promote.
Timers and Threshold both say they are close to be ready for LC.
Chair to check with Security AD if there are any obvious security
problems with either proposal.
- Cross fertilization
(DNS related work in other groups that needs review)
James Snell
draft-snell-dnsepd-00.txt
draft-iab-dns-choices-00.txt
Patrik Faltstrom
DNS issues in SPF
Stephane Bortzmeyer
+ James Snell(DNS Endpoint discovery)
http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-5/sld1.htm
Individual submission not seeking to be a WG document
(draft-snell-dnsepd-00.txt)
This is used for providing web-services tools
2 new RR: XML and EPR
There where concerns that the XML RR was to open and should be
changed to Web services only with restrictions. Number of people
suggested that they use NAPTR records for this. Editors thanked
for feedback and will update documents based on that.
+ Patrik Faltstrom (DNS Design Choices)
IAB draft: (draft-iab-dns-choices)
- discussion of DNS choices in protocol design.
- question about scope of who to go to with DNS questions
involving new DNS RRs
- TomasN: 2 part response:
1 is it going to hurt DNS?
2. Does it help the protocol in question that is requesting it?
DNSEXT or successor will deal with topic 1. .
- Is there a need to have a separate draft to request the new RR type?
A: no.
Stephane Bortzmeyer (DNS and SPF)
http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-6.pdf
non-wg draft: draft-lentczner-spf-00.txt
SPF: Sender Policy Framework. this is a request for a new RR type
used by mail-servers to detect spoofed email's. SPF is defined as
TXT RR with a new name.
There where concerns with reusing TXT due to implementation
problems in the past. Suggestion from WG to specify a new RR with
one RDATA field and use RDLEN as indicator of how long the data
is. There where also questions raised about the recommendation
that Mail server check for both types (TXT and SPF) and the
policies for issuing these queries (serial, parallel, which one
takes preference).
End of meeting
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Thu Dec 9 14:14:03 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23025
for ; Thu, 9 Dec 2004 14:14:03 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CcTeW-000Ng1-Ti
for namedroppers-data@psg.com; Thu, 09 Dec 2004 19:08:36 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CcTeV-000NfQ-LU
for namedroppers@ops.ietf.org; Thu, 09 Dec 2004 19:08:36 +0000
Received: from [10.31.33.98] (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id iB9J8QRk097650;
Thu, 9 Dec 2004 14:08:27 -0500 (EST)
(envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
Date: Thu, 9 Dec 2004 14:02:31 -0500
To: namedroppers
From: Edward Lewis
Subject: wild card validation question
Cc: ed.lewis@neulevel.biz
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.48 on 66.92.146.160
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Regarding this from the minutes:
# Example in presentation:
# ************************************************
# Zone has *.example. IN 3600 NS bogon.example.
# *.example. IN 3600 NSEC twn.example. NS NSEC RRSIG
#
# twn.example. IN 3600 NSEC twp.example. ...
# twn.example. IN 3600 RRSIG NSEC ... signed by example. ...
#
# twp.example. IN 3600 NSEC example. ...
#
# Query: two.example. IN NS
#
# Answer has (?):
# AA = 1, RCODE = 0 (not name error)
# Answer: two.example. IN 3600 NS bogon.example.
# Authority: twn.example. IN 3600 NSEC twp.example. ...
# twn.example. IN 3600 RRSIG NSEC ... signed by example. ...
#
# Suggested fixes:
# a. outlaw loading zones with * NS
# b. exempt certain types from wildcard processing
# c. instruct DNSSEC validators to ignore "problem"
# d. Specify * label can't have certain types and cannot be subdomained
#
# Questions:
#
# There where some statements that c. was the right way to go, but
# need for a clear definition what that means. There was also
# discussion that this is an answer not a referral but that needs to
# be discussed on the mailing list.
I've been meaning to post this to the list, but my schedule has
prevented me from doing so.
Note that the reply here is not a referral - the NS appears in the
answer section, as it is the answer to the query. (This is why an NS
query is used as an example.)
Answer C does seem to be the smoothest way out - unless your metric
is code smoothness. The implication is that the validator has to
understand the special case-ness of this situation. (We may also see
this is true for DS records too, I haven't gotten that far yet.)
Are we willing to accept that the validator is going to be "smart
enough" to understand the odd ball case here? (5 points extra credit
for whoever can enumerate the conditions in which an NS RRSet is
properly signed by the "parent.")
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"A noble spirit embiggens the smallest man." - Jebediah Springfield
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Fri Dec 10 04:01:02 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24887
for ; Fri, 10 Dec 2004 04:01:01 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CcgYU-0001oT-7E
for namedroppers-data@psg.com; Fri, 10 Dec 2004 08:55:14 +0000
Received: from [193.0.0.199] (helo=postman.ripe.net)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CcgYS-0001o8-Py
for namedroppers@ops.ietf.org; Fri, 10 Dec 2004 08:55:13 +0000
Received: by postman.ripe.net (Postfix, from userid 8)
id 2AC8F25218; Fri, 10 Dec 2004 09:55:12 +0100 (CET)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
by postman.ripe.net (Postfix) with ESMTP id E8C3825218
for ; Fri, 10 Dec 2004 09:55:08 +0100 (CET)
Received: from x50.ripe.net (x50.ripe.net [193.0.1.50])
by birch.ripe.net (8.12.10/8.11.6) with SMTP id iBA8t8LE004946
for ; Fri, 10 Dec 2004 09:55:08 +0100
Date: Fri, 10 Dec 2004 09:55:08 +0100
From: "Olaf M. Kolkman"
To: namedroppers@ops.ietf.org
Subject: Fw: I-D ACTION:draft-laurie-dnsext-nsec2v2-00.txt
Message-Id: <20041210095508.2ab1a1c7.olaf@ripe.net>
Organization: RIPE NCC
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary="Multipart=_Fri__10_Dec_2004_09_55_08_+0100_lUWE3yIPYnUlqnq1"
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00
X-RIPE-Spam-Status: N 0.006749 / -5.9
X-RIPE-Signature: 69f5a94708e603887fd0f139cbbcb7df
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
This is a multi-part message in MIME format.
--Multipart=_Fri__10_Dec_2004_09_55_08_+0100_lUWE3yIPYnUlqnq1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
FYI
--Olaf
---------------------- Begin forwarded message ----------------------
Date: Thu, 09 Dec 2004 15:44:12 -0500
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D ACTION:draft-laurie-dnsext-nsec2v2-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : DNSSEC NSEC2 Owner and RDATA Format
Author(s) : B. Laurie, G. Sission
Filename : draft-laurie-dnsext-nsec2v2-00.txt
Pages : 11
Date : 2004-12-9
The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be
used to provide authenticated denial of existence of DNS owner names
and types; however, it also permits any user to obtain a listing of
all DNS owner names in a zone. This can accomplished via successive
DNS queries for all NSEC RRs in that zone.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-laurie-dnsext-nsec2v2-00.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-laurie-dnsext-nsec2v2-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-laurie-dnsext-nsec2v2-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
---------------------- End forwarded message ------------------------
--
---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
--Multipart=_Fri__10_Dec_2004_09_55_08_+0100_lUWE3yIPYnUlqnq1
Content-Type: Message/External-body;
name="00000000.mimetmp"
Content-Disposition: attachment;
filename="00000000.mimetmp"
Content-Transfer-Encoding: base64
Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA0LTEyLTkxNTU4MzUuSS1E
QGlldGYub3JnPgoKRU5DT0RJTkcgbWltZQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGF1
cmllLWRuc2V4dC1uc2VjMnYyLTAwLnR4dAoK
--Multipart=_Fri__10_Dec_2004_09_55_08_+0100_lUWE3yIPYnUlqnq1
Content-Type: Message/External-body;
name="draft-laurie-dnsext-nsec2v2-00.txt"
Content-Disposition: attachment;
filename="draft-laurie-dnsext-nsec2v2-00.txt"
Content-Transfer-Encoding: base64
Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA0LTEyLTkxNTU4MzYuSS1E
QGlldGYub3JnPgoKCg==
--Multipart=_Fri__10_Dec_2004_09_55_08_+0100_lUWE3yIPYnUlqnq1--
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Fri Dec 10 04:42:20 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27665
for ; Fri, 10 Dec 2004 04:42:20 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CchF4-0006vv-Ss
for namedroppers-data@psg.com; Fri, 10 Dec 2004 09:39:14 +0000
Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CchF1-0006vd-DY
for namedroppers@ops.ietf.org; Fri, 10 Dec 2004 09:39:11 +0000
Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218])
by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP
id 92FD68B801; Fri, 10 Dec 2004 09:39:10 +0000 (GMT)
Message-ID: <41B96EBF.3020009@algroup.co.uk>
Date: Fri, 10 Dec 2004 09:39:11 +0000
From: Ben Laurie
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Olaf M. Kolkman"
Cc: namedroppers@ops.ietf.org
Subject: Re: Fw: I-D ACTION:draft-laurie-dnsext-nsec2v2-00.txt
References: <20041210095508.2ab1a1c7.olaf@ripe.net>
In-Reply-To: <20041210095508.2ab1a1c7.olaf@ripe.net>
X-Enigmail-Version: 0.89.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Olaf M. Kolkman wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> Title : DNSSEC NSEC2 Owner and RDATA Format
> Author(s) : B. Laurie, G. Sission
> Filename : draft-laurie-dnsext-nsec2v2-00.txt
> Pages : 11
> Date : 2004-12-9
So's you know, there was a screwup with the I-D editors and the previous
versions of this, meaning I had to rename it to get it into the queue.
This version is also generated from XML instead of nroff, and has real
examples in it (generated by a patched version of BIND 9.3 - patches
available if you want them). Other changes are minor.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Fri Dec 10 08:09:04 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12278
for ; Fri, 10 Dec 2004 08:09:04 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CckQh-000402-QA
for namedroppers-data@psg.com; Fri, 10 Dec 2004 13:03:27 +0000
Received: from [17.254.13.22] (helo=mail-out3.apple.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CckQW-0003yo-1o
for namedroppers@ops.ietf.org; Fri, 10 Dec 2004 13:03:16 +0000
Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225])
by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id iBADAKSh013770
for ; Fri, 10 Dec 2004 05:10:20 -0800 (PST)
Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com
(Content Technologies SMTPRS 4.3.17) with ESMTP id for ;
Fri, 10 Dec 2004 05:04:26 -0800
Received: from [17.219.199.108] ([17.219.199.108])
by relay2.apple.com (8.12.11/8.12.11) with SMTP id iBAD2wlb028913
for ; Fri, 10 Dec 2004 05:02:59 -0800 (PST)
Message-Id: <200412101302.iBAD2wlb028913@relay2.apple.com>
Subject: Re: EDNS0 numbers
Date: Fri, 10 Dec 2004 05:03:01 -0800
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire
To:
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
>I can't find the registry either. (IANA, where are you?) But section
>7 of RFC2671 says:
>
> IESG approval should be required to create new entries in the EDNS
> Extended Label Type or EDNS Version Number registries, while any
> published RFC (including Informational, Experimental, or BCP)
> should be grounds for allocation of an EDNS Option Code.
>
>While very clear, this metric doesn't fall into any of the buckets in
>RFC2434. It sounds closest to "IETF Consensus" (or "IETF Review", as
>used by draft-narten-iana-considerations-rfc2434bis-01.txt), but one
>could argue that it was intended to be "Specification Required".
Thanks.
I plan to send an email to IANA requesting:
EDNS0 option code 1 for "Long-Lived Queries for DNS"
, and
EDNS0 option code 2 for "Dynamic DNS Update Leases"
.
Stuart Cheshire
* Wizard Without Portfolio, Apple Computer, Inc.
* www.stuartcheshire.org
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 14 03:33:40 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01218
for ; Tue, 14 Dec 2004 03:33:39 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1Ce7xl-000Ggh-Qp
for namedroppers-data@psg.com; Tue, 14 Dec 2004 08:23:17 +0000
Received: from [193.0.0.199] (helo=postman.ripe.net)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1Ce7xW-000GeP-CU
for namedroppers@ops.ietf.org; Tue, 14 Dec 2004 08:23:02 +0000
Received: by postman.ripe.net (Postfix, from userid 8)
id 75A2524CB0; Tue, 14 Dec 2004 09:23:01 +0100 (CET)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
by postman.ripe.net (Postfix) with ESMTP
id 52AE924B0C; Tue, 14 Dec 2004 09:22:57 +0100 (CET)
Received: from x50.ripe.net (x50.ripe.net [193.0.1.50])
by birch.ripe.net (8.12.10/8.11.6) with SMTP id iBE8MvLE009943;
Tue, 14 Dec 2004 09:22:57 +0100
Date: Tue, 14 Dec 2004 09:22:57 +0100
From: "Olaf M. Kolkman"
To: namedroppers@ops.ietf.org
Cc: James Snell
Subject: Re: DNS-EPD Updates [was Re: New Internet-Draft: DNS-Endpoint
Discovery (http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt)]
Message-Id: <20041214092257.60f876bd.olaf@ripe.net>
In-Reply-To: <2bcdc7c404112312564379f11f@mail.gmail.com>
References:
<41A1BF98.9030107@algroup.co.uk>
<20041122160405.D842913E12@sa.vix.com>
<2bcdc7c404112211215d62904b@mail.gmail.com>
<2bcdc7c404112312564379f11f@mail.gmail.com>
Organization: RIPE NCC
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00
X-RIPE-Spam-Status: N 0.011799 / -5.9
X-RIPE-Signature: 1da2844ed2410c4c16f6a26abc474c9d
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Dear Colleagues,
On Tue, 23 Nov 2004 12:56:31 -0800
James Snell wrote:
> FYI... the -01 version of the DNS-EPD specification has been posted.
>
> http://www.ietf.org/internet-drafts/draft-snell-dnsepd-01.txt
IMHO James seems to have covered all concerns that were brought up during
the last IETF and on the list. Please review this document on the DNS
specifics issues and make issues known on this list.
If we do not receive any further feedback and if so asked by the AD
that is to review this work, the chairs will say that this group has
critically reviewed the DNS issues and that all issues raised have
been addressed.
-- Olaf
---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 14 06:28:04 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14333
for ; Tue, 14 Dec 2004 06:28:03 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CeAf8-000C4D-8i
for namedroppers-data@psg.com; Tue, 14 Dec 2004 11:16:14 +0000
Received: from [193.94.160.1] (helo=netcore.fi)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CeAf2-000C21-5s
for namedroppers@ops.ietf.org; Tue, 14 Dec 2004 11:16:08 +0000
Received: from localhost (pekkas@localhost)
by netcore.fi (8.11.6/8.11.6) with ESMTP id iBEBG5S19518;
Tue, 14 Dec 2004 13:16:06 +0200
Date: Tue, 14 Dec 2004 13:16:05 +0200 (EET)
From: Pekka Savola
To: namedroppers@ops.ietf.org
cc: paf@cisco.com, sra@isc.org
Subject: draft-iab-dns-choices-00 comments
Message-ID:
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1400303138-1103022755=:19423"
Content-ID:
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--1589707168-1400303138-1103022755=:19423
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; format=flowed
Content-ID:
Content-Transfer-Encoding: 8BIT
Hi,
The fight over draft-iab-dns-choices-00 appears to have settled down a
bit.. I wonder how it's going forward. In any case, below are the
comments I sent in May but for which I didn't get a response to.
In summary, I think the document should be either more focused (be
more clear from the start, title, etc. that it's only interested in
storing arbitrary data in the DNS) or more generic (data storage and
record discovery). Currently it seems to be including a bit of both,
but not doing a sufficiently complete job on both.
---------- Forwarded message ----------
Date: Thu, 20 May 2004 12:24:45 +0300 (EEST)
From: Pekka Savola
To: Patrik Fältström
Cc: sra@isc.org
Subject: Re: I-D ACTION:draft-ymbk-dns-choices-00.txt
[...]
major issues
------------
1) the existence of wildcards (or not) seems to be dominating at
least some design choices [and being overly assumptive about being
used in an MX environment]. It might make sense to discuss this in a
more explicit manner. For example, for certain kinds of applications,
the usage of wildcards might not prevent specific kinds of approaches,
or you might be able to just say "don't push if there's resistance".
2) I think the document either needs to be more focused or needs more
text. As it is, the doc seems mostly centered on applications wanting
to store all kinds of data (not facilitated by the existing records,
if not for TXT) in the DNS. I see a couple of different aspects which
may result in a different kind of conclusions, at least:
a) using DNS for service discovery, but so that the result of that
discovery is properly defined DNS record or hostname.
b) using DNS to store service/application-specific data, in a
fashion that isn't easily facilitated with current records (e.g.,
keying material, certificates, other kinds of data, etc.)
c) something else?
These approaches have a number of common issues like "where in the
domain tree to put this data?", "who are the users of that data, and
how can they find it?", and "which records to use to store the data?"
-- but the answers to these questions, and others, might vary
depending on what you want to be doing.
more or less substantial
------------------------
Even when a specific prefix is chosen, the data will still have to beM
stored in some RR type. This RR type can either be a "kitchen-sinkM
record" or a new RR type. This implies that some other mechanism hasM
to be applied as well, with implications detailed in other parts ofM
this note.M
==> For non native speakers, it may not be 100% certain what you refer
to with a 'kitchen-sink record' maybe worth spelling out?
==> I couldn't find that "other part of this note". Could you be more
specific in the reference and/or spell this out better?
(I think this is part of the distinction between "where to put the
data" and "how to encode the data" -- maybe 3.2 and 3.3 should go into
their own section, or the like?)
Adding a new RR type is the technically correct answer from the DNSM
protocol standpoint (more on this below), doing so requires some DNSM
expertise, due to the issues listed in Section 3.5. As a result,M
this option is usually considered too hard.M
==> it might be worth pointing here to RFC2929 that some types require
IETF Consensus, but some only Specification Required.
4. The case against protocol use of TXT RRs
==> this, again, is a case about using TXT RRs for _storing_
arbitrary data in the DNS, but doesn't address e.g., the service
discovery issues. (Of course, you could try to do service discovery
by storing the parameters in appropriately located TXT records, but
that's probably not so interesting for anyone..)
Using one of the naming modifications discussed in Section 3.2 andM
Section 3.3 would address the subtyping problem, but each of theseM
approaches brings in new problems of its own. The prefix approachM
(such as SRV RRs use) does not work well with wildcards, which is aM
particular problem for mail-related applications, since MX RRs areM
probably the most common use of DNS wildcards.
==> again, here, IMHO at least in most cases the answer could be like,
"if it hurts, don't do it" (meaning either the application, or the use
of wildcards). As long as the application designers are aware how
wildcards operate and how they are (or not) deployed, using a
mechanism which might not work 100% with wildcards might be entirely
editorial
---------
application. DNS extension discussion too often circulate aroundM
reuse of the TXT record. This document lists different mechanisms toM
==> s/circulate/circulates/ ?
accomplish the extension to DNS, and comes to the conclusion use of aM
new RR Type is the best solution.M
==> s/use/that the use/
Historically, extension of DNS to store data for applications tied toM
a domain name has been done in different ways at different times. MXM
==> s/extension of/extending/ (sounds better)
Adding a new RR type is the technically correct answer from the DNSM
protocol standpoint (more on this below), doing so requires some DNSM
expertise, due to the issues listed in Section 3.5. As a result,M
==> s/doing/but doing/
lack of defined semantics becomes a problem, because there is nothingM
to prevent collisions some other incompatible use of TXT RRs.
==> s/collisions/collisions with/ ?
8 ReferencesM
==> split to norm/informative refs, please
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--1589707168-1400303138-1103022755=:19423--
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 14 10:56:01 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11682
for ; Tue, 14 Dec 2004 10:56:00 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CeEtZ-000Lm7-7H
for namedroppers-data@psg.com; Tue, 14 Dec 2004 15:47:25 +0000
Received: from [192.134.4.11] (helo=mx2.nic.fr)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CeEtT-000Llg-QJ
for namedroppers@ops.ietf.org; Tue, 14 Dec 2004 15:47:19 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
by mx2.nic.fr (Postfix) with ESMTP
id BB73126C097; Tue, 14 Dec 2004 16:47:18 +0100 (CET)
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151])
by mx2.nic.fr (Postfix) with ESMTP
id 4456026C095; Tue, 14 Dec 2004 16:47:17 +0100 (CET)
Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68])
by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id iBEFlG8q717057;
Tue, 14 Dec 2004 16:47:16 +0100 (CET)
Received: by vespucci.nic.fr (Postfix, from userid 1055)
id 94414FB39; Tue, 14 Dec 2004 16:47:16 +0100 (CET)
Date: Tue, 14 Dec 2004 16:47:16 +0100
From: Stephane Bortzmeyer
To: "Olaf M. Kolkman"
Cc: namedroppers@ops.ietf.org
Subject: Re: IETF61 DNSEXT Minutes
Message-ID: <20041214154716.GA17384@nic.fr>
References: <20041209122524.2fab51f6.olaf@ripe.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041209122524.2fab51f6.olaf@ripe.net>
X-Operating-System: Debian GNU/Linux testing/unstable
X-Kernel: Linux 2.4.26-1-k7 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.6+20040907i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
On Thu, Dec 09, 2004 at 12:25:24PM +0100,
Olaf M. Kolkman wrote
a message of 283 lines which said:
> There where concerns with reusing TXT due to implementation
> problems in the past.
I believe it is less ambiguous to say that "There where concerns with
reusing TXT *format*".
Otherwise, for those who wonder what happened since, the SPF group at
last succeeded in structuring and has now a beautiful SPF council,
with several tasks, one of the highest priorities being to move the
draft to a RFC. It will probably be a different draft which is
"almost" ready so that's the reason why there was no news from us.
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 14 12:20:02 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22914
for ; Tue, 14 Dec 2004 12:20:02 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CeGE6-0008f8-BL
for namedroppers-data@psg.com; Tue, 14 Dec 2004 17:12:42 +0000
Received: from [200.23.30.77] (helo=mail.nic.mx)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CeGDt-0008cn-Bh
for namedroppers@ops.ietf.org; Tue, 14 Dec 2004 17:12:29 +0000
Received: from localhost (localhost.nic.mx [127.0.0.1])
by mail.nic.mx (Postfix) with ESMTP id 9B02D183001
for ; Tue, 14 Dec 2004 11:12:28 -0600 (CST)
Received: from mail.nic.mx ([127.0.0.1])
by localhost (mail.nic.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
id 90759-03 for ;
Tue, 14 Dec 2004 11:12:28 -0600 (CST)
Received: from glozano.mail.nic.mx (unknown [200.33.1.76])
by mail.nic.mx (Postfix) with ESMTP id 46D07182FD8
for ; Tue, 14 Dec 2004 11:12:28 -0600 (CST)
Message-Id: <6.2.0.14.2.20041214111013.0a64b7f8@mail.nic.mx>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Tue, 14 Dec 2004 11:12:28 -0600
To: namedroppers@ops.ietf.org
From: Gustavo Lozano Ibarra
Subject: draft-lozano-nsec-random-00
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: by amavisd-new at nic.mx
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50,MIME_QP_LONG_LINE
autolearn=ham version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable
I have been talking with some colleagues at NIC Mexico and others=
organizations about an idea to address the issue of DNS enumeration in the=
DNSSECbis protocol.
I wrote a draft describing the idea and I would appreciate receiving=
comments about it.
The draft :=
http://www.ietf.org/internet-drafts/draft-lozano-nsec-random-00.txt
Thank you.
--
=20
Gustavo Lozano Ibarra
NIC-Mexico Top Level Domain .MX
http//www.nic.mx
Tel/Fax. +52(81)83875346 ext. 117
El contenido del presente mensaje de datos es confidencial y no podr=E1=20
modificarse, distribuirse y/o difundirse por ning=FAn medio sin la previa=20
autorizaci=F3n del emisor original, as=ED mismo no se considera oferta,=20
propuesta o acuerdo. El Emisor no es apoderado de NIC-M=E9xico ni tiene=20
facultad alguna para obligar a NIC-M=E9xico con la transmisi=F3n y contenido=
del=20
presente mensaje de datos, incluyendo el (los) archivo(s) anexo(s).
The content of this data transmission is confidential, therefore, it shall=
=20
not be modified, distributed and/or disclosed through any mean without the=
=20
original sender's previous authorization. Any information, offer or=20
agreement made by the sender of this data transmission, should be considered=
=20
as personal and not binding for NIC-Mexico. =20
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 14 12:37:39 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24603
for ; Tue, 14 Dec 2004 12:37:39 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CeGWz-000BRd-SM
for namedroppers-data@psg.com; Tue, 14 Dec 2004 17:32:13 +0000
Received: from [65.201.175.9] (helo=mail.verisignlabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CeGWe-000BMO-Ku
for namedroppers@ops.ietf.org; Tue, 14 Dec 2004 17:31:52 +0000
Received: from [10.131.244.227] ([::ffff:172.25.170.10])
(AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by mail.verisignlabs.com with esmtp; Tue, 14 Dec 2004 12:31:51 -0500
id 0054C08F.41BF2387.00004283
Message-ID: <41BF2387.1040100@verisignlabs.com>
Date: Tue, 14 Dec 2004 12:31:51 -0500
From: David Blacka
Organization: VeriSign, Inc.
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Gustavo Lozano Ibarra
CC: namedroppers@ops.ietf.org
Subject: Re: draft-lozano-nsec-random-00
References: <6.2.0.14.2.20041214111013.0a64b7f8@mail.nic.mx>
In-Reply-To: <6.2.0.14.2.20041214111013.0a64b7f8@mail.nic.mx>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Gustavo Lozano Ibarra wrote:
> I have been talking with some colleagues at NIC Mexico and others organizations about an idea to address the issue of DNS enumeration in the DNSSECbis protocol.
>
> I wrote a draft describing the idea and I would appreciate receiving comments about it.
>
> The draft : http://www.ietf.org/internet-drafts/draft-lozano-nsec-random-00.txt
Well, for one, you would be enabling a man in the middle to provably
deny the existence of anything in the zone, which is contrary to the
design goals of DNSSEC.
--
David Blacka
Sr. Engineer VeriSign Applied Research
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 14 14:58:01 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10775
for ; Tue, 14 Dec 2004 14:58:00 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CeIcj-0001zT-Vs
for namedroppers-data@psg.com; Tue, 14 Dec 2004 19:46:17 +0000
Received: from [17.254.13.23] (helo=mail-out4.apple.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CeIce-0001xw-Oh
for namedroppers@ops.ietf.org; Tue, 14 Dec 2004 19:46:12 +0000
Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225])
by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id iBEJsKCm017633
for ; Tue, 14 Dec 2004 11:54:20 -0800 (PST)
Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com
(Content Technologies SMTPRS 4.3.17) with ESMTP id for ;
Tue, 14 Dec 2004 11:47:29 -0800
Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119])
by relay2.apple.com (8.12.11/8.12.11) with SMTP id iBEJkABE013280
for ; Tue, 14 Dec 2004 11:46:10 -0800 (PST)
Message-Id: <200412141946.iBEJkABE013280@relay2.apple.com>
Subject: Unexpected DNS responses
Date: Tue, 14 Dec 2004 11:46:11 -0800
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire
To:
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
When doing a DNS query at Apple, I'm seeing strange results.
A query for the address record for login.oscar.aol.com reveals that it is
an alias for login.glogin.messaging.aol.com. The address for
login.glogin.messaging.aol.com is also given: 64.12.200.89.
>[chesh7:~] cheshire% dig -t a login.oscar.aol.com
>
>; <<>> DiG 9.2.2 <<>> -t a login.oscar.aol.com
>;; global options: printcmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5932
>;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
>
>;; QUESTION SECTION:
>;login.oscar.aol.com. IN A
>
>;; ANSWER SECTION:
>login.oscar.aol.com. 123 IN CNAME login.glogin.messaging.aol.com.
>login.glogin.messaging.aol.com. 10 IN A 64.12.200.89
>
>;; AUTHORITY SECTION:
>glogin.messaging.aol.com. 98 IN NS mtc-gdns008.ns.aol.com.
>glogin.messaging.aol.com. 98 IN NS dtc-gdns008.ns.aol.com.
>
>;; ADDITIONAL SECTION:
>mtc-gdns008.ns.aol.com. 223 IN A 64.12.182.88
>dtc-gdns008.ns.aol.com. 215 IN A 205.188.139.88
>
>;; Query time: 8 msec
>;; SERVER: 17.128.100.10#53(17.128.100.10)
>;; WHEN: Tue Dec 14 11:38:01 2004
>;; MSG SIZE rcvd: 177
However, a query for the AAAA record for login.oscar.aol.com gives a
no-error no-answer result for login.glogin.messaging.aol.com!
The question in the question section of the result doesn't match the
question that was asked, and the client ignores it as bogus.
There's no CNAME record in the response to indicate to the client that
login.oscar.aol.com is actually an alias for
login.glogin.messaging.aol.com: the client asks for X and gets an answer
for Y, with no indication why an answer for Y is relevant.
>[chesh7:~] cheshire% dig -t aaaa login.oscar.aol.com
>
>; <<>> DiG 9.2.2 <<>> -t aaaa login.oscar.aol.com
>;; global options: printcmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61168
>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
>;; QUESTION SECTION:
>;login.glogin.messaging.aol.com. IN AAAA
>
>;; Query time: 82 msec
>;; SERVER: 17.128.100.10#53(17.128.100.10)
>;; WHEN: Tue Dec 14 11:41:55 2004
>;; MSG SIZE rcvd: 48
>
>[chesh7:~] cheshire%
Is this a bogus caching DNS server, or is this kind of response normal
and expected? Should the client handle this, or is the client right to
ignore it?
Stuart Cheshire
* Wizard Without Portfolio, Apple Computer, Inc.
* www.stuartcheshire.org
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 14 16:17:55 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19190
for ; Tue, 14 Dec 2004 16:17:55 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CeJsp-0005be-Et
for namedroppers-data@psg.com; Tue, 14 Dec 2004 21:06:59 +0000
Received: from [204.152.187.5] (helo=farside.isc.org)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CeJsk-0005at-29
for namedroppers@ops.ietf.org; Tue, 14 Dec 2004 21:06:54 +0000
Received: from drugs.dv.isc.org (localhost [IPv6:::1])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id 5F102677EF
for ; Tue, 14 Dec 2004 21:06:53 +0000 (UTC)
(envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iBEL6kZ5070358;
Wed, 15 Dec 2004 08:06:46 +1100 (EST)
(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200412142106.iBEL6kZ5070358@drugs.dv.isc.org>
To: Stuart Cheshire
Cc: namedroppers@ops.ietf.org
From: Mark Andrews
Subject: Re: Unexpected DNS responses
In-reply-to: Your message of "Tue, 14 Dec 2004 11:46:11 -0800."
<200412141946.iBEJkABE013280@relay2.apple.com>
Date: Wed, 15 Dec 2004 08:06:46 +1100
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
> When doing a DNS query at Apple, I'm seeing strange results.
>
> A query for the address record for login.oscar.aol.com reveals that it is
> an alias for login.glogin.messaging.aol.com. The address for
> login.glogin.messaging.aol.com is also given: 64.12.200.89.
>
> >[chesh7:~] cheshire% dig -t a login.oscar.aol.com
> >
> >; <<>> DiG 9.2.2 <<>> -t a login.oscar.aol.com
> >;; global options: printcmd
> >;; Got answer:
> >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5932
> >;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
> >
> >;; QUESTION SECTION:
> >;login.oscar.aol.com. IN A
> >
> >;; ANSWER SECTION:
> >login.oscar.aol.com. 123 IN CNAME login.glogin.messaging.aol.com.
> >login.glogin.messaging.aol.com. 10 IN A 64.12.200.89
> >
> >;; AUTHORITY SECTION:
> >glogin.messaging.aol.com. 98 IN NS mtc-gdns008.ns.aol.com.
> >glogin.messaging.aol.com. 98 IN NS dtc-gdns008.ns.aol.com.
> >
> >;; ADDITIONAL SECTION:
> >mtc-gdns008.ns.aol.com. 223 IN A 64.12.182.88
> >dtc-gdns008.ns.aol.com. 215 IN A 205.188.139.88
> >
> >;; Query time: 8 msec
> >;; SERVER: 17.128.100.10#53(17.128.100.10)
> >;; WHEN: Tue Dec 14 11:38:01 2004
> >;; MSG SIZE rcvd: 177
>
> However, a query for the AAAA record for login.oscar.aol.com gives a
> no-error no-answer result for login.glogin.messaging.aol.com!
>
> The question in the question section of the result doesn't match the
> question that was asked, and the client ignores it as bogus.
>
> There's no CNAME record in the response to indicate to the client that
> login.oscar.aol.com is actually an alias for
> login.glogin.messaging.aol.com: the client asks for X and gets an answer
> for Y, with no indication why an answer for Y is relevant.
>
> >[chesh7:~] cheshire% dig -t aaaa login.oscar.aol.com
> >
> >; <<>> DiG 9.2.2 <<>> -t aaaa login.oscar.aol.com
> >;; global options: printcmd
> >;; Got answer:
> >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61168
> >;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> >
> >;; QUESTION SECTION:
> >;login.glogin.messaging.aol.com. IN AAAA
> >
> >;; Query time: 82 msec
> >;; SERVER: 17.128.100.10#53(17.128.100.10)
> >;; WHEN: Tue Dec 14 11:41:55 2004
> >;; MSG SIZE rcvd: 48
> >
> >[chesh7:~] cheshire%
>
> Is this a bogus caching DNS server, or is this kind of response normal
> and expected? Should the client handle this, or is the client right to
> ignore it?
The client should reject the second answer. You should upgrade /
replace the offending nameserver. Probably a old BIND 8 with the
following bug.
1650. [bug] NODATA responses from forwarders that followed
a CNAME were not handled correctly.
> Stuart Cheshire
> * Wizard Without Portfolio, Apple Computer, Inc.
> * www.stuartcheshire.org
>
>
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive:
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Thu Dec 16 15:25:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04986
for ; Thu, 16 Dec 2004 15:25:44 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1Cf23w-0006tK-VX
for namedroppers-data@psg.com; Thu, 16 Dec 2004 20:17:24 +0000
Received: from [65.201.175.9] (helo=mail.verisignlabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1Cf23r-0006rr-PQ
for namedroppers@ops.ietf.org; Thu, 16 Dec 2004 20:17:19 +0000
Received: from [10.131.244.227] ([::ffff:172.25.170.10])
(AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by mail.verisignlabs.com with esmtp; Thu, 16 Dec 2004 15:17:14 -0500
id 0054C0F5.41C1ED4A.000017A5
Message-ID: <41C1ED4A.1060606@verisignlabs.com>
Date: Thu, 16 Dec 2004 15:17:14 -0500
From: David Blacka
Organization: VeriSign, Inc.
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: namedroppers@ops.ietf.org
Subject: private algorithms and the DS record
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
I was thinking about the use of private algorithms in DNSSEC the other
day, and it struck me that they might not, strictly speaking, work.
Note that records-11 has the following text in Appendex A.1.1:
Algorithm number 253 is reserved for private use and will never be
assigned to a specific algorithm. The public key area in the DNSKEY
RR and the signature area in the RRSIG RR begin with a wire encoded
domain name, which MUST NOT be compressed. The domain name indicates
the private algorithm to use and the remainder of the public key area
is determined by that algorithm. Entities should only use domain
names they control to designate their private algorithms.
Fair enough, but there are no instructions for the DS record. So how
would a resolver be able to distinguish between a known private
algorithm from an unknown private algorithm from the delegation?
Note this text from protocol-09, section 5.2:
If the validator does not support any of the algorithms listed in an
authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
described above.
I.e., it is expected that a DNSSEC validator would be able to make the
determination that it does or does not support any of the algorithms
directly from the DS set. As soon as a DNSSEC validator knows about one
private algorithm (per scheme), it suddenly cannot make this determination.
Or am I missing something?
--
David Blacka
Sr. Engineer VeriSign Applied Research
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Thu Dec 16 15:37:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06352
for ; Thu, 16 Dec 2004 15:37:26 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1Cf2Ku-000AdY-SW
for namedroppers-data@psg.com; Thu, 16 Dec 2004 20:34:56 +0000
Received: from [65.201.175.9] (helo=mail.verisignlabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1Cf2Kq-000AbX-KB
for namedroppers@ops.ietf.org; Thu, 16 Dec 2004 20:34:52 +0000
Received: from [10.131.244.227] ([::ffff:172.25.170.10])
(AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by mail.verisignlabs.com with esmtp; Thu, 16 Dec 2004 15:34:51 -0500
id 0054C0F5.41C1F16B.00001ABF
Message-ID: <41C1F16B.7060904@verisignlabs.com>
Date: Thu, 16 Dec 2004 15:34:51 -0500
From: David Blacka
Organization: VeriSign, Inc.
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: namedroppers@ops.ietf.org
Subject: DNSSEC and unknown algorithms
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
I do realize that this topic was probably discussed as nauseum, and this
comment is extra-super late, but...
In protocol-09, section 5.2, there are two paragraphs describing what to
do when a resolver encounters a delegation to a zone signed only with
unknown algorithms:
If the validator does not support any of the algorithms listed in an
authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
described above.
and
If the resolver does not support any of the algorithms listed in an
authenticated DS RRset, then the resolver will not be able to verify
the authentication path to the child zone. In this case, the
resolver SHOULD treat the child zone as if it were unsigned.
(sort of redundant to have both paragraphs, but whatever)
My question is, why is this a SHOULD (or "should" in the first
paragraph). I suppose I'm imagination impaired, but what other option
does the resolver actually have except to treat the zone as unsigned?
In my mind, and I may be missing something, if a resolver does not treat
the zone as unsigned, it will be making validation decisions based on
unverified data. Which, I think, is a bad idea. My memory is a bit
hazy on the subject, but wasn't it that sort of thing that caused us to
do the typecode rollover in the first place?
--
David Blacka
Sr. Engineer VeriSign Applied Research
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Thu Dec 16 16:10:54 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09597
for ; Thu, 16 Dec 2004 16:10:54 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1Cf2qG-000GMx-UK
for namedroppers-data@psg.com; Thu, 16 Dec 2004 21:07:20 +0000
Received: from [204.152.187.5] (helo=farside.isc.org)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1Cf2qC-000GMB-L6
for namedroppers@ops.ietf.org; Thu, 16 Dec 2004 21:07:16 +0000
Received: from drugs.dv.isc.org (localhost [IPv6:::1])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by farside.isc.org (Postfix) with ESMTP id B4AA2677F2
for ; Thu, 16 Dec 2004 21:07:15 +0000 (UTC)
(envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iBGL7CfV093770;
Fri, 17 Dec 2004 08:07:12 +1100 (EST)
(envelope-from marka@drugs.dv.isc.org)
Message-Id: <200412162107.iBGL7CfV093770@drugs.dv.isc.org>
To: David Blacka
Cc: namedroppers@ops.ietf.org
From: Mark Andrews
Subject: Re: DNSSEC and unknown algorithms
In-reply-to: Your message of "Thu, 16 Dec 2004 15:34:51 CDT."
<41C1F16B.7060904@verisignlabs.com>
Date: Fri, 17 Dec 2004 08:07:12 +1100
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
> I do realize that this topic was probably discussed as nauseum, and this
> comment is extra-super late, but...
>
> In protocol-09, section 5.2, there are two paragraphs describing what to
> do when a resolver encounters a delegation to a zone signed only with
> unknown algorithms:
>
> If the validator does not support any of the algorithms listed in an
> authenticated DS RRset, then the resolver has no supported
> authentication path leading from the parent to the child. The
> resolver should treat this case as it would the case of an
> authenticated NSEC RRset proving that no DS RRset exists, as
> described above.
>
> and
>
> If the resolver does not support any of the algorithms listed in an
> authenticated DS RRset, then the resolver will not be able to verify
> the authentication path to the child zone. In this case, the
> resolver SHOULD treat the child zone as if it were unsigned.
>
> (sort of redundant to have both paragraphs, but whatever)
>
> My question is, why is this a SHOULD (or "should" in the first
> paragraph). I suppose I'm imagination impaired, but what other option
> does the resolver actually have except to treat the zone as unsigned?
>
> In my mind, and I may be missing something, if a resolver does not treat
> the zone as unsigned, it will be making validation decisions based on
> unverified data. Which, I think, is a bad idea. My memory is a bit
> hazy on the subject, but wasn't it that sort of thing that caused us to
> do the typecode rollover in the first place?
The security policy may say otherwise.
Say you have a policy that says "Every zone beneath example.net will
be signed with algorithm A" and example.net is only signed with
algorithm B.
Treating the zone as unsigned would be a violation of that
policy.
> --
> David Blacka
> Sr. Engineer VeriSign Applied Research
>
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive:
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Thu Dec 16 16:34:25 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13924
for ; Thu, 16 Dec 2004 16:34:24 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1Cf3Bb-000Jj3-VV
for namedroppers-data@psg.com; Thu, 16 Dec 2004 21:29:23 +0000
Received: from [65.201.175.9] (helo=mail.verisignlabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1Cf3BW-000JiZ-Mh
for namedroppers@ops.ietf.org; Thu, 16 Dec 2004 21:29:18 +0000
Received: from [10.131.244.227] ([::ffff:172.25.170.10])
(AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by mail.verisignlabs.com with esmtp; Thu, 16 Dec 2004 16:29:17 -0500
id 0054C158.41C1FE2D.000029D9
Message-ID: <41C1FE2D.90604@verisignlabs.com>
Date: Thu, 16 Dec 2004 16:29:17 -0500
From: David Blacka
Organization: VeriSign, Inc.
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Andrews
CC: namedroppers@ops.ietf.org
Subject: Re: DNSSEC and unknown algorithms
References: <200412162107.iBGL7CfV093770@drugs.dv.isc.org>
In-Reply-To: <200412162107.iBGL7CfV093770@drugs.dv.isc.org>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Mark Andrews wrote:
>>In my mind, and I may be missing something, if a resolver does not treat
>>the zone as unsigned, it will be making validation decisions based on
>>unverified data. Which, I think, is a bad idea. My memory is a bit
>>hazy on the subject, but wasn't it that sort of thing that caused us to
>>do the typecode rollover in the first place?
>
>
> The security policy may say otherwise.
>
> Say you have a policy that says "Every zone beneath example.net will
> be signed with algorithm A" and example.net is only signed with
> algorithm B.
>
> Treating the zone as unsigned would be a violation of that
> policy.
Just to clarify, in my head, everything always has an exception for
"local policy". But in this case, am I right in thinking that treating
the zone as *signed* and not entirely bogus is not an option? Or to put
this another way, what other options besides "treat the zone as
unsigned" or "write the whole zone off as bogus due to local policy"
does a validator have?
--
David Blacka
Sr. Engineer VeriSign Applied Research
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Thu Dec 16 16:59:38 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16685
for ; Thu, 16 Dec 2004 16:59:38 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1Cf3aD-000NLk-KH
for namedroppers-data@psg.com; Thu, 16 Dec 2004 21:54:49 +0000
Received: from [65.201.175.9] (helo=mail.verisignlabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1Cf3a9-000NL9-A2
for namedroppers@ops.ietf.org; Thu, 16 Dec 2004 21:54:45 +0000
Received: from [10.131.244.227] ([::ffff:172.25.170.10])
(AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by mail.verisignlabs.com with esmtp; Thu, 16 Dec 2004 16:54:44 -0500
id 0054C158.41C20424.00002FC8
Message-ID: <41C20424.9040300@verisignlabs.com>
Date: Thu, 16 Dec 2004 16:54:44 -0500
From: David Blacka
Organization: VeriSign, Inc.
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Wes Hardaker
CC: namedroppers@ops.ietf.org
Subject: Re: DNSSEC and unknown algorithms
References: <41C1F16B.7060904@verisignlabs.com>
In-Reply-To:
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Wes Hardaker wrote:
>>>>>>On Thu, 16 Dec 2004 15:34:51 -0500, David Blacka said:
>
>
> David> In protocol-09, section 5.2, there are two paragraphs
> David> describing what to do when a resolver encounters a delegation
> David> to a zone signed only with unknown algorithms:
>
> proto-09-5.2> If the validator does not support any of the algorithms
> proto-09-5.2> listed in an authenticated DS RRset, then the resolver
> proto-09-5.2> has no supported authentication path leading from the
> proto-09-5.2> parent to the child. The resolver should treat this
> proto-09-5.2> case as it would the case of an authenticated NSEC RRset
> proto-09-5.2> proving that no DS RRset exists, as described above.
>
> If you follow the advice in that last sentence, doesn't it allow for
> someone to craft a DS packet with a unassigned algorithm ID and send
> it to the requester and they'll actually immediately treat that packet
> as a proof of non-existence? Why would you ever treat a response you
> can't authenticate as an authenticated NSEC? Treating it as an
> unauthenticated NSEC I can understand, but not as an authenticated
> one.
No.
This is actually discussed earlier in section (5.2). The validator is
working with verified DS records from the parent. I.e., the parent is
signed with a known algorithm. So you aren't making a security decision
based on unauthenticated data here (which is what I'm worried that some
misguided implementation might do).
--
David Blacka
Sr. Engineer VeriSign Applied Research
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Thu Dec 16 18:13:12 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25299
for ; Thu, 16 Dec 2004 18:13:12 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1Cf4bF-0004qY-He
for namedroppers-data@psg.com; Thu, 16 Dec 2004 22:59:57 +0000
Received: from [65.205.251.75] (helo=robin.verisign.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1Cf4b3-0004oN-Bm
for namedroppers@ops.ietf.org; Thu, 16 Dec 2004 22:59:45 +0000
Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33])
by robin.verisign.com (8.12.11/8.12.11) with ESMTP id iBGMxihD021664;
Thu, 16 Dec 2004 14:59:44 -0800 (PST)
Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72)
id ; Thu, 16 Dec 2004 14:59:44 -0800
Message-ID:
From: "Hallam-Baker, Phillip"
To: "'David Blacka'" , namedroppers@ops.ietf.org
Subject: RE: DNSSEC and unknown algorithms
Date: Thu, 16 Dec 2004 14:59:24 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Well one point that really does need to be made clear here that we messed up
on big time in S/MIME is that applications SHOULD treat the zone no worse
than if it were unsigned.
So if there is a policy that says it is signed with X and it is signed
instead with Y then treating it as unsigned still leads to the same error.
What we need to avoid are the pathalogical cases that are inflicted in
SMIME, eg WARNING THIS EMAIL IS SIGNED DO YOU WANT TO OPEN IT? Which appears
when certain email clients receive S.MIME signed email.
Telling people to not penalize people who provide security may sound obvious
but the fact that they did it wrong is why we are now redoing email
signature for the fourth attempt.
> -----Original Message-----
> From: owner-namedroppers@ops.ietf.org
> [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of David Blacka
> Sent: Thursday, December 16, 2004 3:35 PM
> To: namedroppers@ops.ietf.org
> Subject: DNSSEC and unknown algorithms
>
>
> I do realize that this topic was probably discussed as
> nauseum, and this
> comment is extra-super late, but...
>
> In protocol-09, section 5.2, there are two paragraphs
> describing what to
> do when a resolver encounters a delegation to a zone signed only with
> unknown algorithms:
>
> If the validator does not support any of the algorithms
> listed in an
> authenticated DS RRset, then the resolver has no supported
> authentication path leading from the parent to the child. The
> resolver should treat this case as it would the case of an
> authenticated NSEC RRset proving that no DS RRset exists, as
> described above.
>
> and
>
> If the resolver does not support any of the algorithms
> listed in an
> authenticated DS RRset, then the resolver will not be
> able to verify
> the authentication path to the child zone. In this case, the
> resolver SHOULD treat the child zone as if it were unsigned.
>
> (sort of redundant to have both paragraphs, but whatever)
>
> My question is, why is this a SHOULD (or "should" in the first
> paragraph). I suppose I'm imagination impaired, but what
> other option
> does the resolver actually have except to treat the zone as unsigned?
>
> In my mind, and I may be missing something, if a resolver
> does not treat
> the zone as unsigned, it will be making validation decisions based on
> unverified data. Which, I think, is a bad idea. My memory is a bit
> hazy on the subject, but wasn't it that sort of thing that
> caused us to
> do the typecode rollover in the first place?
>
> --
> David Blacka
> Sr. Engineer VeriSign Applied Research
>
> --
> to unsubscribe send a message to
> namedroppers-request@ops.ietf.org with the word 'unsubscribe'
> in a single line as the message text body.
> archive:
>
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Fri Dec 17 09:04:47 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19663
for ; Fri, 17 Dec 2004 09:04:47 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CfIcB-000Bq0-BM
for namedroppers-data@psg.com; Fri, 17 Dec 2004 13:57:51 +0000
Received: from [129.6.16.226] (helo=smtp.nist.gov)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CfIc7-000Bod-2Q
for namedroppers@ops.ietf.org; Fri, 17 Dec 2004 13:57:47 +0000
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92])
by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iBHDvc9W024367
for ; Fri, 17 Dec 2004 08:57:38 -0500
Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185])
by postmark.nist.gov (8.12.5/8.12.5) with SMTP id iBHDvLLS014400
for ; Fri, 17 Dec 2004 08:57:21 -0500 (EST)
From: "Scott Rose"
To:
Subject: RE: DNSSEC and unknown algorithms
Date: Fri, 17 Dec 2004 08:57:21 -0500
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-reply-to: <41C1F16B.7060904@verisignlabs.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: scottr@nist.gov
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
> -----Original Message-----
> From: owner-namedroppers@ops.ietf.org
> [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of David Blacka
>
> I do realize that this topic was probably discussed as nauseum, and this
> comment is extra-super late, but...
>
> In protocol-09, section 5.2, there are two paragraphs describing what to
> do when a resolver encounters a delegation to a zone signed only with
> unknown algorithms:
>
> If the validator does not support any of the algorithms listed in an
> authenticated DS RRset, then the resolver has no supported
> authentication path leading from the parent to the child. The
> resolver should treat this case as it would the case of an
> authenticated NSEC RRset proving that no DS RRset exists, as
> described above.
>
> and
>
> If the resolver does not support any of the algorithms listed in an
> authenticated DS RRset, then the resolver will not be able to verify
> the authentication path to the child zone. In this case, the
> resolver SHOULD treat the child zone as if it were unsigned.
>
> (sort of redundant to have both paragraphs, but whatever)
>
> My question is, why is this a SHOULD (or "should" in the first
> paragraph). I suppose I'm imagination impaired, but what other option
> does the resolver actually have except to treat the zone as unsigned?
>
I think it was a decision to defer to local policy. Some sites may wish to
shoot themselves in the foot. If a validator sees a DNSKEY with an algo it
doesn't understand, it may still be able to verify the parent's RRSIG
covering the DS, so a smart validator would determine "signed by something I
can't verify": and it's up to local policy to how that response is handled.
Scott
> --
> David Blacka
> Sr. Engineer VeriSign Applied Research
>
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive:
>
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Fri Dec 17 12:17:35 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11498
for ; Fri, 17 Dec 2004 12:17:35 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CfLcv-0002A1-5o
for namedroppers-data@psg.com; Fri, 17 Dec 2004 17:10:49 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CfLch-00028g-4m
for namedroppers@ops.ietf.org; Fri, 17 Dec 2004 17:10:36 +0000
Received: from mail.ogud.com (localhost [127.0.0.1])
by ogud.com (8.12.11/8.12.11) with ESMTP id iBHHAT6b051288
for ; Fri, 17 Dec 2004 12:10:29 -0500 (EST)
(envelope-from namedroppers@mail.ogud.com)
Received: (from namedroppers@localhost)
by mail.ogud.com (8.12.11/8.12.11/Submit) id iBHHATL7051287
for namedroppers@ops.ietf.org; Fri, 17 Dec 2004 12:10:29 -0500 (EST)
(envelope-from namedroppers)
Received: from [168.150.236.43] (helo=wes.hardakers.net)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1Cf396-000JUE-MK
for namedroppers@ops.ietf.org; Thu, 16 Dec 2004 21:26:48 +0000
Received: by wes.hardakers.net (Postfix, from userid 274)
id 0E26911D905; Thu, 16 Dec 2004 13:26:43 -0800 (PST)
To: David Blacka
Cc: namedroppers@ops.ietf.org
Subject: Re: DNSSEC and unknown algorithms
References: <41C1F16B.7060904@verisignlabs.com>
From: Wes Hardaker
Organization: Sparta
Date: Thu, 16 Dec 2004 13:26:43 -0800
In-Reply-To: <41C1F16B.7060904@verisignlabs.com> (David Blacka's message of
"Thu, 16 Dec 2004 15:34:51 -0500")
Message-ID:
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through
Obscurity, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
[ Moderators note: Post was moderated, either because it was posted by
a non-subscriber, or because it was over 20K.
With the massive amount of spam, it is easy to miss and therefore
delete relevant posts by non-subsrcibers. Please fix your
subscription addresses. ]
>>>>> On Thu, 16 Dec 2004 15:34:51 -0500, David Blacka said:
David> In protocol-09, section 5.2, there are two paragraphs
David> describing what to do when a resolver encounters a delegation
David> to a zone signed only with unknown algorithms:
proto-09-5.2> If the validator does not support any of the algorithms
proto-09-5.2> listed in an authenticated DS RRset, then the resolver
proto-09-5.2> has no supported authentication path leading from the
proto-09-5.2> parent to the child. The resolver should treat this
proto-09-5.2> case as it would the case of an authenticated NSEC RRset
proto-09-5.2> proving that no DS RRset exists, as described above.
If you follow the advice in that last sentence, doesn't it allow for
someone to craft a DS packet with a unassigned algorithm ID and send
it to the requester and they'll actually immediately treat that packet
as a proof of non-existence? Why would you ever treat a response you
can't authenticate as an authenticated NSEC? Treating it as an
unauthenticated NSEC I can understand, but not as an authenticated
one.
--
"In the bathtub of history the truth is harder to hold than the soap,
and much more difficult to find." -- Terry Pratchett
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Fri Dec 17 12:23:43 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12246
for ; Fri, 17 Dec 2004 12:23:42 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CfLm1-0003Jx-Tx
for namedroppers-data@psg.com; Fri, 17 Dec 2004 17:20:13 +0000
Received: from [192.94.214.100] (helo=nutshell.tislabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CfLlw-0003In-MY
for namedroppers@ops.ietf.org; Fri, 17 Dec 2004 17:20:08 +0000
Received: (from uucp@localhost)
by nutshell.tislabs.com (8.12.9/8.12.9) id iBHHGocP021272
for ; Fri, 17 Dec 2004 12:16:50 -0500 (EST)
Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0)
id srcAAAYwa4IP; Fri, 17 Dec 04 12:16:48 -0500
Received: from localhost (weiler@localhost)
by tislabs.com (8.12.9/8.12.9) with ESMTP id iBHHIR2m018815;
Fri, 17 Dec 2004 12:18:31 -0500 (EST)
Date: Fri, 17 Dec 2004 12:18:26 -0500 (EST)
From: Samuel Weiler
X-X-Sender: weiler@filbert
To: David Blacka
cc: namedroppers@ops.ietf.org
Subject: Re: DNSSEC and unknown algorithms
In-Reply-To: <41C1F16B.7060904@verisignlabs.com>
Message-ID:
References: <41C1F16B.7060904@verisignlabs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
On Thu, 16 Dec 2004, David Blacka wrote:
> My question is, why is this a SHOULD (or "should" in the first
> paragraph). I suppose I'm imagination impaired, but what other option
> does the resolver actually have except to treat the zone as unsigned?
Maybe the resolver could still check to see if all RRsets still have
unexpired RRSIGs of an appropriate algorithm type, even if the crypto
bits don't work? It shouldn't set the ad bit if an answer passes
those checks, but it might throw an error if they fail.
As the author of text that led to these paragraphs, I don't recall
exactly why I didn't use a 2119 MUST. In general, I think 2119 MUSTs
should be used sparingly, and only with known good reason. If there's
any plausible non-offending alternative, a SHOULD is more appropriate.
> In my mind, and I may be missing something, if a resolver does not treat
> the zone as unsigned, it will be making validation decisions based on
> unverified data. Which, I think, is a bad idea. My memory is a bit
> hazy on the subject, but wasn't it that sort of thing that caused us to
> do the typecode rollover in the first place?
TCR happened because some (widely deployed) resolvers treat any answer
with an NXT being as being a denial of existance, no matter the name
bounds of that NXT. Since DS added NXTs to positive answers (unsecure
referrals), unsecure delegations from signed zones didn't work. I
don't know if we ever tested what happened to other NXT-bearing
positive answers (i.e. wildcard answers), but this was sufficient to
justify the TCR. Jakob discovered the bug on New Years' Eve, two
years ago. Mark Andrews tracked it down the next day.
To answer David's question, no, the use of unvalidated data is not
what triggered the TCR. I don't recall whether an unvalidated NXT is
sufficient to trigger the bug above -- it might be, but that wasn't
the reason for the TCR.
-- Sam
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Fri Dec 17 14:21:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23561
for ; Fri, 17 Dec 2004 14:21:51 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CfNa3-0001tQ-53
for namedroppers-data@psg.com; Fri, 17 Dec 2004 19:15:59 +0000
Received: from [129.6.16.226] (helo=smtp.nist.gov)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CfNZx-0001s7-Tw
for namedroppers@ops.ietf.org; Fri, 17 Dec 2004 19:15:54 +0000
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92])
by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iBHJFn6I019285
for ; Fri, 17 Dec 2004 14:15:49 -0500
Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185])
by postmark.nist.gov (8.12.5/8.12.5) with SMTP id iBHJFbLS007018
for ; Fri, 17 Dec 2004 14:15:38 -0500 (EST)
From: "Scott Rose"
To:
Subject: RE: draft-lozano-nsec-random-00
Date: Fri, 17 Dec 2004 14:15:37 -0500
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-reply-to: <41BF2387.1040100@verisignlabs.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: scottr@nist.gov
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
> -----Original Message-----
> From: owner-namedroppers@ops.ietf.org
> [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of David Blacka
>
> Gustavo Lozano Ibarra wrote:
> > I have been talking with some colleagues at NIC Mexico and
> others organizations about an idea to address the issue of DNS
> enumeration in the DNSSECbis protocol.
> >
> > I wrote a draft describing the idea and I would appreciate
> receiving comments about it.
> >
> > The draft :
> http://www.ietf.org/internet-drafts/draft-lozano-nsec-random-00.txt
>
> Well, for one, you would be enabling a man in the middle to provably
> deny the existence of anything in the zone, which is contrary to the
> design goals of DNSSEC.
>
Also, one of the early design principles was that DNSSEC would not add names
to the zone. That is, the same canonical order of names must exist in both
the signed and unsigned zones. Personally, I don't know how important this
is, but I feel uneasy with schemes that add names to the zone when they
become signed.
Scott
> --
> David Blacka
> Sr. Engineer VeriSign Applied Research
>
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive:
>
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Fri Dec 17 15:57:08 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04378
for ; Fri, 17 Dec 2004 15:57:07 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CfP5a-000Ec0-T6
for namedroppers-data@psg.com; Fri, 17 Dec 2004 20:52:38 +0000
Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CfP5V-000Eas-CA
for namedroppers@ops.ietf.org; Fri, 17 Dec 2004 20:52:33 +0000
Received: from zeder.TechFak.Uni-Bielefeld.DE (zeder.TechFak.Uni-Bielefeld.DE [129.70.128.80])
by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id iBHKqSor011152;
Fri, 17 Dec 2004 21:52:29 +0100 (MET)
Received: from localhost (pk@localhost)
by zeder.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id iBHKqSV29463;
Fri, 17 Dec 2004 21:52:28 +0100 (MET)
Message-Id: <200412172052.iBHKqSV29463@zeder.TechFak.Uni-Bielefeld.DE>
X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs
X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol
To: Gustavo Lozano Ibarra
Cc: namedroppers@ops.ietf.org
Subject: Re: draft-lozano-nsec-random-00
In-reply-to: Your message of "Tue, 14 Dec 2004 11:12:28 CST."
<6.2.0.14.2.20041214111013.0a64b7f8@mail.nic.mx>
X-Organization: Uni Bielefeld, Technische Fakultaet
X-Phone: +49 521 106 2902
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29458.1103316747.1@zeder.TechFak.Uni-Bielefeld.DE>
Date: Fri, 17 Dec 2004 21:52:28 +0100
From: Peter Koch
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
> I wrote a draft describing the idea and I would appreciate receiving comments
> about it.
>
> The draft : http://www.ietf.org/internet-drafts/draft-lozano-nsec-random-00.t
>xt
You're introducing competing NSEC RRs separating NXDOMAIN from NOERROR/NODATA.
The choice of the NSEC RR to be sent with the answer needs to be specified
more precisely (since the server may not be able to know which one was
randomly generated), but essentially you're giving up authenticated denial
of existence (of names):
In your zone
a.example (random generated)
b.example (original)
c.example (random generated)
e.example (original)
f.example (random generated)
h.example (original)
z.example (random generated)
you create NSEC RRs pointing from one randomly generated name to 'the next',
but since there's no information in those randomly generated names, the
approach can be reduced to a single NSEC RR spanning the whole zone. Now,
all names within the zone (any zone) can be proven not to exist, including,
of course, those that do actually exist and own RRsets.
-Peter
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From nv33134@yahoo.com Sun Dec 19 06:37:23 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25345;
Sun, 19 Dec 2004 06:37:23 -0500 (EST)
Date: Sun, 19 Dec 2004 06:37:23 -0500 (EST)
Message-Id: <200412191137.GAA25345@ietf.org>
Received: from [218.12.34.234] (helo=ietf.org)
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1CfzWN-0007eZ-OF; Sun, 19 Dec 2004 06:46:47 -0500
From: "Dr. Plinio"
To: PresenteDeNatal@ns.cnri.reston.va.us
Subject: Um cordial presente de Natal e Ano Novo
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
MIME-Version: 1.0
Content-Type: text/html
X-Spam-Score: 26.9 (++++++++++++++++++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
c0412pcoMail
Caros amigos,
Lhes enviamos -como um simples, mas cordial presente de Natal e Ano Novo- alguns trechos do artigo "Parai e vede", escrito por Plinio Corrêa de Oliveira. Aqueles que desejarem receber por e-mail, gratuitamente, a íntegra deste artigo, mais o texto do mesmo autor "A ti, caro ateu", simplesmente cliquem em:
DrPlinio:DoisTextosGratuitos.
Um feliz Natal e Ano Novo 2005 lhes deseja, atenciosamente,
Ferreira Passos, Atualidade Brasileira / Rio de Janeiro
Parai e vede
Sede espiritual de almas exaustas
Em torno de mim noto uma sede espiritual mal saciada, um desejo mudo e talvez até subconsciente, de reencontrar um pouco da verdadeira alegria do verdadeiro Natal: no olhar de muitos dos conhecidos e desconhecidos com que cruzo pelas ruas, no reflexo dos amigos ao lado dos quais luto e trabalho e dos íntimos cuja amizade me tem acompanhado ao longo dos anos que se vão.
É uma ocasião para lembrar tantas recordações áureas, e aplacar a sede de maravilhoso, de doce, de sacrossanto, de que reluz o Natal.
Por alguns instantes, abramo-nos à luz do Natal, a fim de que se reanimem as nossas almas exaustas e desoladas. Depois, retomaremos com maior coragem o fardo quase insuportável do dia-a-dia.
Luz, paz, alento...
Morreu o Natal autêntico? Com um pouco de exagero, poder-se-ia dizer que sim. Morreu na alma metalizada de tantos milhões de homens. Morreu até em certos presepes. Sim, nos presepes progressistas, que nos exibem a Sagrada Família com os traços e a fisionomia desfigurados pela arte moderna, e até com conotações que induzem à revolução social.
Mas, se há algum exagero em dizer que o Natal morreu, é verdade que alguns lampejos de vida ele ainda conserva. Vamos à procura deles.
Encontrá-lo-emos antes de tudo - e borbulhantes - no próprio fato de ser dia de Natal. Queiram ou não queiram os homens, a graça lhes bate às portas da alma, mais sublime, mais meiga, mais insistente, nestes dias de Natal. Dir-se-ia que, apesar de tudo, paira nos ares uma luz, uma paz, um alento, uma força de idealismo e dedicação, que é difícil não perceber.
Deus, ei-Lo exorável e ao nosso alcance, feito homem como nós, tendo junto de Si a Mãe perfeita. Mãe dEle mas também nossa. Por meio dEla, até os piores pecadores tudo podem pedir e esperar.
As almas crispadas se distendem
Ao contemplar isto, nossas almas crispadas se distendem. Nossos egoísmos se desarmam. A paz penetra em nós e em torno de nós. Sentimos que em nosso vizinho algo também está enobrecido e dulcificado. Florescem os dons de alma. O dom do afeto. O dom do perdão. E, como símbolo, a oferta delicada e desinteressada de algum presente.
Para que nada falte, o irmão corpo - como dizia São Francisco - também tem sua parte na alegria. Feita a oração junto ao presepe, sentam-se todos à mesma mesa.
Alegria de Natal? Sim. Mas muito mais do que isto. Alegria dos 365 dias do ano, para o católico verdadeiro. Pois na alma em que, pela graça, habita o Salvador, esta alegria dura sempre e jamais se apaga. Nem a dor, nem a luta, nem a doença e nem a morte a eliminam. É a alegria da fé e do sobrenatural.
Não há alegria igual
Oh vós que andais pelo caminho, parai e vede se há uma dor semelhante à minha, exclamou Isaías profeta, antevendo a Paixão do Salvador e a compaixão de Maria.
Mas ele também poderia ter dito, profetizando as alegrias cristãs perenes e indestrutíveis que o Natal leva a seu auge: oh vós que passais pelo caminho, parai e vede se há alegria semelhante à minha.
-- Oh vós que viveis para o ouro, oh vós que viveis tolamente para a vanglória, oh vós que viveis torpemente para a sensualidade, oh vós que viveis diabolicamente para a revolta e para o crime: parai e vede as almas verdadeiramente católicas, iluminadas pela alegria do Natal: o que é a vossa alegria comparada à delas?
Não vejais nestas palavras provocação, nem desdém. Elas são muito mais do que isto.
São um convite para o Natal perene, que é a vida do verdadeiro fiel: "Christianus alter Christus" - o cristão é um outro Jesus Cristo.
Não, não há alegria igual. Até mesmo quando o católico está, como Jesus Nosso Senhor, cravado na cruz...
LINKS:
* Para receber o texto completo deste artigo, clique em:
DrPlinio:TextoGratuitoCompleto
* Para receber outros artigos do mesmo autor:
DrPlinio:ProximosArtigos
* Para receber mais informação sobre o autor:
DrPlinioMaisInfo
* Para enviar sua valiosa opinião:
MinhaOpiniao
* Para ser retirado imediatamente de nosso AddressBook:
Retirar
From owner-namedroppers@ops.ietf.org Sun Dec 19 19:53:53 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26876
for ; Sun, 19 Dec 2004 19:53:53 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgBfO-0000Od-Uq
for namedroppers-data@psg.com; Mon, 20 Dec 2004 00:44:50 +0000
Received: from [17.254.13.22] (helo=mail-out3.apple.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgBfJ-0000OB-Rw
for namedroppers@ops.ietf.org; Mon, 20 Dec 2004 00:44:45 +0000
Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225])
by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id iBK0qGUU023515
for ; Sun, 19 Dec 2004 16:52:16 -0800 (PST)
Received: from relay4.apple.com (relay4.apple.com) by mailgate1.apple.com
(Content Technologies SMTPRS 4.3.17) with ESMTP id for ;
Sun, 19 Dec 2004 16:46:10 -0800
Received: from [17.83.207.5] ([17.83.207.5])
by relay4.apple.com (8.12.11/8.12.11) with SMTP id iBK0ig8K006224
for ; Sun, 19 Dec 2004 16:44:43 -0800 (PST)
Message-Id: <200412200044.iBK0ig8K006224@relay4.apple.com>
Subject: Re: Unexpected DNS responses
Date: Sun, 19 Dec 2004 16:44:45 -0800
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire
To:
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Thanks to everyone who responded. I got many replies along these lines:
>Is there some sort of caching going on at the host level?
>There shouldn't be with dig, but who knows? I would
>suggest performing the "dig -t aaaa login.oscar.aol.com"
>on a different host to see if you get the same response.
>
>It almost sounds like dig is doing a CNAME subsitution and
>there is some hidden cache at work.
Clearly doing queries from other machines produces different results.
Clearly some cache at Apple is doing CNAME subsitution. The question was
whether this is legal. We can fix our cache at Apple, but if this
situation is common at lots of other sites, should we make our OS X
resolver client handle it?
It sounds like the consensus is no, we should not. It sounds like this is
a bug in BIND 8, and the consensus is that we should not work around it
in our client, but simply tell any site having this problem that they
need to upgrade their name servers.
Thanks for everyone's input.
Stuart Cheshire
* Wizard Without Portfolio, Apple Computer, Inc.
* www.stuartcheshire.org
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Mon Dec 20 10:36:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08326
for ; Mon, 20 Dec 2004 10:36:24 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgPVQ-000Ck0-3w
for namedroppers-data@psg.com; Mon, 20 Dec 2004 15:31:28 +0000
Received: from [65.201.175.9] (helo=mail.verisignlabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgPVK-000Cjf-RS
for namedroppers@ops.ietf.org; Mon, 20 Dec 2004 15:31:22 +0000
Received: from [10.131.244.227] ([::ffff:172.25.170.10])
(AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by mail.verisignlabs.com with esmtp; Mon, 20 Dec 2004 10:31:18 -0500
id 0054C2E7.41C6F046.0000127F
Message-ID: <41C6F045.8010501@verisignlabs.com>
Date: Mon, 20 Dec 2004 10:31:17 -0500
From: David Blacka
Organization: VeriSign, Inc.
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
References: <41C1ED4A.1060606@verisignlabs.com> <20041217165427.3e1a46b1.olaf@ripe.net>
In-Reply-To: <20041217165427.3e1a46b1.olaf@ripe.net>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
On Dec 17, 2004, at 10:54 AM, Olaf M. Kolkman wrote:
> Are you refering to algorithm id clashes?
yes.
Private algorithms are identified with an algorithm number (253 or 254)
and an additional DNS name or OID. When you are looking at a DNSKEY or
RRSIG, you can figure out exactly what the algorithm name is by looking
at the number, seeing that it is 253, then looking at the beginning for
the key data or signature data and parsing a DNS name.
Nobody has implemented this that I know of, but it looks easy enough.
HOWEVER, when the resolver is following a delegation, it 1) looks for
the presence or absence of the DS set. If present, it makes sure that
it understands at least one of the algorithms presented in the DS
record. BUT, it cannot tell if "253" refers to a private algorithm it
has heard of or some other private algorithm, because there are NO
INSTRUCTIONS for putting the private key DNS name or OID in the DS
record anywhere. Therefore, one has to assume that it is not present.
Thus, the only information that the resolver has at that point in the
validation process is that the DS record is using *some* private
algorithm, but it cannot tell which one.
Basically, all I am pointing out is that private algorithm identifiers
need to be handled everywhere algorithm numbers appear. And the DS
record is missing information about to handle private algorithms.
It is true that, if the validator goes on to the subzone and fetches
the DNSKEYs, it can match the DS to the DNSKEY and actually find out.
BUT, the way protocol-09 is written, that isn't how validators are
expected to work.
--
David Blacka
Sr. Engineer Verisign Applied Research
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Mon Dec 20 12:56:56 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19714
for ; Mon, 20 Dec 2004 12:56:56 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgRiM-0002rz-Dm
for namedroppers-data@psg.com; Mon, 20 Dec 2004 17:52:58 +0000
Received: from [129.6.16.226] (helo=smtp.nist.gov)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgRiI-0002qx-2C
for namedroppers@ops.ietf.org; Mon, 20 Dec 2004 17:52:54 +0000
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92])
by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iBKHqe9W003873
for ; Mon, 20 Dec 2004 12:52:40 -0500
Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185])
by postmark.nist.gov (8.12.5/8.12.5) with SMTP id iBKHqGLS011436
for ; Mon, 20 Dec 2004 12:52:17 -0500 (EST)
From: "Scott Rose"
To:
Subject: RE: private algorithms and the DS record
Date: Mon, 20 Dec 2004 12:52:16 -0500
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-reply-to: <41C6F045.8010501@verisignlabs.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: scottr@nist.gov
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Well, the validator needs to obtain the DNSKEY RR anyway to validate the DS
RR (the hash uses the entire RDATA of the DNSKEY). If there are two private
algorithms in use, then the validator must rely on the key_id to
differentiate.
I wouldn't expect a validator to make any decision on a zone based solely on
the DS RR since it can only validate the RRSIG and not the key hash without
the DNSKEY from the child zone.
Scott
> -----Original Message-----
> From: owner-namedroppers@ops.ietf.org
> [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of David Blacka
>
> On Dec 17, 2004, at 10:54 AM, Olaf M. Kolkman wrote:
>
> > Are you refering to algorithm id clashes?
>
> yes.
>
> Private algorithms are identified with an algorithm number (253 or 254)
> and an additional DNS name or OID. When you are looking at a DNSKEY or
> RRSIG, you can figure out exactly what the algorithm name is by looking
> at the number, seeing that it is 253, then looking at the beginning for
> the key data or signature data and parsing a DNS name.
>
> Nobody has implemented this that I know of, but it looks easy enough.
>
> HOWEVER, when the resolver is following a delegation, it 1) looks for
> the presence or absence of the DS set. If present, it makes sure that
> it understands at least one of the algorithms presented in the DS
> record. BUT, it cannot tell if "253" refers to a private algorithm it
> has heard of or some other private algorithm, because there are NO
> INSTRUCTIONS for putting the private key DNS name or OID in the DS
> record anywhere. Therefore, one has to assume that it is not present.
> Thus, the only information that the resolver has at that point in the
> validation process is that the DS record is using *some* private
> algorithm, but it cannot tell which one.
>
> Basically, all I am pointing out is that private algorithm identifiers
> need to be handled everywhere algorithm numbers appear. And the DS
> record is missing information about to handle private algorithms.
>
> It is true that, if the validator goes on to the subzone and fetches
> the DNSKEYs, it can match the DS to the DNSKEY and actually find out.
> BUT, the way protocol-09 is written, that isn't how validators are
> expected to work.
>
> --
> David Blacka
> Sr. Engineer Verisign Applied Research
>
>
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive:
>
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Mon Dec 20 13:26:31 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21127
for ; Mon, 20 Dec 2004 13:26:30 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgSAW-0006gx-B9
for namedroppers-data@psg.com; Mon, 20 Dec 2004 18:22:04 +0000
Received: from [65.201.175.9] (helo=mail.verisignlabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgSAS-0006gT-19
for namedroppers@ops.ietf.org; Mon, 20 Dec 2004 18:22:00 +0000
Received: from [10.131.244.227] ([::ffff:172.25.170.10])
(AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by mail.verisignlabs.com with esmtp; Mon, 20 Dec 2004 13:21:59 -0500
id 0054C013.41C71847.000034C4
Message-ID: <41C71847.9040109@verisignlabs.com>
Date: Mon, 20 Dec 2004 13:21:59 -0500
From: David Blacka
Organization: VeriSign, Inc.
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Scott Rose
CC: namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
References:
In-Reply-To:
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Scott Rose wrote:
> Well, the validator needs to obtain the DNSKEY RR anyway to validate the DS
> RR (the hash uses the entire RDATA of the DNSKEY). If there are two private
> algorithms in use, then the validator must rely on the key_id to
> differentiate.
>
> I wouldn't expect a validator to make any decision on a zone based solely on
> the DS RR since it can only validate the RRSIG and not the key hash without
> the DNSKEY from the child zone.
Huh? I don't even know what this means. Validators validate RRsets,
not individual fields in a record.
In any case, if what you are saying is correct, then the text in
protocol-09 is (very) misleading, perhaps even wrong.
What I am saying is that protocol-09 states that the validator makes a
decision based on the (verified) DS set from the parent, and that this
causes a problem wrt private algorithms. Have I utterly misinterpreted
this paragraph?
If the validator does not support any of the algorithms listed in an
authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
described above.
or this paragraph (both from section 5.2 of protocol-09)?
If the resolver does not support any of the algorithms listed in
an authenticated DS RRset, then the resolver will not be able to
verify the authentication path to the child zone. In this case,
the resolver SHOULD treat the child zone as if it were unsigned.
Note that this problem is very easy to fix. Either make it clear that
this logic only occurs after matching the DS to the DNSKEY, or (and this
is even easier) define how the private algorithm identifier is put in
the DS record. Like, prepend it to the key hash, which is essentially
like how it is done for DNSKEY and RRSIG now.
--
David Blacka
Sr. Engineer VeriSign Applied Research
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Mon Dec 20 13:58:32 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22810
for ; Mon, 20 Dec 2004 13:58:31 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgSfW-000A6T-4k
for namedroppers-data@psg.com; Mon, 20 Dec 2004 18:54:06 +0000
Received: from [129.6.16.226] (helo=smtp.nist.gov)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgSfQ-000A5T-QU
for namedroppers@ops.ietf.org; Mon, 20 Dec 2004 18:54:00 +0000
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92])
by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iBKIrt9W018268;
Mon, 20 Dec 2004 13:53:55 -0500
Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185])
by postmark.nist.gov (8.12.5/8.12.5) with SMTP id iBKIroLS024207;
Mon, 20 Dec 2004 13:53:50 -0500 (EST)
From: "Scott Rose"
To: "David Blacka"
Cc:
Subject: RE: private algorithms and the DS record
Date: Mon, 20 Dec 2004 13:53:50 -0500
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-reply-to: <41C71847.9040109@verisignlabs.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: scottr@nist.gov
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
> -----Original Message-----
> From: David Blacka [mailto:davidb@verisignlabs.com]
> >
> > I wouldn't expect a validator to make any decision on a zone
> based solely on
> > the DS RR since it can only validate the RRSIG and not the key
> hash without
> > the DNSKEY from the child zone.
>
> Huh? I don't even know what this means. Validators validate RRsets,
> not individual fields in a record.
>
Maybe I misunderstood your post, but your reply clears it up.
> In any case, if what you are saying is correct, then the text in
> protocol-09 is (very) misleading, perhaps even wrong.
>
> What I am saying is that protocol-09 states that the validator makes a
> decision based on the (verified) DS set from the parent, and that this
> causes a problem wrt private algorithms. Have I utterly misinterpreted
> this paragraph?
>
> If the validator does not support any of the algorithms listed in an
> authenticated DS RRset, then the resolver has no supported
> authentication path leading from the parent to the child. The
> resolver should treat this case as it would the case of an
> authenticated NSEC RRset proving that no DS RRset exists, as
> described above.
>
A validator would not know if it supports the private algorithms until it
got the DNSKEY RRset from the parent and finds out which private algorithm
is used. Was that the idea? This seems to be a corner case: If a resolver
doesn't understand any private algorithm and encounters one in a DS, it
behaves according to the paragraph above.
In the case where the resolver understands one or more private algorithms,
it cannot make a statement of the security of a child without getting the
child DNSKEY RRset first. I think that's the crux of the issue.
> or this paragraph (both from section 5.2 of protocol-09)?
>
> If the resolver does not support any of the algorithms listed in
> an authenticated DS RRset, then the resolver will not be able to
> verify the authentication path to the child zone. In this case,
> the resolver SHOULD treat the child zone as if it were unsigned.
>
> Note that this problem is very easy to fix. Either make it clear that
> this logic only occurs after matching the DS to the DNSKEY, or (and this
> is even easier) define how the private algorithm identifier is put in
> the DS record. Like, prepend it to the key hash, which is essentially
> like how it is done for DNSKEY and RRSIG now.
>
The former situation (matching DS and DNSKEY) has to be done anyway, what
makes that less attractive than adding the name of the algorithm to the DS
hash (besides the work in obtaining and processing the DNSKEY RRset)?
Scott
> --
> David Blacka
> Sr. Engineer VeriSign Applied Research
>
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Mon Dec 20 14:12:45 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24058
for ; Mon, 20 Dec 2004 14:12:44 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgSuq-000CV0-4n
for namedroppers-data@psg.com; Mon, 20 Dec 2004 19:09:56 +0000
Received: from [65.201.175.9] (helo=mail.verisignlabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgSuk-000CUM-Hz
for namedroppers@ops.ietf.org; Mon, 20 Dec 2004 19:09:50 +0000
Received: from [10.131.244.227] ([::ffff:172.25.170.10])
(AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by mail.verisignlabs.com with esmtp; Mon, 20 Dec 2004 14:09:49 -0500
id 0054C2E5.41C7237D.00003F05
Message-ID: <41C7237D.9040205@verisignlabs.com>
Date: Mon, 20 Dec 2004 14:09:49 -0500
From: David Blacka
Organization: VeriSign, Inc.
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Scott Rose
CC: namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
References:
In-Reply-To:
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Scott Rose wrote:
>>-----Original Message-----
>>From: David Blacka [mailto:davidb@verisignlabs.com]
>>
>>>I wouldn't expect a validator to make any decision on a zone
>>
>>based solely on
>>
>>>the DS RR since it can only validate the RRSIG and not the key
>>
>>hash without
>>
>>>the DNSKEY from the child zone.
>>
>>Huh? I don't even know what this means. Validators validate RRsets,
>>not individual fields in a record.
>>
>
>
> Maybe I misunderstood your post, but your reply clears it up.
>
> A validator would not know if it supports the private algorithms until it
> got the DNSKEY RRset from the parent and finds out which private algorithm
> is used. Was that the idea? This seems to be a corner case: If a resolver
> doesn't understand any private algorithm and encounters one in a DS, it
> behaves according to the paragraph above.
True, this problem won't present itself in the (normal) case of not
understanding any private algorithm identifiers.
> In the case where the resolver understands one or more private algorithms,
> it cannot make a statement of the security of a child without getting the
> child DNSKEY RRset first. I think that's the crux of the issue.
Yes, exactly.
>
>>or this paragraph (both from section 5.2 of protocol-09)?
>>
>> If the resolver does not support any of the algorithms listed in
>> an authenticated DS RRset, then the resolver will not be able to
>> verify the authentication path to the child zone. In this case,
>> the resolver SHOULD treat the child zone as if it were unsigned.
>>
>>Note that this problem is very easy to fix. Either make it clear that
>>this logic only occurs after matching the DS to the DNSKEY, or (and this
>> is even easier) define how the private algorithm identifier is put in
>>the DS record. Like, prepend it to the key hash, which is essentially
>>like how it is done for DNSKEY and RRSIG now.
>>
>
>
> The former situation (matching DS and DNSKEY) has to be done anyway, what
> makes that less attractive than adding the name of the algorithm to the DS
> hash (besides the work in obtaining and processing the DNSKEY RRset)?
Er, no, it doesn't have to be done if you know you can't do anything
with the DNSKEYs. That is how I understand the logic, anyway.
In any case, the reaon why adding the name to the DS is more attractive
is the symmetry with DNSKEY and RRSIG. It looks to me that the fact
that this was NOT done was just an oversight. A not surprising one,
considering.
--
David Blacka
Sr. Engineer VeriSign Applied Research
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Mon Dec 20 16:48:07 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13653
for ; Mon, 20 Dec 2004 16:48:06 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgVGS-0003v2-ST
for namedroppers-data@psg.com; Mon, 20 Dec 2004 21:40:24 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgVGO-0003uT-C6
for namedroppers@ops.ietf.org; Mon, 20 Dec 2004 21:40:20 +0000
Received: from [10.31.32.75] (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id iBKLeBTb076581;
Mon, 20 Dec 2004 16:40:12 -0500 (EST)
(envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To: <41C1ED4A.1060606@verisignlabs.com>
References: <41C1ED4A.1060606@verisignlabs.com>
Date: Mon, 20 Dec 2004 16:40:16 -0500
To: David Blacka
From: Edward Lewis
Subject: Re: private algorithms and the DS record
Cc: namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.48 on 66.92.146.160
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At 15:17 -0500 12/16/04, David Blacka wrote:
>I was thinking about the use of private algorithms in DNSSEC the other day,
>and it struck me that they might not, strictly speaking, work.
>Fair enough, but there are no instructions for the DS record. So how would a
>resolver be able to distinguish between a known private algorithm from an
>unknown private algorithm from the delegation?
>I.e., it is expected that a DNSSEC validator would be able to make the
>determination that it does or does not support any of the algorithms directly
>from the DS set. As soon as a DNSSEC validator knows about one private
>algorithm (per scheme), it suddenly cannot make this determination.
>
>Or am I missing something?
I'll start with what might be, strictly speaking, a dumb question.
Why can't a verifier do this/What happens if this is what is done:
Get the DS set for X and validate it with parent's algorithms
Toss out all the DS records for unknown algorithms it finds in the set
(Toss out = remove from further consideration)
Finds one (to make this simple) last DS - for a 'private' algorithm
Get the DNSKEY set for X w/o validation
Finds the lone corresponding DNSKEY and pulls out the private alg name
Looks to see if the private alg name is one it understands
Course, here's where the problems begin:
1) If the private alg name is one not understood, there's no way to
validate that the received DNSKEY set for X is genuine.
2) If the private alg name is understood and the DNSKEY set fails to
validate then you have dubious data
3) If the private alg name is understood and the DNSKEY set passes
validation you are in luck.
The problem is with #1 and #2. You can't decide if the received data
is genuine (and you therefore ought to proceed as if you can't
validate the data) or if the data is sub'd in for a set that oughta
fall into category #3.
E.g., let's say verifier and signer know Godot's Algorithm, called
"godot.algorithm" in a private-algorithm public key. I ask for
"www.dave.example." and along the way get the DS set for
dave.example.
So the next thing I expect to hear is a DNSKEY set for dave.example
sent from dave.example, but instead Bert is off in the corner
sniffing my wireless and transmits his "version" of the DNSKEY set
for dave.example., with a private algorithm called "ernie.algorithm"
in it.
I'll hear Bert's version and process it before the true version gets
into the airwaves. Given careful crafting of the private algorithm,
I can be duped into believing that Dave's Algorithm isn't in use, but
Ernie's Algorithm is. But since I don't know Ernie's Algorithm, I
give up.
Even if the airwaves will soon send the true DNSKEY set my way, why
after thinking may I should give up for legitimate reasons, would I
continue wait for Godot? ("It's a joke son." - Foghorn Leghorn.) End
of e.g.
It seems to me to be that A) private algorithms are hosed or B) the
DS2 RRSet includes the sub-algorithm field (the name of the private
algorithm). Well, those are my two first approximations - maybe
there's a way to squeeze the private alg name into the hash in the DS
for private algorithms before it's too late.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"A noble spirit embiggens the smallest man." - Jebediah Springfield
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Mon Dec 20 17:33:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19763
for ; Mon, 20 Dec 2004 17:33:25 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgVzv-0009De-9u
for namedroppers-data@psg.com; Mon, 20 Dec 2004 22:27:23 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgVzp-0009DJ-W0
for namedroppers@ops.ietf.org; Mon, 20 Dec 2004 22:27:18 +0000
Received: from [10.31.32.75] (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id iBKMLUxN076837;
Mon, 20 Dec 2004 17:21:31 -0500 (EST)
(envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To: <41C1FE2D.90604@verisignlabs.com>
References: <200412162107.iBGL7CfV093770@drugs.dv.isc.org>
<41C1FE2D.90604@verisignlabs.com>
Date: Mon, 20 Dec 2004 17:21:27 -0500
To: David Blacka
From: Edward Lewis
Subject: Re: DNSSEC and unknown algorithms
Cc: Mark Andrews , namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.48 on 66.92.146.160
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At 16:29 -0500 12/16/04, David Blacka wrote:
>>David Blacka wrote:
>>>My question is, why is this a SHOULD (or "should" in the first paragraph).
>Mark Andrews wrote:
>> The security policy may say otherwise.
That and a verifier might consider this an outright resolution service failure.
(Back to where "my = David"):
>Just to clarify, in my head, everything always has an exception for "local
>policy". But in this case, am I right in thinking that treating the zone as
>*signed* and not entirely bogus is not an option? Or to put this another way,
>what other options besides "treat the zone as unsigned" or "write the whole
>zone off as bogus due to local policy" does a validator have?
I think the answer to the last question is "none." (With "write off
the zone as bogus" meaning RCODE = service failure.)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"A noble spirit embiggens the smallest man." - Jebediah Springfield
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Mon Dec 20 23:29:26 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13796
for ; Mon, 20 Dec 2004 23:29:26 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgbU2-000MZk-8V
for namedroppers-data@psg.com; Tue, 21 Dec 2004 04:18:50 +0000
Received: from [65.201.175.9] (helo=mail.verisignlabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgbTo-000MYG-Os
for namedroppers@ops.ietf.org; Tue, 21 Dec 2004 04:18:36 +0000
Received: from [192.168.1.10] ([::ffff:68.48.24.54])
(AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by mail.verisignlabs.com with esmtp; Mon, 20 Dec 2004 23:18:31 -0500
id 0054C317.41C7A417.00001C79
Message-ID: <41C7A48A.8040008@verisignlabs.com>
Date: Mon, 20 Dec 2004 23:20:26 -0500
From: David Blacka
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Edward Lewis
CC: namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
References: <41C1ED4A.1060606@verisignlabs.com>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Edward Lewis wrote:
> Course, here's where the problems begin:
>
> 1) If the private alg name is one not understood, there's no way to
> validate that the received DNSKEY set for X is genuine.
>
> 2) If the private alg name is understood and the DNSKEY set fails to
> validate then you have dubious data
>
> 3) If the private alg name is understood and the DNSKEY set passes
> validation you are in luck.
>
> The problem is with #1 and #2. You can't decide if the received data is
> genuine (and you therefore ought to proceed as if you can't validate the
> data) or if the data is sub'd in for a set that oughta fall into
> category #3.
Once again, Ed dazzles me with his insight. I had not yet considered
the security implications of this issue, only the asymmetry of it.
Just to summarize: Ed has shown that a zone signed only with a known
private algorithm (and any number of unknown algorithms) could be made
to appear (erroneously) insecure via a MitM attack.
> It seems to me to be that A) private algorithms are hosed or B) the DS2
> RRSet includes the sub-algorithm field (the name of the private
> algorithm). Well, those are my two first approximations - maybe there's
> a way to squeeze the private alg name into the hash in the DS for
> private algorithms before it's too late.
Well, if we don't fix it, then yes, I believe that private algorithms
are hosed. As for B), I don't think we need to define a DS2, we need
merely to define the same rule for DS records as is defined for DNSKEY
and RRSIG.
For instance, we could modify the second sentence of the first paragraph
of records-11, Appendix A.1.1 from:
The public key area in the DNSKEY RR and the signature area in the
RRSIG RR begin with a wire encoded domain name, which MUST NOT be
compressed.
to
The public key area in the DNSKEY RR, the signature area in the RRSIG
RR, and the hash area in the DS RR begin with a wire encoded domain
name, which MUST NOT be compressed.
Plus a similar transformation in the next paragraph for the OID case,
assuming that it isn't too late to modify the document before RFC.
That would give the DS as much attention as anything else with respect
to private algorithms, in any case.
--
David Blacka
Sr. Engineer Verisign Applied Research
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 21 06:20:19 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26559
for ; Tue, 21 Dec 2004 06:20:19 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CghzW-000H8P-F2
for namedroppers-data@psg.com; Tue, 21 Dec 2004 11:15:46 +0000
Received: from [193.0.0.199] (helo=postman.ripe.net)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CghzS-000H7q-Bp
for namedroppers@ops.ietf.org; Tue, 21 Dec 2004 11:15:42 +0000
Received: by postman.ripe.net (Postfix, from userid 8)
id AAC682472B; Tue, 21 Dec 2004 12:15:41 +0100 (CET)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
by postman.ripe.net (Postfix) with ESMTP
id AF8EE2460D; Tue, 21 Dec 2004 12:15:39 +0100 (CET)
Received: from x50.ripe.net (x50.ripe.net [193.0.1.50])
by birch.ripe.net (8.12.10/8.11.6) with SMTP id iBLBFd8Q008824;
Tue, 21 Dec 2004 12:15:39 +0100
Date: Tue, 21 Dec 2004 12:15:39 +0100
From: "Olaf M. Kolkman"
To: David Blacka
Cc: Ed.Lewis@neustar.biz, namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
Message-Id: <20041221121539.31fbcc62.olaf@ripe.net>
In-Reply-To: <41C7A48A.8040008@verisignlabs.com>
References: <41C1ED4A.1060606@verisignlabs.com>
<41C7A48A.8040008@verisignlabs.com>
Organization: RIPE NCC
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00
X-RIPE-Spam-Status: N 0.000049 / -5.9
X-RIPE-Signature: 3067ead3579da8853ab20946ca5bc274
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
On Mon, 20 Dec 2004 23:20:26 -0500
David Blacka wrote:
> For instance, we could modify the second sentence of the first paragraph
> of records-11, Appendix A.1.1 from:
>
(...)
Hmmmm.... this hurts a bit.
We have a choice;
- We send in a note to the RFC editor, now or during 48-hours; that is
if the WG consents on this issue. (this is a security bug that was
not covered earlier).
- We let the RFCs be published and write a small I-D that updates the
documents.
Whatever we do we have a problem of deployed code not knowing of
this. I currently think the first choice is more elegant.
Please spend some time on reviewing this issue and its solution, it is
important enough!
-- Olaf
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 21 09:24:00 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13321
for ; Tue, 21 Dec 2004 09:24:00 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1Cgkrb-000BfU-3S
for namedroppers-data@psg.com; Tue, 21 Dec 2004 14:19:47 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgkrV-000Ber-QO
for namedroppers@ops.ietf.org; Tue, 21 Dec 2004 14:19:42 +0000
Received: from [10.31.32.75] (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id iBLEJZit082716;
Tue, 21 Dec 2004 09:19:36 -0500 (EST)
(envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To: <20041221121539.31fbcc62.olaf@ripe.net>
References: <41C1ED4A.1060606@verisignlabs.com>
<41C7A48A.8040008@verisignlabs.com>
<20041221121539.31fbcc62.olaf@ripe.net>
Date: Tue, 21 Dec 2004 09:17:14 -0500
To: "Olaf M. Kolkman"
From: Edward Lewis
Subject: Re: private algorithms and the DS record
Cc: David Blacka , Ed.Lewis@neustar.biz,
namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.48 on 66.92.146.160
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At 12:15 +0100 12/21/04, Olaf M. Kolkman wrote:
>We have a choice;
>
>- We send in a note to the RFC editor, now or during 48-hours; that is
> if the WG consents on this issue. (this is a security bug that was
> not covered earlier).
>
>- We let the RFCs be published and write a small I-D that updates the
> documents.
I'd prefer the first - I find clarification documents tiring.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"A noble spirit embiggens the smallest man." - Jebediah Springfield
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 21 10:56:17 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22129
for ; Tue, 21 Dec 2004 10:56:17 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgmHf-000NB8-Ja
for namedroppers-data@psg.com; Tue, 21 Dec 2004 15:50:47 +0000
Received: from [192.94.214.100] (helo=nutshell.tislabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgmHa-000NAZ-6P
for namedroppers@ops.ietf.org; Tue, 21 Dec 2004 15:50:42 +0000
Received: (from uucp@localhost)
by nutshell.tislabs.com (8.12.9/8.12.9) id iBLFlMx1012817
for ; Tue, 21 Dec 2004 10:47:22 -0500 (EST)
Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0)
id srcAAAtYaWbz; Tue, 21 Dec 04 10:47:20 -0500
Received: from localhost (weiler@localhost)
by tislabs.com (8.12.9/8.12.9) with ESMTP id iBLFn3AS011749
for ; Tue, 21 Dec 2004 10:49:03 -0500 (EST)
Date: Tue, 21 Dec 2004 10:49:03 -0500 (EST)
From: Samuel Weiler
X-X-Sender: weiler@filbert
To: namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
In-Reply-To:
Message-ID:
References: <41C1ED4A.1060606@verisignlabs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Ed writes:
> 1) If the private alg name is one not understood, there's no way to
> validate that the received DNSKEY set for X is genuine.
I'm confused. Doesn't the DS hash already cover the name of the
algorithm, which is carried in the DNSKEY? The validator doesn't need
to check the RRSIG(DNSKEY), just match the DNSKEY to the DS. Yes,
someone could substitute in a DNSKEY with a different private
algorithm name, but, unless these cryptographic hashes aren't worth
the money we're paying for them, the DS won't match whatever the
attackers generate, right?
In other words, I think Ed's validator todo list is sufficient (which
adds the "if it's a private algorithm, get the DNSKEY and see if you
understand it" steps).
> maybe there's a way to squeeze the private alg name into the hash
> in the DS for private algorithms before it's too late.
I don't think this is needed.
As for updating the docs, I also prefer an RFC Editor note rather than
a separate doc.
-- Sam
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 21 11:21:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23577
for ; Tue, 21 Dec 2004 11:21:43 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1Cgmif-0000uh-Q5
for namedroppers-data@psg.com; Tue, 21 Dec 2004 16:18:41 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgmiL-0000tC-Ej
for namedroppers@ops.ietf.org; Tue, 21 Dec 2004 16:18:21 +0000
Received: from [10.31.32.75] (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id iBLGIF5a083171;
Tue, 21 Dec 2004 11:18:16 -0500 (EST)
(envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To:
References: <41C1ED4A.1060606@verisignlabs.com>
Date: Tue, 21 Dec 2004 11:18:12 -0500
To: Samuel Weiler
From: Edward Lewis
Subject: Re: private algorithms and the DS record
Cc: namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.48 on 66.92.146.160
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At 10:49 -0500 12/21/04, Samuel Weiler wrote:
>Doesn't the DS hash already cover the name of the
>algorithm, which is carried in the DNSKEY?
There is that safety net, yes. Maybe all hope is not lost.
>The validator doesn't need
>to check the RRSIG(DNSKEY), just match the DNSKEY to the DS.
One factoid that's been bandied about is that the RRSIG(DNSKEY)
provides two functions. It enables the KSK/ZSK model of key
management. It also provides a time-limiting/revocation-like
function, i.e., if there is no RRSIG(DNSKEY) then the DNSKEY set is
worthless to validation. If you can't make heads or tails of the
key's algorithm, the key is of no value to you, the fact that this
makes the RRSIG(DNSKEY) for it also unintelligible is unimportant.
>someone could substitute in a DNSKEY with a different private
>algorithm name, but, unless these cryptographic hashes aren't worth
>the money we're paying for them, the DS won't match whatever the
>attackers generate, right?
I suppose that's the case. I wonder - if you have a 2048 bit key for
a private algorithm and a 160 bit hash, I'd be pretty free to find a
2048 bit sequence to put at the end of a domain name to cook up a
result. For the mathematicians, just how good is SHA-1.
(Yes, I know, here we go again with the crypto fans touting how good
SHA-1 is. ;))
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"A noble spirit embiggens the smallest man." - Jebediah Springfield
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 21 11:54:55 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28659
for ; Tue, 21 Dec 2004 11:54:54 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgnEE-0004nV-36
for namedroppers-data@psg.com; Tue, 21 Dec 2004 16:51:18 +0000
Received: from [195.82.114.197] (helo=shed.alex.org.uk)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgnE2-0004kN-Fk
for namedroppers@ops.ietf.org; Tue, 21 Dec 2004 16:51:06 +0000
Received: from [192.168.100.25] (localhost [127.0.0.1])
by shed.alex.org.uk (Postfix) with ESMTP
id 7F1C9C2DA4; Tue, 21 Dec 2004 16:51:05 +0000 (GMT)
Date: Tue, 21 Dec 2004 16:51:05 +0000
From: Alex Bligh
Reply-To: Alex Bligh
To: Samuel Weiler , namedroppers@ops.ietf.org
Cc: Alex Bligh
Subject: Re: private algorithms and the DS record
Message-ID: <9347523AF3E1691C9687BE7D@[192.168.100.25]>
In-Reply-To:
References: <41C1ED4A.1060606@verisignlabs.com>
X-Mailer: Mulberry/4.0.0a3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
--On 21 December 2004 10:49 -0500 Samuel Weiler wrote:
> As for updating the docs, I also prefer an RFC Editor note rather than
> a separate doc.
(From a position of relative ignorance) yes I agree - assuming we are
confident we have infact bottomed the problem out as the worst thing
to do would be to half fix it.
Alex
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 21 12:30:06 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01413
for ; Tue, 21 Dec 2004 12:30:06 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgnnZ-0009UJ-CI
for namedroppers-data@psg.com; Tue, 21 Dec 2004 17:27:49 +0000
Received: from [65.201.175.9] (helo=mail.verisignlabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgnnU-0009Tl-2O
for namedroppers@ops.ietf.org; Tue, 21 Dec 2004 17:27:44 +0000
Received: from [10.131.244.227] ([::ffff:172.25.170.10])
(AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by mail.verisignlabs.com with esmtp; Tue, 21 Dec 2004 12:27:43 -0500
id 0054C075.41C85D0F.00004506
Message-ID: <41C85D0E.40002@verisignlabs.com>
Date: Tue, 21 Dec 2004 12:27:42 -0500
From: David Blacka
Organization: VeriSign, Inc.
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alex Bligh
CC: Samuel Weiler , namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
References: <41C1ED4A.1060606@verisignlabs.com> <9347523AF3E1691C9687BE7D@[192.168.100.25]>
In-Reply-To: <9347523AF3E1691C9687BE7D@[192.168.100.25]>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Alex Bligh wrote:
>
>
> --On 21 December 2004 10:49 -0500 Samuel Weiler wrote:
>
>> As for updating the docs, I also prefer an RFC Editor note rather than
>> a separate doc.
>
>
> (From a position of relative ignorance) yes I agree - assuming we are
> confident we have infact bottomed the problem out as the worst thing
> to do would be to half fix it.
Perhaps I am now suddenly confused. What is "half fix it"?
Let me summarize this issue as I see it:
1) I pointed out an issue of symmetry: in this one case, a validator
cannot make the same decision at the same algorithmic point as it can
without private algorithms. That is, it cannot decide to treat the
subzone as unsigned from the DS set alone, it must fetch the DNSKEY to
find the full name of the algorithm. I see this as an implementation
problem. Something that might work, but is an unnecessary complication,
and a complication that isn't clearly visible from the documents.
2) Ed pointed out a possible security problem.
3) Sam argued that this security problem (if it exists) would be hard to
exploit.
Let's approach this issue from the opposite direction. Is there any
reason NOT to prepend the private alg. name to the DS hash? Was the
fact that the DS wasn't mentioned in the private algorithm appendix ON
PURPOSE?
I am personally of the opinion that the fact that the DS was omitted was
just an oversight, due to the fact that no one really examined private
algorithms during the main review process. I am of the opinion that NOT
fixing this means, at the very minimum, that private algorithm support
will be harder than necessary to implement in the validator. It *may*
mean that private algorithms are unusable or at least unsafe.
And I am unsure where the concept that putting the private algorithm
label in the DS record only "half" fixes the problem comes from. Or why
it would be seen as any more of a hack in DS than in DNSKEY or RRSIG.
If, as I suspect, this was a simple oversight, then of course an RFC
Editor note is the correct approach.
--
David Blacka
Sr. Engineer VeriSign Applied Research
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 21 13:00:36 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04526
for ; Tue, 21 Dec 2004 13:00:35 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgoFT-000DOF-Me
for namedroppers-data@psg.com; Tue, 21 Dec 2004 17:56:39 +0000
Received: from [129.6.16.226] (helo=smtp.nist.gov)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgoFP-000DNl-HK
for namedroppers@ops.ietf.org; Tue, 21 Dec 2004 17:56:35 +0000
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92])
by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iBLHuPYa000898
for ; Tue, 21 Dec 2004 12:56:25 -0500
Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185])
by postmark.nist.gov (8.12.5/8.12.5) with SMTP id iBLHu5LS003822
for ; Tue, 21 Dec 2004 12:56:05 -0500 (EST)
From: "Scott Rose"
To:
Subject: RE: private algorithms and the DS record
Date: Tue, 21 Dec 2004 12:56:06 -0500
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <41C85D0E.40002@verisignlabs.com>
Importance: Normal
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: scottr@nist.gov
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
> -----Original Message-----
> From: owner-namedroppers@ops.ietf.org
> [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of David Blacka
>
> Let's approach this issue from the opposite direction. Is there any
> reason NOT to prepend the private alg. name to the DS hash? Was the
> fact that the DS wasn't mentioned in the private algorithm appendix ON
> PURPOSE?
>
> I am personally of the opinion that the fact that the DS was omitted was
> just an oversight, due to the fact that no one really examined private
> algorithms during the main review process. I am of the opinion that NOT
> fixing this means, at the very minimum, that private algorithm support
> will be harder than necessary to implement in the validator. It *may*
> mean that private algorithms are unusable or at least unsafe.
>
It was an oversight. Private algorithms were not really brought up enough
during the rewrite process.
Scott
>
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 21 13:16:49 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05735
for ; Tue, 21 Dec 2004 13:16:49 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgoWX-000GHu-Tu
for namedroppers-data@psg.com; Tue, 21 Dec 2004 18:14:17 +0000
Received: from [195.82.114.197] (helo=shed.alex.org.uk)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgoWK-000GBj-NM
for namedroppers@ops.ietf.org; Tue, 21 Dec 2004 18:14:05 +0000
Received: from [192.168.100.25] (localhost [127.0.0.1])
by shed.alex.org.uk (Postfix) with ESMTP
id 1A413C2DA4; Tue, 21 Dec 2004 18:14:04 +0000 (GMT)
Date: Tue, 21 Dec 2004 18:14:04 +0000
From: Alex Bligh
Reply-To: Alex Bligh
To: David Blacka
Cc: Samuel Weiler , namedroppers@ops.ietf.org,
Alex Bligh
Subject: Re: private algorithms and the DS record
Message-ID: <0489E5A93325360838A81FCE@[192.168.100.25]>
In-Reply-To: <41C85D0E.40002@verisignlabs.com>
References: <41C1ED4A.1060606@verisignlabs.com>
<9347523AF3E1691C9687BE7D@[192.168.100.25]>
<41C85D0E.40002@verisignlabs.com>
X-Mailer: Mulberry/4.0.0a3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
--On 21 December 2004 12:27 -0500 David Blacka
wrote:
>> (From a position of relative ignorance) yes I agree - assuming we are
>> confident we have infact bottomed the problem out as the worst thing
>> to do would be to half fix it.
>
> Perhaps I am now suddenly confused. What is "half fix it"?
I'm not pointing out any great hole and I'm not saying what you propose
half fixes it. I am just saying if we rushed into getting EFC Editor to put
in a note to the effect suggested, and a short time later Ed came up with
another equally startling revelation saying "oops we didn't fix that hole
completely" we'd look a bit silly (and worse have rather confused
documentation).
The advantage of the I-D process is that it gets more peer review,
so it would be good to know, if we are going to go the RFC-Editor process,
that everyone thinks we've really fixed the hole, and that there's
no/little change peer review is going to point out a problem with the
proposed solution.
FAOD, from my ill-informed standpoint, fixing it as described seems the
right thing to do.
Alex
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 21 13:21:16 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05921
for ; Tue, 21 Dec 2004 13:21:16 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgobK-000GsT-MI
for namedroppers-data@psg.com; Tue, 21 Dec 2004 18:19:14 +0000
Received: from [66.92.66.68] (helo=cyteen.hactrn.net)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1Cgoaf-000Glg-Jm
for namedroppers@ops.ietf.org; Tue, 21 Dec 2004 18:18:34 +0000
Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK))
by cyteen.hactrn.net (Postfix) with ESMTP id EF64920B
for ; Tue, 21 Dec 2004 13:18:32 -0500 (EST)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
by thrintun.hactrn.net (Postfix) with ESMTP id D395D41C8
for ; Tue, 21 Dec 2004 13:18:31 -0500 (EST)
Date: Tue, 21 Dec 2004 13:18:31 -0500
From: Rob Austein
To: namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
In-Reply-To: <41C85D0E.40002@verisignlabs.com>
References: <41C1ED4A.1060606@verisignlabs.com>
<9347523AF3E1691C9687BE7D@192.168.100.25>
<41C85D0E.40002@verisignlabs.com>
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20041221181831.D395D41C8@thrintun.hactrn.net>
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At Tue, 21 Dec 2004 12:27:42 -0500, David Blacka wrote:
>
> Let me summarize this issue as I see it:
>
> 1) I pointed out an issue of symmetry: in this one case, a validator
> cannot make the same decision at the same algorithmic point as it can
> without private algorithms. That is, it cannot decide to treat the
> subzone as unsigned from the DS set alone, it must fetch the DNSKEY to
> find the full name of the algorithm. I see this as an implementation
> problem. Something that might work, but is an unnecessary complication,
> and a complication that isn't clearly visible from the documents.
I think what you've detected is an optimization that can't be
performed in the case of private algorithms. The original purpose of
the algorithm check on the DS RRset was to defend against algorithm
downgrade attacks (your points 2 and 3). I do not see it as a big
deal that one has to retrieve the child's apex DNSKEY RRset before one
can figure out whether one really understands the algorithm in use.
The private algorithms are specified as subtypes of a subtype. You
should expect them to be a horrible mess.
> 2) Ed pointed out a possible security problem.
>
> 3) Sam argued that this security problem (if it exists) would be hard to
> exploit.
I think that Sam and Scott have demonstrated that this is not in fact
a serious problem, since the DS hash covers the algorithm ID.
There may be an algorithm downgrade attack issue if somebody uses two
separate private algorithms in the same zone. Maybe not. Haven't
analyzed it in detail. Am not convinced we should be losing sleep
over it.
> Let's approach this issue from the opposite direction. Is there any
> reason NOT to prepend the private alg. name to the DS hash? Was the
> fact that the DS wasn't mentioned in the private algorithm appendix ON
> PURPOSE?
If I understand what you're proposing, it would special-case the
private algorithm subtype, ie, the DS RR would now be doing special
voodoo for the private algorithm subtypes. The situation is not
equivilent to the situation with DNSKEY and RRIG -- in the latter
cases, the special-case voodoo was inserted into a field that's
algorithm-specific in any case (key material or sig material,
respectively). In the DS case, if I understand you correctly, you're
proposing to insert the special-case voodoo into a field that's the
same for every (signature) algorithm (hash of the key material).
I don't think we should do this to the DS RR. It already hashs the
private algorithm identifier information as part of the key material,
that should suffice.
So, to answer your question, while I don't think there was a concious
decision here (don't think anybody thought much about it), I think the
algorithm as specified is correct.
If you do manage to convince the WG to change this, we'll probably
need to do the equivilent of TCR to the private algorithm subtypes.
--Rob
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 21 16:06:22 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22056
for ; Tue, 21 Dec 2004 16:06:21 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1Cgr94-000DCM-RT
for namedroppers-data@psg.com; Tue, 21 Dec 2004 21:02:14 +0000
Received: from [192.94.214.100] (helo=nutshell.tislabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1Cgr8z-000DBH-QB
for namedroppers@ops.ietf.org; Tue, 21 Dec 2004 21:02:10 +0000
Received: (from uucp@localhost)
by nutshell.tislabs.com (8.12.9/8.12.9) id iBLKwoRb014479
for ; Tue, 21 Dec 2004 15:58:50 -0500 (EST)
Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0)
id srcAAA_maGrC; Tue, 21 Dec 04 15:58:48 -0500
Received: from localhost (weiler@localhost)
by tislabs.com (8.12.9/8.12.9) with ESMTP id iBLL0Ua4022554
for ; Tue, 21 Dec 2004 16:00:30 -0500 (EST)
Date: Tue, 21 Dec 2004 16:00:29 -0500 (EST)
From: Samuel Weiler
X-X-Sender: weiler@filbert
To: namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
In-Reply-To: <41C85D0E.40002@verisignlabs.com>
Message-ID:
References: <41C1ED4A.1060606@verisignlabs.com>
<9347523AF3E1691C9687BE7D@[192.168.100.25]>
<41C85D0E.40002@verisignlabs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
> Is there any reason NOT to prepend the private alg. name to the DS
> hash?
I concur with Rob: this adds unnecessary ugliness to the DS RR, and is
likely a backwards-incompatible change. I don't want to have to dust
off 3755 and wait for IANA again.
> Was the fact that the DS wasn't mentioned in the private algorithm
> appendix ON PURPOSE?
Concur with Scott and Rob: there was no particular consideration given
to private algorithms. If there had been, I still doubt we would have
changed anything.
-- Sam
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 21 16:21:03 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25482
for ; Tue, 21 Dec 2004 16:21:03 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgrPN-000FVP-VC
for namedroppers-data@psg.com; Tue, 21 Dec 2004 21:19:05 +0000
Received: from [65.201.175.9] (helo=mail.verisignlabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgrPG-000FTm-Rw
for namedroppers@ops.ietf.org; Tue, 21 Dec 2004 21:18:58 +0000
Received: from [10.131.244.227] ([::ffff:172.25.170.10])
(AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by mail.verisignlabs.com with esmtp; Tue, 21 Dec 2004 16:18:57 -0500
id 0054C355.41C89341.00007390
Message-ID: <41C89341.3040501@verisignlabs.com>
Date: Tue, 21 Dec 2004 16:18:57 -0500
From: David Blacka
Organization: VeriSign, Inc.
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Samuel Weiler
CC: namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
References: <41C1ED4A.1060606@verisignlabs.com> <9347523AF3E1691C9687BE7D@[192.168.100.25]> <41C85D0E.40002@verisignlabs.com>
In-Reply-To:
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Samuel Weiler wrote:
>>Is there any reason NOT to prepend the private alg. name to the DS
>>hash?
>
>
> I concur with Rob: this adds unnecessary ugliness to the DS RR, and is
> likely a backwards-incompatible change. I don't want to have to dust
> off 3755 and wait for IANA again.
Backwards-incompatible with what?
>>Was the fact that the DS wasn't mentioned in the private algorithm
>>appendix ON PURPOSE?
>
>
> Concur with Scott and Rob: there was no particular consideration given
> to private algorithms. If there had been, I still doubt we would have
> changed anything.
The text of protocol-09 section 5.2 does not support this postion.
--
David Blacka
Sr. Engineer VeriSign Applied Research
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 21 18:37:07 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20179
for ; Tue, 21 Dec 2004 18:37:05 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgtG9-00078Y-DN
for namedroppers-data@psg.com; Tue, 21 Dec 2004 23:17:41 +0000
Received: from [217.155.92.109] (helo=mail.links.org)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgtG0-000777-Nl
for namedroppers@ops.ietf.org; Tue, 21 Dec 2004 23:17:32 +0000
Received: from [193.133.15.218] (localhost [127.0.0.1])
by mail.links.org (Postfix) with ESMTP id A5C4A33C45;
Tue, 21 Dec 2004 23:17:31 +0000 (GMT)
Message-ID: <41C8AE97.2030803@algroup.co.uk>
Date: Tue, 21 Dec 2004 23:15:35 +0000
From: Ben Laurie
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Edward Lewis
Cc: Samuel Weiler , namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
References: <41C1ED4A.1060606@verisignlabs.com>
In-Reply-To:
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Edward Lewis wrote:
> At 10:49 -0500 12/21/04, Samuel Weiler wrote:
>
>> Doesn't the DS hash already cover the name of the
>> algorithm, which is carried in the DNSKEY?
>
>
> There is that safety net, yes. Maybe all hope is not lost.
>
>> The validator doesn't need
>> to check the RRSIG(DNSKEY), just match the DNSKEY to the DS.
>
>
> One factoid that's been bandied about is that the RRSIG(DNSKEY) provides
> two functions. It enables the KSK/ZSK model of key management. It also
> provides a time-limiting/revocation-like function, i.e., if there is no
> RRSIG(DNSKEY) then the DNSKEY set is worthless to validation. If you
> can't make heads or tails of the key's algorithm, the key is of no value
> to you, the fact that this makes the RRSIG(DNSKEY) for it also
> unintelligible is unimportant.
>
>> someone could substitute in a DNSKEY with a different private
>> algorithm name, but, unless these cryptographic hashes aren't worth
>> the money we're paying for them, the DS won't match whatever the
>> attackers generate, right?
>
>
> I suppose that's the case. I wonder - if you have a 2048 bit key for a
> private algorithm and a 160 bit hash, I'd be pretty free to find a 2048
> bit sequence to put at the end of a domain name to cook up a result.
> For the mathematicians, just how good is SHA-1.
>
> (Yes, I know, here we go again with the crypto fans touting how good
> SHA-1 is. ;))
Is this my cue? The work factor for finding such a cooked up result is
huge, i.e. around 2^159. Yes, there are many 2048 bit sequences that'll
work, but finding one will take you a _very_ long time. Impossibly long.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 21 20:04:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29493
for ; Tue, 21 Dec 2004 20:04:12 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1Cguqm-000KCP-1L
for namedroppers-data@psg.com; Wed, 22 Dec 2004 00:59:36 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1Cguqg-000KBe-UF
for namedroppers@ops.ietf.org; Wed, 22 Dec 2004 00:59:31 +0000
Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id iBM0wLTf096805;
Tue, 21 Dec 2004 19:58:22 -0500 (EST)
(envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To: <41C8AE97.2030803@algroup.co.uk>
References: <41C1ED4A.1060606@verisignlabs.com>
<41C8AE97.2030803@algroup.co.uk>
Date: Tue, 21 Dec 2004 19:58:05 -0500
To: Ben Laurie
From: Edward Lewis
Subject: Re: private algorithms and the DS record
Cc: Edward Lewis , Samuel Weiler ,
namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At 23:15 +0000 12/21/04, Ben Laurie wrote:
>Is this my cue? The work factor for finding such a cooked up result is huge,
>i.e. around 2^159. Yes, there are many 2048 bit sequences that'll work, but
>finding one will take you a _very_ long time. Impossibly long.
Right on the mark. I suppose finding a sequence that matches the
footprint and hashes the same is even more to ask. Exit stage left.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"A noble spirit embiggens the smallest man." - Jebediah Springfield
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Wed Dec 22 00:08:03 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19338
for ; Wed, 22 Dec 2004 00:08:02 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CgydG-0000Hk-An
for namedroppers-data@psg.com; Wed, 22 Dec 2004 05:01:54 +0000
Received: from [66.92.66.68] (helo=cyteen.hactrn.net)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CgydB-0000GU-I1
for namedroppers@ops.ietf.org; Wed, 22 Dec 2004 05:01:50 +0000
Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK))
by cyteen.hactrn.net (Postfix) with ESMTP id DDB04304
for ; Wed, 22 Dec 2004 00:01:48 -0500 (EST)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
by thrintun.hactrn.net (Postfix) with ESMTP id 4613741C8
for ; Wed, 22 Dec 2004 00:01:48 -0500 (EST)
Date: Wed, 22 Dec 2004 00:01:48 -0500
From: Rob Austein
To: namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
In-Reply-To: <41C89341.3040501@verisignlabs.com>
References: <41C1ED4A.1060606@verisignlabs.com>
<9347523AF3E1691C9687BE7D@192.168.100.25>
<41C85D0E.40002@verisignlabs.com>
<41C89341.3040501@verisignlabs.com>
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20041222050148.4613741C8@thrintun.hactrn.net>
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At Tue, 21 Dec 2004 16:18:57 -0500, David Blacka wrote:
>
> Samuel Weiler wrote:
> >
> > I concur with Rob: this adds unnecessary ugliness to the DS RR, and is
> > likely a backwards-incompatible change. I don't want to have to dust
> > off 3755 and wait for IANA again.
>
> Backwards-incompatible with what?
At least one of us is confused.
If I understood you correctly, you proposed that the DS RR "Digest
Field" (-records-11 5.1.4), which currently holds a digest calculated
on the same field of the corresponding DNSKEY RR regardless of the
signature algorithm, should be changed to include a second copy of the
private algorithm identifier as a special case for the private key
subtypes of the DNSKEY RR. This would be an incompatable change to
the content of the DS RR: currently deployed code based on the current
specs would have to be changed, since otherwise digests would never
match for the private key subtypes.
Please note that, if you follow the definitions in -records 5.1.4,
2.1.1 through 2.1.4, and A.1.1, the private algorithm subtypes (253
and 254) -already- include the private algorithm identifier (DNS name
for subtype 253, OID for subtype 254) in the public key field (2.1.4),
which is of course already included in the hash (5.1.4). You appear
to be proposing that we include a -second- copy of this private
algorithm identifier in the DS hash, for reasons that escape me.
Or perhaps you're proposing to include the raw private identifier
algorithm itself rather than its hash, and the hash field of the DS RR
is now to contain the concatenation of the private algorithm
identifier and the hash, again special-cased just for the private
algorithm subtypes, which is again not backwards compatible. If this
is what you meant, the case for it is a bit more understandable, but
it's still unnecessary, since that identifier is already an input to
the hash and is thus already available for you to use without
requiring a non-backwards compatible change.
Yes, there is deployed code, at least three implementations if I
recall correctly (nsd, bind9, Net::DNS::SEC, perhaps others I've
forgotten). Yes, we could change all of them if we had to, but I
don't think you've yet demonstrated any real need to do so.
At least one of us is confused. Perhaps it's me.
> > Concur with Scott and Rob: there was no particular consideration given
> > to private algorithms. If there had been, I still doubt we would have
> > changed anything.
>
> The text of protocol-09 section 5.2 does not support this postion.
Hmm? -protocol 5.2 talks about what happens if one doesn't support
any of the algorithms listed in the DS RRset. In the case of private
algorithms, yeah, one has to retrieve the child's zone's apex DNSKEY
RRset and compute the DS hashes in order to figure out precisely which
algorithms are listed in the DS RRset. So what? Please show me where
it states that the validator is not allowed to retrieve the DNSKEY
RRset if it needs that RRset in order to figure out whether it
supports the algorithms listed in the DS RRset. It has to retrieve
that same DNSKEY RRset anyway if it does understand any of the
algorithms, so what's the issue here?
As stated in an earlier message, I think you've found a place where an
obvious optimization doesn't work for private algorithms, so one has
to do it the slow way. Subtyping sure is a pain, isn't it?
--Rob
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Wed Dec 22 09:42:13 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28104
for ; Wed, 22 Dec 2004 09:42:12 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1Ch7aR-000NU4-Tb
for namedroppers-data@psg.com; Wed, 22 Dec 2004 14:35:35 +0000
Received: from [65.201.175.9] (helo=mail.verisignlabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1Ch7aM-000NTe-Ln
for namedroppers@ops.ietf.org; Wed, 22 Dec 2004 14:35:30 +0000
Received: from [10.131.244.227] ([::ffff:172.25.170.10])
(AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by mail.verisignlabs.com with esmtp; Wed, 22 Dec 2004 09:35:25 -0500
id 0054C3BC.41C9862D.00003B19
Message-ID: <41C9862D.1020408@verisignlabs.com>
Date: Wed, 22 Dec 2004 09:35:25 -0500
From: David Blacka
Organization: VeriSign, Inc.
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Edward Lewis
CC: Samuel Weiler , namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
References: <41C1ED4A.1060606@verisignlabs.com>
In-Reply-To:
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Edward Lewis wrote:
> At 10:49 -0500 12/21/04, Samuel Weiler wrote:
>
>> Doesn't the DS hash already cover the name of the
>> algorithm, which is carried in the DNSKEY?
>
>
> There is that safety net, yes. Maybe all hope is not lost.
There is still potential for a security problem, here, I think.
If an implementation pulls the private algorithm name from the DNSKEY
and eliminate the DNSKEY and DS before actually computing the SHA1 hash
of the DNSKEY.
This seems like a natural thing to do.
Certainly, there is a safer way to handle this, but how will a future
implementer be aware of the issue? By reading the namedropper archives?
--
David Blacka
Sr. Engineer VeriSign Applied Research
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Wed Dec 22 10:20:14 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02961
for ; Wed, 22 Dec 2004 10:20:14 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1Ch8F8-0004aL-Os
for namedroppers-data@psg.com; Wed, 22 Dec 2004 15:17:38 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1Ch8F4-0004Zs-HE
for namedroppers@ops.ietf.org; Wed, 22 Dec 2004 15:17:34 +0000
Received: from [10.31.32.75] (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id iBMFHSsZ099965;
Wed, 22 Dec 2004 10:17:29 -0500 (EST)
(envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To: <41C9862D.1020408@verisignlabs.com>
References: <41C1ED4A.1060606@verisignlabs.com>
<41C9862D.1020408@verisignlabs.com>
Date: Wed, 22 Dec 2004 10:17:32 -0500
To: David Blacka
From: Edward Lewis
Subject: Re: private algorithms and the DS record
Cc: Edward Lewis , Samuel Weiler ,
namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At 9:35 -0500 12/22/04, David Blacka wrote:
>There is still potential for a security problem, here, I think.
>
>If an implementation pulls the private algorithm name from the DNSKEY and
>eliminate the DNSKEY and DS before actually computing the SHA1 hash of the
>DNSKEY.
I'm not following...(maybe I'm context switching too much)...can you elaborate?
>This seems like a natural thing to do.
>
>Certainly, there is a safer way to handle this, but how will a future
>implementer be aware of the issue? By reading the namedropper archives?
Sure - I have a copy of the DNSSEC WG archives on my disk at all times...;)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"A noble spirit embiggens the smallest man." - Jebediah Springfield
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Wed Dec 22 10:41:30 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05743
for ; Wed, 22 Dec 2004 10:41:30 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1Ch8YN-0007Rk-IJ
for namedroppers-data@psg.com; Wed, 22 Dec 2004 15:37:31 +0000
Received: from [65.201.175.9] (helo=mail.verisignlabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1Ch8YJ-0007RE-8I
for namedroppers@ops.ietf.org; Wed, 22 Dec 2004 15:37:27 +0000
Received: from [10.131.244.227] ([::ffff:172.25.170.10])
(AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by mail.verisignlabs.com with esmtp; Wed, 22 Dec 2004 10:37:26 -0500
id 0054C364.41C994B6.00004BD5
Message-ID: <41C994B6.4000802@verisignlabs.com>
Date: Wed, 22 Dec 2004 10:37:26 -0500
From: David Blacka
Organization: VeriSign, Inc.
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Edward Lewis
CC: Samuel Weiler , namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
References: <41C1ED4A.1060606@verisignlabs.com> <41C9862D.1020408@verisignlabs.com>
In-Reply-To:
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Edward Lewis wrote:
> At 9:35 -0500 12/22/04, David Blacka wrote:
>
>> There is still potential for a security problem, here, I think.
>>
>> If an implementation pulls the private algorithm name from the DNSKEY and
>> eliminate the DNSKEY and DS before actually computing the SHA1 hash of
>> the
>> DNSKEY.
>
>
> I'm not following...(maybe I'm context switching too much)...can you
> elaborate?
Sure. Remember that, in the absence of private algorithms the implied
algorithm is:
1) get a referral containing a DS set.
2) for each DS, check the algorithm. If you do not recognize the
algorithm, remove it from consideration.
3) if there are still DSs in consideration, then the subzone must be
signed. if there aren't DSs in consideration (i.e., no supported
algorithms), consider the zone unsigned (or follow local policy, whatever)
4) fetch the DNSKEYs from the subzone, match DSs to DNSKEYs.
In the presence of private algorithms, the temptation might be to
replace step 2 with:
2) for each DS, check the algorithm. If you understand a private
algorithm, and one of the DSs uses a private algorithm, fetch the DNSKEY
set from the child, find the correct key via algorithm and keyid,
pull the private algorithm name and continue as before.
I.e., do the minimum amount of work to satisfy the requirements of step 2.
Where the safe thing to do is: .. find the correct key via algorithm and
keyid, make certain the DS hash matches the DNSKEY key ..
The difference between doing the safe thing and not is currently an
awareness of this safety issue. Right now, the only way a future
implementer would be aware of this issue (and how to handle private
algorithm, period, for that matter) is to either read the namedroppers
archives, or to recreate this analysis.
Maybe it will never come up. Or maybe all implementers of DNSSEC will
have read this thread when it was posted.
--
David Blacka
Sr. Engineer VeriSign Applied Research
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Wed Dec 22 12:18:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14634
for ; Wed, 22 Dec 2004 12:18:44 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1ChA3c-000M0a-JM
for namedroppers-data@psg.com; Wed, 22 Dec 2004 17:13:52 +0000
Received: from [65.201.175.9] (helo=mail.verisignlabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1ChA3H-000Lv6-PN
for namedroppers@ops.ietf.org; Wed, 22 Dec 2004 17:13:32 +0000
Received: from [10.131.244.227] ([::ffff:172.25.170.10])
(AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by mail.verisignlabs.com with esmtp; Wed, 22 Dec 2004 12:13:31 -0500
id 0054C3CE.41C9AB3B.00005EE4
Message-ID: <41C9AB3A.3050209@verisignlabs.com>
Date: Wed, 22 Dec 2004 12:13:30 -0500
From: David Blacka
Organization: VeriSign, Inc.
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Rob Austein
CC: namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
References: <41C1ED4A.1060606@verisignlabs.com> <9347523AF3E1691C9687BE7D@192.168.100.25> <41C85D0E.40002@verisignlabs.com> <41C89341.3040501@verisignlabs.com> <20041222050148.4613741C8@thrintun.hactrn.net>
In-Reply-To: <20041222050148.4613741C8@thrintun.hactrn.net>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Rob Austein wrote:
> At Tue, 21 Dec 2004 16:18:57 -0500, David Blacka wrote:
>
>>Samuel Weiler wrote:
>>
>>>I concur with Rob: this adds unnecessary ugliness to the DS RR, and is
>>>likely a backwards-incompatible change. I don't want to have to dust
>>>off 3755 and wait for IANA again.
>>
>>Backwards-incompatible with what?
>
>
> At least one of us is confused.
I think that now we are getting somewhere.
> If I understood you correctly, you proposed that the DS RR "Digest
> Field" (-records-11 5.1.4), which currently holds a digest calculated
> on the same field of the corresponding DNSKEY RR regardless of the
> signature algorithm, should be changed to include a second copy of the
> private algorithm identifier as a special case for the private key
> subtypes of the DNSKEY RR. This would be an incompatable change to
> the content of the DS RR: currently deployed code based on the current
> specs would have to be changed, since otherwise digests would never
> match for the private key subtypes.
Why would a validator ever match a DS with an unknown algorithm to a DNSKEY?
My central assumption here is that while there is deployed DNSSEC code,
there is no deployed DNSSEC code that thinks it understands any private
algorithm.
So, with the currently deployed base, what difference does it make that
a DS with a private algorithm would never match a DNSKEY? It could
never be used anyway.
If, in the future, implementations add private algorithm support, why
wouldn't they be able to understand this extension?
> Please note that, if you follow the definitions in -records 5.1.4,
> 2.1.1 through 2.1.4, and A.1.1, the private algorithm subtypes (253
> and 254) -already- include the private algorithm identifier (DNS name
> for subtype 253, OID for subtype 254) in the public key field (2.1.4),
> which is of course already included in the hash (5.1.4). You appear
> to be proposing that we include a -second- copy of this private
> algorithm identifier in the DS hash, for reasons that escape me.
Re-read section 5.2, and tell me how to reconcile the advice given there
with how private algorithms are defined. You might want to re-read my
first few posts on this subject.
> Or perhaps you're proposing to include the raw private identifier
> algorithm itself rather than its hash, and the hash field of the DS RR
> is now to contain the concatenation of the private algorithm
> identifier and the hash, again special-cased just for the private
> algorithm subtypes, which is again not backwards compatible. If this
> is what you meant, the case for it is a bit more understandable, but
> it's still unnecessary, since that identifier is already an input to
> the hash and is thus already available for you to use without
> requiring a non-backwards compatible change.
>
> Yes, there is deployed code, at least three implementations if I
> recall correctly (nsd, bind9, Net::DNS::SEC, perhaps others I've
> forgotten). Yes, we could change all of them if we had to, but I
> don't think you've yet demonstrated any real need to do so.
>
> At least one of us is confused. Perhaps it's me.
>
>
>>>Concur with Scott and Rob: there was no particular consideration given
>>>to private algorithms. If there had been, I still doubt we would have
>>>changed anything.
>>
>>The text of protocol-09 section 5.2 does not support this postion.
>
>
> Hmm? -protocol 5.2 talks about what happens if one doesn't support
> any of the algorithms listed in the DS RRset. In the case of private
> algorithms, yeah, one has to retrieve the child's zone's apex DNSKEY
> RRset and compute the DS hashes in order to figure out precisely which
> algorithms are listed in the DS RRset. So what? Please show me where
> it states that the validator is not allowed to retrieve the DNSKEY
> RRset if it needs that RRset in order to figure out whether it
> supports the algorithms listed in the DS RRset. It has to retrieve
> that same DNSKEY RRset anyway if it does understand any of the
> algorithms, so what's the issue here?
To elaborate on my statement: I disagree that we would not have changed
*anything*. At the very least, this corner case would have been
mentioned somewhere in the document (either section 5.2 or A.1.1, I expect).
My issue is not that the behavior you suggest is disallowed, but that it
also isn't mentioned anywhere. How is a future implementer supposed to
know what the issue is here?
Keep in mind that the case under discussion is about when the only
difference between the DS set containing zero supported algorithms and
one is a private algorithm. If the DS record contains one DS with a
private algorithm and one DS with algorithm 5, the whole issue will
never come up.
> As stated in an earlier message, I think you've found a place where an
> obvious optimization doesn't work for private algorithms, so one has
> to do it the slow way. Subtyping sure is a pain, isn't it?
It is certainly more of a pain when the subtyping is applied inconsistently.
I am in no way wedded to the idea of modifying the format of the DS RR.
It just looks like the easiest way to solve the problem that I am
concerned about.
My central issue here is that I am concerned that, if someone were to
implement private algorithms, they would not, in the final analysis, work.
My original point was the conflict between how private algorithms are
defined to work in Appendix A.1.1 and the text in section 5.2. I could
requote it all here, but I think I will just point you all back to my
original message starting this thread. The gist of it is that section
5.2 implies that a validator makes the decision about whether or not to
treat the child zone as signed or not from the DS set alone.
That this technique is, in fact, an optimization of a slower algorithm
may, in fact, be true, but this slower algorithm is *not* *documented*.
Maybe I'm just too pessimistic here. When I see something that is
unclear and confusing to me, I assume that it will also be unclear and
confusing to others. Maybe it won't.
I see four possible resolutions here:
1) DS records are modified to contain the private algorithm name,
allowing the validator algorithm to work the same for public and private
algorithms, or
2) The need and algorithm for fetching the private algorithm name from
the DNSKEY in a safe manner is documented somewhere (another RFC or
additional text), or
3) private algorithms are deprecated, or
4) everyone else decides that the current text is clear enough, there is
no need to change anything, we are fairly sure that future
implementations of private algorithm support will work just fine, thank
you very much.
Any of the above resolutions are acceptable, I think.
--
David Blacka
Sr. Engineer VeriSign Applied Research
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Wed Dec 22 14:08:32 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23973
for ; Wed, 22 Dec 2004 14:08:32 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1ChBlb-000CLP-RA
for namedroppers-data@psg.com; Wed, 22 Dec 2004 19:03:23 +0000
Received: from [66.92.66.68] (helo=cyteen.hactrn.net)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1ChBlW-000CIX-6p
for namedroppers@ops.ietf.org; Wed, 22 Dec 2004 19:03:19 +0000
Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK))
by cyteen.hactrn.net (Postfix) with ESMTP id DE278108
for ; Wed, 22 Dec 2004 14:03:16 -0500 (EST)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
by thrintun.hactrn.net (Postfix) with ESMTP id 4544841C8
for ; Wed, 22 Dec 2004 14:03:16 -0500 (EST)
Date: Wed, 22 Dec 2004 14:03:16 -0500
From: Rob Austein
To: namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
In-Reply-To: <41C9AB3A.3050209@verisignlabs.com>
References: <41C1ED4A.1060606@verisignlabs.com>
<9347523AF3E1691C9687BE7D@192.168.100.25>
<41C85D0E.40002@verisignlabs.com>
<41C89341.3040501@verisignlabs.com>
<20041222050148.4613741C8@thrintun.hactrn.net>
<41C9AB3A.3050209@verisignlabs.com>
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20041222190316.4544841C8@thrintun.hactrn.net>
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At Wed, 22 Dec 2004 12:13:30 -0500, David Blacka wrote:
>
> Why would a validator ever match a DS with an unknown algorithm to a
> DNSKEY?
If the validator knows that it supports at least one private
algorithm, it needs to figure out whether it supports the particular
private algorithm(s) in question. The information that the validator
needs to do this is available, but it's not all in the DS RRset: some
of it is in the DNSKEY RRset, so the validator needs to retrieve and
examine the DNSKEY RRset too.
> My central assumption here is that while there is deployed DNSSEC
> code, there is no deployed DNSSEC code that thinks it understands
> any private algorithm.
Current implementations think that they know how to generate the DS
hash for any DNSKEY RR. You propose to break that.
Whether there are any current implementations of private
algorithms...I'm not aware of any, but, by definition, nobody would
have to tell either you or me if there are any, would they?
> So, with the currently deployed base, what difference does it make
> that a DS with a private algorithm would never match a DNSKEY? It
> could never be used anyway.
Doing it my way, the code currently in the field could support this
with no changes. Implementations that don't support any private
algorithms at all can bail out based just on the algorithm number from
the DS RRset; implementations (if any) that do support private
algorithms can retrieve the DNSKEY and check the private algorithm
identifier of the DNSKEY that matches the DS hash.
Doing it your way, everybody has to know how to do the new DS
calculation algorithm. I still don't see why we need this.
> If, in the future, implementations add private algorithm support,
> why wouldn't they be able to understand this extension?
If we change the protocol to include this extension, of course they
would, but it's not necessary.
> > Please note that, if you follow the definitions in -records 5.1.4,
> > 2.1.1 through 2.1.4, and A.1.1, the private algorithm subtypes
> > (253 and 254) -already- include the private algorithm identifier
> > (DNS name for subtype 253, OID for subtype 254) in the public key
> > field (2.1.4), which is of course already included in the hash
> > (5.1.4). You appear to be proposing that we include a -second-
> > copy of this private algorithm identifier in the DS hash, for
> > reasons that escape me.
>
> Re-read section 5.2, and tell me how to reconcile the advice given
> there with how private algorithms are defined. You might want to
> re-read my first few posts on this subject.
I've read all of this, more than once. You still haven't answered my
question: please show me the text that forbids the validator from
retrieving the DNSKEY RRset as part of figuring out whether it
supports the agorithms listed in the DS RRset. -protocol 5.2 doesn't
specify -how- the validator performs this check. You appear to be
assuming that the validator is only allowed to do a byte equality test
on the algorithm number and is not allowed to think harder if the
algorithm number is itself subtyped. No, wait, you do want it to be
allowed to think harder if it's subtyped, because if it's one of the
private algorithm numbers you want it to do an extra check. Ok, so
why is your extra check (that requires a protocol change) better than
mine (which doesn't)? I don't get it.
Please try re-reading section 5.2 yourself, ok? :)
> To elaborate on my statement: I disagree that we would not have
> changed *anything*. At the very least, this corner case would have
> been mentioned somewhere in the document (either section 5.2 or
> A.1.1, I expect).
No doubt, had we had this discussion before approving the documents,
we would have added more text on this subject. I don't mind writing
more text now either. I do object to changing the protocol, since I
see no need to do so in this case.
> My issue is not that the behavior you suggest is disallowed, but
> that it also isn't mentioned anywhere. How is a future implementer
> supposed to know what the issue is here?
Sounds like there's a clarification draft to write. I never much liked
leaving the whacky private algorithm stuff in the base spec anyway,
but the WG said to keep it when the editors asked, so we did. A
separate draft explaining how to use private algorithms would be fine.
Just please don't change the base protocol.
> Keep in mind that the case under discussion is about when the only
> difference between the DS set containing zero supported algorithms
> and one is a private algorithm. If the DS record contains one DS
> with a private algorithm and one DS with algorithm 5, the whole
> issue will never come up.
Right. So one of two things happens in the case under discussion:
a) The validator knows that it understands zero private algorithms.
Trivial, give up, we're done.
b) The validator knows that it understands at least one private
algorithm. In this case, the validator has to retrieve the DNSKEY
RRset and check the DS hashes so that it can extract the private
algorithm identifiers from the DNSKEY RRs corresponding to the
private algorithm subset of the DS RRset. Painful, but doable.
After performing this check, the validator knows whether it
supports the algorithms listed in the DS RRset or not. Done.
> I am in no way wedded to the idea of modifying the format of the DS
> RR.
Good.
> It just looks like the easiest way to solve the problem that I am
> concerned about.
Guess we'll have to agree to disagree here.
> My central issue here is that I am concerned that, if someone were
> to implement private algorithms, they would not, in the final
> analysis, work.
I think they would, but the implementor would have to do everything
right, and it's pretty clear that there's some text we should write to
help the implementor do it right.
> My original point was the conflict between how private algorithms
> are defined to work in Appendix A.1.1 and the text in section 5.2.
> I could requote it all here, but I think I will just point you all
> back to my original message starting this thread. The gist of it is
> that section 5.2 implies that a validator makes the decision about
> whether or not to treat the child zone as signed or not from the DS
> set alone.
You keep saying that, and I keep not seeing it in the text. Please
show me where it says "from the DS set alone".
> That this technique is, in fact, an optimization of a slower
> algorithm may, in fact, be true, but this slower algorithm is *not*
> *documented*.
Right. It's implied (well, I think it is, your mileage clearly
varies), but it's not obvious, and I agree that we should fix that.
> Maybe I'm just too pessimistic here. When I see something that is
> unclear and confusing to me, I assume that it will also be unclear
> and confusing to others. Maybe it won't.
No, you're probably right about that. It was your proposed solution
(a protocol change) that bothered me, not your problem analysis.
> I see four possible resolutions here:
>
> 1) DS records are modified to contain the private algorithm name,
> allowing the validator algorithm to work the same for public and
> private algorithms, or
Please no.
> 2) The need and algorithm for fetching the private algorithm name
> from the DNSKEY in a safe manner is documented somewhere (another
> RFC or additional text), or
Ok with me. I prefer not to mess around with nontrivial content
changes as RFC Editor note or AUTH48 hacks, so I'd prefer a separate
document.
> 3) private algorithms are deprecated, or
Well that would be ok with me, but the WG wanted to keep this glorp
the last time we asked.
> 4) everyone else decides that the current text is clear enough,
> there is no need to change anything, we are fairly sure that future
> implementations of private algorithm support will work just fine,
> thank you very much.
I think some clarification is in order. I just don't think it
requires either a protocol change or a last minute change to the
documents we already handed off to the RFC Editor.
> Any of the above resolutions are acceptable, I think.
So I think we agree, except on option (1).
--Rob
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Wed Dec 22 18:01:37 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14413
for ; Wed, 22 Dec 2004 18:01:36 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1ChFPO-000GjB-HS
for namedroppers-data@psg.com; Wed, 22 Dec 2004 22:56:42 +0000
Received: from [192.94.214.100] (helo=nutshell.tislabs.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1ChFPC-000Ggu-Dy
for namedroppers@ops.ietf.org; Wed, 22 Dec 2004 22:56:30 +0000
Received: (from uucp@localhost)
by nutshell.tislabs.com (8.12.9/8.12.9) id iBMMrAsm000521
for ; Wed, 22 Dec 2004 17:53:10 -0500 (EST)
Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0)
id srcAAAf5aOab; Wed, 22 Dec 04 17:53:08 -0500
Received: from localhost (weiler@localhost)
by tislabs.com (8.12.9/8.12.9) with ESMTP id iBMMsnsS017810;
Wed, 22 Dec 2004 17:54:49 -0500 (EST)
Date: Wed, 22 Dec 2004 17:54:49 -0500 (EST)
From: Samuel Weiler
X-X-Sender: weiler@filbert
To: David Blacka
cc: Rob Austein , namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
In-Reply-To: <41C9AB3A.3050209@verisignlabs.com>
Message-ID:
References: <41C1ED4A.1060606@verisignlabs.com>
<9347523AF3E1691C9687BE7D@192.168.100.25>
<41C85D0E.40002@verisignlabs.com>
<41C89341.3040501@verisignlabs.com> <20041222050148.4613741C8@thrintun.hactrn.net>
<41C9AB3A.3050209@verisignlabs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
On Wed, 22 Dec 2004, David Blacka wrote:
> 1) DS records are modified to contain the private algorithm name,
> allowing the validator algorithm to work the same for public and private
> algorithms, or
As before, I want to avoid this.
> 2) The need and algorithm for fetching the private algorithm name from
> the DNSKEY in a safe manner is documented somewhere (another RFC or
> additional text), or
Excellent choice. Good catch re: the possible attack if just the
keyid, rather than the hash of the DNSKEY, is compared to the DS --
that needs to be documented. I'm increasingly fond of a "private
algorithm" doc, but an RFC-Editor note seems practical. This isn't a
big deal.
> 3) private algorithms are deprecated, or
I'd prefer to leave them in, providing some space for future
experimentation, but I wouldn't object to deprecating them.
> 4) everyone else decides that the current text is clear enough, there is
> no need to change anything, we are fairly sure that future
> implementations of private algorithm support will work just fine, thank
> you very much.
2 and 3 seem like better choices.
-- Sam
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Wed Dec 22 21:22:30 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28863
for ; Wed, 22 Dec 2004 21:22:29 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1ChIYl-000EpE-Vy
for namedroppers-data@psg.com; Thu, 23 Dec 2004 02:18:35 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1ChIYg-000EoI-LF
for namedroppers@ops.ietf.org; Thu, 23 Dec 2004 02:18:30 +0000
Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id iBN2IHb8002746;
Wed, 22 Dec 2004 21:18:18 -0500 (EST)
(envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id:
In-Reply-To: <41C994B6.4000802@verisignlabs.com>
References: <41C1ED4A.1060606@verisignlabs.com>
<41C9862D.1020408@verisignlabs.com>
<41C994B6.4000802@verisignlabs.com>
Date: Wed, 22 Dec 2004 21:10:57 -0500
To: namedroppers@ops.ietf.org
From: Edward Lewis
Subject: Re: private algorithms and the DS record
Cc: Edward Lewis
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At 10:37 -0500 12/22/04, David Blacka wrote:
I'd have to say that it seems that if an implementer does the right
thing, there isn't a security vulnerability. Yes, if an implementer
isn't careful, the code produced may be susceptible to this.
This sounds like an issue with the documentation of the
specification, not the specification of the protocol. (It's possible
that I haven't read all this carefully enough - I apologize.)
>Or maybe all implementers of DNSSEC will have
>read this thread when it was posted.
Over the years I have been infuriated with being told to "go read the
archives" (either directly or indirectly). To me, the mailing list
is like a round-the-table or at-the-blackboard conversation. It
isn't permanent, it's not reviewed, it's a "hack" with respect to
documentation.
(I mean this in the sense that I believe David is being sarcastic
with the lead-in statement.)
I think the right thing to do is spin up an Informational RFC on the
topic of private algorithms, beginning with what is in this thread.
Or perhaps a wider ranging Informational RFC on experiences in
implementing the validator.
I'm sure that we will find a lot of rough edges in experience with
the RFCs-to-be. Remember that these documents are Proposed
Standards, that means that there is probably more work to do before
becoming Full Standards. (Hopefully the work to do is fixing text
and not fixing code.)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"A noble spirit embiggens the smallest man." - Jebediah Springfield
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Thu Dec 23 09:34:44 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11595
for ; Thu, 23 Dec 2004 09:34:44 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1ChTvm-000Gnn-GZ
for namedroppers-data@psg.com; Thu, 23 Dec 2004 14:27:06 +0000
Received: from [193.0.0.199] (helo=postman.ripe.net)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1ChTvh-000GnS-Px
for namedroppers@ops.ietf.org; Thu, 23 Dec 2004 14:27:01 +0000
Received: by postman.ripe.net (Postfix, from userid 8)
id 123982532A; Thu, 23 Dec 2004 15:27:01 +0100 (CET)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96])
by postman.ripe.net (Postfix) with ESMTP
id 0984525319; Thu, 23 Dec 2004 15:26:58 +0100 (CET)
Received: from x50.ripe.net (x50.ripe.net [193.0.1.50])
by birch.ripe.net (8.12.10/8.11.6) with SMTP id iBNEQv8Q008524;
Thu, 23 Dec 2004 15:26:57 +0100
Date: Thu, 23 Dec 2004 15:26:57 +0100
From: "Olaf M. Kolkman"
To: Edward Lewis
Cc: namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
Message-Id: <20041223152657.730a6b6c.olaf@ripe.net>
In-Reply-To:
References: <41C1ED4A.1060606@verisignlabs.com>
<41C9862D.1020408@verisignlabs.com>
<41C994B6.4000802@verisignlabs.com>
Organization: RIPE NCC
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00,BIZ_TLD
X-RIPE-Spam-Status: N 0.017429 / -3.6
X-RIPE-Signature: e00a81547a8ba9b99413656e51dd2b3a
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,BIZ_TLD
autolearn=no version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
On Wed, 22 Dec 2004 21:10:57 -0500
Edward Lewis wrote:
> I think the right thing to do is spin up an Informational RFC on the
> topic of private algorithms, beginning with what is in this thread.
> Or perhaps a wider ranging Informational RFC on experiences in
> implementing the validator.
How about an "implementation note for DNSSEC", I am sure we can come up with other pitfalls?
-- Olaf
---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 28 12:28:30 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11641
for ; Tue, 28 Dec 2004 12:28:30 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CjL2X-000LDF-Kt
for namedroppers-data@psg.com; Tue, 28 Dec 2004 17:21:45 +0000
Received: from [63.208.196.171] (helo=outbound.mailhop.org)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CjL2L-000LBC-OA
for namedroppers@ops.ietf.org; Tue, 28 Dec 2004 17:21:33 +0000
Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com)
by outbound.mailhop.org with esmtpa (Exim 4.42)
id 1CjL2L-000Ix2-4z
for namedroppers@ops.ietf.org; Tue, 28 Dec 2004 12:21:33 -0500
Received: from localhost (aboba@localhost)
by internaut.com (8.10.2/8.10.2) with ESMTP id iBSHLUM24602
for ; Tue, 28 Dec 2004 09:21:31 -0800
Date: Tue, 28 Dec 2004 09:21:30 -0800 (PST)
From: Bernard Aboba
To: namedroppers@ops.ietf.org
Subject: LLMNR Issue 78: UNIQUEness probing
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information)
X-MHO-User: aboba
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Issue 78: UNIQUEness Probing
Submitter: Thomas Narten
Submitter email address: narten@us.ibm.com
Date first submitted: October 8, 2004
Reference:
Document: LLMNR-36
Comment type: T
Priority: S
Section: 4
Rationale/Explanation of issue:
"To verify uniqueness, a responder MUST send an LLMNR query for
each UNIQUE resource record. If no response is received after a
suitable number of attempts (see Section 2.7), the responder can
use the UNIQUE resource record in response to LLMNR queries. If
a response is received, the responder MUST NOT use the UNIQUE
resource record in response to LLMNR queries."
It sounds like two nodes attempting to use the same name at
the same time will end up both deciding that the name is not in
use. Ooops.
Could we:
- use the source address of queries to distinguish between queries
sent out for a "tentative" name vs. a query from someone else?
- could we (if we see other simultaneous queries) say "danger,
conflict may be present", and do some sort of random wait before
trying again, so that two nodes doing the same thing will wait
different times, with one presumably then able to grab the name?
Will this all be too complicated and take too long? I dunno. But the
algorithm as specified now seems like it wil fail with high
probability (e.g, recovery after powerfail scenario).
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Tue Dec 28 12:47:19 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12579
for ; Tue, 28 Dec 2004 12:47:19 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CjLOH-000Pyk-RM
for namedroppers-data@psg.com; Tue, 28 Dec 2004 17:44:13 +0000
Received: from [63.208.196.171] (helo=outbound.mailhop.org)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CjLOD-000Pxc-0I
for namedroppers@ops.ietf.org; Tue, 28 Dec 2004 17:44:09 +0000
Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com)
by outbound.mailhop.org with esmtpa (Exim 4.42)
id 1CjLOB-0006vZ-KD
for namedroppers@ops.ietf.org; Tue, 28 Dec 2004 12:44:07 -0500
Received: from localhost (aboba@localhost)
by internaut.com (8.10.2/8.10.2) with ESMTP id iBSHi6N25929
for ; Tue, 28 Dec 2004 09:44:06 -0800
Date: Tue, 28 Dec 2004 09:44:06 -0800 (PST)
From: Bernard Aboba
To: namedroppers@ops.ietf.org
Subject: Proposed Resolution of LLMNR Issue 78: UNIQUEness probing
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information)
X-MHO-User: aboba
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_50 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
LLMNR Issue 78, raised during the AD review, concerns the reliability of
the LLMNR uniqueness verification mechanism. The LLMNR Issues list is
available at:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
A version of the LLMNR specification with the proposed resolution of Issue
78 included is available at:
http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-38.txt
A discussion of the issue and the proposed resolution follows.
There are two major scenarios in which LLMNR does not detect name
conflicts:
1. When two or more hosts with conflicting names are simultaneously
verifying uniqueness. As currently specified, LLMNR will allow conflicting
hosts to conclude that no conflict exists, since a responder cannot answer
a query until it has verified uniqueness. If two hosts are simultaneously
probing uniqueness, then neither can respond to each other's queries.
2. When a previously partitioned network heals, revealing one or more
name conflicts. As currently specified, LLMNR does not detect these
conflicts since uniqueness verification is not done periodically and
responses are sent via unicast, not multicast.
Several approaches suggest themselves:
a) Have senders include their UNIQUE RRs within all queries.
This would allow another host receiving such a query
to determine if a conflict was present. This not only
addresses scenario 1, but also scenario 2.
b) Add a UNIQUE flag to queries, to distinguish
uniqueness verification probes. While this would
address scenario 1 by allowing hosts to recognize
a conflict during uniqueness verification, it would
not help with Scenario 2.
c) Attempt to utilize the source address to distinguish
uniqueness verification queries. However, since LLMNR
queries can be sent from any address, there is no way
to determine whether a uniqueness verification probe
is being sent, based on the source address.
d) On receipt of a query for a UNIQUE name, have a
sender backoff further queries for a random time period.
The problem with this approach is that uniqueness
verification is done for each UNIQUE RR. In the event that
two or more hosts conflict with respect to multiple RRs,
all conflicts need to be resolved the same way. A simple
random backoff strategy does not achieve this, because
LLMNR-37 Section 4 only says that:
"If a response is received, the responder MUST NOT use the
UNIQUE resource record in response to LLMNR queries."
Therefore a random backoff strategy could result in
conflicting hosts splitting ownership of the UNIQUE RRs,
which is undesirable.
As a result, it appears that approach a) is the most
general one.
The proposed resolution is as follows:
At the end of Section 2.2, add the following text:
"In order to enable conflict detection, senders SHOULD
include UNIQUE RRs within the additional section of LLMNR queries."
In Section 2.3, change:
"[g] If a responder is authoritative for a name, it SHOULD respond with
RCODE=0 and an empty answer section, if the type of query does not
match a RR that the responder has."
To:
"[g] Responders MUST check the additional section of LLMNR queries for
potential name conflicts, as described in Section 4.1 and 4.2, regardless
of whether the responder is authoritative for the name being
queried.
[h] If a responder is authoritative for a name, it SHOULD respond with
RCODE=0 and an empty answer section, if the type of query does not
match a RR that the responder has."
In Section 2.9, change:
" In LLMNR, the additional section is only intended for use by EDNS0,
TSIG and SIG(0). As a result, senders MAY only include pseudo RR-
types in the additional section of a query; responders MUST ignore
the additional section of queries containing other RR types.
Senders MUST NOT cache RRs from the authority or additional section
of a response as answers, though they may be used for other purposes
such as negative caching."
To:
"Senders MUST NOT cache RRs from the authority or additional section
of a response as answers, though they may be used for other purposes
such as negative caching. Responders MUST NOT cache RRs from the
authority or additional section of a query as answers."
Replace Section 4 with the following:
"4. Conflict resolution
The uniqueness of a resource record depends on the nature of the name
in the query and type of the query. For example it is expected that:
- multiple hosts may respond to a query for an SRV type record
- multiple hosts may respond to a query for an A or AAAA type
record for a cluster name (assigned to multiple hosts in
the cluster)
- only a single host may respond to a query for an A or AAAA
type record for a name.
By default, a responder SHOULD be configured to behave as though all
RRs are UNIQUE on each interface on which LLMNR is enabled.
When name conflicts are detected, they SHOULD be logged. To detect
duplicate use of a name, an administrator can use a name resolution
utility which employs LLMNR and lists both responses and responders.
This would allow an administrator to diagnose behavior and
potentially to intervene and reconfigure LLMNR responders who should
not be configured to respond to the same name.
4.1. Uniqueness Verification
Prior to including a UNIQUE resource record in a response, for each
UNIQUE resource record in a given interface's configuration, the host
MUST verify that there is no other host within the scope of LLMNR
query propagation that can return a resource record for the same
name, type and class on that interface. Once a responder has
verified the uniqueness of a UNIQUE resource record, if it receives
an LLMNR query for that resource record, it MUST respond.
Uniqueness verification is carried out when the host:
- starts up or is rebooted
- wakes from sleep (if the network interface was inactive
during sleep)
- is configured to respond to LLMNR queries on an interface
enabled for transmission and reception of IP traffic
- is configured to respond to LLMNR queries using additional
UNIQUE resource records
- verifies the acquisition of a new IP address and configuration
on an interface
To verify uniqueness, a responder MUST send an LLMNR query for each
UNIQUE resource record, placing its own UNIQUE resource record(s) in
the additional section. The responder can use the UNIQUE resource
record in response to LLMNR queries if both of the following
conditions are satisfied:
- No response is received after a suitable number of attempts
(see Section 2.7) AND
- No LLMNR query is received containing a conflicting resource
record within the additional section.
If a response is received, or if an LLMNR query is received
containing a conflicting resource record within the additional
section, the responder MUST NOT use the UNIQUE resource record in
response to LLMNR queries.
Periodically carrying out uniqueness verification in an attempt to
detect name conflicts is not necessary, wastes network bandwidth, and
may actually be detrimental. For example, if network links are joined
only briefly, and are separated again before any new communication is
initiated, temporary conflicts are benign and no forced
reconfiguration is required. Triggering a reconfiguration in this
case would not serve any useful purpose. LLMNR responders SHOULD NOT
periodically attempt uniqueness verification.
4.2. Conflict Detection and Defense
Hosts on disjoint network links may configure the same name for use
with LLMNR. If these separate network links are later joined or
bridged together, then there may be multiple hosts which are now on
the same link, trying to use the same name. These conflicts may not
be detected by the uniqueness verification procedure described in
Section 4.1.
In order to be able to detect conflicts arising from healing of a
network partition, conflict detection is an ongoing process. Since
LLMNR responses are always sent via unicast, only LLMNR queries can
be used to detect name conflicts. When conflicting hosts attempt to
communicate with any other host on the network, they will at some
point multicast an LLMNR query which will enable the conflict to be
detected. Conflict detection requires LLMNR responders to check the
additional section of a query for conflicting resource records, in
addition to examining the query section in order to determine whether
to respond.
Whenever an LLMNR responder receives an LLMNR query with resource
records in the additional section, the responder checks the resource
records against the UNIQUE resource records configured on the
interface on which the query was received. If the resource record is
found to contain the same name as in a UNIQUE resource record of the
same type, but the source IP address within the LLMNR query does not
match an IP address configured on that interface, then this indicates
a conflict.
An LLMNR responder MUST NOT ignore conflicting LLMNR queries. An
LLMNR responder MUST respond to conflicting LLMNR queries as
described in either [a] or [b] below:
[a] Upon detecting a conflict, an LLMNR responder MAY elect to
immediately stop using the conflicting UNIQUE resource record in
response to LLMNR queries.
The responder MAY also elect to configure a new name. However,
since name reconfiguration may be disruptive, this is not required,
and a responder may have been configured to respond to multiple
names so that alternative names may already be available.
[b] If a responder currently has active TCP connections or other
reasons to prefer to keep using the name, and it has not seen any
other conflicting LLMNR queries within the last DEFEND_INTERVAL
seconds, then it MAY elect to defend its name, by recording the
time that the conflicting LLMNR query was received, and then
sending multicast queries for its UNIQUE resource records, with its
UNIQUE resource records included in the additional section.
Having done this, an LLMNR responder can then continue to use the
name normally without any further special action. However, if this
is not the first conflicting LLMNR query the responder has seen,
and the time recorded for the previous conflicting LLMNR query is
recent, within DEFEND_INTERVAL, then the LLMNR responder MUST
immediately cease using the conflicting resource records.
This is necessary to ensure that two hosts do not get stuck in an
endless loop with both hosts trying to defend the same name.
4.3. Considerations for Multiple Interfaces
A multi-homed host may elect to configure LLMNR on only one of its
active interfaces. In many situations this will be adequate.
However, should a host need to configure LLMNR on more than one of
its active interfaces, there are some additional precautions it MUST
take. Implementers who are not planning to support LLMNR on multiple
interfaces simultaneously may skip this section.
Where a host is configured to issue LLMNR queries on more than one
interface, each interface maintains its own independent LLMNR
resolver cache, containing the responses to LLMNR queries.
A multi-homed host checks the uniqueness of UNIQUE records as
described in Sections 4.1 and 4.2. The situation is illustrated in
figure 1.
---------- ----------
| | | |
[A] [myhost] [myhost]
Figure 1. Link-scope name conflict
In this situation, the multi-homed myhost will probe for, and defend,
its host name on both interfaces. A conflict will be detected on one
interface, but not the other. The multi-homed myhost will not be
able to respond with a host RR for "myhost" on the interface on the
right (see Figure 1). The multi-homed host may, however, be
configured to use the "myhost" name on the interface on the left.
Since names are only unique per-link, hosts on different links could
be using the same name. If an LLMNR client sends requests over
multiple interfaces, and receives replies from more than one, the
result returned to the client is defined by the implementation. The
situation is illustrated in figure 2.
---------- ----------
| | | |
[A] [myhost] [A]
Figure 2. Off-segment name conflict
If host myhost is configured to use LLMNR on both interfaces, it will
send LLMNR queries on both interfaces. When host myhost sends a
query for the host RR for name "A" it will receive a response from
hosts on both interfaces.
Host myhost cannot distinguish between the situation shown in Figure
2, and that shown in Figure 3 where no conflict exists.
[A]
| |
----- -----
| |
[myhost]
Figure 3. Multiple paths to same host
This illustrates that the proposed name conflict resolution mechanism
does not support detection or resolution of conflicts between hosts
on different links. This problem can also occur with unicast DNS
when a multi-homed host is connected to two different networks with
separated name spaces. It is not the intent of this document to
address the issue of uniqueness of names within DNS.
4.4. API issues
[RFC2553] provides an API which can partially solve the name
ambiguity problem for applications written to use this API, since the
sockaddr_in6 structure exposes the scope within which each scoped
address exists, and this structure can be used for both IPv4 (using
v4-mapped IPv6 addresses) and IPv6 addresses.
Following the example in Figure 2, an application on 'myhost' issues
the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
interfaces and the resolver library will return a list containing
multiple addrinfo structures, each with an associated sockaddr_in6
structure. This list will thus contain the IPv4 and IPv6 addresses
of both hosts responding to the name 'A'. Link-local addresses will
have a sin6_scope_id value that disambiguates which interface is used
to reach the address. Of course, to the application, Figures 2 and 3
are still indistinguishable, but this API allows the application to
communicate successfully with any address in the list."
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Wed Dec 29 15:43:29 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09557
for ; Wed, 29 Dec 2004 15:43:29 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CjkZ1-0002W7-O0
for namedroppers-data@psg.com; Wed, 29 Dec 2004 20:36:59 +0000
Received: from [132.151.1.176] (helo=ietf.org)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CjkYx-0002V8-9O
for namedroppers@ops.ietf.org; Wed, 29 Dec 2004 20:36:55 +0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08982;
Wed, 29 Dec 2004 15:36:52 -0500 (EST)
Message-Id: <200412292036.PAA08982@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: namedroppers@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnsext-ecc-key-06.txt
Date: Wed, 29 Dec 2004 15:36:52 -0500
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART,
NO_REAL_NAME autolearn=no version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.
Title : Elliptic Curve KEYs in the DNS
Author(s) : R. Schroeppel, D. Eastlake
Filename : draft-ietf-dnsext-ecc-key-06.txt
Pages : 16
Date : 2004-12-29
The standard method for storing elliptic curve cryptographic keys and
signatures in the Domain Name System is specified.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-06.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dnsext-ecc-key-06.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-dnsext-ecc-key-06.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <2004-12-29153947.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-ecc-key-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsext-ecc-key-06.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2004-12-29153947.I-D@ietf.org>
--OtherAccess--
--NextPart--
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Thu Dec 30 22:40:51 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11679
for ; Thu, 30 Dec 2004 22:40:50 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CkDZ3-000F1I-5C
for namedroppers-data@psg.com; Fri, 31 Dec 2004 03:34:57 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CkDYx-000EzZ-WD
for namedroppers@ops.ietf.org; Fri, 31 Dec 2004 03:34:52 +0000
Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id iBV3YeVe036492
for ; Thu, 30 Dec 2004 22:34:42 -0500 (EST)
(envelope-from ogud@ogud.com)
Message-Id: <6.2.0.14.2.20041219214201.044d6160@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Thu, 30 Dec 2004 22:31:52 -0500
To: namedroppers@ops.ietf.org
From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair
Subject: Dnssec-editors mailing list to close
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_20 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
I have been notified that this mailing list will be turned off around
2004/12/31. As the current work of the DNSSEC editors is largely
complete, we will close the mailing list at that time.
Any issues with the DNSSEC-bis documents should be send to namedroppers
from now on.
Thanks to ISI for hosting the list for us, a new home for the mailing list
archive will be announced soon.
Olafur
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Fri Dec 31 01:23:54 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20271
for ; Fri, 31 Dec 2004 01:23:54 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CkG7K-0005Md-1s
for namedroppers-data@psg.com; Fri, 31 Dec 2004 06:18:30 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CkG7E-0005MI-PH
for namedroppers@ops.ietf.org; Fri, 31 Dec 2004 06:18:25 +0000
Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id iBV6IBij037193;
Fri, 31 Dec 2004 01:18:12 -0500 (EST)
(envelope-from ogud@ogud.com)
Message-Id: <6.2.0.14.2.20041231010157.044d9ba8@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Fri, 31 Dec 2004 01:16:38 -0500
To: "Scott Rose" ,
From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?=
Subject: RE: private algorithms and the DS record
In-Reply-To:
References: <41C85D0E.40002@verisignlabs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At 12:56 21/12/2004, Scott Rose wrote:
> > -----Original Message-----
> > From: owner-namedroppers@ops.ietf.org
> > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of David Blacka
> >
> > Let's approach this issue from the opposite direction. Is there any
> > reason NOT to prepend the private alg. name to the DS hash? Was the
> > fact that the DS wasn't mentioned in the private algorithm appendix ON
> > PURPOSE?
> >
> > I am personally of the opinion that the fact that the DS was omitted was
> > just an oversight, due to the fact that no one really examined private
> > algorithms during the main review process. I am of the opinion that NOT
> > fixing this means, at the very minimum, that private algorithm support
> > will be harder than necessary to implement in the validator. It *may*
> > mean that private algorithms are unusable or at least unsafe.
> >
>
>It was an oversight. Private algorithms were not really brought up enough
>during the rewrite process.
>
>Scott
But this was discussed in the design process of DS and the feeling
was that Private algorithms where second class citizens
that only role is in testing of new algorithms or some strange
convoluted reasons. Thus there was no need to add complexity to
support them.
Going further back, I remember questioning the text in RFC2065
that included the private algorithm identifiers in SIG RR's and
arguing that key ID was sufficient for selecting the correct key
to test.
If we are going to make any changes I would argue for changing RRSIG
not DS :-).
Olafur
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Fri Dec 31 01:27:56 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20509
for ; Fri, 31 Dec 2004 01:27:56 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CkGEY-0005w8-La
for namedroppers-data@psg.com; Fri, 31 Dec 2004 06:25:58 +0000
Received: from [66.92.146.160] (helo=ogud.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CkGEU-0005vb-9c
for namedroppers@ops.ietf.org; Fri, 31 Dec 2004 06:25:54 +0000
Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160])
by ogud.com (8.12.11/8.12.11) with ESMTP id iBV6PePY037238;
Fri, 31 Dec 2004 01:25:41 -0500 (EST)
(envelope-from ogud@ogud.com)
Message-Id: <6.2.0.14.2.20041231011944.04660258@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Fri, 31 Dec 2004 01:25:43 -0500
To: David Blacka , Rob Austein
From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?=
Subject: Re: private algorithms and the DS record
Cc: namedroppers@ops.ietf.org
In-Reply-To: <41C9AB3A.3050209@verisignlabs.com>
References: <41C1ED4A.1060606@verisignlabs.com>
<9347523AF3E1691C9687BE7D@192.168.100.25>
<41C85D0E.40002@verisignlabs.com>
<41C89341.3040501@verisignlabs.com>
<20041222050148.4613741C8@thrintun.hactrn.net>
<41C9AB3A.3050209@verisignlabs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At 12:13 22/12/2004, David Blacka
>Rob Austein wrote:
>
>I see four possible resolutions here:
>
>1) DS records are modified to contain the private algorithm name, allowing
>the validator algorithm to work the same for public and private algorithms, or
>2) The need and algorithm for fetching the private algorithm name from the
>DNSKEY in a safe manner is documented somewhere (another RFC or additional
>text), or
>3) private algorithms are deprecated, or
>4) everyone else decides that the current text is clear enough, there is
>no need to change anything, we are fairly sure that future implementations
>of private algorithm support will work just fine, thank you very much.
>
>Any of the above resolutions are acceptable, I think.
I see #5
5) Remove special handling of Private Key's in RRSIG, i.e. do the same
thing as in DS and cementing Private algorithm's second class status.
Personally I think 2 is the most appropriate approach if this is
big enough a issue to warrant the attention of the working group.
Olafur
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:
From owner-namedroppers@ops.ietf.org Fri Dec 31 11:49:02 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10625
for ; Fri, 31 Dec 2004 11:49:01 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD))
id 1CkPu3-000B1e-7j
for namedroppers-data@psg.com; Fri, 31 Dec 2004 16:45:27 +0000
Received: from [204.152.187.1] (helo=sa.vix.com)
by psg.com with esmtp (Exim 4.43 (FreeBSD))
id 1CkPty-000B1D-8w
for namedroppers@ops.ietf.org; Fri, 31 Dec 2004 16:45:22 +0000
Received: from sa.vix.com (localhost [127.0.0.1])
by sa.vix.com (Postfix) with ESMTP id CFF9913971
for ; Fri, 31 Dec 2004 16:45:21 +0000 (GMT)
(envelope-from vixie@sa.vix.com)
From: Paul Vixie
To: namedroppers@ops.ietf.org
Subject: Re: private algorithms and the DS record
In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?=