From owner-namedroppers@ops.ietf.org Tue Jan 1 11:07:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13357 for ; Tue, 1 Jan 2002 11:07:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16LR3J-000PK4-00 for namedroppers-data@psg.com; Tue, 01 Jan 2002 07:42:09 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16LR3I-000PJy-00 for namedroppers@ops.ietf.org; Tue, 01 Jan 2002 07:42:08 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16LR3I-000GEm-00 for namedroppers@ops.ietf.org; Tue, 01 Jan 2002 07:42:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: To: namedroppers@ops.ietf.org Subject: list policy From: Randy Bush Date: Tue, 01 Jan 2002 03:00:01 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). there is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 2 09:53:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05014 for ; Wed, 2 Jan 2002 09:53:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16LmSI-000Gqe-00 for namedroppers-data@psg.com; Wed, 02 Jan 2002 06:33:22 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16LmSI-000GqX-00 for namedroppers@ops.ietf.org; Wed, 02 Jan 2002 06:33:22 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16LmSI-000E2O-00 for namedroppers@ops.ietf.org; Wed, 02 Jan 2002 06:33:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: Date: Wed, 2 Jan 2002 15:13:34 +0100 (MET) From: Erik Guttman To: Bernard Aboba cc: Erik Guttman , Levon Esibov , cheshire@apple.com, Dave Thaler , sra@hactrn.net, namedroppers@ops.ietf.org Subject: Re: mdns-08 draft Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 21 Dec 2001, Bernard Aboba wrote: > > > How about this? > > > > > > "A host configured to not be a responder SHOULD NOT be a "sender". While > > s/SHOULD NOT/SHOULD > > What are we trying to say here? That senders SHOULD be responders > too? Or that a sender MAY NOT be a responder? The double negative confused me. How about 'Senders SHOULD be Responders, too.' Even this is a bit preachy, IMO. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 3 00:15:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17793 for ; Thu, 3 Jan 2002 00:15:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Lzzd-0005Km-00 for namedroppers-data@psg.com; Wed, 02 Jan 2002 21:00:41 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Lzzc-0005Kg-00 for namedroppers@ops.ietf.org; Wed, 02 Jan 2002 21:00:40 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Lzzc-000Bpu-00 for namedroppers@ops.ietf.org; Wed, 02 Jan 2002 21:00:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20020102224702.024262b0@localhost> Date: Wed, 02 Jan 2002 23:55:00 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?==?iso-8859-1?Q?_Gu=F0mundsson?= Subject: DS design questions Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm trying to get a new version of the draft out the door. The changes agreed to so far bring up few questions that I would like some input on before selecting one the possible. 1. Should the DS record have a digest identifier ? Right now SHA-1 is the only one specified, x years down the road we may need a stronger one. There are two ways to handle this, use digest identifier byte in the record Use the size of the DS record to signal the algorithm used. The second one is compatible with the current specified format of the record, the first one is more explicit. Q 2. NODS bit needed in NXT ? Current draft uses this bit to allow resolvers to detect quickly if a zone is a secure RFC 2535 or insecure DS, new version will outlaw RFC 2535 NULL key reducing the usefulness of this bit. I think this bit is useful in the near term for debugging and testing. From resolver perspective this is nice to have not a show stopper. We waste a type code on this bit from the precious 1-126 range (1/3 of the type space has been used so far). Q 2.5 IF answer to 2 is yes, should the document recommend the use new type code > 42 for NODS or reuse one of the reserved type codes that has never been properly used/documented such as: SINK, EID, NIMLOC, ATMA. Q 3. DS or NXT second RR set in authority section ? It has been strongly suggested that referral answers have DS and NXT added to the authority section, this is motivated by the facts: that it is sometimes hard to reach the correct servers this WILL save lookups. The cost is larger answers and possibly less or no glue in some referrals. I personally think that DS is more important thus it should be the second RR set in the authority section and NXT the third. NXT is more important to resolvers in the negative case and could be suppressed when there is DS, but that is one more special case in servers. 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. From owner-namedroppers@ops.ietf.org Thu Jan 3 08:20:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00577 for ; Thu, 3 Jan 2002 08:20:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16M7S9-000DuK-00 for namedroppers-data@psg.com; Thu, 03 Jan 2002 04:58:37 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16M7S9-000DuE-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 04:58:37 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16M7S8-000Pfw-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 04:58:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?==?iso-8859-1?Q?_Gu=F0mundsson?= of "Wed, 02 Jan 2002 23:55:00 EST." <5.1.0.14.2.20020102224702.024262b0@localhost> Message-Id: <20020103072503.3D5DA28EEE@as.vix.com> From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DS design questions Date: Wed, 02 Jan 2002 23:25:03 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 1. Should the DS record have a digest identifier ? > Right now SHA-1 is the only one specified, x years down the road > we may need a stronger one. There are two ways to handle this, > use digest identifier byte in the record > Use the size of the DS record to signal the algorithm used. > > The second one is compatible with the current specified format of the > record, the first one is more explicit. the second one opens the possibility that we will someday add a pad byte somewhere just to have a distinguishing length. that way lies madness. i strongly recommend the use of an alg-id. > Q 2. NODS bit needed in NXT ? > Current draft uses this bit to allow resolvers to detect quickly if a > zone is a secure RFC 2535 or insecure DS, new version will outlaw RFC 2535 > NULL key reducing the usefulness of this bit. > I think this bit is useful in the near term for debugging and testing. > From resolver perspective this is nice to have not a show stopper. > We waste a type code on this bit from the precious 1-126 range > (1/3 of the type space has been used so far). if processing it and understanding it becomes optional after the near-term uses you envision, then put in the crutch. but if it will add code paths to implementations which won't be written until my three-year-old is in college then by all means leave it out and deal with the near-term inconvenience. > Q 3. DS or NXT second RR set in authority section ? > It has been strongly suggested that referral answers have DS and NXT > added to the authority section, this is motivated by the facts: > that it is sometimes hard to reach the correct servers > this WILL save lookups. > > The cost is larger answers and possibly less or no glue in some referrals. > I personally think that DS is more important thus it should be the > second RR set in the authority section and NXT the third. > NXT is more important to resolvers in the negative case and could be > suppressed when there is DS, but that is one more special case in servers. size constraints basically just do not matter. DNSSEC is not deployable without EDNS, with or without DS RRs in the authority section. thinwire clients (i'm thinking wireless PDA's here) are likely to use IPSec toward a fatpiped proxy for more than just DNSSEC-related reasons. i'd say put in the thing that will limit the number of transactions on the wire rather than the size of the response, since round trip delay is a physical property and seems unlikely to improve beyond speed-of-light in the near term. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 3 08:21:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00600 for ; Thu, 3 Jan 2002 08:21:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16M7bV-000E3T-00 for namedroppers-data@psg.com; Thu, 03 Jan 2002 05:08:17 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16M7bV-000E3N-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 05:08:17 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16M7bV-000PvH-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 05:08:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20020103095614.6e2bbf81.olaf@ripe.net> In-Reply-To: <5.1.0.14.2.20020102224702.024262b0@localhost> References: <5.1.0.14.2.20020102224702.024262b0@localhost> Date: Thu, 3 Jan 2002 09:56:14 +0100 From: "Olaf M. Kolkman" To: Ólafur Guðmundsson Cc: namedroppers@ops.ietf.org Subject: Re: DS design questions Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Wed, 02 Jan 2002 23:55:00 -0500 Ólafur Guðmundsson wrote: > The second one is compatible with the current specified format of the > record, the first one is more explicit. I enjoy aesthetics so the second option is preferred. > Q 2. NODS bit needed in NXT ? > Current draft uses this bit to allow resolvers to detect quickly if a > zone is a secure RFC 2535 or insecure DS, new version will outlaw RFC 2535 > NULL key reducing the usefulness of this bit. > I think this bit is useful in the near term for debugging and testing. > From resolver perspective this is nice to have not a show stopper. > We waste a type code on this bit from the precious 1-126 range > (1/3 of the type space has been used so far). Q2.5beta Can we put a flag-date on the use of this bit? i.e. as soon as RFC2535 is obsolete the bit is obsolete. > > Q 2.5 IF answer to 2 is yes, should the document recommend the use new > type code > 42 for NODS or reuse one of the reserved type codes that > has never been properly used/documented such as: SINK, EID, NIMLOC, ATMA. > > Q 3. DS or NXT second RR set in authority section ? > It has been strongly suggested that referral answers have DS and NXT > added to the authority section, this is motivated by the facts: > that it is sometimes hard to reach the correct servers > this WILL save lookups. > > The cost is larger answers and possibly less or no glue in some referrals. > I personally think that DS is more important thus it should be the > second RR set in the authority section and NXT the third. > NXT is more important to resolvers in the negative case and could be > suppressed when there is DS, but that is one more special case in servers. I think that is a good argument but I am agnostic about this point. --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. From owner-namedroppers@ops.ietf.org Thu Jan 3 08:44:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01070 for ; Thu, 3 Jan 2002 08:44:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16M7tG-000ENc-00 for namedroppers-data@psg.com; Thu, 03 Jan 2002 05:26:38 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16M7tG-000ENV-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 05:26:38 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16M7tG-0000QB-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 05:26:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020103142432.6446bfa2.olaf@ripe.net> In-Reply-To: <20020103095614.6e2bbf81.olaf@ripe.net> References: <5.1.0.14.2.20020102224702.024262b0@localhost> <20020103095614.6e2bbf81.olaf@ripe.net> Date: Thu, 3 Jan 2002 14:24:32 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: DS design questions Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 3 Jan 2002 09:56:14 +0100 "Olaf M. Kolkman" wrote: > > I enjoy aesthetics so the second option is preferred. oops, that should have read first option... --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. From owner-namedroppers@ops.ietf.org Thu Jan 3 09:14:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01759 for ; Thu, 3 Jan 2002 09:14:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16M8Og-000Eva-00 for namedroppers-data@psg.com; Thu, 03 Jan 2002 05:59:06 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16M8Og-000EvU-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 05:59:06 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16M8Og-0001J0-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 05:59:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <5.1.0.14.2.20020102224702.024262b0@localhost> <20020103072503.3D5DA28EEE@as.vix.com> Message-Id: From: Randy Bush To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: DS design questions Date: Thu, 03 Jan 2002 05:58:35 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> 1. Should the DS record have a digest identifier ? >> Right now SHA-1 is the only one specified, x years down the road >> we may need a stronger one. There are two ways to handle this, >> use digest identifier byte in the record >> Use the size of the DS record to signal the algorithm used. >> The second one is compatible with the current specified format of the >> record, the first one is more explicit. > the second one opens the possibility that we will someday add a pad byte > somewhere just to have a distinguishing length. that way lies madness. > i strongly recommend the use of an alg-id. what paul said randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 3 11:28:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05465 for ; Thu, 3 Jan 2002 11:28:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MAQ8-000Gf9-00 for namedroppers-data@psg.com; Thu, 03 Jan 2002 08:08:44 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16MAQ7-000Gf3-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 08:08:43 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MAQ7-0006eQ-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 08:08:43 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698E1@vhqpostal.verisign.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1946F.5D045410" From: "Hallam-Baker, Phillip" To: "'Randy Bush'" , Paul Vixie Cc: namedroppers@ops.ietf.org Subject: RE: DS design questions Date: Thu, 3 Jan 2002 07:57:36 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1946F.5D045410 Content-Type: text/plain; charset="iso-8859-1" Support for multiple algorithms is somewhat tricky. In particular it is important to avoid a downgrade attack. There is no value in supporting the use of a strong cipher and a weak one if the attacker can convince the relying party that the weaker one was selected. I would need to see a fuller description to be able to fully asses the merits of the proposed mod. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Thursday, January 03, 2002 8:59 AM > To: Paul Vixie > Cc: namedroppers@ops.ietf.org > Subject: Re: DS design questions > > > >> 1. Should the DS record have a digest identifier ? > >> Right now SHA-1 is the only one specified, x years down the road > >> we may need a stronger one. There are two ways to handle this, > >> use digest identifier byte in the record > >> Use the size of the DS record to signal the algorithm used. > >> The second one is compatible with the current specified > format of the > >> record, the first one is more explicit. > > the second one opens the possibility that we will someday > add a pad byte > > somewhere just to have a distinguishing length. that way > lies madness. > > i strongly recommend the use of an alg-id. > > what paul said > > randy > > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > ------_=_NextPart_000_01C1946F.5D045410 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1946F.5D045410-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 3 14:29:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08893 for ; Thu, 3 Jan 2002 14:29:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MDIF-000KIC-00 for namedroppers-data@psg.com; Thu, 03 Jan 2002 11:12:47 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16MDIE-000KI4-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 11:12:46 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MDIE-000FpY-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 11:12:46 -0800 In-Reply-To: <20020103072503.3D5DA28EEE@as.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 3 Jan 2002 11:09:50 -0800 (PST) From: Brian Wellington To: Subject: Re: DS design questions Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 2 Jan 2002, Paul Vixie wrote: > > 1. Should the DS record have a digest identifier ? > > Right now SHA-1 is the only one specified, x years down the road > > we may need a stronger one. There are two ways to handle this, > > use digest identifier byte in the record > > Use the size of the DS record to signal the algorithm used. > > > > The second one is compatible with the current specified format of the > > record, the first one is more explicit. > > the second one opens the possibility that we will someday add a pad byte > somewhere just to have a distinguishing length. that way lies madness. > i strongly recommend the use of an alg-id. I strongly agree. > > Q 2. NODS bit needed in NXT ? > > Current draft uses this bit to allow resolvers to detect quickly if a > > zone is a secure RFC 2535 or insecure DS, new version will outlaw RFC 2535 > > NULL key reducing the usefulness of this bit. > > I think this bit is useful in the near term for debugging and testing. > > From resolver perspective this is nice to have not a show stopper. > > We waste a type code on this bit from the precious 1-126 range > > (1/3 of the type space has been used so far). > > if processing it and understanding it becomes optional after the near-term > uses you envision, then put in the crutch. but if it will add code paths to > implementations which won't be written until my three-year-old is in college > then by all means leave it out and deal with the near-term inconvenience. If RFC 2535 NULL KEYs are outlawed (and no implementation will need to support both NULL KEYs and DS), I don't think the bit is needed. As for complexity, I don't think it matters too much. If an RFC2535-style response is misinterpreted as a DS response (because there is no NODS bit), it will still fail to verify because there will be no NXT record in the authority section showing the lack of DS. > > Q 3. DS or NXT second RR set in authority section ? > > It has been strongly suggested that referral answers have DS and NXT > > added to the authority section, this is motivated by the facts: > > that it is sometimes hard to reach the correct servers > > this WILL save lookups. > > > > The cost is larger answers and possibly less or no glue in some referrals. > > I personally think that DS is more important thus it should be the > > second RR set in the authority section and NXT the third. > > NXT is more important to resolvers in the negative case and could be > > suppressed when there is DS, but that is one more special case in servers. > > size constraints basically just do not matter. DNSSEC is not deployable > without EDNS, with or without DS RRs in the authority section. thinwire > clients (i'm thinking wireless PDA's here) are likely to use IPSec toward > a fatpiped proxy for more than just DNSSEC-related reasons. i'd say put > in the thing that will limit the number of transactions on the wire rather > than the size of the response, since round trip delay is a physical property > and seems unlikely to improve beyond speed-of-light in the near term. I think putting these in the authority section is crucial if there is supposed to be an implementation in the near future. A lot of extra cost in the resolver for dealing with state can be removed if the DS/NXT records are guaranteed to be in the response packet, as they will be if they're in the authority section. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 3 15:32:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10620 for ; Thu, 3 Jan 2002 15:32:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MEN8-000LwG-00 for namedroppers-data@psg.com; Thu, 03 Jan 2002 12:21:54 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16MEN8-000LwA-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 12:21:54 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MEN8-000JIe-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 12:21:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3C34B686.A79956E4@isi.edu> References: Date: Thu, 03 Jan 2002 14:52:38 -0500 From: Daniel Massey To: Brian Wellington CC: namedroppers@ops.ietf.org Subject: Re: DS design questions Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian Wellington wrote: > > On Wed, 2 Jan 2002, Paul Vixie wrote: > > > > 1. Should the DS record have a digest identifier ? > > > Right now SHA-1 is the only one specified, x years down the road > > > we may need a stronger one. There are two ways to handle this, > > > use digest identifier byte in the record > > > Use the size of the DS record to signal the algorithm used. > > > > > > The second one is compatible with the current specified format of the > > > record, the first one is more explicit. > > > > the second one opens the possibility that we will someday add a pad byte > > somewhere just to have a distinguishing length. that way lies madness. > > i strongly recommend the use of an alg-id. > > I strongly agree. > Add one more strongly agree. > > > Q 2. NODS bit needed in NXT ? > > > Current draft uses this bit to allow resolvers to detect quickly if a > > > zone is a secure RFC 2535 or insecure DS, new version will outlaw RFC 2535 > > > NULL key reducing the usefulness of this bit. > > > I think this bit is useful in the near term for debugging and testing. > > > From resolver perspective this is nice to have not a show stopper. > > > We waste a type code on this bit from the precious 1-126 range > > > (1/3 of the type space has been used so far). > > > > if processing it and understanding it becomes optional after the near-term > > uses you envision, then put in the crutch. but if it will add code paths to > > implementations which won't be written until my three-year-old is in college > > then by all means leave it out and deal with the near-term inconvenience. > > If RFC 2535 NULL KEYs are outlawed (and no implementation will need to > support both NULL KEYs and DS), I don't think the bit is needed. > I thought the NODS bit was good at first, but on second thought I also think it should not have a NODS bit. The bit doesn't gain anything once NULL keys are gone (at least as far as I can tell, please correct me if that is wrong) >From the perspective of someone looking at a new spec, NODS would just be an extra bit that needs to be set but has no meaning. It seems to me like the best thing to do is to make a clean break and eliminate the NODS bit. Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 3 17:00:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12260 for ; Thu, 3 Jan 2002 17:00:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MFcQ-000Nmg-00 for namedroppers-data@psg.com; Thu, 03 Jan 2002 13:41:46 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16MFcQ-000Nma-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 13:41:46 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MFcQ-000NGc-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 13:41:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <01c401c1949c$9d7b5840$b9370681@antd.nist.gov> References: <3C34B686.A79956E4@isi.edu> From: "Scott Rose" To: Subject: Re: DS design questions Date: Thu, 3 Jan 2002 16:21:31 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If we are going to have a flag day for DNSSEC rollout with DS, then we should eliminate the NODS bit in the NXT record. "Vanilla" RFC2535 signed zones would not be deemed "true DNSSEC secured" anyway. But consider the alternative: zone 'SUB.A' is signed RFC2535 and has a SIG(KEY) record from the parent in it's zone. What would happen when a DS-aware resolver gets the delegation from 'A', it will see that no DS RR is present (in the NXT record bitmap)? The resolver contacts 'SUB.A" it gets the KEY and SIG record for the KEY signed by the parent (zone A). Should a resolver be assumed to have enough intelligence to start the validation process the old RFC2535 way (or more difficult - a mix of DS/RFC2535 chaining)? Scott ----- Original Message ----- From: "Daniel Massey" To: "Brian Wellington" Cc: Sent: Thursday, January 03, 2002 2:52 PM Subject: Re: DS design questions > > > > Q 2. NODS bit needed in NXT ? > > > > Current draft uses this bit to allow resolvers to detect quickly if a > > > > zone is a secure RFC 2535 or insecure DS, new version will outlaw RFC 2535 > > > > NULL key reducing the usefulness of this bit. > > > > I think this bit is useful in the near term for debugging and testing. > > > > From resolver perspective this is nice to have not a show stopper. > > > > We waste a type code on this bit from the precious 1-126 range > > > > (1/3 of the type space has been used so far). > > > > > > if processing it and understanding it becomes optional after the near-term > > > uses you envision, then put in the crutch. but if it will add code paths to > > > implementations which won't be written until my three-year-old is in college > > > then by all means leave it out and deal with the near-term inconvenience. > > > > If RFC 2535 NULL KEYs are outlawed (and no implementation will need to > > support both NULL KEYs and DS), I don't think the bit is needed. > > > > I thought the NODS bit was good at first, but on second thought I also > think it should not have a NODS bit. > > The bit doesn't gain anything once NULL keys are gone (at least > as far as I can tell, please correct me if that is wrong) > >From the perspective of someone looking at a new spec, NODS would > just be an extra bit that needs to be set but has no meaning. > It seems to me like the best thing to do is to make a clean break > and eliminate the NODS bit. > > Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 3 20:23:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14671 for ; Thu, 3 Jan 2002 20:23:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MIq0-0002VT-00 for namedroppers-data@psg.com; Thu, 03 Jan 2002 17:08:00 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16MIq0-0002VN-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 17:08:00 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MIq0-0007OT-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 17:08:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <20020103072503.3D5DA28EEE@as.vix.com> Message-ID: Date: Thu, 3 Jan 2002 11:09:50 -0800 (PST) From: Brian Wellington To: Subject: Re: DS design questions Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2 Jan 2002, Paul Vixie wrote: > > 1. Should the DS record have a digest identifier ? > > Right now SHA-1 is the only one specified, x years down the road > > we may need a stronger one. There are two ways to handle this, > > use digest identifier byte in the record > > Use the size of the DS record to signal the algorithm used. > > > > The second one is compatible with the current specified format of the > > record, the first one is more explicit. > > the second one opens the possibility that we will someday add a pad byte > somewhere just to have a distinguishing length. that way lies madness. > i strongly recommend the use of an alg-id. I strongly agree. > > Q 2. NODS bit needed in NXT ? > > Current draft uses this bit to allow resolvers to detect quickly if a > > zone is a secure RFC 2535 or insecure DS, new version will outlaw RFC 2535 > > NULL key reducing the usefulness of this bit. > > I think this bit is useful in the near term for debugging and testing. > > From resolver perspective this is nice to have not a show stopper. > > We waste a type code on this bit from the precious 1-126 range > > (1/3 of the type space has been used so far). > > if processing it and understanding it becomes optional after the near-term > uses you envision, then put in the crutch. but if it will add code paths to > implementations which won't be written until my three-year-old is in college > then by all means leave it out and deal with the near-term inconvenience. If RFC 2535 NULL KEYs are outlawed (and no implementation will need to support both NULL KEYs and DS), I don't think the bit is needed. As for complexity, I don't think it matters too much. If an RFC2535-style response is misinterpreted as a DS response (because there is no NODS bit), it will still fail to verify because there will be no NXT record in the authority section showing the lack of DS. > > Q 3. DS or NXT second RR set in authority section ? > > It has been strongly suggested that referral answers have DS and NXT > > added to the authority section, this is motivated by the facts: > > that it is sometimes hard to reach the correct servers > > this WILL save lookups. > > > > The cost is larger answers and possibly less or no glue in some referrals. > > I personally think that DS is more important thus it should be the > > second RR set in the authority section and NXT the third. > > NXT is more important to resolvers in the negative case and could be > > suppressed when there is DS, but that is one more special case in servers. > > size constraints basically just do not matter. DNSSEC is not deployable > without EDNS, with or without DS RRs in the authority section. thinwire > clients (i'm thinking wireless PDA's here) are likely to use IPSec toward > a fatpiped proxy for more than just DNSSEC-related reasons. i'd say put > in the thing that will limit the number of transactions on the wire rather > than the size of the response, since round trip delay is a physical property > and seems unlikely to improve beyond speed-of-light in the near term. I think putting these in the authority section is crucial if there is supposed to be an implementation in the near future. A lot of extra cost in the resolver for dealing with state can be removed if the DS/NXT records are guaranteed to be in the response packet, as they will be if they're in the authority section. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 4 00:56:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20022 for ; Fri, 4 Jan 2002 00:56:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MN2z-0008Bq-00 for namedroppers-data@psg.com; Thu, 03 Jan 2002 21:37:41 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16MN2z-0008Bj-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 21:37:41 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MN2z-000KlR-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 21:37:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <01c401c1949c$9d7b5840$b9370681@antd.nist.gov> Message-ID: Date: Thu, 3 Jan 2002 21:01:55 -0800 (PST) From: Brian Wellington To: Scott Rose cc: Subject: Re: DS design questions Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 3 Jan 2002, Scott Rose wrote: > If we are going to have a flag day for DNSSEC rollout with DS, then we > should eliminate the NODS bit in the NXT record. "Vanilla" RFC2535 signed > zones would not be deemed "true DNSSEC secured" anyway. But consider the > alternative: > > zone 'SUB.A' is signed RFC2535 and has a SIG(KEY) record from the parent in > it's zone. > What would happen when a DS-aware resolver gets the delegation from 'A', it > will see that no DS RR is present (in the NXT record bitmap)? The resolver > contacts 'SUB.A" it gets the KEY and SIG record for the KEY signed by the > parent (zone A). Should a resolver be assumed to have enough intelligence > to start the validation process the old RFC2535 way (or more difficult - a > mix of DS/RFC2535 chaining)? I don't understand this. If RFC 2535 signed zones are deprecated and not considered secure, why would a resolver need to start the validation process in the old way? Shouldn't the lack of DS or provably absent DS be enough to make the validation attempt fail? Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 4 01:17:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20146 for ; Fri, 4 Jan 2002 01:17:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MNTJ-0008me-00 for namedroppers-data@psg.com; Thu, 03 Jan 2002 22:04:53 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16MNTI-0008mY-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 22:04:52 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MNTI-000M65-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 22:04:52 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20020104035226.337B97B7B@berkshire.research.att.com> From: "Steven M. Bellovin" To: bert hubert Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: DS and Opt-in - a proposal Date: Thu, 03 Jan 2002 22:52:26 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In message <20011228075044.B22180@outpost.ds9a.nl>, bert hubert writes: >On Thu, Dec 27, 2001 at 10:14:46AM +0100, Olaf M. Kolkman wrote: > >> deployment limited to only the largest (g|c)TLDs. I understood >> 'delegation only' was considdered for a new version of the draft.) >> >> --Olaf >> >> P.S. I love the idea to have DNSSEC in a workable state by summer. > >I seem to keep hammering this point - have clientside people been involved >yet? The vast majority of DNS lookups right now are A queries, and most of >those come from the browser. Talk to the IPsec vendors -- general IPsec, beyond VPNs, isn't secure without DNSSEC. I'm referring particularly to the opportunistic encryption folks, i.e., draft-richardson-ipsec-opportunistic-03.txt --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 4 01:17:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20157 for ; Fri, 4 Jan 2002 01:17:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MNT6-0008lY-00 for namedroppers-data@psg.com; Thu, 03 Jan 2002 22:04:40 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16MNT5-0008lS-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 22:04:39 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MNT5-000M5M-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 22:04:39 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20020104035713.B12FB7B7C@berkshire.research.att.com> From: "Steven M. Bellovin" To: =?iso-8859-1?Q?=D3lafur?==?iso-8859-1?Q?_Gu=F0mundsson?= Cc: namedroppers@ops.ietf.org Subject: Re: DS design questions Date: Thu, 03 Jan 2002 22:57:13 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In message <5.1.0.14.2.20020102224702.024262b0@localhost>, =?iso-8859-1?Q?=D3la fur?==?iso-8859-1?Q?_Gu=F0mundsson?= writes: >I'm trying to get a new version of the draft out the door. The changes >agreed to so far bring up few questions that I would like some input >on before selecting one the possible. > >1. Should the DS record have a digest identifier ? >Right now SHA-1 is the only one specified, x years down the road >we may need a stronger one. There are two ways to handle this, > use digest identifier byte in the record > Use the size of the DS record to signal the algorithm used. > >The second one is compatible with the current specified format of the >record, the first one is more explicit. Definitely have an explicit identifier. As Phillip said, the details of how it's done are important, but the risks of a downgrade attack are greater if there's ever any ambiguity about which algorithm is in use. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 4 01:19:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20175 for ; Fri, 4 Jan 2002 01:19:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MNT1-0008lN-00 for namedroppers-data@psg.com; Thu, 03 Jan 2002 22:04:35 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16MNT1-0008lH-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 22:04:35 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MNT1-000M4u-00 for namedroppers@ops.ietf.org; Thu, 03 Jan 2002 22:04:35 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20020104040226.0E1AB7B7D@berkshire.research.att.com> From: "Steven M. Bellovin" To: Roy Arends Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: DS and Opt-in - a proposal Date: Thu, 03 Jan 2002 23:02:26 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In message <20011228111431.V13525-100000@node10c4d.a2000.nl>, Roy Arends writes : >We are not talking about authenticated [denial of] existence in general, >only about authenticated [denial of] existence of unsecured names. > >Imagine going into a tourist office (.city), the only authoritative >place in town to get the authenticatable, verifiable information from. Let me point folks at draft-bellovin-dnsext-bloomfilt-00.txt, which is designed to address that issue. (a) Is the issue important enough to be worth introducing a brand-new mechanism at this time? (b) Is the false positive rate acceptable? (c) If so, is the protocol complexity of this suggestion acceptable? (d) Is it operationally real? --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 4 11:29:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07686 for ; Fri, 4 Jan 2002 11:29:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MWqf-000Mup-00 for namedroppers-data@psg.com; Fri, 04 Jan 2002 08:05:37 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16MWqf-000Muj-00 for namedroppers@ops.ietf.org; Fri, 04 Jan 2002 08:05:37 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MWqf-000PqT-00 for namedroppers@ops.ietf.org; Fri, 04 Jan 2002 08:05:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3C35D244.EA9ED015@isi.edu> References: <3C34B686.A79956E4@isi.edu> <01c401c1949c$9d7b5840$b9370681@antd.nist.gov> Date: Fri, 04 Jan 2002 11:03:16 -0500 From: Daniel Massey To: Scott Rose CC: namedroppers@ops.ietf.org Subject: Re: DS design questions Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In my view, the flag day would wipe out the old rules and would have the following impact on the example: > > zone 'SUB.A' is signed RFC2535 and has a SIG(KEY) record from the > parent in it's zone. After the flag day, both A and SUB.A are doing the wrong thing: - SIGs generated by A's KEY should be kept local to A's zone - any SIGs in the SUB.A zone should be generated by a SUB.A key This gets rid of a lot of inter-zone coordination issues, questions of who is authoritative for what, problems with when things expire, scaling problems, etc. > What would happen when a DS-aware resolver gets the delegation from 'A', it > will see that no DS RR is present (in the NXT record bitmap)? The resolver > contacts 'SUB.A" it gets the KEY and SIG record for the KEY signed by the > parent (zone A). Ignore the SIG from KEY A. perhaps log a warning that this zone is operating under obsolete rules. > Should a resolver be assumed to have enough intelligence > to start the validation process the old RFC2535 way (or more difficult - a > mix of DS/RFC2535 chaining)? > No, definitely not. The resolver should not be complicated by the trying to understand both the old and new styles. A resolver is either configured with a trusted key for the zone or uses a DS record at the parent. Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 4 12:47:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09493 for ; Fri, 4 Jan 2002 12:47:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MYEZ-000PON-00 for namedroppers-data@psg.com; Fri, 04 Jan 2002 09:34:23 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16MYEZ-000POH-00 for namedroppers@ops.ietf.org; Fri, 04 Jan 2002 09:34:23 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MYEZ-0004CF-00 for namedroppers@ops.ietf.org; Fri, 04 Jan 2002 09:34:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <3C34B686.A79956E4@isi.edu> <01c401c1949c$9d7b5840$b9370681@antd.nist.gov> In-Reply-To: <01c401c1949c$9d7b5840$b9370681@antd.nist.gov> ("Scott Rose"'s message of "Thu, 3 Jan 2002 16:21:31 -0500") Message-ID: To: "Scott Rose" Cc: Subject: Re: DS design questions From: David Blacka Date: Fri, 04 Jan 2002 11:43:35 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Scott" == Scott Rose writes: Scott> If we are going to have a flag day for DNSSEC rollout with DS, Scott> then we should eliminate the NODS bit in the NXT record. Scott> "Vanilla" RFC2535 signed zones would not be deemed "true Scott> DNSSEC secured" anyway. But consider the alternative: Scott> zone 'SUB.A' is signed RFC2535 and has a SIG(KEY) record from Scott> the parent in it's zone. What would happen when a DS-aware Scott> resolver gets the delegation from 'A', it will see that no DS Scott> RR is present (in the NXT record bitmap)? The resolver Scott> contacts 'SUB.A" it gets the KEY and SIG record for the KEY Scott> signed by the parent (zone A). Should a resolver be assumed Scott> to have enough intelligence to start the validation process Scott> the old RFC2535 way (or more difficult - a mix of DS/RFC2535 Scott> chaining)? This makes me wonder about the expected behavior of DNSSEC-aware resolvers. My (possibly wrong) conception was that resolvers would only query with the DNSSEC-OK bit (and EDNS0) if there was a reasonable chance that server would understand it. That is, it would query for DNSSEC records at zones for which it had trusted keys, cached validated keys, or when following a _secure_ delegation. When following an insecure delegation, the resolver would drop EDNS0 (and DNSSEC-OK) on the assumption that those nameservers are DNSSEC (and probably EDNS0) unaware. Since, AFAIK, querying an older DNS server with EDNS0 causes FORMERR to be returned, this seemed to me to be a logical thing to do. Under this scheme, however, this alternative scenario would not work because the resolver would never see SUB.A's keyset (because it didn't ask for it by turning on the DO bit). Should resolvers be querying servers with the DO bit without any indication of whether or not the server will understand it? Should DNSSEC server return DNSSEC information without being asked for it? -- David Blacka Sr. Research 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. From owner-namedroppers@ops.ietf.org Fri Jan 4 12:47:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09523 for ; Fri, 4 Jan 2002 12:47:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MYDw-000PMl-00 for namedroppers-data@psg.com; Fri, 04 Jan 2002 09:33:44 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16MYDv-000PMf-00 for namedroppers@ops.ietf.org; Fri, 04 Jan 2002 09:33:43 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MYDv-0004A4-00 for namedroppers@ops.ietf.org; Fri, 04 Jan 2002 09:33:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <5.1.0.14.2.20020102224702.024262b0@localhost> Message-ID: <20020104112923.M40792-100000@hlid.dc.ogud.com> Date: Fri, 4 Jan 2002 11:38:59 -0500 (EST) From: Olafur Gudmundsson To: namedroppers@ops.ietf.org Subject: Re: DS design questions Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Wed, 2 Jan 2002, Ólafur Guðmundsson wrote: > I'm trying to get a new version of the draft out the door. The changes > agreed to so far bring up few questions that I would like some input > on before selecting one the possible. Thanks to everyone that has responded to these question either on the list or in private. Summary of results. > > 1. Should the DS record have a digest identifier ? Yes, I will add a field to the DS record and require IETF standards action (the most difficult step) to create a new digest identifier, we do not what to many algorithms used. > > Q 2. NODS bit needed in NXT ? Most answers lets have a clean break, and not include this bit. > Q 3. DS or NXT second RR set in authority section ? Fewest people had opinion on this one, but all the answers where "require both", which was not my question. In the draft I will require that authority section on referral answer contain "NS DS SIG(DS) NXT/parent SIG(NXT/parent)" in this order, DS will only be included if it exists, and NXT/child is not allowed. thanks again 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. From owner-namedroppers@ops.ietf.org Fri Jan 4 19:19:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16619 for ; Fri, 4 Jan 2002 19:19:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MeKP-0009l1-00 for namedroppers-data@psg.com; Fri, 04 Jan 2002 16:04:49 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16MeKO-0009kv-00 for namedroppers@ops.ietf.org; Fri, 04 Jan 2002 16:04:48 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MeKO-000Fs8-00 for namedroppers@ops.ietf.org; Fri, 04 Jan 2002 16:04:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <3C34B686.A79956E4@isi.edu> <01c401c1949c$9d7b5840$b9370681@antd.nist.gov> In-Reply-To: David Blacka's message of "Fri, 04 Jan 2002 11:43:35 -0500" Message-ID: To: David Blacka Cc: "Scott Rose" , Subject: Re: DS design questions From: Derek Atkins Date: 04 Jan 2002 14:13:16 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David Blacka writes: > My (possibly wrong) conception was that resolvers would only query > with the DNSSEC-OK bit (and EDNS0) if there was a reasonable chance > that server would understand it. That is, it would query for DNSSEC > records at zones for which it had trusted keys, cached validated keys, > or when following a _secure_ delegation. When following an insecure > delegation, the resolver would drop EDNS0 (and DNSSEC-OK) on the > assumption that those nameservers are DNSSEC (and probably EDNS0) > unaware. This certainly does not appear to be what BIND does, at least by my watching it. It appears to at least try EDNS0 on every (initial) request. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 4 20:18:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16995 for ; Fri, 4 Jan 2002 20:18:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MfKr-000BXV-00 for namedroppers-data@psg.com; Fri, 04 Jan 2002 17:09:21 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16MfKq-000BXP-00 for namedroppers@ops.ietf.org; Fri, 04 Jan 2002 17:09:20 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16MfKq-000HaW-00 for namedroppers@ops.ietf.org; Fri, 04 Jan 2002 17:09:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: Date: Fri, 4 Jan 2002 14:47:17 -0800 (PST) From: Brian Wellington To: David Blacka cc: Scott Rose , Subject: Re: DS design questions Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 4 Jan 2002, David Blacka wrote: > >>>>> "Scott" == Scott Rose writes: > > Scott> If we are going to have a flag day for DNSSEC rollout with DS, > Scott> then we should eliminate the NODS bit in the NXT record. > Scott> "Vanilla" RFC2535 signed zones would not be deemed "true > Scott> DNSSEC secured" anyway. But consider the alternative: > > Scott> zone 'SUB.A' is signed RFC2535 and has a SIG(KEY) record from > Scott> the parent in it's zone. What would happen when a DS-aware > Scott> resolver gets the delegation from 'A', it will see that no DS > Scott> RR is present (in the NXT record bitmap)? The resolver > Scott> contacts 'SUB.A" it gets the KEY and SIG record for the KEY > Scott> signed by the parent (zone A). Should a resolver be assumed > Scott> to have enough intelligence to start the validation process > Scott> the old RFC2535 way (or more difficult - a mix of DS/RFC2535 > Scott> chaining)? > > This makes me wonder about the expected behavior of DNSSEC-aware > resolvers. > > My (possibly wrong) conception was that resolvers would only query > with the DNSSEC-OK bit (and EDNS0) if there was a reasonable chance > that server would understand it. That is, it would query for DNSSEC > records at zones for which it had trusted keys, cached validated keys, > or when following a _secure_ delegation. When following an insecure > delegation, the resolver would drop EDNS0 (and DNSSEC-OK) on the > assumption that those nameservers are DNSSEC (and probably EDNS0) > unaware. I would think that a resolver which understands EDNS and is capable of verifying DNSSEC records would always query with EDNS0 and the DO bit, unless it believes that the remote server will not understand it. That is, when it sees a FORMERR response, it will no longer send EDNS/DO to the same server. > Since, AFAIK, querying an older DNS server with EDNS0 causes FORMERR > to be returned, this seemed to me to be a logical thing to do. Right. > Under this scheme, however, this alternative scenario would not work > because the resolver would never see SUB.A's keyset (because it didn't > ask for it by turning on the DO bit). Unless it defaults to enabling the DO bit. > Should resolvers be querying servers with the DO bit without any > indication of whether or not the server will understand it? Yes. There's no harm in this. > Should > DNSSEC server return DNSSEC information without being asked for it? No. Otherwise the DO bit is useless. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 5 02:31:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02001 for ; Sat, 5 Jan 2002 02:31:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Ml1a-000KtJ-00 for namedroppers-data@psg.com; Fri, 04 Jan 2002 23:13:50 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Ml1a-000KtD-00 for namedroppers@ops.ietf.org; Fri, 04 Jan 2002 23:13:50 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Ml1Z-0002OD-00 for namedroppers@ops.ietf.org; Fri, 04 Jan 2002 23:13:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020105071111.02B257B4B@berkshire.research.att.com> From: "Steven M. Bellovin" To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org Subject: Re: DS design questions Date: Sat, 05 Jan 2002 02:11:10 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In message <20020104112923.M40792-100000@hlid.dc.ogud.com>, Olafur Gudmundsson writes: >On Wed, 2 Jan 2002, Olafur Gudmundsson wrote: > >> I'm trying to get a new version of the draft out the door. The changes >> agreed to so far bring up few questions that I would like some input >> on before selecting one the possible. > >Thanks to everyone that has responded to these question either on the >list or in private. > >Summary of results. >> >> 1. Should the DS record have a digest identifier ? > >Yes, I will add a field to the DS record and require IETF standards >action (the most difficult step) to create a new digest identifier, >we do not what to many algorithms used. A more important step than requiring a standards action is to define the precise semantics of the digest identifier, once more than one exists. That has to be done now, regardless of the existence or non-existence of other choices, or today's code won't do the right thing tomorrow when a new algorithm is added. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 8 19:59:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15463 for ; Tue, 8 Jan 2002 19:59:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16O6sD-000Gvr-00 for namedroppers-data@psg.com; Tue, 08 Jan 2002 16:45:45 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16O6sD-000Gvl-00 for namedroppers@ops.ietf.org; Tue, 08 Jan 2002 16:45:45 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16O6sD-000J7F-00 for namedroppers@ops.ietf.org; Tue, 08 Jan 2002 16:45:45 -0800 Message-Id: <200201081342.IAA20397@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-08.txt Date: Tue, 08 Jan 2002 08:42:37 -0500 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 : Linklocal Multicast DNS (LMDNS) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-08.txt Pages : 17 Date : 07-Jan-02 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a DNS server. In order to allow DNS name resolution in such environments, the use of a multicast DNS is proposed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-mdns-08.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-mdns-08.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: <20020107134924.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020107134924.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. From owner-namedroppers@ops.ietf.org Tue Jan 8 20:00:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15520 for ; Tue, 8 Jan 2002 20:00:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16O6qz-000GuS-00 for namedroppers-data@psg.com; Tue, 08 Jan 2002 16:44:29 -0800 Received: from roam.psg.com ([147.28.0.10]) by psg.com with esmtp (Exim 3.33 #1) id 16O6qz-000GuL-00 for namedroppers@ops.ietf.org; Tue, 08 Jan 2002 16:44:29 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16Ny2l-000EQU-00 for namedroppers@ops.ietf.org; Tue, 08 Jan 2002 07:20:03 -0800 Message-Id: <200201081342.IAA20397@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-08.txt Date: Tue, 08 Jan 2002 08:42:37 -0500 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 : Linklocal Multicast DNS (LMDNS) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-08.txt Pages : 17 Date : 07-Jan-02 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a DNS server. In order to allow DNS name resolution in such environments, the use of a multicast DNS is proposed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-mdns-08.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-mdns-08.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: <20020107134924.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020107134924.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. From owner-namedroppers@ops.ietf.org Tue Jan 8 20:55:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15462 for ; Tue, 8 Jan 2002 19:59:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16O6xT-000H2P-00 for namedroppers-data@psg.com; Tue, 08 Jan 2002 16:51:11 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16O6xT-000H2J-00 for namedroppers@ops.ietf.org; Tue, 08 Jan 2002 16:51:11 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16O6xT-000JHF-00 for namedroppers@ops.ietf.org; Tue, 08 Jan 2002 16:51:11 -0800 In-Reply-To: <20020104040226.0E1AB7B7D@berkshire.research.att.com> Message-ID: <20020108153521.M28305-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 8 Jan 2002 16:35:11 +0100 (CET) From: Roy Arends To: "Steven M. Bellovin" Cc: Roy Arends , Subject: Re: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 3 Jan 2002, Steven M. Bellovin wrote: > In message <20011228111431.V13525-100000@node10c4d.a2000.nl>, Roy Arends writes > : > > >We are not talking about authenticated [denial of] existence in general, > >only about authenticated [denial of] existence of unsecured names. > > > >Imagine going into a tourist office (.city), the only authoritative > >place in town to get the authenticatable, verifiable information from. > > Let me point folks at draft-bellovin-dnsext-bloomfilt-00.txt, which is > designed to address that issue. > > (a) Is the issue important enough to be worth introducing a brand-new > mechanism at this time? > > (b) Is the false positive rate acceptable? > > (c) If so, is the protocol complexity of this suggestion acceptable? > > (d) Is it operationally real? The idea of using bloom-filters is interesting, but I've some small concerns about the following: wrt loops: In the paper there is an example of using an url in a resource record: https://bloomfilter.ns.example.com?324+3248+23980+89732+... 1) this triggers another lookup, which uses the DNS. What if "bloomfilter.ns.example.com" does not exist ? How is that denied ? 2) How is the existence of the bloom resource record containing the url denied ? My 0.02 Euro Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 9 02:21:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00388 for ; Wed, 9 Jan 2002 02:21:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OCmk-000MgZ-00 for namedroppers-data@psg.com; Tue, 08 Jan 2002 23:04:30 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16OCmj-000MgT-00 for namedroppers@ops.ietf.org; Tue, 08 Jan 2002 23:04:29 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16OCmj-0003Ye-00 for namedroppers@ops.ietf.org; Tue, 08 Jan 2002 23:04:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: Message-Id: From: Randy Bush To: Olafur Gudmundsson , Randy Bush Cc: namedroppers Subject: Re: DS and Opt-in - a proposal Date: Tue, 08 Jan 2002 23:00:06 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The discussion concluded that the deployment of DS was critical, and worried > that a decision not to adopt Opt-in could pose problems in deployment. Thus > we propose the following: > o DS and Opt-in proposals both be adopted and > o RFC 2535 backwards compatibility NOT be retained. (flag day!) > ... > This beings a two week last call on this proposal, to end 2002.01.01. it has been over two weeks. it is the view of the chairs that o there seems to be a very clear consensus for DS. in fact, there were no negative technical comments. o there does not seem to be a consensus for Opt-In. there was considerable discussion pro and con, with technical considerations in both directions. if someone has NEW technical arguments to present for or against either proposal, please do so now. N_E_W arguments. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 9 21:59:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26801 for ; Wed, 9 Jan 2002 21:59:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OV8I-000FFk-00 for namedroppers-data@psg.com; Wed, 09 Jan 2002 18:39:58 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16OV8I-000FFe-00 for namedroppers@ops.ietf.org; Wed, 09 Jan 2002 18:39:58 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16OV8I-000AJb-00 for namedroppers@ops.ietf.org; Wed, 09 Jan 2002 18:39:58 -0800 Message-Id: <200201092102.QAA15219@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-song-dnsext-nai-support-00.txt Date: Wed, 09 Jan 2002 16:02:11 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DNS RR type for NAI Author(s) : J. Song et al. Filename : draft-song-dnsext-nai-support-00.txt Pages : 6 Date : 08-Jan-02 This document proposes the use of the new DNS RR type 'NAI' to specify the most current location of the user(Host IP address). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-song-dnsext-nai-support-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-song-dnsext-nai-support-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-song-dnsext-nai-support-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. --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: <20020108150609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-song-dnsext-nai-support-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-song-dnsext-nai-support-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020108150609.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. From owner-namedroppers@ops.ietf.org Wed Jan 9 22:13:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27170 for ; Wed, 9 Jan 2002 22:13:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OVSz-000FdE-00 for namedroppers-data@psg.com; Wed, 09 Jan 2002 19:01:21 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16OVSy-000Fd8-00 for namedroppers@ops.ietf.org; Wed, 09 Jan 2002 19:01:20 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16OVSy-000Atk-00 for namedroppers@ops.ietf.org; Wed, 09 Jan 2002 19:01:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200201092102.QAA15219@ietf.org> In-Reply-To: <200201092102.QAA15219@ietf.org> (Internet-Drafts@ietf.org's message of "Wed, 09 Jan 2002 16:02:11 -0500") Message-ID: To: santajun@lycos.co.kr, galahad@netsgo.com Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-song-dnsext-nai-support-00.txt From: Simon Josefsson Date: Thu, 10 Jan 2002 00:02:18 +0100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This draft looks useful, I have only one minor comment. In section 3 which describes the name syntax, have you considered using the SOA emailaddress -> domainname translation instead? That is, your example in section 4 would look like: junhyuk.samsung.skt.co.kr. 86400 IN NAI 165.213.221.4 instead of junhyuk@.samsung.skt.co.kr. 86400 IN NAI 165.213.221.4 Perhaps the TTL in the example should be smaller as well, given your TTL discussion. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 9 22:48:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28642 for ; Wed, 9 Jan 2002 22:48:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OW4N-000GKK-00 for namedroppers-data@psg.com; Wed, 09 Jan 2002 19:39:59 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16OW4N-000GKE-00 for namedroppers@ops.ietf.org; Wed, 09 Jan 2002 19:39:59 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16OW4N-000Bz2-00 for namedroppers@ops.ietf.org; Wed, 09 Jan 2002 19:39:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201100337.g0A3bZp60075@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 09 Jan 2002 16:02:11 CDT." <200201092102.QAA15219@ietf.org> To: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: draft-song-dnsext-nai-support-00.txt Date: Thu, 10 Jan 2002 14:37:35 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There are some obvious flaws in this to start with. 1. the world in no longer just IPv4. 2. there is no way to say that the user is just off-net. 3. there is already well established ways to map these sorts of addresses into domain names. You need to justify why there should be another method used. Mark -- Mark Andrews, Internet Software Consortium 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. From owner-namedroppers@ops.ietf.org Wed Jan 9 23:16:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29175 for ; Wed, 9 Jan 2002 23:16:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OWT4-000GoU-00 for namedroppers-data@psg.com; Wed, 09 Jan 2002 20:05:30 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16OWT4-000GoN-00 for namedroppers@ops.ietf.org; Wed, 09 Jan 2002 20:05:30 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16OWT4-000ChB-00 for namedroppers@ops.ietf.org; Wed, 09 Jan 2002 20:05:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200201092102.QAA15219@ietf.org> In-Reply-To: Simon Josefsson's message of "Thu, 10 Jan 2002 00:02:18 +0100" Message-ID: To: Simon Josefsson Cc: santajun@lycos.co.kr, galahad@netsgo.com, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-song-dnsext-nai-support-00.txt From: Derek Atkins Date: 09 Jan 2002 22:52:23 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Simon, Based on your suggestion, how would you cope with a sitation where a site has an alias (cname) that happens to match a username? For example, assume you have a user "warlord@mit.edu" (not a hard assumption ;) and you already have the following host (cname) record: warlord.mit.edu. IN CNAME some-computer.mit.edu. How are you supposed to add in: warlord.mit.edu. IN NAI .... Keep in mind that CNAMEs are not allowed to co-exist with other RR types at a node. Similar problem if a username matches a subdomain (because the data would want to live in the child zone). -derek Simon Josefsson writes: > This draft looks useful, I have only one minor comment. In section 3 > which describes the name syntax, have you considered using the SOA > emailaddress -> domainname translation instead? That is, your example > in section 4 would look like: > > junhyuk.samsung.skt.co.kr. 86400 IN NAI 165.213.221.4 > > instead of > > junhyuk@.samsung.skt.co.kr. 86400 IN NAI 165.213.221.4 > > Perhaps the TTL in the example should be smaller as well, given your > TTL discussion. > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 10 00:14:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00529 for ; Thu, 10 Jan 2002 00:14:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OXKN-000Hk6-00 for namedroppers-data@psg.com; Wed, 09 Jan 2002 21:00:35 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16OXKM-000Hjz-00 for namedroppers@ops.ietf.org; Wed, 09 Jan 2002 21:00:34 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16OXKM-000EFG-00 for namedroppers@ops.ietf.org; Wed, 09 Jan 2002 21:00:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <200201092102.QAA15219@ietf.org> Message-ID: Date: Wed, 9 Jan 2002 20:59:23 -0800 (PST) From: Ben Clifford To: cc: Subject: Re: I-D ACTION:draft-song-dnsext-nai-support-00.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 9 Jan 2002 Internet-Drafts@ietf.org wrote: > This document proposes the use of the new DNS RR type 'NAI' to > specify the most current location of the user(Host IP address). It seems that what you mean "user" means something along the lines of "mobile host, belonging to a person" rather than actually meaning a "person". Forgive me if I am overlooking something, but what is wrong with using the A RR type for this purpose (used, as you suggest in the draft, with short TTL and with the label formatted as you suggest) For example, junhyuk@.samsung.skt.co.kr. 30 IN A 165.213.221.4 Is there some extra implied meaning, for example, that NAI hosts should be able to keep TCP connections open, even though the IP address has changed? -- Ben Clifford benc@hawaga.org.uk http://www.hawaga.org.uk/ben/ GPG: 30F06950 - signed/encrypted mail encouraged Job Required - Will do most things unix or IP for money. =WARNING= Do not ever send e-mail to philip@hawaga.org.uk =WARNING= to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 10 00:16:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00586 for ; Thu, 10 Jan 2002 00:16:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OXUN-000Huv-00 for namedroppers-data@psg.com; Wed, 09 Jan 2002 21:10:55 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16OXUM-000Hup-00 for namedroppers@ops.ietf.org; Wed, 09 Jan 2002 21:10:54 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16OXUM-000EXr-00 for namedroppers@ops.ietf.org; Wed, 09 Jan 2002 21:10:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: Date: Wed, 9 Jan 2002 21:05:04 -0800 (PST) From: Ben Clifford To: Derek Atkins cc: Simon Josefsson , , , Subject: Re: I-D ACTION:draft-song-dnsext-nai-support-00.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 9 Jan 2002, Derek Atkins wrote: > Based on your suggestion, how would you cope with a sitation where a > site has an alias (cname) that happens to match a username? For > example, assume you have a user "warlord@mit.edu" (not a hard > assumption ;) and you already have the following host (cname) record: Perhaps you shouldn't use the root DNS name as the realm name? For example, warlord.student-realm.mit.edu or warlord.faculty-realm.mit.edu If you are putting in symbols to separate out different kinds of object, I would think that the standard way to do it (x.subdomain.y.gov) would be the better way? -- Ben Clifford benc@hawaga.org.uk http://www.hawaga.org.uk/ben/ GPG: 30F06950 - signed/encrypted mail encouraged telnet/ssh guest@barbarella.hawaga.org.uk password guest to talk webcam: http://barbarella.hawaga.org.uk/benc-cgi/watchers.cgi Job Required - Will do most things unix or IP for money. =WARNING= Do not ever send e-mail to philip@hawaga.org.uk =WARNING= to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 10 00:43:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01448 for ; Thu, 10 Jan 2002 00:43:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OXuO-000ITO-00 for namedroppers-data@psg.com; Wed, 09 Jan 2002 21:37:48 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16OXuO-000ITI-00 for namedroppers@ops.ietf.org; Wed, 09 Jan 2002 21:37:48 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16OXuO-000FIe-00 for namedroppers@ops.ietf.org; Wed, 09 Jan 2002 21:37:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: In-Reply-To: Ben Clifford's message of "Wed, 9 Jan 2002 21:05:04 -0800 (PST)" Message-ID: To: Ben Clifford Cc: Simon Josefsson , , , Subject: Re: I-D ACTION:draft-song-dnsext-nai-support-00.txt From: Derek Atkins Date: 10 Jan 2002 00:33:56 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ben Clifford writes: > Perhaps you shouldn't use the root DNS name as the realm name? > > For example, > warlord.student-realm.mit.edu > or > warlord.faculty-realm.mit.edu You are implying a separation where one does not exist. There _is_ no "warlord@student-realm.mit.edu". My point was that "warlord@.mit.edu." would work but removing the trailing '@' causes problems. Obviously there are other naming tricks we could do (I believe you are suggesting that, but I disagree with your example suggestion). I think a better suggestion would be: warlord._user.mit.edu. > If you are putting in symbols to separate out different kinds of object, I > would think that the standard way to do it (x.subdomain.y.gov) would be > the better way? No, because you have the same potential problem... If you ever have a user name that matches a subdomain you get into trouble. The only way to do it is to create a special subdomain (ala SRV records) that uses a special name which you can pretty much guarantee will never exist. Never mind the fact that I'm not convinced the NAI record is something that needs to happen. We already have IMPP; why do we need DNS to give the same location information? IMPP is already designed to have users register their precense (location) information. I'm not convinced that DNS can provide the level of dynamic or duplicate information that IMPP can provide. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 10 11:27:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18044 for ; Thu, 10 Jan 2002 11:27:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Ohlj-00037q-00 for namedroppers-data@psg.com; Thu, 10 Jan 2002 08:09:31 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Ohlj-00037k-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 08:09:31 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Ohlj-0007py-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 08:09:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201100949.g0A9njG21147@open.nlnetlabs.nl> In-Reply-To: "Randy Bush's message as of Jan 9, 8:41" From: ted@tednet.nl (Ted Lindgreen) Date: Thu, 10 Jan 2002 10:49:45 +0100 To: Randy Bush , Olafur Gudmundsson Subject: Re: DS and Opt-in - a proposal Cc: namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Randy Bush, on Jan 9, 8:41, in "Re: DS and Opt-in - ..."] > o there seems to be a very clear consensus for DS. in fact, there were > no negative technical comments. Agree. > o there does not seem to be a consensus for Opt-In. there was > considerable discussion pro and con, with technical considerations > in both directions. > > if someone has NEW technical arguments to present for or against either > proposal, please do so now. N_E_W arguments. N_E_W arguments, at least new technical arguments, are probably difficult to produce, I think they have been beaten to death and are pretty clear for most of us. What has not been discussed enough, IMHO, is what we want to accomplish with DNSSEC, and once we answer that question, the technical arguments about Opt-In fall into place easily. I'll try to take a shot at it. I see four paths to go forward: 1. Forget DNSSEC in its current shape. 2. Strive for full implementation, i.e. the goal is to get most of the DNS tree secured over time. 3. Go for course grain security, i.e. some or more large secureds branches side by side with large unsecured branches, and divided by clearly defined borders. 4. Go for fine grain security, i.e. some or more secured RRs within a further unsecured DNS-tree. ad 1. This will happen when we do not go forward, it's the easy way :-) ad 2. This is not realistic to expect to happen soon. ad 3. Course grain security will lead to secured safehavens, garded by the major DNS forwarders/cachers. Some users may also check themselves, but many others will probably just trust their ISPs DNS forwarders/cachers. This way, it will be difficult for scriptkiddies to produce major spoofs in the safehavens, which is a major gain. ad 4. Fine grain security makes it possible to have scattered secured RRs, this is more easily implementaed than 3, and it solves many problems for instance for the IPSEC people, and may open some interesting business opportunities. People who want these scattered secured RRs to be certified will check them themselves, others will probably want an answer (with possible outdated sig) more dearly than a certified answer, so chances are big that most major DNS forwarders/cachers will not bother checking the few scattered secured RRs. Now, lets see how Opt-In fits in: 1. Does not matter. 2. Chances are slim we ever get here without Opt-In, chances are virtually zero we get here when we start with Opt-In. 3. Opt-In does not fit into this scheme. 4. Opt-In makes this possible, but there are probably more easy ways to accomplish the same (like an alternative PKI outside DNS, or DNSSEC without auth. denial). -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 10 11:30:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18165 for ; Thu, 10 Jan 2002 11:30:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Ohx0-0003NL-00 for namedroppers-data@psg.com; Thu, 10 Jan 2002 08:21:10 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Ohx0-0003NE-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 08:21:10 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Ohx0-0008Ap-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 08:21:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200201092102.QAA15219@ietf.org> In-Reply-To: (Derek Atkins's message of "09 Jan 2002 22:52:23 -0500") Message-ID: To: Derek Atkins Cc: santajun@lycos.co.kr, galahad@netsgo.com, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-song-dnsext-nai-support-00.txt From: Simon Josefsson Date: Thu, 10 Jan 2002 12:42:02 +0100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would add the NAI RR at some-computer.mit.edu instead. Before we get into the case where the CNAME points at a machine in a different zone (is that really a likely scenario?) or another user named "some-computer" (ditto), I'd agree that using user._nai.example.org might solve this more cleanly. (not _user) As for IPv6, Mobile IPv4 is not compatible with Mobile IPv6 so they need separate mechanisms, or a RR format that can encode both IPv4 and IPv6 addresses. Derek Atkins writes: > Simon, > > Based on your suggestion, how would you cope with a sitation where a > site has an alias (cname) that happens to match a username? For > example, assume you have a user "warlord@mit.edu" (not a hard > assumption ;) and you already have the following host (cname) record: > > warlord.mit.edu. IN CNAME some-computer.mit.edu. > > How are you supposed to add in: > > warlord.mit.edu. IN NAI .... > > Keep in mind that CNAMEs are not allowed to co-exist with other RR > types at a node. Similar problem if a username matches a subdomain > (because the data would want to live in the child zone). > > -derek > > Simon Josefsson writes: > >> This draft looks useful, I have only one minor comment. In section 3 >> which describes the name syntax, have you considered using the SOA >> emailaddress -> domainname translation instead? That is, your example >> in section 4 would look like: >> >> junhyuk.samsung.skt.co.kr. 86400 IN NAI 165.213.221.4 >> >> instead of >> >> junhyuk@.samsung.skt.co.kr. 86400 IN NAI 165.213.221.4 >> >> Perhaps the TTL in the example should be smaller as well, given your >> TTL discussion. >> >> >> >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 10 20:48:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27496 for ; Thu, 10 Jan 2002 20:48:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Oqab-000DzX-00 for namedroppers-data@psg.com; Thu, 10 Jan 2002 17:34:37 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Oqaa-000DzR-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 17:34:36 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Oqaa-000N2F-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 17:34:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: To: santajun@lycos.co.kr, sjosefsson@rsasecurity.com, warlord@mit.edu, namedroppers@ops.ietf.org Subject: Fw: I-D ACTION:draft-song-dnsext-nai-support-00.txt Date: Fri, 11 Jan 2002 08:54:06 +0900 (KST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit -------DMGEF9SY8VAHC.697QEYERYLH44HQ7. I would assign a one specific domain name to that purpose So for example if I assign/reserver some domain names like naiservice=2Emit=2Eedu for that purpose, I don't give hostnames having suffix as naiservice=2Emit=2Eedu for other purpose=2E Then although you concatenate any username to that domain name like anyusername=2Enaiservice=2Emit=2Eedu, it'll not conflick with other hostnames to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 10 20:50:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27519 for ; Thu, 10 Jan 2002 20:50:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OqiO-000E8a-00 for namedroppers-data@psg.com; Thu, 10 Jan 2002 17:42:40 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16OqiO-000E8T-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 17:42:40 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16OqiO-000NFj-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 17:42:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Message-Id: From: "¼ÛÁØÇõ" To: warlord@mit.edu Cc: santajun@lycos.co.kr, sjosefsson@rsasecurity.com, santajun@lycos.co.kr, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-song-dnsext-nai-support-00.txt Date: Fri, 11 Jan 2002 09:35:12 +0900 (KST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, In 3GPP2 P.S0001-B, we are currently supporting the service call IRS (Internet Reachability Service), which is using DNS "A Record" for one to one mapping between mobile host IP address and NAI (user.realm. format). Although NAI actually form of user.specific_node.domain, there are still some possibility can cause some confusion. I believe separately defining "NAI" as DNS RR, helps clarify that problem. Speaking of IMPP, what defining NAI in DNS RR can do far more than just instant message service. One of the application, we are thinking for Internet Reachability Service (IRS) is push service. Contents provider can provide certain contents service, regardless of location of user. User can be travelling from Asia to US, and could simply register for updating NAI with temporaly IP address. It may work regardless of access network (Wideband CDMA, CDMA2000, Bluetooth, and Wireless LAN). It can provide always on user reachbility which is actually user mobility. Unlike SIP which is very specific for VoIP, defining NAI as a DNS RR can provide far much general way of user (Mobile Host) location service. Eventually it may interwork with ENUM which will provide interoperability between Internet and PSTN. And it is currently under investigate. Thanks JunHyuk Ben Clifford writes: > Perhaps you shouldn't use the root DNS name as the realm name? > > For example, > warlord.student-realm.mit.edu > or > warlord.faculty-realm.mit.edu You are implying a separation where one does not exist. There _is_ no "warlord@student-realm.mit.edu". My point was that "warlord@.mit.edu." would work but removing the trailing '@' causes problems. Obviously there are other naming tricks we could do (I believe you are suggesting that, but I disagree with your example suggestion). I think a better suggestion would be: warlord._user.mit.edu. > If you are putting in symbols to separate out different kinds of object, I > would think that the standard way to do it (x.subdomain.y.gov) would be > the better way? No, because you have the same potential problem... If you ever have a user name that matches a subdomain you get into trouble. The only way to do it is to create a special subdomain (ala SRV records) that uses a special name which you can pretty much guarantee will never exist. Never mind the fact that I'm not convinced the NAI record is something that needs to happen. We already have IMPP; why do we need DNS to give the same location information? IMPP is already designed to have users register their precense (location) information. I'm not convinced that DNS can provide the level of dynamic or duplicate information that IMPP can provide. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 10 20:56:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27592 for ; Thu, 10 Jan 2002 20:56:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Oqo4-000EH6-00 for namedroppers-data@psg.com; Thu, 10 Jan 2002 17:48:32 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Oqo3-000EH0-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 17:48:31 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Oqo3-000NPW-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 17:48:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit References: <200201110041.TAA09085@fort-point-station.mit.edu> In-Reply-To: "XXXXXX"'s message of "Fri, 11 Jan 2002 09:35:12 +0900 (KST)" Message-ID: To: "XXXXXX" Cc: sjosefsson@rsasecurity.com, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-song-dnsext-nai-support-00.txt From: Derek Atkins Date: 10 Jan 2002 20:04:37 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit "XXXXXX" writes: > Hi all, > > In 3GPP2 P.S0001-B, we are currently supporting the service call IRS > (Internet Reachability Service), which is using DNS "A Record" for > one to one mapping between mobile host IP address and NAI > (user.realm. format). Although NAI actually form of > user.specific_node.domain, there are still some possibility can > cause some confusion. I believe separately defining "NAI" as DNS > RR, helps clarify that problem. Why can't you just just the Home Address for this? Sure, the first packet will have to go through the home agent, but you just need to provide a service that says "Mobile Host A.B.C.D is currently located at Care-of Address W.X.Y.Z". > Speaking of IMPP, what defining NAI in DNS RR can do far more than > just instant message service. So can IMPP. The PP stands for "Precence Protocol". The hope is to have a general "user X is reachable via this list of protocols" where each list-entry is a URI defining a communication protocol, an address, and perhaps a "local name". For example, my reachability could be: im:warlord@mit.edu voice:+1.617.555.1212 fax:+1.617.555.1234 email:warlord@mit.edu The PP in IMPP is meant to go far beyond just IM. > User can be travelling from Asia to US, and could simply register > for updating NAI with temporaly IP address. It may work regardless > of access network (Wideband CDMA, CDMA2000, Bluetooth, and Wireless > LAN). It can provide always on user reachbility which is actually > user mobility. I don't believe that DNS is the right place to do this. You really want a local lookup service based on your home address. If you're moving a lot, in a MIPv6 world, you might be changing your care-of address ever few seconds (or maybe every minute). DNS just can't keep up with that level of data dynamics. > Unlike SIP which is very specific for VoIP, defining NAI as a DNS RR > can provide far much general way of user (Mobile Host) location > service. You are confused. SIP is not specific to voice. In fact, SIP happens to also be the leading IM protocol, too. > Eventually it may interwork with ENUM which will provide > interoperability between Internet and PSTN. And it is currently > under investigate. A worthy goal. > Thanks > JunHyuk -derek > Ben Clifford writes: > > > Perhaps you shouldn't use the root DNS name as the realm name? > > > > For example, > > warlord.student-realm.mit.edu > > or > > warlord.faculty-realm.mit.edu > > You are implying a separation where one does not exist. There _is_ > no "warlord@student-realm.mit.edu". > > My point was that "warlord@.mit.edu." would work but removing the > trailing '@' causes problems. Obviously there are other naming > tricks we could do (I believe you are suggesting that, but I disagree > with your example suggestion). I think a better suggestion would > be: > warlord._user.mit.edu. > > > If you are putting in symbols to separate out different kinds of object, I > > would think that the standard way to do it (x.subdomain.y.gov) would be > > the better way? > > No, because you have the same potential problem... If you ever have a > user name that matches a subdomain you get into trouble. The only way > to do it is to create a special subdomain (ala SRV records) that uses > a special name which you can pretty much guarantee will never exist. > > Never mind the fact that I'm not convinced the NAI record is something > that needs to happen. We already have IMPP; why do we need DNS to > give the same location information? IMPP is already designed to have > users register their precense (location) information. I'm not > convinced that DNS can provide the level of dynamic or duplicate > information that IMPP can provide. > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > > > > > > > Next Entertainment, LYCOS > =========================================================================== > Áñ°ÌÁö ¾ÊÀ¸¸é ÀÎÅͳÝÀÌ ¾Æ´Õ´Ï´Ù!! http://www.lycos.co.kr > 2002³â ÀÓ¿À³â! ¿ÃÇØ ³ªÀÇ ¿î¼¼´Â? - ¶óÀÌÄÚ½º ¿î¼¼(http://lucky.lycos.co.kr) > ¸»¶ìÇØ¿¡ ÀüÇÏ´Â ½Å³âÃàÇÏ ¸Þ½ÃÁö - ¶óÀÌÄÚ½º eÄ«µå(http://ecard.lycos.co.kr) -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 10 20:58:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27626 for ; Thu, 10 Jan 2002 20:58:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Oqne-000EG8-00 for namedroppers-data@psg.com; Thu, 10 Jan 2002 17:48:06 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Oqne-000EG0-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 17:48:06 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Oqne-000NOp-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 17:48:06 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698F1@vhqpostal.verisign.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C19A3C.2075F080" From: "Hallam-Baker, Phillip" To: "'ted@tednet.nl'" , Randy Bush , Olafur Gudmundsson Cc: namedroppers Subject: RE: DS and Opt-in - a proposal Date: Thu, 10 Jan 2002 17:05:57 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C19A3C.2075F080 Content-Type: text/plain; charset="iso-8859-1" I have yet to see a technical argument of any kind against Opt-in. To assist the group I enclose my summary of this thread below. I really do not see the technical opposition that Randy appears to believe exists. At SLC I heard plenty of political arguments of the form 'we do not want to support this community' or even 'we want to deliberately disenfranchise this community'. If it is the view of the group that they do not want to support .com, .net and .org I would like the group to explicitly state that that is their position. I take issue with Ted's analysis. There is another possibility. If the group decides to design a DNS security specification that cannot be supported by a significant community then the result will be divergence. That is a bad thing in the DNS system. Remember however that it takes two to diverge. In fact I don't believe that divergence is a likely outcome. Instead what I believe is a more likely outcome is that the IESG asks why the DNSEXT group is disputing a protocol modification which nobody is seriously disputing is necessary if DNSSEC is to be depolyable in the large domains so that the 30 million odd names registered in them can use the protcol. The group is told to fix the problem before the planned rewrite of 2535 goes forward. The way to make standards progress rapidly in standards processes is to fix them promptly when problems are identified. I have never seen a standards process accelerated by ignoring design flaws. To answer the issues in the thread: Ted's analysis essentially argues that because full implementation of DNS sec is unlikely the Opt in proposal reduces the probaility of full implementation occurring (!) I do not understand this argument. Perhaps there is a mistype and a negative was dropped somewhere. The technical case for Opt-in is that it very substantially reduces the cost of deployment of DNSsec in the large domains. The security model supported by Opt-in provides exactly the same security assurances with the single exception that in an opt-in zone an attacker may insert a record for an unregistered zone. This 'risk' does not constitute a 'threat' in the large domains because any party can register a domain in .com, .net or .org by means of a credit card. The issues raised against were that a change in the spec would break backwards compatibility in the limited sense that a resolver that does not support Opt-in would be unable to make use of an opt-in secured zone. This does not seem to be much of an argument when the alternative is not to have the zone secured at all. Opt in is an optional spec, the only consequence of this risk is that the security considerations section should provide adequate warning that the issue must be considered. Olaf's contributions were as follows: >From a zone administrator's point of view, given the tools I know exist >today and which I expect will be created within the first few years, it >is _vastly_ less resistive to sign the whole zone than to sign just parts >of it related to PKI. This is not a valid criticism. If a zone is large enough that opt-in becomes necessary it is unlikely that it is being managed using standard tools in any case. The proponents of opt-in are not expecting to rely on the community at large to implement the signing component. >I would like to know if there will be a new version of the OPT-in >draft that allows opt-in only over delegation records? And later: >Administrators of large caches will not turn verification on if only a >few records in a few zones are signed; It is to expensive to >troubleshoot and there is little to gain. I think we are far from >having the applications or their host os-es doing their own >verification, so if administrators do not turn their caches into >verifying caches then DNSSEC has failed to secure the infrastructure. Again this is not a technical argument, it is social. It is trumped by the argument that there will be practically no use of DNS sec if it cannot be deployed in the large zones. >The other interest group, users that want to use the DNS as a PKI, will >not suffer from OPT-IN. The verification will be done by the specially >designed applications. They are not interested in fully signed zones, >they just want to get to that one RR and need to verify it. >I can live with OPT-IN if it is designed to be a transition mechanism >for g|tLDs. If it is designed to be used throughout the whole tree >.DNSSEC will loose. OPT-IN is definitely not suitable for use throughout the whole tree. The insertion of the DNS record 12ry24f1872trw287yt1247t.com does not constitute a security threat. The insertion of shop.ibm.com does. This is however no more than a security consideration. Steve Bellovin made a proposal concerning Bloom filters, however there was only one response and it appears to be somewhat late in the game to start a completely new track (as Steve himself suggests might be the case). Jaap asked for some hard numbers that demonstrate the need for opt-in. It has been demonstrated that without OPT-IN the data volumes would increase by a significant factor (10). It is simply naive to believe that such a change would be accomodated by any operator of a critical infrastructure unless there was an overwhelming justification. Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: ted@tednet.nl [mailto:ted@tednet.nl] > Sent: Thursday, January 10, 2002 4:50 AM > To: Randy Bush; Olafur Gudmundsson > Cc: namedroppers > Subject: Re: DS and Opt-in - a proposal > > > [Quoting Randy Bush, on Jan 9, 8:41, in "Re: DS and Opt-in - ..."] > > > o there seems to be a very clear consensus for DS. in > fact, there were > > no negative technical comments. > > Agree. > > > o there does not seem to be a consensus for Opt-In. there was > > considerable discussion pro and con, with technical > considerations > > in both directions. > > > > if someone has NEW technical arguments to present for or > against either > > proposal, please do so now. N_E_W arguments. > > N_E_W arguments, at least new technical arguments, are probably > difficult to produce, I think they have been beaten to death > and are pretty clear for most of us. > > What has not been discussed enough, IMHO, is what we want to > accomplish with DNSSEC, and once we answer that question, the > technical arguments about Opt-In fall into place easily. > > I'll try to take a shot at it. I see four paths to go forward: > > 1. Forget DNSSEC in its current shape. > 2. Strive for full implementation, i.e. the goal is to get > most of the DNS tree secured over time. > 3. Go for course grain security, i.e. some or more large secureds > branches side by side with large unsecured branches, and > divided by clearly defined borders. > 4. Go for fine grain security, i.e. some or more secured RRs within > a further unsecured DNS-tree. > > ad 1. This will happen when we do not go forward, it's the > easy way :-) > > ad 2. This is not realistic to expect to happen soon. > > ad 3. Course grain security will lead to secured safehavens, > garded by the major DNS forwarders/cachers. Some users > may also check themselves, but many others will probably > just trust their ISPs DNS forwarders/cachers. This way, > it will be difficult for scriptkiddies to produce major > spoofs in the safehavens, which is a major gain. > > ad 4. Fine grain security makes it possible to have scattered > secured RRs, this is more easily implementaed than 3, and > it solves many problems for instance for the IPSEC people, > and may open some interesting business opportunities. > People who want these scattered secured RRs to be certified > will check them themselves, others will probably want an > answer (with possible outdated sig) more dearly than a > certified answer, so chances are big that most major DNS > forwarders/cachers will not bother checking the few > scattered secured RRs. > > Now, lets see how Opt-In fits in: > 1. Does not matter. > 2. Chances are slim we ever get here without Opt-In, chances > are virtually zero we get here when we start with Opt-In. > 3. Opt-In does not fit into this scheme. > 4. Opt-In makes this possible, but there are probably more > easy ways to accomplish the same (like an alternative PKI > outside DNS, or DNSSEC without auth. denial). > > -- ted > > > > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > ------_=_NextPart_000_01C19A3C.2075F080 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C19A3C.2075F080-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 10 20:58:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27641 for ; Thu, 10 Jan 2002 20:58:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OqqL-000ELj-00 for namedroppers-data@psg.com; Thu, 10 Jan 2002 17:50:53 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16OqqK-000ELd-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 17:50:52 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16OqqK-000NTa-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 17:50:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Message-Id: From: "¼ÛÁØÇõ" To: warlord@MIT.EDU Cc: sjosefsson@rsasecurity.com, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-song-dnsext-nai-support-00.txt Date: Fri, 11 Jan 2002 10:44:52 +0900 (KST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Please read below comment. ----------------------------------------------------- From: Derek Atkins Sent: 10 Jan 2002 20:04:37 -0500 To: "XXXXXX" Cc: sjosefsson@rsasecurity.com, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-song-dnsext-nai-support-00.txt "XXXXXX" writes: > Hi all, > > In 3GPP2 P.S0001-B, we are currently supporting the service call IRS > (Internet Reachability Service), which is using DNS "A Record" for > one to one mapping between mobile host IP address and NAI > (user.realm. format). Although NAI actually form of > user.specific_node.domain, there are still some possibility can > cause some confusion. I believe separately defining "NAI" as DNS > RR, helps clarify that problem. Why can't you just just the Home Address for this? Sure, the first packet will have to go through the home agent, but you just need to provide a service that says "Mobile Host A.B.C.D is currently located at Care-of Address W.X.Y.Z". (Above are not specific for Mobile IP, it is beneficial for PPP dial up service too.) > Speaking of IMPP, what defining NAI in DNS RR can do far more than > just instant message service. So can IMPP. The PP stands for "Precence Protocol". The hope is to have a general "user X is reachable via this list of protocols" where each list-entry is a URI defining a communication protocol, an address, and perhaps a "local name". For example, my reachability could be: im:warlord@mit.edu voice:+1.617.555.1212 fax:+1.617.555.1234 email:warlord@mit.edu The PP in IMPP is meant to go far beyond just IM. (Okay, I wasn't aware of that. In fact I found the some similiarty with ENUM) > User can be travelling from Asia to US, and could simply register > for updating NAI with temporaly IP address. It may work regardless > of access network (Wideband CDMA, CDMA2000, Bluetooth, and Wireless > LAN). It can provide always on user reachbility which is actually > user mobility. I don't believe that DNS is the right place to do this. You really want a local lookup service based on your home address. If you're moving a lot, in a MIPv6 world, you might be changing your care-of address ever few seconds (or maybe every minute). DNS just can't keep up with that level of data dynamics. (That is not likely happen in real world. Access Router (What we called Packet Data Serving Node) is sometimes covering the size of California.) > Unlike SIP which is very specific for VoIP, defining NAI as a DNS RR > can provide far much general way of user (Mobile Host) location > service. You are confused. SIP is not specific to voice. In fact, SIP happens to also be the leading IM protocol, too. (I may be, as fas as I know there is SIMPLE is only thing working on that.) > Eventually it may interwork with ENUM which will provide > interoperability between Internet and PSTN. And it is currently > under investigate. A worthy goal. Thanks JunHyuk > Thanks > JunHyuk -derek > Ben Clifford writes: > > > Perhaps you shouldn't use the root DNS name as the realm name? > > > > For example, > > warlord.student-realm.mit.edu > > or > > warlord.faculty-realm.mit.edu > > You are implying a separation where one does not exist. There _is_ > no "warlord@student-realm.mit.edu". > > My point was that "warlord@.mit.edu." would work but removing the > trailing '@' causes problems. Obviously there are other naming > tricks we could do (I believe you are suggesting that, but I disagree > with your example suggestion). I think a better suggestion would > be: > warlord._user.mit.edu. > > > If you are putting in symbols to separate out different kinds of object, I > > would think that the standard way to do it (x.subdomain.y.gov) would be > > the better way? > > No, because you have the same potential problem... If you ever have a > user name that matches a subdomain you get into trouble. The only way > to do it is to create a special subdomain (ala SRV records) that uses > a special name which you can pretty much guarantee will never exist. > > Never mind the fact that I'm not convinced the NAI record is something > that needs to happen. We already have IMPP; why do we need DNS to > give the same location information? IMPP is already designed to have > users register their precense (location) information. I'm not > convinced that DNS can provide the level of dynamic or duplicate > information that IMPP can provide. > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > > > > > > > Next Entertainment, LYCOS > =========================================================================== > Áñ°ÌÁö ¾ÊÀ¸¸é ÀÎÅͳÝÀÌ ¾Æ´Õ´Ï´Ù!! http://www.lycos.co.kr > 2002³â ÀÓ¿À³â! ¿ÃÇØ ³ªÀÇ ¿î¼¼´Â? - ¶óÀÌÄÚ½º ¿î¼¼(http://lucky.lycos.co.kr) > ¸»¶ìÇØ¿¡ ÀüÇÏ´Â ½Å³âÃàÇÏ ¸Þ½ÃÁö - ¶óÀÌÄÚ½º eÄ«µå(http://ecard.lycos.co.kr) -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Next Entertainment, LYCOS =========================================================================== Áñ°ÌÁö ¾ÊÀ¸¸é ÀÎÅͳÝÀÌ ¾Æ´Õ´Ï´Ù!! http://www.lycos.co.kr 2002³â ÀÓ¿À³â! ¿ÃÇØ ³ªÀÇ ¿î¼¼´Â? - ¶óÀÌÄÚ½º ¿î¼¼(http://lucky.lycos.co.kr) ¸»¶ìÇØ¿¡ ÀüÇÏ´Â ½Å³âÃàÇÏ ¸Þ½ÃÁö - ¶óÀÌÄÚ½º eÄ«µå(http://ecard.lycos.co.kr) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 10 21:26:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27917 for ; Thu, 10 Jan 2002 21:26:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OrEu-000F1W-00 for namedroppers-data@psg.com; Thu, 10 Jan 2002 18:16:16 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16OrEt-000F1Q-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 18:16:15 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16OrEt-000OBE-00 for namedroppers@ops.ietf.org; Thu, 10 Jan 2002 18:16:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200201110143.UAA18504@pacific-carrier-annex.mit.edu> In-Reply-To: <200201110143.UAA18504@pacific-carrier-annex.mit.edu> Message-ID: To: "XXXXXX" Cc: sjosefsson@rsasecurity.com, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-song-dnsext-nai-support-00.txt From: Derek Atkins Date: 10 Jan 2002 21:14:40 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Before I response, JunHyuk, I should let you know that your mailer is broken. Your local MUA/MTA is not assigning a unique Message-ID to your outgoing messages. The end result is that when you send a message both to the list and to me directly, it doesn't get filtered (because technically they are different messages). Could you take a look at your system and try to correct this? Thanks. Now, to respond... "XXXXXX" writes: > Why can't you just just the Home Address for this? Sure, the first > packet will have to go through the home agent, but you just need to > provide a service that says "Mobile Host A.B.C.D is currently located > at Care-of Address W.X.Y.Z". > > (Above are not specific for Mobile IP, it is beneficial for PPP dial > up service too.) Fair enough... But the IMPP-type solution as stated below will still solve the problem for PPP as well as Mobile-IP, and any other mobility solution. It would even work when we go to the IETF and use DHCP to get random addresses ;) > (Okay, I wasn't aware of that. In fact I found the some similiarty with ENUM) With all this similarity, why re-invent the wheel? > (That is not likely happen in real world. Access Router (What we > called Packet Data Serving Node) is sometimes covering the size of > California.) You don't know that this will always be the case. There are certainly some people who believe that each and every cell site might be its own ipv6 subnetwork, with layer-3 MIPv6 handoffs between each cell site. I think it's reasonable to assume rapid (and frequent) handoffs. If they don't happen, then maybe you've over-designed your system a bit. However, if you don't design your system for frequent, rapid handoffs and then you find that deployment is going to result in such a system, you now have an unusable solution. "'tis better to over-engineer now than re-engineer later." > > Unlike SIP which is very specific for VoIP, defining NAI as a DNS RR > > can provide far much general way of user (Mobile Host) location > > service. > > You are confused. SIP is not specific to voice. In fact, SIP happens > to also be the leading IM protocol, too. > > (I may be, as fas as I know there is SIMPLE is only thing working on that.) Well, yes... by definition! (SIMPLE is the group that is standardizing SIP for IMPP). My point was that SIP is usuable beyond VoIP. Besides, SIP was just an example. My point is that I think there are other (existing) solutions that solve the NAI "problem" in a way that is both more scalable, more secure, and more generic. Don't reinvent the wheel. :) -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 11 07:00:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13406 for ; Fri, 11 Jan 2002 07:00:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16P06j-000PjY-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 03:44:25 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16P06i-000PjR-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 03:44:24 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16P06i-000DM9-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 03:44:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201111051.g0BApw226099@open.nlnetlabs.nl> In-Reply-To: ""Hallam-Baker, Phillip"'s message as of Jan 11, 3:03" From: ted@tednet.nl (Ted Lindgreen) Date: Fri, 11 Jan 2002 11:51:58 +0100 To: namedroppers Subject: RE: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting "Hallam-Baker, Phillip", on Jan 11, 3:03, in "RE: DS and Opt-in - ..."] > I have yet to see a technical argument of any kind against Opt-in. Dear Phillip, I thought this was pretty clear, but apparently not, so I'll try to summarise. The technical arguments against Opt-in boil down to: It changes the protocol in such a manner that it becomes less, or even not at all, useful for the goal: "To make the DNS infrastructure less vulnerible" The technical arguments in favor of Opt-In boil down to: It extends the protocol such that superlarge zones can start implementing DNSSEC, while fully retaining its usefulness for the goal: "To implementing PKI facilities into DNS" My question, seeing these two different goals, was: What was the goal again? And I added with that question 2 remarks: 1. I thought one of the goals still was "To make the DNS infrastructure less vulnerible" 2. If I'm mistaken on 1, then we better rethink DNSSEC at all, because: 2a. DNSSEC makes a lousy PKI, there is not even a key revocation mechanisme. 2b. There are perhaps more appropriate infrastructures, for this, like LDAP, but also other. 2c. But if we misuse DNS anyway, Opt-In seems an overly complicated way, just allowing for no NXT records would be much simpler and with almost the same effect. I've seen a number of replies on my question, which make me believe that there are more people that think that "To make the DNS infrastructure less vulnerible" still is an important goal. Another question that was raised and referred to by you: - Olaf asked why full RFC2535 would be a problem for large or even superlarge zones. He referred to documented work (by NLnet Labs) that showed that: - signing zones with many tens of millions delegations is not a big techical challenge with the current of-the-shelf available hardware. - Dealing with ten times larger zonefiles appears not to be a big techical challenge with the current of-the-shelf available hardware. - Securing a delegation-only zone (like ,com) causes significantly less growth than a factor of ten. What I read as answer were handwaving arguments, like the size of Verisigns computerroom. I also read a request from Jaap for hard numbers. In your current mail I again see you answering that with only a handwaving argument. So, in conclusion, just two of the technical arguments: 1. There is no consensus, that reducing the usefulness of DNSSEC to just a PKI, is the right thing to do. 2. There is serious doubt, that Opt-In is really necessary for even the largest TLDs to join the RFC2535 party. Regards, -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 11 07:03:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13430 for ; Fri, 11 Jan 2002 07:03:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16P0I6-000Pyu-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 03:56:10 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16P0I5-000Pyo-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 03:56:09 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16P0I5-000Dez-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 03:56:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201111135.g0BBZvA26230@open.nlnetlabs.nl> In-Reply-To: "Ted Lindgreen's message as of Jan 11, 11:51" From: ted@tednet.nl (Ted Lindgreen) Date: Fri, 11 Jan 2002 12:35:57 +0100 To: namedroppers Subject: RE: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sorry, send it of to quickly, let me refrase the conclusion. [Quoting Ted Lindgreen, on Jan 11, 11:51, in "RE: DS and Opt-in - ..."] > [Quoting "Hallam-Baker, Phillip", on Jan 11, 3:03, in "RE: DS and Opt-in - ..."] > > > I have yet to see a technical argument of any kind against Opt-in. > > In conclusion, just five of the technical arguments I remember that have been raised: 1. There is no consensus, that reducing the usefullness of DNSSEC and ignore DNS's current vulneribilty, is the right thing to do. 2. DNSSEC+OptIn makes only a lousy PKI. 3. DNS is the wrong tool for the job. 4. DNSSEC+OptIn is a very complicated way to achieve something that can also be achieved in much simpler ways. 5. There is serious doubt, that Opt-In is actually necessary for even the largest TLDs to join the DNSSEC party. Regards, -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 11 07:34:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13636 for ; Fri, 11 Jan 2002 07:34:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16P0l2-0000hW-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 04:26:04 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16P0l1-0000hQ-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 04:26:03 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16P0l1-000ERu-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 04:26:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200201111135.g0BBZvA26230@open.nlnetlabs.nl> Message-Id: From: Randy Bush To: ted@tednet.nl (Ted Lindgreen) Cc: namedroppers Subject: RE: DS and Opt-in - a proposal Date: Fri, 11 Jan 2002 04:25:23 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 5. There is serious doubt, that Opt-In is actually necessary > for even the largest TLDs to join the DNSSEC party. for me personally, i.e. chair hat far off, this is the big missing piece of the puzzle to me. given it would seem to be the main motivation for opt-in, that it is not described and quantified may be why folk are not jumping on the bandwagon. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 11 08:16:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14116 for ; Fri, 11 Jan 2002 08:16:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16P1Lw-0001VI-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 05:04:12 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16P1Lv-0001VB-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 05:04:11 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16P1Lv-000FQY-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 05:04:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4058698F1@vhqpostal.verisign.com> Message-ID: Date: Fri, 11 Jan 2002 14:03:19 +0100 (MET) From: Jakob Schlyter To: "Hallam-Baker, Phillip" Cc: "'ted@tednet.nl'" , Randy Bush , Olafur Gudmundsson , namedroppers Subject: RE: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 10 Jan 2002, Hallam-Baker, Phillip wrote: > Jaap asked for some hard numbers that demonstrate the need for opt-in. but has not been presented any. none. please provide us with facts why you cannot sign and serve the gtlds you are operating if opt-in is not deployed. jakob to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 11 17:06:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01372 for ; Fri, 11 Jan 2002 17:06:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16P9aA-000Dbr-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 13:51:26 -0800 Received: from [208.46.199.50] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16P9aA-000Dbj-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:51:26 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16P9a9-00008L-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:51:25 -0800 In-Reply-To: <200201111135.g0BBZvA26230@open.nlnetlabs.nl> Message-ID: <20020111154503.W49608-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 11 Jan 2002 16:42:44 +0100 (CET) From: Roy Arends To: Ted Lindgreen Cc: namedroppers Subject: RE: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 11 Jan 2002, Ted Lindgreen wrote: > In conclusion, just five of the technical arguments I remember > that have been raised: > > 1. There is no consensus, that reducing the usefullness of DNSSEC > and ignore DNS's current vulneribilty, is the right thing to do. That is FUD, not a technical arguement. > 2. DNSSEC+OptIn makes only a lousy PKI. DNSSEC - OptIn makes a lousy PKI. OptIn is the redundant word here. > 3. DNS is the wrong tool for the job. Tool ? For what job ? Is this still about the PKI stuff ? > 4. DNSSEC+OptIn is a very complicated way to achieve something > that can also be achieved in much simpler ways. Very very very vague. > 5. There is serious doubt, that Opt-In is actually necessary > for even the largest TLDs to join the DNSSEC party. Ah, finally, we have an arguement here. Your questioning the motivation for opt-in, not really a technical arguement for or against opt-in. No-one in their right mind will dispute that a opt-in com zone is significantly smaller then an 2535 com zone. Significantly smaller in the sense that from rollout, the opt-in com zone is practically the same size as the plain com/net/org zone. It (opt-in) allows the zone to grow in scalable, manageble ways. There is serious effort been put into stopping opt-in from happening. Some tried to get the FUD out, but it keeps entering the picture, even to the rediculous first 4 points above. To me it is worrying that a WG-Chair bases "no-consensus" on the mere fact that a few people question the motives behind opt-in (while they are very clear) rather then stating technical arguements against opt-in. Now, I don't work for Verisign, so I don't have, nor am interested in such numbers, but they can probably be produced. Roy Arends to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 11 17:06:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01384 for ; Fri, 11 Jan 2002 17:06:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16P9ad-000DdG-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 13:51:55 -0800 Received: from [208.46.199.50] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16P9ad-000DdA-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:51:55 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16P9ab-00008X-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:51:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from Randy Bush of "Fri, 11 Jan 2002 04:25:23 PST." Message-Id: <20020111160906.B123C28EF0@as.vix.com> From: Paul Vixie To: namedroppers Subject: Re: DS and Opt-in - a proposal Date: Fri, 11 Jan 2002 08:09:06 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > 5. There is serious doubt, that Opt-In is actually necessary > > for even the largest TLDs to join the DNSSEC party. > > for me personally, i.e. chair hat far off, this is the big missing > piece of the puzzle to me. given it would seem to be the main > motivation for opt-in, that it is not described and quantified may > be why folk are not jumping on the bandwagon. i stepped into the bandwagon once i realized that DS had to happen in a non-backward-compatible way. opt-in is actually the cleaner and more elegant way to do dnssec, but i would not have supported putting it in unless i'd already swallowed the DS poison. i won't argue from "necessity" since i consider even COM to be servable without opt-in. (and i don't think COM's publisher could prove otherwise, so there!) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 11 17:06:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01396 for ; Fri, 11 Jan 2002 17:06:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16P9am-000DdR-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 13:52:04 -0800 Received: from [208.46.199.50] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16P9al-000DdL-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:52:03 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16P9ak-00008b-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:52:02 -0800 Message-ID: <20020111165804.GA9911@slam.admin.cto.netsol.com> References: <200201111135.g0BBZvA26230@open.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201111135.g0BBZvA26230@open.nlnetlabs.nl> Date: Fri, 11 Jan 2002 11:58:04 -0500 From: Mark Kosters To: Ted Lindgreen Cc: namedroppers Subject: Re: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Jan 11, 2002 at 12:35:57PM +0100, Ted Lindgreen wrote: > 4. DNSSEC+OptIn is a very complicated way to achieve something > that can also be achieved in much simpler ways. Please present the better way. I personally think opt-in is a pretty simple way to incrementally adopt dnssec in large zones. It grows as demand (people who have signed their zones) warrants. > 5. There is serious doubt, that Opt-In is actually necessary > for even the largest TLDs to join the DNSSEC party. The main issue is serving up the zones. With DNSSEC, memory footprint and zone file contents jump an order of magnitude. So, if we support 2535 this puts us uncomfortably close to the edge of what is available now and the near future for boxes stuffed with large amounts of memory. Based on past growth rates, we would outpace Moores law. Also propagation in a timely manner is a problem in sites that are far-flung. * Of course, one can engineer around these things by partitioning, internal query routing, etc. But, as one of the providers of critical infrastructure, we like to keep the zone serving issue as simple as possible (Murphy's law applies here). Opt-in allows us to do that and we like to serve it up as soon as possible. The primary purpose Opt-in solves is the problem of redundant crypto (signing unsecured delegations that is overridden by the child). Notwithstanding the Moore's Law issue, if we keep 2535 type of info in the parent zones, this gets to be a large overhead for very marginal benefit. Especially when it is unclear how many delegations desire to be actually secured, this gets to be a very expensive endeavour. I don't see those rationale behind those who think that 100% of the dns tree needs to be secured and feel compelled to force them to be that way. I see that very few (but important) domains will actually serve up dnssec zones. And this will go up slowly over a long period of time given demand from customers has not yet really started given the api needs to be fleshed out more so the clients can see that the answer was performed over a secure resolution path. Since we are doing this non-backwards compatible thing with DS (which I understand is much more expensive on the resolver than opt-in), why not add in opt-in too? It does not hurt the security model and it helps us and every other large zone maintainer get this out the door. Regards, Mark * We had a similar thing a number of years ago on the routing side dealing with the advertisement explosion that resulted in rfc 2050 that helped deal with memory footprint and convergence. -- Mark Kosters markk@netsol.com 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. From owner-namedroppers@ops.ietf.org Fri Jan 11 17:07:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01436 for ; Fri, 11 Jan 2002 17:07:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16P9ZX-000DbC-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 13:50:47 -0800 Received: from [208.46.199.50] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16P9ZX-000Db6-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:50:47 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16P9ZV-000083-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:50:45 -0800 References: <200201111135.g0BBZvA26230@open.nlnetlabs.nl> In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Randy Bush Cc: ted@tednet.nl (Ted Lindgreen), namedroppers Subject: Re: DS and Opt-in - a proposal From: Derek Atkins Date: 11 Jan 2002 09:52:19 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk in Salt-Lake, in the after-dnsext DNSSec meeting, I specifically asked the Verisign group (I'm sorry, I don't remember who you were specifically) to get me a few numbers: size of .COM zone size of .COM zone with 2535 size of .COM zone with DS size of .COM zone with Opt-In size of .COM zone with DS+Opt-In I believe that we were assuming a 1% "interest" in DNSSec (1% of the children supply keys). It's now mid-January and I haven't heard back from Verisign. Until I do, my personal belief is that Opt-In is "assertion-ware" and should be ignored. -derek Randy Bush writes: > > 5. There is serious doubt, that Opt-In is actually necessary > > for even the largest TLDs to join the DNSSEC party. > > for me personally, i.e. chair hat far off, this is the big missing > piece of the puzzle to me. given it would seem to be the main > motivation for opt-in, that it is not described and quantified may > be why folk are not jumping on the bandwagon. > > randy > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 11 17:11:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01546 for ; Fri, 11 Jan 2002 17:11:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16P9Zq-000DbV-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 13:51:06 -0800 Received: from [208.46.199.50] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16P9Zp-000DbP-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:51:05 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16P9Zo-00008B-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:51:04 -0800 In-Reply-To: <200201111051.g0BApw226099@open.nlnetlabs.nl> References: <200201111051.g0BApw226099@open.nlnetlabs.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1010761827.9589.0.camel@error-messages.mit.edu> Mime-Version: 1.0 Subject: RE: DS and Opt-in - a proposal From: Greg Hudson To: Ted Lindgreen Cc: namedroppers Date: 11 Jan 2002 10:10:27 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2002-01-11 at 05:51, Ted Lindgreen wrote: > The technical arguments against Opt-in boil down to: > > It changes the protocol in such a manner that it becomes > less, or even not at all, useful for the goal: > > "To make the DNS infrastructure less vulnerible" I can't help but believe that people are confused about the ramifications of opt-in. As I understand the situation, with straight rfc2535, if Verisign wants to charge extra to sign people's KEY records, they can. Verisign would be forced to sign everyone's NS records (or no one's), but without a KEY record that doesn't provide very much additional protection. So, lack of opt-in does not particularly damage the goal of protecting the DNS infrastructure at the .com level. There is some danger that people in leaf zones will find it more convenient to use opt-in than sign their own zones, but I am not convinced this is a significant danger. Even if your argument made sense, your wording would be going overboard. Since opt-in is a domain holder's choice, it cannot make DNSSEC "less useful" for the stated goal, though it could conceivably make it "less likely to achieve" the goal. The rest of my message is tangential; Ted made some other statements I disagree with, but they don't relate to my argument above. As much as I think DNSSEC holds potential as a PKI, I do definitely believe that "to protect the DNS infrastructure" is its primary goal. > 2a. DNSSEC makes a lousy PKI, there is not even a > key revocation mechanisme. Quite the contrary. Because DNSSEC is an online system, you can make signatures expire quickly, and people can easily fetch new signatures when expiry happens. That's a big improvement over the web browser PKI we live with today, where certificates have to last a long time (on the order of months), and the revocation features are ignored. > 2b. There are perhaps more appropriate infrastructures, > for this, like LDAP, but also other. LDAP is a protocol. It is not, at the current time, a global infrastructure. It may be more appropriate as a protocol, but it simply isn't there to do the job in the important capacity. (To be fair, DNSSEC isn't there as a global infrastructure either, but it's somewhat more likely to get there than LDAP is.) > 2c. But if we misuse DNS anyway, Opt-In seems an overly > complicated way, just allowing for no NXT records > would be much simpler and with almost the same effect. No, that would be completely inadequate. DNSSEC with opt-in allows authenticated denial of signed records in an opt-in zone. If we simply allowed .com to have no NXT records, then anyone could spoof a response to a .com query saying that amazon.com has no KEY record, even if it does have one. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 11 17:11:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01558 for ; Fri, 11 Jan 2002 17:11:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16P9bG-000Ddw-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 13:52:34 -0800 Received: from [208.46.199.50] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16P9bG-000Ddq-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:52:34 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16P9bE-00008j-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:52:32 -0800 Message-ID: <20020111220953.A18701@pasta.cs.uit.no> References: <5.1.0.14.0.20020111122620.03421008@imap2.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.0.20020111122620.03421008@imap2.es.net>; from fink@es.net on Fri, Jan 11, 2002 at 12:32:34PM -0800 Date: Fri, 11 Jan 2002 22:09:53 +0100 From: Feico Dillema To: namedroppers@ops.ietf.org, NGtrans List , Keith Moore Cc: Bob Fink Subject: Re: (ngtrans) review of 6to4-DNS Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Jan 11, 2002 at 12:32:34PM -0800, Bob Fink wrote: > In mid-November Randy forwarded a request from ngtrans for DNSEXT to review > the 6to4-DNS draft: > > > there is any feedback from this group that you can give, either to the > author or ngtrans. Just a minor note; I've implemented the proposed method from section: ``3.1 6to4 NS records derived from IPv4 NS records'', in the DNS proxy (DNSALG) totd. See: http://www.vermicelli.pasta.cs.uit.no/ipv6/software.html It has not been tested a lot, and I have gotten no feedback from the totd user community (neither positive or negative) on this functionality. So, if you try it in your assessment of the draft, please let me know if it works according expectation too. Feico. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 11 17:12:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01618 for ; Fri, 11 Jan 2002 17:12:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16P9ZF-000DZf-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 13:50:29 -0800 Received: from [208.46.199.50] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16P9ZD-000DZZ-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:50:27 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16P9Z9-00007u-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:50:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <200201111051.g0BApw226099@open.nlnetlabs.nl> Message-ID: <20020111154046.X49608-100000@node10c4d.a2000.nl> Date: Fri, 11 Jan 2002 15:44:56 +0100 (CET) From: Roy Arends To: Ted Lindgreen Cc: namedroppers Subject: RE: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ted, I think your reply reveals a general misunderstanding. What can be done with opt-in, i.e. have specific unsecured names (not single RRsets mind you) in a zone, can also be done with 2535: I simply delegate the unsecured name away. I.E. A zone is merely a practical term for part of a domain that has been delegated to you minus that what you have delegated away. So, in general we're talking about names. With 2535, a choice can be made for each individual name if it is signed or not. With opt-in this is done in a more efficient way. Again, the ONLY thing (yes the only, and I have yet to see somebody disputing that) is that opt-in gives up: authenticated [denial of] UNSIGNED nodes. i.e. if it is not signed, it is not secure............ If anyone feels uncomfortable with that, sign the zone 2535-style. This is _not_ the same as "just give up authenticated denial at all". Not even close. Roy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 11 17:13:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01653 for ; Fri, 11 Jan 2002 17:13:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16P9at-000Ddg-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 13:52:11 -0800 Received: from [208.46.199.50] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16P9at-000Dda-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:52:11 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16P9as-00008f-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 13:52:10 -0800 Message-Id: <5.1.0.14.0.20020111122620.03421008@imap2.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Fri, 11 Jan 2002 12:32:34 -0800 To: namedroppers@ops.ietf.org From: Bob Fink Subject: review of 6to4-DNS Cc: NGtrans List , Keith Moore Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In mid-November Randy forwarded a request from ngtrans for DNSEXT to review the 6to4-DNS draft: Abstract from the draft "This memo discusses several potential mechanisms for locating the DNS servers which provide "reverse lookup" of 6to4 addresses. Please note that this is a preliminary draft which only attempts to outline possible means of solving the problem, for purpose of discussion. This version of the proposal is NOT rigorously specified, and the author claims significant expertise in neither DNS nor anycast. Nevertheless, it is hoped that these proposals are sufficiently detailed to allow reviewers to make a first-order assessment of their viability. The assistance of appropriate experts in drafting future revisions of these proposals would be most welcome. " I have not seen any comments on this list and would like to again ask if there is any feedback from this group that you can give, either to the author or ngtrans. Thanks, Bob Fink ngtrans co-chair to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 01:39:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09214 for ; Sat, 12 Jan 2002 01:39:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PHhw-0000K9-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 22:32:00 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PHhw-0000K3-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 22:32:00 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PHhw-000Hd9-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 22:32:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20020111154503.W49608-100000@node10c4d.a2000.nl> In-Reply-To: <20020111154503.W49608-100000@node10c4d.a2000.nl> Message-ID: To: Roy Arends Cc: Ted Lindgreen , namedroppers Subject: Re: DS and Opt-in - a proposal From: Derek Atkins Date: 11 Jan 2002 17:24:07 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends writes: > No-one in their right mind will dispute that a opt-in com zone is > significantly smaller then an 2535 com zone. Significantly smaller in the > sense that from rollout, the opt-in com zone is practically the same size > as the plain com/net/org zone. It (opt-in) allows the zone to grow in > scalable, manageble ways. Why doesn't DS alone provide for this? If a child is not secured, then the parent would have no DS/SIG{DS} records. As more children request secured delegations, their DS/SIG{DS} records get added to the parent. > Now, I don't work for Verisign, so I don't have, nor am interested in such > numbers, but they can probably be produced. One would think so, but they haven't been. From where I sit, looking at the prospects of DS, the only place that Opt-In would appear to be useful is in the tld zones. Considering the few number of tlds, I'd like to see proof that Opt-In is necessary. By proof I don't want just a comparrison to 2535 -- the WG has already agreed that DS is the way to go. I'd like to see a comparrison of Opt-In against 2535+DS! Nobody has yet done that. I believe that DS is sufficient to solve the scaling problems, and still provides the secure delegation to non-secure zones (and secured non-existance of all zones). > Roy Arends -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 01:39:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09225 for ; Sat, 12 Jan 2002 01:39:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PHcX-0000AZ-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 22:26:25 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PHcX-0000AT-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 22:26:25 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PHcX-000HTS-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 22:26:25 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698F4@vhqpostal.verisign.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C19AED.3DA86FA0" From: "Hallam-Baker, Phillip" To: "'ted@tednet.nl'" , namedroppers Subject: RE: DS and Opt-in - a proposal Date: Fri, 11 Jan 2002 14:13:47 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C19AED.3DA86FA0 Content-Type: text/plain; charset="iso-8859-1" > In conclusion, just five of the technical arguments I remember > that have been raised: > > 1. There is no consensus, that reducing the usefullness of DNSSEC > and ignore DNS's current vulneribilty, is the right thing to do. > 2. DNSSEC+OptIn makes only a lousy PKI. > 3. DNS is the wrong tool for the job. > 4. DNSSEC+OptIn is a very complicated way to achieve something > that can also be achieved in much simpler ways. Arguments 1-4 are based on a false assumption that calls into question the authros understanding of what OPT-IN does and what a PKI is. 1. OPT-IN does nothing to reduce the utility of DNSSEC. OPT-IN is OPTIONAL, it only adds one extra feature that allows deployment in large zones at acceptable cost. 2. DNSSEC makes exactly as good or bad a PKI as DNSSEC + OPTIN 3. What job? And you accuse me of handwaving ??? 4. Specify how, again handwaving. > 5. There is serious doubt, that Opt-In is actually necessary > for even the largest TLDs to join the DNSSEC party. And the criteria for 'necessary' would be defined by whom? We have established that the cost of deployment is raised by an order of magnitude. The demands for further proof can only be made in bad faith. Providing a full answer to the question would require revealling 1) customer confidential information, 2) proprietary trade secrets and 3) be obsolete within a few months. An order of magnitude is an order of magnitude. If a feature optimises an expensive protocol by an order of magnitude a reasonable group will accept it. VeriSign would not have a Vice President, the Principal Scientist, and four research engineers arguing the case if the costs in question were small change. Phill ------_=_NextPart_000_01C19AED.3DA86FA0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C19AED.3DA86FA0-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 01:39:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09237 for ; Sat, 12 Jan 2002 01:39:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PHcL-0000AP-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 22:26:13 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PHcL-0000AJ-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 22:26:13 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PHcK-000HSu-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 22:26:12 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698F3@vhqpostal.verisign.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C19AED.35B474B0" From: "Hallam-Baker, Phillip" To: "'ted@tednet.nl'" , namedroppers Subject: RE: DS and Opt-in - a proposal Date: Fri, 11 Jan 2002 14:13:34 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C19AED.35B474B0 Content-Type: text/plain; charset="iso-8859-1" > I thought this was pretty clear, but apparently not, > so I'll try to summarise. > > The technical arguments against Opt-in boil down to: > > It changes the protocol in such a manner that it becomes > less, or even not at all, useful for the goal: > > "To make the DNS infrastructure less vulnerible" This is untrue. Nobody has identified any security threat that is controlled in 2535 that is not controlled with Opt-in. The record insertion risk is not realised as a threat because anyone can register names in the large domains. Sercurity is risk control, not risk elimination, the cost of implementation has to be justified in terms of improved security. Nobody has demonstrated that Opt-in reduces the ability to control threats. Nobody disputes that Opt-in significantly reduces costs. > The technical arguments in favor of Opt-In boil down to: > > It extends the protocol such that superlarge zones > can start implementing DNSSEC, while fully retaining > its usefulness for the goal: > > "To implementing PKI facilities into DNS" That is not an issue. DNSSEC is not architected as a PKI and OPT-in is not intended to support PKI type facilities. The only connection between PKI and opt-in is that the original concept grew out of discussions between well known PKI experts and DNS experts. While DNSSEC may be used for 'opportunistic encryption' for end entity applications and is likely to become the key distribution infrastructure that allows IPSEC to move beyond VPS and justify its first initial, DNSSEC is not a PKI, adding OPT-IN to DNSSEC does not make it any more or less of a PKI. > My question, seeing these two different goals, was: > > What was the goal again? Good question to ask since it appears that you are confused. The purpose of Opt-in is to enable deployment of DNSSEC in the large zones. It has no other purpose that is not part of the overall purpose of DNSSEC. > Another question that was raised and referred to by you: > - Olaf asked why full RFC2535 would be a problem for large or > even superlarge zones. He referred to documented work (by > NLnet Labs) that showed that: > - signing zones with many tens of millions delegations is not > a big techical challenge with the current of-the-shelf > available hardware. He may have asserted that, he did not demonstrate it. Nobody is disputing the increase in the data volume, that is the major killer. The capabilities of 'commercial off the shelf' cryptographic hardware are significantly reduced when you have to use FIPS-140/3 certified devices and manage the private keys to a high standard. > - Dealing with ten times larger zonefiles appears not to be > a big techical challenge with the current of-the-shelf > available hardware. If you believe that any production manager is going to accept responsibility for deployment of a technology that has such a dramatic effect on a critical infrastructure it is unlikely that any amount of reason is going to disabuse you of the notion. The primary contractual obligation of VeriSign to ICANN is to maintain the reliability of the DNS system. Deployment of a security specification that unnecessarily compromises that reliability just is not going to happen. > What I read as answer were handwaving arguments, like the size of > Verisigns computerroom. I also read a request from Jaap for hard > numbers. In your current mail I again see you answering that > with only a handwaving argument. The hard numbers of significance here are 30 million domain names and 85% of Internet users. Nobody is disputing that OPT-IN significantly reduces the cost of deploying DNSSEC. The only dispute is the degree to which the cost is reduced. We have by your own admission agreed that is is an order of magnitude. Case closed, discussion over. > So, in conclusion, just two of the technical arguments: > > 1. There is no consensus, that reducing the usefulness of > DNSSEC to just a PKI, is the right thing to do. An entirely irrelevant argument since OPT-IN has nothing to do with 'PKI'. > 2. There is serious doubt, that Opt-In is really necessary > for even the largest TLDs to join the RFC2535 party. This is disingenuous. What you really mean is that you want to engineer a situation in which you can either force VeriSign to spend a huge amount of money or accuse VeriSign of bad faith, either because VeriSign does not deploy DNSSEC or because VeriSign does not deploy a standard version of DNSSEC or adopts some other security measure. Such games may have weight inside this group. However they will have very little weight in the IESG or the IETF at large and absolutely none outside the IETF. The consensus amongst the operators of large domains is that OPT in is essential if DNSSEC is to be deployed. The consensus amongst the group is that OPT-IN does no harm to the objectives or the implementation of DNSSEC. The only dispute is over the issue of whether the group should adopt a change to the specification to accomodate the operators of large domains. Phill ------_=_NextPart_000_01C19AED.35B474B0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C19AED.35B474B0-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 01:39:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09248 for ; Sat, 12 Jan 2002 01:39:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PHiB-0000KL-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 22:32:15 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PHiB-0000KF-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 22:32:15 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PHiB-000Hdc-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 22:32:15 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698F6@vhqpostal.verisign.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C19AEF.3D53AE00" From: "Hallam-Baker, Phillip" To: "'Greg Hudson'" , Ted Lindgreen Cc: namedroppers Subject: RE: DS and Opt-in - a proposal Date: Fri, 11 Jan 2002 14:28:05 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C19AEF.3D53AE00 Content-Type: text/plain; charset="iso-8859-1" Greg raises some important issues about PKI architectures. The essential point is that whatever you do to DNSSEC it is not going to make a good client interface to PKI, however it may be part of the infrastructure that a PKI interface accesses to deliver validated private keys to applications. I have no dispute with the concept of using DNS and DNSSEC as part of a trust infrastructure. I do dispute the notion that welding DNSSEC calls into applications is a good plan. There is a lot of PKI about, there are millions of certificates, PGP keys and DNSSEC will hopefully add millions more keys which are usefull for 'some' purpose. What that purpose is is going to require local configuration at the site level. Here a site may be a division of an F500 company or a consumer with a lot of geeky gadgets that she is not even aware do PKI very often. That is the purpose of the XKMS specification which allows lightweight application clients to interogate a trust service to obtain keys. The idea that OPT-IN somehow turns DNSSEC into XKMs is not just untrue, it is completely wierd. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Greg Hudson [mailto:ghudson@MIT.EDU] > Sent: Friday, January 11, 2002 10:10 AM > To: Ted Lindgreen > Cc: namedroppers > Subject: RE: DS and Opt-in - a proposal > > > On Fri, 2002-01-11 at 05:51, Ted Lindgreen wrote: > > The technical arguments against Opt-in boil down to: > > > > It changes the protocol in such a manner that it becomes > > less, or even not at all, useful for the goal: > > > > "To make the DNS infrastructure less vulnerible" > > I can't help but believe that people are confused about the > ramifications of opt-in. > > As I understand the situation, with straight rfc2535, if > Verisign wants > to charge extra to sign people's KEY records, they can. > Verisign would > be forced to sign everyone's NS records (or no one's), but > without a KEY > record that doesn't provide very much additional protection. > > So, lack of opt-in does not particularly damage the goal of protecting > the DNS infrastructure at the .com level. There is some danger that > people in leaf zones will find it more convenient to use opt-in than > sign their own zones, but I am not convinced this is a significant > danger. > > Even if your argument made sense, your wording would be going > overboard. Since opt-in is a domain holder's choice, it cannot make > DNSSEC "less useful" for the stated goal, though it could conceivably > make it "less likely to achieve" the goal. > > The rest of my message is tangential; Ted made some other statements I > disagree with, but they don't relate to my argument above. > As much as I > think DNSSEC holds potential as a PKI, I do definitely > believe that "to > protect the DNS infrastructure" is its primary goal. > > > 2a. DNSSEC makes a lousy PKI, there is not even a > > key revocation mechanisme. > > Quite the contrary. Because DNSSEC is an online system, you can make > signatures expire quickly, and people can easily fetch new signatures > when expiry happens. That's a big improvement over the web > browser PKI > we live with today, where certificates have to last a long > time (on the > order of months), and the revocation features are ignored. > > > 2b. There are perhaps more appropriate infrastructures, > > for this, like LDAP, but also other. > > LDAP is a protocol. It is not, at the current time, a global > infrastructure. It may be more appropriate as a protocol, > but it simply > isn't there to do the job in the important capacity. > > (To be fair, DNSSEC isn't there as a global infrastructure either, but > it's somewhat more likely to get there than LDAP is.) > > > 2c. But if we misuse DNS anyway, Opt-In seems an overly > > complicated way, just allowing for no NXT records > > would be much simpler and with almost the same effect. > > No, that would be completely inadequate. DNSSEC with opt-in allows > authenticated denial of signed records in an opt-in zone. If > we simply > allowed .com to have no NXT records, then anyone could spoof > a response > to a .com query saying that amazon.com has no KEY record, even if it > does have one. > > > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > ------_=_NextPart_000_01C19AEF.3D53AE00 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C19AEF.3D53AE00-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 01:50:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09379 for ; Sat, 12 Jan 2002 01:50:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PHs4-0000gS-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 22:42:28 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PHs4-0000gL-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 22:42:28 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PHs4-000Hvk-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 22:42:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020112001849.B18571@outpost.ds9a.nl> References: <200201111135.g0BBZvA26230@open.nlnetlabs.nl> <20020111154503.W49608-100000@node10c4d.a2000.nl> In-Reply-To: <20020111154503.W49608-100000@node10c4d.a2000.nl>; from Roy.Arends@nominum.com on Fri, Jan 11, 2002 at 04:42:44PM +0100 Date: Sat, 12 Jan 2002 00:18:49 +0100 From: bert hubert To: Roy Arends Cc: Ted Lindgreen , namedroppers Subject: Opt-in generates implementation pull Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, Jan 11, 2002 at 04:42:44PM +0100, Roy Arends wrote: > > 5. There is serious doubt, that Opt-In is actually necessary > > for even the largest TLDs to join the DNSSEC party. > > Ah, finally, we have an arguement here. Your questioning the motivation > for opt-in, not really a technical arguement for or against opt-in. Mounting my hobby horse again, this is actually a good thing. It creates a business pull for dnssec implementation, which complements our technology push. Yes, a fully signed zone with secure denial of non-secured delegated zones is technically a good thing. However, it requires a big investment that does not scale well with the amount of secured delegations - there is a huge up-front cost. This does not make business sense. Businesses like to see costs that rise with increasing customer base, where those costs rise with a lower exponent than the income generated - at which point it is beneficial for them to grow. Opt-in makes this possible. For an initially modest investment, a new service can be launched: the secure delegation. > There is serious effort been put into stopping opt-in from happening. Some > tried to get the FUD out, but it keeps entering the picture, even to the > rediculous first 4 points above. >From Ted's standpoint, I understand where he is coming from. Opt-in does not generate benefits for everybody. It is technically far inferiour to 2535. Sadly you could call this the VHS effect. Inferior technology that makes better business sense always wins out over superior technology that represents a shoddy business case. 2535 is betamax. > Now, I don't work for Verisign, so I don't have, nor am interested in such > numbers, but they can probably be produced. Everybody should feel interested. A registry that implements opt-in enables its registrars to sensibly offer secure delegations, which will generate an implementation pull, leading to a safer internet. DNSSEC will *not* happen because it makes geeks' hearts flutter, including mine. Even though I used to have Betamax. Regards, bert hubert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk Netherlabs BV / Rent-a-Nerd.nl - Nerd Available - Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 01:52:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09392 for ; Sat, 12 Jan 2002 01:52:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PHsM-0000hj-00 for namedroppers-data@psg.com; Fri, 11 Jan 2002 22:42:46 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PHsM-0000hd-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 22:42:46 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PHsM-000HwG-00 for namedroppers@ops.ietf.org; Fri, 11 Jan 2002 22:42:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <1010761827.9589.0.camel@error-messages.mit.edu> Message-ID: Date: Fri, 11 Jan 2002 15:36:11 -0800 (PST) From: Brian Wellington To: Greg Hudson cc: Ted Lindgreen , namedroppers Subject: RE: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 11 Jan 2002, Greg Hudson wrote: > On Fri, 2002-01-11 at 05:51, Ted Lindgreen wrote: > > The technical arguments against Opt-in boil down to: > > > > It changes the protocol in such a manner that it becomes > > less, or even not at all, useful for the goal: > > > > "To make the DNS infrastructure less vulnerible" > > I can't help but believe that people are confused about the > ramifications of opt-in. > > As I understand the situation, with straight rfc2535, if Verisign wants > to charge extra to sign people's KEY records, they can. Verisign would > be forced to sign everyone's NS records (or no one's), but without a KEY > record that doesn't provide very much additional protection. NS records are never signed in the parent. With or without opt-in, Verisign can implement different pricing structures. The main difference is that without opt-in, the size of .com is inversely proportional to the percentage signed, which doesn't work too well for them if only a small percentage is signed. (Staying out of the flame war, just staing facts...) Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 08:30:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20356 for ; Sat, 12 Jan 2002 08:30:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PO0t-000BHA-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 05:15:59 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PO0s-000BH4-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 05:15:58 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PO0s-0003hV-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 05:15:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020111232924.A24826@pianosa.catch22.org> References: <5.1.0.14.0.20020111122620.03421008@imap2.es.net> In-Reply-To: <5.1.0.14.0.20020111122620.03421008@imap2.es.net>; from fink@es.net on Fri, Jan 11, 2002 at 12:32:34PM -0800 Date: Fri, 11 Jan 2002 23:29:24 -0800 From: David Terrell To: Bob Fink Cc: namedroppers@ops.ietf.org, NGtrans List , Keith Moore Subject: Re: (ngtrans) review of 6to4-DNS Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, Jan 11, 2002 at 12:32:34PM -0800, Bob Fink wrote: > In mid-November Randy forwarded a request from ngtrans for DNSEXT to review > the 6to4-DNS draft: > > > > Abstract from the draft > > "This memo discusses several potential mechanisms for locating the DNS > servers which provide "reverse lookup" of 6to4 addresses. > > Please note that this is a preliminary draft which only attempts to outline > possible means of solving the problem, for purpose of discussion. This > version of the proposal is NOT rigorously specified, and the author claims > significant expertise in neither DNS nor anycast. Nevertheless, it is hoped > that these proposals are sufficiently detailed to allow reviewers to make a > first-order assessment of their viability. > The assistance of appropriate experts in drafting future revisions of > these proposals would be most welcome. " > > I have not seen any comments on this list and would like to again ask if > there is any feedback from this group that you can give, either to the > author or ngtrans. I've implemented code that follows the alternative laid out in 3.2 (6to4 NS records inferred from 6to4 prefix). It's available at http://www.meat.net/~dbt/code/rev6to4/, implemented as a BIND 9 plugin. General commentary on the alternatives: 3.1) 6to4 NS records inferred from IPv4 NS records Advantages: Probably follows rfc2182/bcp16. Disavantages: For a site located behind a single IPv4 address possibly served by a fairly clueless ISP it could be hard to get them to set this up; nameservers only reachable over IPv4. 3.2) 6to4 NS records inferred from 6to4 prefix Advantage: reachable over ipv6, easy to set up for small to medium sized sites. Disadvantage: Only reachable within the site. Requires allocation of a magic SLA by IANA (:ffff:?) and special addresses within that network for this purpose. My gut feeling: The disadvantages of of 3.2 seem fairly minor. Walking the reverse DNS and potential negative caching from unreachable servers is far less of an rfc2182 problem than forward DNS -- i.e. reverse lookups are rarely important except when that site is clearly functional. Section 4 is more problematic. There's a much more dramatic tradeoff here depending on what method is chosen. There was some small discussion between the draft author and myself on this list as to where the actual creation of metarecords should be done. The options are: 1) Do it on the core side (i.e. authoritative servers for ip6.arpa). 2) do it at the edge (individual recursive or stub resolvers). The problem with this is that there is very little room for overlap. The edge recursive resolver can query the 2.0.0.2.ip6.arpa nameserver and generate metarecords in an NXDOMAIN case, OR the core server can return authoritative or metarecords depending on whether it has authoritative data. If the core server generates metarecords then there is no reason or chance for the edge server to. However, if the core server is already being queried for possible authoritative data then there's little reason not to implement the metarecord generation and remove the need to deploy specialized code at the edge, which also makes this a global change, instead of only effective at the ipv6 sites that implement these records. I'd also like to mention security concerns. It's probably a good idea to blackhole as many things as we can. Queries to e.2.0.0.2.ip6.int on a remote nameserver could end up causing multicast DOSes. Queries to a.0.2.0.0.2.ip6.int could result in unforseen security boundaries being crossed at sites that use RFC 1918 space for private resources. The list that exists in my code at the above referenced URL comes from the default list of null routes that KAME ships for the 2002:: zone. A magic name for 2002:c058:6301:: would make my traceroutes happen a lot faster. -- David Terrell | "Americans need to watch what they say, Prime Minister, Nebcorp | watch what they do, and this is not a dbt@meat.net | time for remarks like that; there never http://wwn.nebcorp.com/ | is." - Ari Fleischer, White House Press Secretary to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 08:44:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20486 for ; Sat, 12 Jan 2002 08:44:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16POK3-000Bmg-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 05:35:47 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16POK3-000BmT-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 05:35:47 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16POK2-0004DZ-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 05:35:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: <20020112103443.A49608-100000@node10c4d.a2000.nl> Date: Sat, 12 Jan 2002 11:32:18 +0100 (CET) From: Roy Arends To: Derek Atkins Cc: Roy Arends , namedroppers Subject: Re: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 11 Jan 2002, Derek Atkins wrote: > Roy Arends writes: > > > No-one in their right mind will dispute that a opt-in com zone is > > significantly smaller then an 2535 com zone. Significantly smaller in the > > sense that from rollout, the opt-in com zone is practically the same size > > as the plain com/net/org zone. It (opt-in) allows the zone to grow in > > scalable, manageble ways. > > Why doesn't DS alone provide for this? If a child is not secured, > then the parent would have no DS/SIG{DS} records. As more children > request secured delegations, their DS/SIG{DS} records get added to > the parent. Lets look at both. First a delegation with 2535+DS. In 2535+DS the extra statement is (marked by -> ) a.com. NXT b.com. NS DS SIG NXT a.com. SIG (NXT) b.com. NS somewhere -> b.com. NXT d.com. NS SIG NXT -> b.com. SIG (NXT) d.com. NS somehwere.... opt-in proposes to do it: -> a.com. NXT d.com. NS DS SIG a.com. SIG (NXT) b.com. NS somewhere d.com. NS somewhere.... (note the absence of the NXT bit in a.com NXT which states opt-in). DS obsoletes no-key and the accompanying SIG, but still has the NXT plus SIG(NXT) for every unsecured delegation. > > Now, I don't work for Verisign, so I don't have, nor am interested in such > > numbers, but they can probably be produced. > > One would think so, but they haven't been. From where I sit, looking > at the prospects of DS, the only place that Opt-In would appear to be > useful is in the tld zones. Considering the few number of tlds, I'd > like to see proof that Opt-In is necessary. > > By proof I don't want just a comparrison to 2535 -- the WG has already > agreed that DS is the way to go. I'd like to see a comparrison of > Opt-In against 2535+DS! Nobody has yet done that. I believe that DS > is sufficient to solve the scaling problems, and still provides the > secure delegation to non-secure zones (and secured non-existance of > all zones). Take 1000 domains, average of 2 NS records per delegation. One percent is secure. Lets leave the apex out for a sec. 1035: 2000 NS records 2535: 2000 NS 1000 KEY 1000 NXT 2000 SIG ------------ 6000 RRs DS: 2000 NS 10 DS 1000 NXT 1010 SIG ------------- 4020 RRs opt-in:2000 NS 10 DS 10 NXT 20 SIG ------------- 2040 RRs While the number of RR are trippled when comparing 2535 with opt-in, and doubled comparing DS with opt-in, these are only numbers of RR, not calculated is the size of the RR. It is fair to say that the size of a SIG is by far larger then the others. Also, this assumes only one signature per signed RRset. Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 08:44:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20497 for ; Sat, 12 Jan 2002 08:44:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16POJm-000Bls-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 05:35:30 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16POJm-000Blm-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 05:35:30 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16POJm-0004D6-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 05:35:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201120933.g0C9XMg35205@open.nlnetlabs.nl> In-Reply-To: "Derek Atkins's message as of Jan 12, 7:48" From: ted@tednet.nl (Ted Lindgreen) Date: Sat, 12 Jan 2002 10:33:22 +0100 To: namedroppers Subject: Re: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Derek Atkins, on Jan 12, 7:48, in "Re: DS and Opt-in - ..."] > By proof I don't want just a comparrison to 2535 -- the WG has already > agreed that DS is the way to go. I'd like to see a comparrison of > Opt-In against 2535+DS! Nobody has yet done that. .... Correct, that is because we don't heve a working DS implementation yet. The good news, however, is that it can easily be estimated from work that has been done, as the effect of DS is roughly equivalent to that of sig@child, which has been studied in detail. The short answer is that with a parsely secured zone, and 2545 the number of RRs more than double, with 2535+DS the number of RRs less than double, and with 2535+DS+OptIn it hardly grows. With a fully secured zone there is no difference. The long answer is: At NLnet Labs, we (in fact, Roy Arends and Miek Gieben) started in early 2000 to gain life experience with 2535 on TLDs by really signing actual .com, .de, and .nl zonefiles and playing real-life registry (with written permission from these registries, by the way). In very short: what was found, was that the expected problems with machine power were much less to non-existing, and a real problem was the adminstration and maintenance of (valid and signed) childs KEY RRs in the parent zonefiles. We have concentrated on the last problem, but both sig@child and later DS indeed have also a very benificial effect on zonefile size and needed signing power, as they obsolete the NULL-KEY. For some estimates (for hard figures, please ask Roy Arends or Miek Gieben): Let's look at a delegation-only TLD (like .nl and .com). Assume N delegations, and fraction X secured. Further assume on average 2 RRs per delegation and 1 glue RR per 2 NS RRs. When N is large, we can safely ignore the handfull of local RRs (SOA, etc). In the non-DNSSEC situation, we have about 3N RRs. In RFC-2535 we must add a KEY or NULL-KEY plus an NXT and both signed to each RR (Please note that neither NS nor glue get signed at the paret). This makes 7N RRs. So it more than doubles. In RFC-2535+DS there are no KEYs, there are only DS RRs for zones that continue to be secured (please note that all zonenames themselves remain secured). This makes (5 + 2X)N. With X=small this is 5N, i.e. less than double, with X=100% it becomes again 7N. RFC-2535+DS+OptIn, there are no NXTs for zones that are not secured (please note that these names themselves are not secured anymore because of OptIn). This makes (3+4X)N. With X=small this is 3N, with X=100% it becomes again 7N. REMARK 1: the above estimate is not valid for other zones than only- or mostly-delegation zones, there we find the often mentioned "order of magnitude" growth. REMARK 2: We (NLnet Labs) still think that the machine power needed to do either nothing, RFC 2535, RFC-2535+DS, or RFC-2535+DS+OptIn actually matters. The real problem is the administrative burden needed for secure childs at the registry, which is independend of Opt-In (but strongly influenced by DS). Regards, -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 08:50:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20541 for ; Sat, 12 Jan 2002 08:50:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16POQj-000Byq-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 05:42:41 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16POQj-000Byk-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 05:42:41 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16POQj-0004Oy-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 05:42:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201121319.g0CDJLv35761@open.nlnetlabs.nl> In-Reply-To: "Ted Lindgreen's message as of Jan 12, 10:33" From: ted@tednet.nl (Ted Lindgreen) Date: Sat, 12 Jan 2002 14:19:20 +0100 To: namedroppers Subject: Re: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Reading back my last message about the growth of zonefiles, I realize that I forgot that in vanilla RFC2535 the child-KEYs and their parental SIG can be exported away from the parent's zonefile when a child becomes secured. This leads to a decreasing zonefile as the secured fraction increases. Although it does not change much from the conclusion I've, just for fun, fixed the list. Remember: N = number of delegations and large X = fraction secured Delegation-only zonefile. Formula few secured half most secured No DNSSEC 3N - - - Vanilla (5+(1-X)2)N 7N 6N 5N DS (5+2X)N 5N 6N 7N OptIn+DS (3+4X)N 3N 5N 7N Anyway, I can't help being slightly amused to see people, who have survived several orders of magnitude growth during the past Internet hype, now being so exited about a mere variation around a factor of 2 when it comes to implement DNSSEC :-) -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 13:29:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22866 for ; Sat, 12 Jan 2002 13:29:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PShE-000Iw4-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 10:16:00 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PShE-000Ivx-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 10:16:00 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PShE-000BLN-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 10:16:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Randy Bush To: namedroppers Subject: Date: Sat, 12 Jan 2002 10:15:37 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit due to a disk full condition, the following messages did not make it to the namedroppers mailing list. my deepest apologies. i hope the senders kept a copies. randy --- [ times vvvvvvvv are gmt ] 2002-01-12 14:25:31 16PP6B-000DJA-00 <= ahu@outpost.powerdns.com H=outpost.ds9a.nl (outpost.powerdns.com) [213.244.168.210] P=esmtp S=1765 id=20020112152527.A30692@outpost.ds9a.nl 2002-01-12 14:45:27 16PPPT-000Dp2-00 <= moore@cs.utk.edu H=astro.cs.utk.edu [160.36.58.43] P=esmtp S=1499 id=200201121441.g0CEfKi27662@astro.cs.utk.edu 2002-01-12 16:15:57 16PQp2-000GAh-00 <= ted@open.nlnetlabs.nl H=open.nlnetlabs.nl [213.53.69.1] P=esmtp S=1892 id=200201121615.g0CGFqA36170@open.nlnetlabs.nl 2002-01-12 16:16:19 16PQpO-000GAy-00 <= email@btamail.net.cn H=(pc-1) [202.108.68.140] P=smtp S=10337 id=1452967-220021612153013904@btamail.net.cn 2002-01-12 17:33:45 16PS2L-000IAN-00 <= Roy.Arends@nominum.com H=shell.nominum.com [128.177.192.160] P=esmtp S=3331 id=20020112172543.B49608-100000@node10c4d.a2000.nl 2002-01-12 17:53:48 16PSLk-000IeP-00 <= warlord@MIT.EDU H=fort-point-station.mit.edu [18.7.7.76] P=esmtp S=3398 id=sjmofjzcv6l.fsf@indiana.mit.edu to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 13:57:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23045 for ; Sat, 12 Jan 2002 13:57:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PTEl-000Jva-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 10:50:39 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PTEl-000JvU-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 10:50:39 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PTEl-000CFF-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 10:50:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: In-Reply-To: Message-ID: To: Randy Bush Cc: namedroppers Subject: Re: From: Derek Atkins Date: 12 Jan 2002 13:27:09 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush writes: > 2002-01-12 17:53:48 16PSLk-000IeP-00 <= warlord@MIT.EDU H=fort-point-station.mit.edu [18.7.7.76] P=esmtp S=3398 id=sjmofjzcv6l.fsf@indiana.mit.edu Ok, resent.. Thanks, -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 13:57:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23055 for ; Sat, 12 Jan 2002 13:57:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PTF8-000Jvn-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 10:51:02 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PTF7-000Jvg-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 10:51:01 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PTF7-000CFq-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 10:51:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201121828.TAA16068@omval.tednet.nl> In-Reply-To: "Roy Arends's message as of Jan 12, 18:33" From: ted@tednet.nl (Ted Lindgreen) Date: Sat, 12 Jan 2002 19:28:30 +0100 To: namedroppers Subject: Re: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Roy Arends, on Jan 12, 18:33, in "Re: DS and Opt-in - ..."] > Factor of 2 in numbers, which result in an order of magnitude in > size. Please, make that, taking glue into consideration: in the worst case less or much less than a factor of two, going to nil difference as implementation progresses. As for size: > Lets put in another small variable called Q in your formulae. Q stands for Ok, I bear with you... > WHOA, factor 10, order of magnitude.... Interesting, but now I get a bit confused reading on, about your own real life experiment: > btw, last year at NLnet Labs, signing a .com zone increased the bare > zonefile with factor 4 (ascii file, not the file in core). Signed by a > single 768 bit DSA key. This took about 71 hours including sorting, > without certified crypto-hardware or software. so, the ascii size increased a factor of 4, please explain, perhaps Q above is a little exaggerated? And, also, that experiment was done before DS was invented, if I recall correctly. Another remark about size, I think that's less relevant as memory and bandwidth availability has increased faster than CPU power over the years. Therefore, I can understand that a steep increase in CPU workload ( ~ nr. if RRs) hits Moore's Law a lot sooner than an increase in average RR size. -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 13:57:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23067 for ; Sat, 12 Jan 2002 13:57:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PTEO-000JuF-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 10:50:16 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PTEO-000Ju9-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 10:50:16 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PTEO-000CEW-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 10:50:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20020112172543.B49608-100000@node10c4d.a2000.nl> In-Reply-To: <20020112172543.B49608-100000@node10c4d.a2000.nl> Message-ID: To: Roy Arends Cc: , namedroppers Subject: Re: DS and Opt-in - a proposal From: Derek Atkins Date: 12 Jan 2002 13:26:47 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends writes: > Lets put in another small variable called Q in your formulae. Q stands for > the size of the SIG record (against size of NS, A or NXT) multiplied by > the amount of signatures per RRset. Lets assume the size of NS,A and NXT > is 1. > > In the example below, Q stands for three SIGs plus a size of 10 per sig > (which result in 30). I still don't understand where this 30 is coming from? Do you mean you are assuming three SIG records at factor-10 size? Well, geeze, if you assume a factor of ten, surprise, you get a factor of ten. I'd rather work with _REAL_ numbers. There are Z zones currently in .COM and the zone-file is B bytes in core. Assume SIG records are of size S. Also assume that NXT records are of size N and DS records are of size D. This implies that we've got a total size of: B + Z*(N+S) + Z*X*(D+S) B + Z*(N+(1+X)*S+X*D) Now assume a 1024-bit RSA key as the signatory. Therefore SIG records are approximately 142 bytes each (128 bytes for the signature itself and 14 bytes for the rest of the sig header). This implies we're adding approximately Z*(1+X)*142 bytes due to signatures. So the question is, what is Z, and what is B? > btw, last year at NLnet Labs, signing a .com zone increased the bare > zonefile with factor 4 (ascii file, not the file in core). Signed by a > single 768 bit DSA key. This took about 71 hours including sorting, > without certified crypto-hardware or software. This isn't too surprising. Signature creation with DSA is a lot worse than signature creating with RSA. So, I would expect that RSA signature would take significantly less time on equivalent hardware (probably a factor of two). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 15:03:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23488 for ; Sat, 12 Jan 2002 15:03:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PUAW-000LP3-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 11:50:20 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PUAW-000LOx-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 11:50:20 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PUAW-000DqD-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 11:50:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <200201121828.TAA16068@omval.tednet.nl> Message-ID: <20020112201033.V54445-100000@node10c4d.a2000.nl> Date: Sat, 12 Jan 2002 20:35:46 +0100 (CET) From: Roy Arends To: Ted Lindgreen Cc: namedroppers Subject: Re: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 12 Jan 2002, Ted Lindgreen wrote: > [Quoting Roy Arends, on Jan 12, 18:33, in "Re: DS and Opt-in - ..."] > > > Factor of 2 in numbers, which result in an order of magnitude in > > size. > > Please, make that, taking glue into consideration: in the worst case > less or much less than a factor of two, going to nil difference as > implementation progresses. > > As for size: > > Lets put in another small variable called Q in your formulae. Q stands for > > Ok, I bear with you... > > > WHOA, factor 10, order of magnitude.... > > Interesting, but now I get a bit confused reading on, about your > own real life experiment: > > > btw, last year at NLnet Labs, signing a .com zone increased the bare > > zonefile with factor 4 (ascii file, not the file in core). Signed by a > > single 768 bit DSA key. This took about 71 hours including sorting, > > without certified crypto-hardware or software. > > so, the ascii size increased a factor of 4, please explain, perhaps > Q above is a little exaggerated? No, Q was merely: approx 150 bytes for a SIG RDATA compared to approx 15 bytes for a NS RDATA (is 10 to 1) times 3 Signatures per signed RRset. That is 30 to 1 amount of signature RDATA to NS RDATA for each signed RRset. But then there is lies, damned lies and statistics. > And, also, that experiment was done before DS was invented, if I > recall correctly. Yes. All that, still 71 hrs of sorting & signing, for a zone that denies security for every individual delegation. With OptIn it would probably be 3 hrs of sorting, and ehhh, that's it. Try that for a factor (71:3). That factor would slowly decrease with the adoption of DNSSEC. > Another remark about size, I think that's less relevant as memory > and bandwidth availability has increased faster than CPU power over > the years. Therefore, I can understand that a steep increase in > CPU workload ( ~ nr. if RRs) hits Moore's Law a lot sooner than an > increase in average RR size. Fine, lets assume that for a second, still it would be far more scalable to do a rollout with opt-in then without, while the change in security model hardly hurts, as been said a number of times. Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 15:09:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23509 for ; Sat, 12 Jan 2002 15:09:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PUBd-000LQM-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 11:51:29 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PUBd-000LQG-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 11:51:29 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PUBd-000DsA-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 11:51:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020112114656.A15290@pianosa.catch22.org> References: <20020111232924.A24826@pianosa.catch22.org> <200201121441.g0CEfKi27662@astro.cs.utk.edu> In-Reply-To: <200201121441.g0CEfKi27662@astro.cs.utk.edu>; from moore@cs.utk.edu on Sat, Jan 12, 2002 at 09:41:20AM -0500 Date: Sat, 12 Jan 2002 11:46:56 -0800 From: David Terrell To: Keith Moore Cc: Bob Fink , namedroppers@ops.ietf.org, NGtrans List Subject: Re: (ngtrans) review of 6to4-DNS Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, Jan 12, 2002 at 09:41:20AM -0500, Keith Moore wrote: > > The problem with this is that there is very little room for overlap. > > The edge recursive resolver can query the 2.0.0.2.ip6.arpa nameserver > > and generate metarecords in an NXDOMAIN case, OR the core server > > can return authoritative or metarecords depending on whether it has > > authoritative data. > > one possible problem - just because the 2.0.0.2.ip6.arpa nameserver > has NS records pointing to some prefix doesn't mean that the delegation > extends all the way to the zone for the 6to4 prefix. they could be > delegated to the v4 ISP, for instance, without the ISP having populated > that zone for some or all of its customers. In that case the arpa nameserver would return delegations (and perhaps up through the RIR to the "tier-1" isp to the local ISP). As soon as that first delegation is done, all implicit possibilities are lost unless it's done at the edge site. Hm. (i.e. if an ISP has their 6to4 reverse delegated to them, and they don't choose to insert authority records for a particular user, and that user sets up 6to4, should we fall back to the implicit records? I would say yes, since if they specifically want to blackhole 6to4 records they have the ability to do so with wildcard entries.) -- David Terrell | "Naturally, this is a frivolous example, and not likely to dbt@meat.net | face scrutiny well. In fact, you should have seen me giggle Nebcorp PM | as I typed the words 'zero-administration.'" - Benjy Feen, wwn.nebcorp.com | "Monkeybagel Consulting", www.monkeybagel.com. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 15:09:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23522 for ; Sat, 12 Jan 2002 15:09:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PUBD-000LQ0-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 11:51:03 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PUBD-000LPu-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 11:51:03 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PUBC-000DrO-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 11:51:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020112203642.N54445-100000@node10c4d.a2000.nl> Date: Sat, 12 Jan 2002 20:37:46 +0100 (CET) Date: Sat, 12 Jan 2002 18:32:13 +0100 (CET) From: Roy Arends To: Ted.Lindgreen@tednet.nl Cc: Roy Arends , Derek Atkins , namedroppers Subject: Re: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 12 Jan 2002, Ted Lindgreen wrote: > [Quoting Roy Arends, on Jan 12, 14:55, in "Re: DS and Opt-in - ..."] > > > While the number of RR are trippled when comparing 2535 with opt-in, and > > doubled comparing DS with opt-in .... > > You forget the glue, which makes the difference again a little less > pronounced, but anyway, we seem to agree that we are talking about > a factor of 2 and not an order of magnitude. Factor of 2 in numbers, which result in an order of magnitude in size. Lets put in another small variable called Q in your formulae. Q stands for the size of the SIG record (against size of NS, A or NXT) multiplied by the amount of signatures per RRset. Lets assume the size of NS,A and NXT is 1. In the example below, Q stands for three SIGs plus a size of 10 per sig (which result in 30). X=0 X=.5 X=1 Q=30 Q=30 Q=30 No DNSSEC 3N 3N 3N 3N DS (4+X+Q(1+X))N 34N 49.5N 65N OptIn+DS (3+2X+Q(2X))N 3N 34N 65N WHOA, factor 10, order of magnitude.... anyway, I was on the low side by estimating that a SIG record is about 10 times larger then an A or NS record. Most importantly, optin sets the growth scale more dynamically (from Q(1+X)N to 2XQN ) which allows for an initial offset of 0. > > doubled comparing DS with opt-in, these are only numbers of RR, not > > calculated is the size of the RR. It is fair to say that the size of a SIG > > is by far larger then the others. > > Of course, but the size of RRs is a whole other problem. To cope > with that we have already consensus, that we need the larger EDNS0 > packets as prerequisite for DNSSEC, but still if many decide to > use multiple and/or larger KEYs or SIGs than EDNS0 can hold, large > scale fallback from UDP to TCP will happen with a possibly devastating > effect on the performance of the DNS infrastructure. But, again, > this is another problem, which even OptIn cannot solve. Nice, but no, size of SIG _is_ relevant here. With OptIn there are simply less signatures when X has not reached 1. That is why the Q factor above is so influential. btw, last year at NLnet Labs, signing a .com zone increased the bare zonefile with factor 4 (ascii file, not the file in core). Signed by a single 768 bit DSA key. This took about 71 hours including sorting, without certified crypto-hardware or software. http://www.nlnetlabs.nl/dnssec/sign.com.html Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 15:10:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23540 for ; Sat, 12 Jan 2002 15:10:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PUBW-000LQC-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 11:51:22 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PUBV-000LQ6-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 11:51:21 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PUBV-000Dru-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 11:51:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20020112191139.T54445-100000@node10c4d.a2000.nl> In-Reply-To: <20020112191139.T54445-100000@node10c4d.a2000.nl> Message-ID: To: Roy Arends Cc: , namedroppers Subject: Re: DS and Opt-in - a proposal From: Derek Atkins Date: 12 Jan 2002 14:46:18 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends writes: > Generating RSA signatures is slower then DSA signatures.... I'm sorry, you are correct. Generating an RSA signature takes about twice as long as generating a DSA signature. HOWEVER, verifying a DSA signature takes ten times as long as verifying an RSA signature. Considering most of the DNSSec operation would be verification, you wind up performing twice as much work up front to save an order of magnitude of work for the verifier. To give some concrete numbers, courtesey Eric Rescorla: => Here are some approximate timings for the various operations => (measured on a Celeron 300). All moduli are 1024-bit. => => RSA private key op 30 ms (e.g. signature create) => RSA public key op 2 ms (e.g. signature verification) => DSA signature 17 ms => DSA verify 21 ms > Roy Arends > Nominum -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 16:07:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23887 for ; Sat, 12 Jan 2002 16:07:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PVG3-000MrL-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 13:00:07 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PVG3-000MrF-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 13:00:07 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PVG3-000G4V-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 13:00:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201121955.g0CJtWi24860@astro.cs.utk.edu> In-reply-to: Your message of "Sat, 12 Jan 2002 11:46:56 PST." <20020112114656.A15290@pianosa.catch22.org> From: Keith Moore To: David Terrell cc: Keith Moore , Bob Fink , namedroppers@ops.ietf.org, NGtrans List Subject: Re: (ngtrans) review of 6to4-DNS Date: Sat, 12 Jan 2002 14:55:32 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > (i.e. if an ISP has their 6to4 reverse delegated to them, and they > don't choose to insert authority records for a particular user, and > that user sets up 6to4, should we fall back to the implicit records? > I would say yes, since if they specifically want to blackhole 6to4 > records they have the ability to do so with wildcard entries.) I'd say yes also. But it means that if the servers for the 2.0.0.2.ip6.arpa zone are going to return pseudo NS records pointing to the default server addresses for {IPv4}.2.0.0.2.ip6.arpa then (if there are *any* NS records for a prefix of the address being queried), those zone servers will have to first try the query themselves, and get back NXDOMAIN, before returning the pseudo records. Keith to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 16:08:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23898 for ; Sat, 12 Jan 2002 16:08:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PVGD-000MrU-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 13:00:17 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PVGD-000MrO-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 13:00:17 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PVGD-000G4n-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 13:00:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20020112201033.V54445-100000@node10c4d.a2000.nl> In-Reply-To: <20020112201033.V54445-100000@node10c4d.a2000.nl> Message-ID: To: Roy Arends Cc: Ted Lindgreen , namedroppers Subject: Re: DS and Opt-in - a proposal From: Derek Atkins Date: 12 Jan 2002 15:11:40 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends writes: > > so, the ascii size increased a factor of 4, please explain, perhaps > > Q above is a little exaggerated? > > No, Q was merely: approx 150 bytes for a SIG RDATA compared to approx 15 > bytes for a NS RDATA (is 10 to 1) times 3 Signatures per signed RRset. > That is 30 to 1 amount of signature RDATA to NS RDATA for each signed > RRset. Let's ignore plain 2535. Where do you get 3 Sigs per RRset? There is SIG{NXT} for each record, sure. And for the secure children there is SIG{DS}. That's 1+X. Where is this third signature coming from? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 16:09:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23914 for ; Sat, 12 Jan 2002 16:09:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PVHQ-000Msu-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 13:01:32 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PVHP-000Mso-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 13:01:31 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PVHP-000G6w-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 13:01:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201122043.VAA16209@omval.tednet.nl> In-Reply-To: "Roy Arends's message as of Jan 12, 20:37" From: ted@tednet.nl (Ted Lindgreen) Date: Sat, 12 Jan 2002 21:43:57 +0100 To: Roy Arends , Ted Lindgreen Subject: Re: DS and Opt-in - a proposal Cc: namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Roy Arends, on Jan 12, 20:37, in "Re: DS and Opt-in - ..."] > All that, still 71 hrs of sorting & signing, for a zone that denies > security for every individual delegation. Please, lets stick to the subject, we were talking about the size of a zonefile, not the CPU time of the signing session. And IF you want to discus CPU time, then don't use the elapsed-time it took us to sign .com on a memory starved alpha desktop PC as reference. [Quoting Derek Atkins, on Jan 12, 21:11, in "Re: DS and Opt-in - ..."] > Where do you get 3 Sigs per RRset? There is SIG{NXT} for each record, > sure. And for the secure children there is SIG{DS}. That's 1+X. > Where is this third signature coming from? No, the two SIGs were not for different RRsets, Roy assumed we will be using 3 SIGs per RRset, each from different KEYs. There are a few RFC drafts talking about more than one KEY and/or SIG to allow for key rollovers, but I'm not sure why Roy thinks that 3 KEY/SIG sets for all RRsets in a TLD will be the future norm. Roy, perhaps you can enlighten us? -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 16:11:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23944 for ; Sat, 12 Jan 2002 16:11:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PVHv-000MuQ-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 13:02:03 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PVHu-000MuC-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 13:02:02 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PVHu-000G7r-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 13:02:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20020112212444.K54445-100000@node10c4d.a2000.nl> In-Reply-To: <20020112212444.K54445-100000@node10c4d.a2000.nl> Message-ID: To: Roy Arends Cc: Ted Lindgreen , namedroppers Subject: Re: DS and Opt-in - a proposal From: Derek Atkins Date: 12 Jan 2002 15:59:15 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends writes: > I was assuming that one will sign a zone with more then one key, which > will create more then one signature. If I want to do a scheduled key > rollover, then at some point before the rollover date I signed the zone > with 2 keys, and after the rollover with 2 keys, while the two signing > events share at least one key. To smoothen the rollover, I'll sign with 3 > keys. Ok, so the steady state of DS is (1+X)*S, with local maxima of (1+X)*2*S during (infrequent) times of key rollover. > Example: > > at point 1, there are 2 keys, key A and B. Now, I want to roll key A over > to key C. Why would you have two keys at any particular steady-state time? Sure, you need a second key during a rollover, but that does not mean you need to keep around a second set of signatures at all times. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 16:12:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23961 for ; Sat, 12 Jan 2002 16:12:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PVHK-000Msl-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 13:01:26 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PVHK-000Msf-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 13:01:26 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PVHK-000G6j-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 13:01:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: <20020112212444.K54445-100000@node10c4d.a2000.nl> Date: Sat, 12 Jan 2002 21:40:16 +0100 (CET) From: Roy Arends To: Derek Atkins Cc: Roy Arends , Ted Lindgreen , namedroppers Subject: Re: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 12 Jan 2002, Derek Atkins wrote: > Roy Arends writes: > > > > so, the ascii size increased a factor of 4, please explain, perhaps > > > Q above is a little exaggerated? > > > > No, Q was merely: approx 150 bytes for a SIG RDATA compared to approx 15 > > bytes for a NS RDATA (is 10 to 1) times 3 Signatures per signed RRset. > > That is 30 to 1 amount of signature RDATA to NS RDATA for each signed > > RRset. > > Let's ignore plain 2535. > > Where do you get 3 Sigs per RRset? There is SIG{NXT} for each record, > sure. And for the secure children there is SIG{DS}. That's 1+X. > Where is this third signature coming from? I was assuming that one will sign a zone with more then one key, which will create more then one signature. If I want to do a scheduled key rollover, then at some point before the rollover date I signed the zone with 2 keys, and after the rollover with 2 keys, while the two signing events share at least one key. To smoothen the rollover, I'll sign with 3 keys. Example: at point 1, there are 2 keys, key A and B. Now, I want to roll key A over to key C. point 1 | point 2 key A | key C key B | key B To make sure I have some redundancy, I start signing the zone with key C _before_ I'll discontinue key A, so I would have point 1 | point 2 | point 3 key A | key A | key B Key B | key B | key C | key C | At point 2 I would have 3 different keys. IMHO this would be a real situation. I have seen setups with a 5 keys, where 1 would roll-over as follows: pX is some point in time, kX..X+4 are the set of current keys at pX p1 p2 p3 p4 p5 --+--+--+--+-- k1|k2|k3|k4|k5 k2|k3|k4|k5|k6 k3|k4|k5|k6|k7 k4|k5|k6|k7|k8 k5|k6|k7|k8|k9 Assuming a single key, no matter how strong, for a zone as critical as com, without rollover mechanisms like above, is IMHO bad practice, that is why I calculated in more keys. Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 16:19:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24032 for ; Sat, 12 Jan 2002 16:19:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PVPQ-000NBT-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 13:09:48 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PVPQ-000NBM-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 13:09:48 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PVPQ-000GKl-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 13:09:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200201122043.VAA16209@omval.tednet.nl> In-Reply-To: <200201122043.VAA16209@omval.tednet.nl> Message-ID: To: ted@tednet.nl (Ted Lindgreen) Cc: Roy Arends , namedroppers Subject: Re: DS and Opt-in - a proposal From: Derek Atkins Date: 12 Jan 2002 16:07:51 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ted@tednet.nl (Ted Lindgreen) writes: > > Where do you get 3 Sigs per RRset? There is SIG{NXT} for each record, > > sure. And for the secure children there is SIG{DS}. That's 1+X. > > Where is this third signature coming from? > > No, the two SIGs were not for different RRsets, Roy assumed we will > be using 3 SIGs per RRset, each from different KEYs. There are a few Except in delegation zones like .COM the only entries are NS and glue-A records, neither of which are actually signed. So you're not actually signing each RRSet, you're signing each node (regarless of the number of RRSets at that node). It doesn't matter how many NS or glue-A records you have; you're only signing SIG{NXT} and SIG{DS} at the NS nodes and ignoring the glue-A nodes. > RFC drafts talking about more than one KEY and/or SIG to allow for > key rollovers, but I'm not sure why Roy thinks that 3 KEY/SIG sets > for all RRsets in a TLD will be the future norm. Roy, perhaps you > can enlighten us? I don't understand this, either. Sure, you need a second key (which doubles the number of signatures) during key rollover, but I don't expect anyone to keep multiple key/sigs around at all times. > -- ted -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 16:30:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24165 for ; Sat, 12 Jan 2002 16:30:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PVbR-000NYf-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 13:22:13 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PVbR-000NYZ-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 13:22:13 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PVbQ-000GeA-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 13:22:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from Derek Atkins of "12 Jan 2002 15:59:15 EST." Message-Id: <20020112212040.A98AF28EEB@as.vix.com> From: Paul Vixie To: namedroppers Subject: Re: DS and Opt-in - a proposal Date: Sat, 12 Jan 2002 13:20:40 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit gentlefolk, when all is said and done about how hard or easy non-opt-in is to sign, transfer, or serve, other more relevant facts will still hold sway. that's that verisign will not sign .COM until they want to. nobody, not DoC or ICANN or IANA or certainly not IETF is going to somehow argue them into it. so you can prove that it's possible to do it all day long, but their conceptions, even irrational preconceptions, will still hold sway. so please, let's all stop flapping our gums and explaining the math of it, because this is not a math problem. if we were otherwise ready to roll out dnssec i'd say tell verisign to go pound sand. (and in fact, i did say this, when i thought dnssec was otherwise ready to roll out.) but since we're doing DS with a non-backward-compatible flag day, we're not talking about holding up dnssec to get opt-in in (which would be stupid, and which we wouldn't do.) that makes this more like a first-principles discussion, as in "would we have done it this way in the beginning if anybody had thought of markk's opt-in idea in the beginning?" my answer is: YES. this is the right way to do dns security. if anybody wants to have a relevant discussion about this, that's where to begin. the math isn't relevant and never was. verisign's desires aren't relevant and never were. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jan 12 17:35:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24505 for ; Sat, 12 Jan 2002 17:35:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PWZD-000Onp-00 for namedroppers-data@psg.com; Sat, 12 Jan 2002 14:23:59 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PWZD-000Onj-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 14:23:59 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PWZD-000IKj-00 for namedroppers@ops.ietf.org; Sat, 12 Jan 2002 14:23:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201122220.XAA16321@omval.tednet.nl> In-Reply-To: "Derek Atkins's message as of Jan 12, 22:07" From: ted@tednet.nl (Ted Lindgreen) Date: Sat, 12 Jan 2002 23:20:25 +0100 To: namedroppers Subject: Re: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Derek Atkins, on Jan 12, 22:07, in "Re: DS and Opt-in - ..."] > > RFC drafts talking about more than one KEY and/or SIG to allow for > > key rollovers, but I'm not sure why Roy thinks that 3 KEY/SIG sets > > for all RRsets in a TLD will be the future norm. Roy, perhaps you > > can enlighten us? > > I don't understand this, either. Sure, you need a second key (which > doubles the number of signatures) during key rollover, but I don't > expect anyone to keep multiple key/sigs around at all times. As Roy already explained, this is for procedure schemes to do key roll-overs, as worked out at several places. These schemes tried to solve the 3-generation problem of vanilla 2535 (a zone needs its parent to sign its new KEY and at the same time its children to include the SIGs from the new KEY in their zonefile). This was extremely complicated to do in a secure manner and without disrupting service when scheduled, and virtually impossible when unscheduled (as an emergency key rollover after a key compromise). That's why DS has been introduced, and with DS these complicated procedures are greatly simplified. With DS one needs either a temporary double zone-KEY (useful for large zones, like TLDs) or a temporary double set of RRs (useful for most other zones), but not both, to do a scheduled rollover. An unscheduled rollover needs no double KEY or SIGs (in fact you don't want the compromised old stuff anymore), but some out-of-band mechanisme is needed instead. -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 03:27:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08794 for ; Sun, 13 Jan 2002 03:27:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PfmZ-0009A8-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 00:14:23 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PfmY-0009A2-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 00:14:22 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PfmY-0009RL-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 00:14:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698FC@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Derek Atkins'" , Roy Arends Cc: Ted Lindgreen , namedroppers Subject: RE: DS and Opt-in - a proposal Date: Sat, 12 Jan 2002 19:05:35 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Derek is missing the point here, the NOC has to have capacity for the peak load. The fact that key rollover is infrequent is irrelevant since you still have to plan capacity so you have that capability. Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Saturday, January 12, 2002 3:59 PM > To: Roy Arends > Cc: Ted Lindgreen; namedroppers > Subject: Re: DS and Opt-in - a proposal > > > Roy Arends writes: > > > I was assuming that one will sign a zone with more then one > key, which > > will create more then one signature. If I want to do a scheduled key > > rollover, then at some point before the rollover date I > signed the zone > > with 2 keys, and after the rollover with 2 keys, while the > two signing > > events share at least one key. To smoothen the rollover, > I'll sign with 3 > > keys. > > Ok, so the steady state of DS is (1+X)*S, with local maxima of > (1+X)*2*S during (infrequent) times of key rollover. > > > Example: > > > > at point 1, there are 2 keys, key A and B. Now, I want to > roll key A over > > to key C. > > Why would you have two keys at any particular steady-state time? > Sure, you need a second key during a rollover, but that does not mean > you need to keep around a second set of signatures at all times. > > -derek > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 03:28:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08822 for ; Sun, 13 Jan 2002 03:28:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PfmC-00099s-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 00:14:00 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PfmB-00099m-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 00:13:59 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PfmB-0009Qj-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 00:13:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698FB@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Derek Atkins'" , Roy Arends Cc: Ted.Lindgreen@tednet.nl, namedroppers Subject: RE: DS and Opt-in - a proposal Date: Sat, 12 Jan 2002 19:01:33 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just an additional point of information here, the secure signing hardware used for commercial grade crypto tends to have processors that are slower than Celeron 300s. In fact the popular chip of the moment is the ARM. Don't ask me what happens to all these PR we see for mega-fast crypto chips with modular exponentiation H/W. For some reason it does not seem to wind up at the companies who have trustworthy manufacturing facilities that can pass a decent audit and end up in FIPS 140/3 certified gear. Derek's original point was actually not far off when you do the whole signature creation process which includes test verification. Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Saturday, January 12, 2002 2:46 PM > To: Roy Arends > Cc: Ted.Lindgreen@tednet.nl; namedroppers > Subject: Re: DS and Opt-in - a proposal > > > Roy Arends writes: > > > Generating RSA signatures is slower then DSA signatures.... > > I'm sorry, you are correct. Generating an RSA signature takes about > twice as long as generating a DSA signature. HOWEVER, verifying a DSA > signature takes ten times as long as verifying an RSA signature. > > Considering most of the DNSSec operation would be verification, you > wind up performing twice as much work up front to save an order of > magnitude of work for the verifier. > > To give some concrete numbers, courtesey Eric Rescorla: > > => Here are some approximate timings for the various operations > => (measured on a Celeron 300). All moduli are 1024-bit. > => > => RSA private key op 30 ms (e.g. signature create) > => RSA public key op 2 ms (e.g. signature verification) > => DSA signature 17 ms > => DSA verify 21 ms > > > Roy Arends > > Nominum > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 04:14:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08795 for ; Sun, 13 Jan 2002 03:27:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Pfmy-0009B0-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 00:14:48 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Pfmx-0009Au-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 00:14:47 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Pfmx-0009SM-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 00:14:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <2F3EC696EAEED311BB2D009027C3F4F4058698FC@vhqpostal.verisign.com> In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4058698FC@vhqpostal.verisign.com> Message-ID: To: "Hallam-Baker, Phillip" Cc: Roy Arends , Ted Lindgreen , namedroppers Subject: Re: DS and Opt-in - a proposal From: Derek Atkins Date: 12 Jan 2002 22:37:02 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit No, I understand the point. I was arguing that just because you need to support the maxima of (1+X)*2*S does not mean that you should expect to have two sets of SIGs at all times. Considering that the current assumption is that X=.01 at this time, we're talking about 2.02*S. -derek "Hallam-Baker, Phillip" writes: > Derek is missing the point here, the NOC has to have capacity > for the peak load. The fact that key rollover is infrequent is > irrelevant since you still have to plan capacity so you have > that capability. > > > Phillip Hallam-Baker FBCS C.Eng. > Principal Scientist > VeriSign Inc. > pbaker@verisign.com > 781 245 6996 x227 > > > > -----Original Message----- > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > Sent: Saturday, January 12, 2002 3:59 PM > > To: Roy Arends > > Cc: Ted Lindgreen; namedroppers > > Subject: Re: DS and Opt-in - a proposal > > > > > > Roy Arends writes: > > > > > I was assuming that one will sign a zone with more then one > > key, which > > > will create more then one signature. If I want to do a scheduled key > > > rollover, then at some point before the rollover date I > > signed the zone > > > with 2 keys, and after the rollover with 2 keys, while the > > two signing > > > events share at least one key. To smoothen the rollover, > > I'll sign with 3 > > > keys. > > > > Ok, so the steady state of DS is (1+X)*S, with local maxima of > > (1+X)*2*S during (infrequent) times of key rollover. > > > > > Example: > > > > > > at point 1, there are 2 keys, key A and B. Now, I want to > > roll key A over > > > to key C. > > > > Why would you have two keys at any particular steady-state time? > > Sure, you need a second key during a rollover, but that does not mean > > you need to keep around a second set of signatures at all times. > > > > -derek > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > warlord@MIT.EDU PGP key available > > > > > > to unsubscribe send a message to > > namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 11:38:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12427 for ; Sun, 13 Jan 2002 11:38:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PnRx-000I6v-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 08:25:37 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PnRx-000I6p-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 08:25:37 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PnRx-000MQJ-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 08:25:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <200201131216.g0DCGRi16059@birch.ripe.net> Message-ID: <20020113132416.H54445-100000@node10c4d.a2000.nl> Date: Sun, 13 Jan 2002 14:09:56 +0100 (CET) From: Roy Arends To: Olaf Kolkman Cc: Roy Arends , Derek Atkins , namedroppers , Ted Lindgreen Subject: Re: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 13 Jan 2002, Olaf Kolkman wrote: > PS: I am still afraid, and I know that is a social argument, that > with having OPT-IN available on all levels of the tree we will end up > with only a few RRs signed, the DNS as a system will loose that way. > The argument that 'people can use opt-in to circumvent NXT walks' is a > good incentive to have zones with only their www.companyname.com name > signed. All the other data in the DNS would remain unsecured, > spoofable etc. etc. I rather sign nodes in my domain because I want to, not because I must. Note: as said, also with 2535+DS it is possible to have just www.companyname.com signed and the rest not. However, a helluva lot more work, so the rest is signed because it has to (i.e. choosing the lesser of two administrative evils). That, to me, is silly. I've a lock on the front and back door of my house. That is by choice. I will protest if I must have locks on every door, including the kitchen-sink. Opt-In offers a choice. Some may not like that choice. I do. Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 11:38:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12453 for ; Sun, 13 Jan 2002 11:38:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PnU8-000IAe-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 08:27:52 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PnU8-000IAY-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 08:27:52 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PnU8-000MUD-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 08:27:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201131539.QAA17500@omval.tednet.nl> In-Reply-To: "Roy Arends's message as of Jan 13, 14:11" From: ted@tednet.nl (Ted Lindgreen) Date: Sun, 13 Jan 2002 16:39:28 +0100 To: namedroppers Subject: Re: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Roy Arends, on Jan 13, 14:11, in "Re: DS and Opt-in - ..."] > I've a lock on the front and back door of my house. That is by choice. > I will protest if I must have locks on every door, including the > kitchen-sink. > > Opt-In offers a choice. Some may not like that choice. I do. Thanks Roy, you hit the nail on the head, this is exactly what other people bothers: it is the granularity of the choice, and the effect on that for the larger community. - If the goal is to make a protocol to lock the doors of their own chosing of their own homes (secure a certain RR) then yes, Opt-In is absolutely a brilliant idea. - However, if the goal is to make a common infrastructure safer, there is serious doubt that Opt-In will lead to that more quickly. Let me give another example: If there is a need to make the airline infrastructure safer then checking the people that get into the planes may help, lets assume it does. Now, like with DNSSEC, it is unrealistic to have all airfields over the whole world to implement this overnight, so partial implementation is a fact of life. Now, with small grain granularity, i.e. leave it up to the individual airfield to check, check not, or check only the blue-eyed people, it's not likely that the goal will be reached quickly: most people have little choice in their destination, they just need to go there for some reason, and even then there might even be a brown-eyed terrorist. In the course grain granularity, say a number of large countries pick it up for all their fields, it leads to: 1. The choice, at least for people in these large countries becomes clear: limit your travel to countries that comply, or live dangerously. 2. Organisers of large meetings may decide to stick to those countries. 3. Countries that don't comply may see a strong reason to change their policy, f.i. to not be avoided. Others, who love the dangerous, might not. Also compare this with USENET: dividing the USENET world into a highly regulated "mod", an anarchistic "alt" and for the rest self-regulated hierachies at the top level worked out beautiful. It worked out so well, because it was totally clear what you could expect on where you are in the tree. Before that splitup, it was a little mess here and there. -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 11:38:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12464 for ; Sun, 13 Jan 2002 11:38:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PnQc-000I5W-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 08:24:14 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PnQc-000I5Q-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 08:24:14 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PnQc-000MO7-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 08:24:14 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers Subject: draft minutes Message-Id: Date: Sun, 13 Jan 2002 08:24:14 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ these minutes from Jun-ichiro itojun Hagino are the only ones i have received. will submit tomorrow if i get no others. please send corrections now -- randy ] multicast dns - is this the right solution? ?: is it the same protocol, or new protocol? reuse of the port number, reuse of the packet format ?: when we started, "behavior just like DNS" operational problem, conceptual problem alain: icmp6 name lookup - one solution looked at (but was not provided for ipv4) aboba: no set of goals stated, document is ready for ietf last call something gone very wrong. is this solving the right problem? is there a better solution? mohta: zeroconf is not a good thing to pursue. if we don't want client configuration, dns servers having wellknown anycast addresses work fine ?: would like to do "infrared" thing that palm does, or appletalk. need some mechanism for resolving name. rob: there are people with different goals. ?: it is a good way to reuse DNS. we won't be able to solve the problem even if we start fresh aboba: if zeroconf requirement is broken? olafur: zeroconf is a part of requirement. --- dns threat model (rob) examine why dnssec was started dnssec ensures data item is the same when they are put in, and when they are pulled out lack of threat model? dnssec has dependency on time sync. --- delegation signer (olafur) motivation key record repeats the mistake of ns record in delegations, same record in two zones key at child is clumbersome parent advertises strong identifier of key used resolver verifies DS record from parent only verifies key if sig matches verified DS DS advantages information flow in key handshake is now identical to NS minimizes communication only when hcild changes KEY set signing key less data in parent DS much small than key DS only at secdure delegation child in full control of security status no conflicting key sets disadvantages: more work for resolvers. 3 implementations what change from the last IETF NODS in NXT bitmap at unsecured delegations DS can only pont at DS zone keys that can sign zone key size field dropped server returning... DS complicates life for resolvers chop off 2535, or DS, or opt-in next steps DS seem to work DS makes DNSSEC much/some easier for operations DS increments complexity in resolvers advance or discard? ?: is it really advantageous to have less data in parent? less state - similar to opt-in minimizes communication deployability difference for big zones how much better should combine discussion for opt-in it is advantageous that downstream reload does not happen when upstream key changes balance: decoupling child signing and parent signing - weakening security outband or inband? key rollover for .com - 6month, 2 key alive at one time (comments continue after opt-in talk) --- opt-in dnssec painful for large zones huge upfront cost null KEYS, nxt RR and signatures for child zones that are not secure little initial deployment high generation cost ordering re-signing distributing changes since 00 total rewrite goal is the same, different methods NXT indicates opt-in instead of KEY opt-in uses noSig techniques basically, finer granurality, opt-in 2535 choice can be made on per-record (instead of per-zone) 2535 NXT - authenticated denial of existence of names does not allow unsigned names opt-in NXT - authenticated denial of existence of SIGNED names does allow unsigned names 2535 - positive answer = this delegation is not signed the unsigned name exist (crypto verifiable) opt-in - negative answer = there exist no signed delgation between two signed names the unsigned name exist (not crypto verifiable) pros and cons every advantage has disadvantages positive: opt-in reduces the amount of crypto in a zone negative: opt-in gives up authenticated denial of existence for unsecured delegations (give up security for unsecured data item) don't "like" opt-in? sign it with 2535 opt-in does not obsolete 2535 positive side-effect traversing a zone through NXT recodrs gives only signed names and signed delegations a chain of secure delegations is possible without the requirement to sign the whole zone 2535 is not "better " ot "worse" than opt-in 2535 has advantages for the average zone opt-in has advantages for the delegation-only zone (large zone) randy: change in security model. attacking the problem of size by a protocol change, and security model change. assumption - the little part of zone gets signed. ?: it is already hard to keep up hardware with .com size. vixie: losing ability to cryptographically prove non-existence of names, or nonexistence of child signature, is it true? - not exactly. ?: it is up to zone owner. ?: we can mix 2535 and opt-in in a single zone. --- key desire to have algorithms separately documented. minimize dependency to 2535 key format draft documents standard moduli? --- AD bit outstanding issue ad draft status document passed working group last call, not sent out when can AD bit be set? AD = authenticated data AD draft says authoritative server can set the AD bit if local security policy allows comments on the mailing list afer last call disagree argument for text the issue only affects resolvers that trust server doing signature validation on all data loaded is expensive either slows loading or answers integrity of whole zones on servers can be protected by other means signed zone files, signed zone transfer against AD MUST only be set if signatures have been verified setting the AD bit under other conditions is wrong AA bit implies that the data is authentic suggestion authors must add text that clarify states that AD bit is not be set by default and MUST only be set if there are some other validity checks in place document must also document what [stub] resolvers are affected ?: 2535 says about AD bit - data satisfies the security policy of the server ?: what is "policy"? can you tell what kind of policy the server is implementing? ?: the situation happens only when you talk to authoritative zone. it should be your own domain, so you know the policy? ?: why you can't use AA bit for that? authors will update the draft. do we need DS? do we need opt-in? vixie: from test results, it seems (something like) DS is needed for key rollover opt-in is just a hack for one zone (.com) anyway we need to get this DONE. ?: opt-in is needed, to sign .com. can't deploy .com with 2535. ?: cost vs usefulness. cost is significant for large zones. ?: does opt-in break security of zones (= signed chain)? bill: interoperability between 2535 and DS? - yes, DS-capable resolvers can (but there is a flag day). olafur: we are doing this too long. for DS and opt-in, need go or nogo. ?: there are people who are trying to deploy 2535. too long wait. randy: agree with vixie. ?: not deployable as it is today. vixie: need to separate between deployability due to size, and other issues. does it matter if we sign .com today, or 2004? this needs to come to conclusion. during this week people will talk and try to come to conclusion, and then to the list. vixie: the reason why root is not signed is that dnssec is still seems to be in flux --- tkey securet key renewal mode necessary to refresh shared keys for tsig new mode for update procedure and mechanism in tkey renewal mode defined key has lifetime. during renewal, key lifetime overwraps tsig-signed query from client expiration time check server urges clients to send tkey renewal requests tkey secret key renewal request from client DH public key old key's name and algorithm answer from server establish new secret by DH TSIG-signed query with the new key from client server adopts the new key feature systematic control by server "renewal", not add/delete limit number of shared keys think about network errors. feel no need for this. server can delete the key when it expires. tkey is just for temporary measure. it is direciton we shouldn't go. --- dns mib proposed replacement for 1611 not ready for prime time yet. please read, test it and comment. need requirement document to start with. --- ngtrans dns op req problem: IPv4-only and IPv6-only nodes coexist, how to resolve? long term problem consequences - this working group has to do something. requirement single root requirement, applies for IPv4 and IPv6 dns is IP version independent application. need to be able to get the same data independent from data. we can change v6 things, we cannot change v4 things need some kind of bridging system, so that v6 only resolver can get data from v4 only server, or other ways need symmetry in bridging system? no. v4 resolver - no good way. zone needs to be served by dualstack node. v6 resolver - relaying system? leakage of information serve zones on dualstack node, period. --- dynamic update we assume that updated records gets eventually removed explicitly state an expiration time repeat of past effort. if we are going to repeat this one, requirement document is needed. we can't assume wall clock (powered off). there seem to be some need. --- application keys - limiting the scope of the key resource record simple idea - restrict KEY to dnssec. dnssec key vs application keys - looks like a different beast. reolver behavior is very different. separate rtype, SRV, KEY, ... protocol specific flag? attribute? should we separate pubkey and cert? we need a requirement document. (battery is out) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 11:41:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12534 for ; Sun, 13 Jan 2002 11:41:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PnY7-000IHn-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 08:31:59 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PnY6-000IHh-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 08:31:58 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PnY6-000Map-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 08:31:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20020113132416.H54445-100000@node10c4d.a2000.nl> In-Reply-To: <20020113132416.H54445-100000@node10c4d.a2000.nl> Message-ID: To: Roy Arends Cc: Olaf Kolkman , namedroppers , Ted Lindgreen Subject: Re: DS and Opt-in - a proposal From: Derek Atkins Date: 13 Jan 2002 11:13:59 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends writes: > On Sun, 13 Jan 2002, Olaf Kolkman wrote: > > > PS: I am still afraid, and I know that is a social argument, that > > with having OPT-IN available on all levels of the tree we will end up > > with only a few RRs signed, the DNS as a system will loose that way. > > The argument that 'people can use opt-in to circumvent NXT walks' is a > > good incentive to have zones with only their www.companyname.com name > > signed. All the other data in the DNS would remain unsecured, > > spoofable etc. etc. > > I rather sign nodes in my domain because I want to, not because I > must. And if everyone in the universe gets this choice, we wont be any better than we are now, because nobody is willing to go to the extra effort to add security if they don't have to. When it comes to scurity, choices are a Bad Idea (TM). The more choices you have, the more possibility you have to shoot yourself in the foot. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 12:18:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12719 for ; Sun, 13 Jan 2002 12:18:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Po8E-000JFK-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 09:09:18 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Po8A-000JF2-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 09:09:14 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Po8A-000NYL-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 09:09:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020112152527.A30692@outpost.ds9a.nl> References: <200201121319.g0CDJLv35761@open.nlnetlabs.nl> In-Reply-To: <200201121319.g0CDJLv35761@open.nlnetlabs.nl>; from ted@tednet.nl on Sat, Jan 12, 2002 at 02:19:20PM +0100 Date: Sat, 12 Jan 2002 15:25:27 +0100 From: bert hubert To: Ted Lindgreen Cc: namedroppers Subject: Re: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, Jan 12, 2002 at 02:19:20PM +0100, Ted Lindgreen wrote: > Anyway, I can't help being slightly amused to see people, who have > survived several orders of magnitude growth during the past Internet > hype, now being so exited about a mere variation around a factor > of 2 when it comes to implement DNSSEC :-) Easy. Those orders of magnitude of growth in complexity were accompanied by orders of magnitude of growth in revenue. In other words, they were needed in order to increase business. Failure to meet the demand would lead to decreased revenues or even disqualification as a registry. Compare this to introducing OptIn-less DNSSEC. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk Netherlabs BV / Rent-a-Nerd.nl - Nerd Available - Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 12:29:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12430 for ; Sun, 13 Jan 2002 11:38:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PnRb-000I6c-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 08:25:15 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PnRb-000I6W-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 08:25:15 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PnRb-000MPh-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 08:25:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201131216.g0DCGRi16059@birch.ripe.net> In-Reply-To: Message from Roy Arends of "Sat, 12 Jan 2002 21:40:16 +0100." <20020112212444.K54445-100000@node10c4d.a2000.nl> To: Roy Arends cc: Derek Atkins , Ted Lindgreen , namedroppers Subject: Re: DS and Opt-in - a proposal Date: Sun, 13 Jan 2002 13:16:27 +0100 From: Olaf Kolkman Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit * I was assuming that one will sign a zone with more then one key, which * will create more then one signature. If I want to do a scheduled key * rollover, then at some point before the rollover date I signed the zone * with 2 keys, and after the rollover with 2 keys, while the two signing * events share at least one key. To smoothen the rollover, I'll sign with 3 * keys. This statement does not hold with DS. ( So there are no unexpected peaks in the size because of key-rollover in a 2335-DS only scheme ) Argument: You use a production key to sign your records, that one is signed by the a master key. At rollover of the Master key you need to have a signature of the apex keyset with both old and new master key. With DS you can also rollover your production key without having double signature. You just need to have a signature over the new key made well in advance (at least one TTL of the apex keyset before you resign with the new key). So in 2535+DS+NXT you can securely manage your zone with only having 1 additional signature per unsecured delegation and 2 additional signatures with a secure delegation. By the way: A back of the envelope guestimate shows that for a name length of 'i' bytes the zone size of a zone dominated by unsecured delegations with 2 NS records and 2 glue records per delegation the zone size grows as: (9*i+j)/6*i where 'j' is the byte size of the signature. Which for reasonable signature length and reasonable label sizes is about a factor 3 to 4. I can't speak for G|TLDs but I think most of them will be able to cope with that. --Olaf PS: I am still afraid, and I know that is a social argument, that with having OPT-IN available on all levels of the tree we will end up with only a few RRs signed, the DNS as a system will loose that way. The argument that 'people can use opt-in to circumvent NXT walks' is a good incentive to have zones with only their www.companyname.com name signed. All the other data in the DNS would remain unsecured, spoofable etc. etc. PPS: Input for the guestimate: Take size of RRset to be '2*i' for a NS record, 'i' for an A record, '2i' for the NXT record and i+j for the SIG. Assume two NS records and two glue A records per delegation. growth: >From N* (2*(2i) + 2*i)=6i to N* (2*(2i) + 2*i +2i + i+j)=9i+j to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 12:55:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13132 for ; Sun, 13 Jan 2002 12:55:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Pohv-000K5N-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 09:46:11 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Pohs-000K5H-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 09:46:08 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Pohs-000OVV-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 09:46:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from Derek Atkins of "13 Jan 2002 11:13:59 EST." Message-Id: <20020113172527.BD66428EEA@as.vix.com> From: Paul Vixie To: namedroppers Subject: paternalism, or just xenophobia? (was Re: DS and Opt-in - a proposal) Date: Sun, 13 Jan 2002 09:25:27 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > I rather sign nodes in my domain because I want to, not because I must. > > And if everyone in the universe gets this choice, we wont be any > better than we are now, because nobody is willing to go to the > extra effort to add security if they don't have to. > > When it comes to scurity, choices are a Bad Idea (TM). The more > choices you have, the more possibility you have to shoot yourself > in the foot. there's an undercurrent of father-knows-best running through this thread. and it's starting to appear that this, rather than pro/anti verisign sentiments or any kind of law of math or physics, is at the heart of the debate. let me test this by adding a thread on the issue of paternalism. -------- dns is a distributed, coherent, autonomous, reliable database. (the only one of its kind in the history of our kind.) let's focus for a moment on "autonomous" by contrasting dns against RFC952 (HOSTS.TXT) at the instant that the owner/provider of a network resource desires that resource to gain a universal (coherent; unique) name which has more meaning than its IP address and/or port number. with RFC952, the next step was to involve another party -- SRI-NIC.ARPA, who would register your universal identifier in a global shared database (HOSTS.TXT). with RFC1034, the next step was and is entirely a local matter: you edit the zone which covers the part of the namespace you're adding a name to, and you instruct your DNS server to publish this new zone. this is what "dns autonomy" is about. the only time you ever have to involve another party in your naming work is when delegating new zones or changing the delegation of an existing zone, if and only if you are not also the owner of the delegating (parent) zone. -------- much has been said in the opt-in debate about "changing the security model," from a common understanding that such changes if any must be carefully understood and not adopted as an unanalyzed side effect of some seemingly compelling change. i propose that opposition to dnssec opt-in on the grounds that other zone owners ought not have this choice available to them is "changing the dns autonomy model" and ought receive the same level of analysis and concern. at the moment, the dns autonomy model is that one only needs permission from a second party when you want that party's zone edited to add or change a delegation of one of your zones. dnssec + ds adds key management to delegation management but does not add more parties to the list of "who can control what data a zone owner wants to see published." opposition to opt-in on the grounds of preventing "too many choices" seems to imply that "the set of all resolver owners" ought to have the ability to control what a zone owner is allowed to publish. -------- i think that anyone who secures less than they could secure is being silly. but i recognize the autonomy of zone owners and i cannot in good conscience try to force them to publish what i want instead of what they want. an unsecure answer under the opt-in plan has the same security status as it has without dnssec at all. resolvers can believe it or not, as they please. there is no new transaction mode where you get something you think is secure that really isn't as secure as it could be -- that is, when you get something that isn't secure, you know it. why are any of you here willing to take a stand that "the owner of VIX.COM ought to have to swallow the whole DNSSEC pill or get no authenticity at all"? it's my zone. what part of it is secure ought to be my decision. whether it is secure at all ought to be a decision i share with the owner of COM. so, what business do any of you have butting into my affairs in this way? (note that i'll sign the whole thing, without opt-in, as soon as possible, but that that has to be my choice, not your choice, or we'll have to fight.) in legislative matters, this dispicable behavior is called "attaching a rider" and is a form of passive aggression. "you can have the part of this you want if you also take this other part that you really don't want." a bet is made by the attacher that chances are nonzero that the impact will simply be that folks move a lot of their unsecurable content into different zones. or won't use dnssec at all because its deployment cost is too high. especially as they'll know that the cost was made artificially higher for reasons of security model purity. changes to the security model can't implicitly call for changes to the autonomy model. if we're going to change the autonomy model, let's do it with our eyes open. or preferrably, let's not change the autonomy model, but rather, let's make the security model work under the existing autonomy model. because there is no place for paternalism in protocol design. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 13:03:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13207 for ; Sun, 13 Jan 2002 13:03:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Pojj-000K7k-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 09:48:03 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Pojh-000K7e-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 09:48:01 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Pojh-000OYm-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 09:48:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <200201131539.QAA17500@omval.tednet.nl> Message-ID: <20020113182126.O54445-100000@node10c4d.a2000.nl> Date: Sun, 13 Jan 2002 18:31:45 +0100 (CET) From: Roy Arends To: Ted Lindgreen Cc: namedroppers Subject: Re: DS and Opt-in - a proposal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 13 Jan 2002, Ted Lindgreen wrote: > [Quoting Roy Arends, on Jan 13, 14:11, in "Re: DS and Opt-in - ..."] > > > I've a lock on the front and back door of my house. That is by choice. > > I will protest if I must have locks on every door, including the > > kitchen-sink. > > > > Opt-In offers a choice. Some may not like that choice. I do. > > Thanks Roy, you hit the nail on the head, this is exactly what other > people bothers: it is the granularity of the choice, and the effect on > that for the larger community. > > - If the goal is to make a protocol to lock the doors of their > own chosing of their own homes (secure a certain RR) then > yes, Opt-In is absolutely a brilliant idea. The granularity boils down to a single node, not individual RRsets, but anyway... > - However, if the goal is to make a common infrastructure safer, > there is serious doubt that Opt-In will lead to that more > quickly. > > Let me give another example: > > If there is a need to make the airline infrastructure safer then > checking the people that get into the planes may help, lets > assume it does. > > Now, like with DNSSEC, it is unrealistic to have all airfields > over the whole world to implement this overnight, so partial > implementation is a fact of life. > > Now, with small grain granularity, i.e. leave it up to the > individual airfield to check, check not, or check only the > blue-eyed people, This is getting silly. Check blue-eyed people: opt-in ? "either walk, or go by car. Going by bike will only lead to people going in wrong directions." If you want to discuss this seriously, I'm open to that, until then ... roy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 13:03:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13219 for ; Sun, 13 Jan 2002 13:03:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PokK-000K80-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 09:48:40 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PokI-000K7t-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 09:48:38 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PokH-000OZp-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 09:48:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20020113172527.BD66428EEA@as.vix.com> Message-Id: From: Randy Bush To: Paul Vixie Cc: namedroppers Subject: Re: paternalism, or just xenophobia? (was Re: DS and Opt-in - a proposal) Date: Sun, 13 Jan 2002 09:47:38 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > there's an undercurrent of father-knows-best running through this thread. > and it's starting to appear that this, rather than pro/anti verisign > sentiments or any kind of law of math or physics, is at the heart of the > debate. let me test this by adding a thread on the issue of paternalism. this discussion is hard enough already. let's not drift into who acts how and who loves whom, please. thanks. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 13:17:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13355 for ; Sun, 13 Jan 2002 13:17:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Pp0i-000Kau-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 10:05:36 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Pp0i-000Kao-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 10:05:36 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Pp0i-000P23-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 10:05:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Your message of "Sun, 13 Jan 2002 09:47:38 PST." Message-Id: <20020113175833.AFFC928EEA@as.vix.com> To: namedroppers@ops.ietf.org Subject: Re: paternalism, or just xenophobia? (was Re: DS and Opt-in - a proposal) Date: Sun, 13 Jan 2002 09:58:33 -0800 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > this discussion is hard enough already. let's not drift into who acts how > and who loves whom, please. thanks. then you must disallow all arguments of the form "whether or not a distant zone editor is able to choose which of their subdomains to authenticate is something i care about for reason XYZ." i don't think you could or should do that. it is easier to have this argument than to try to prevent it. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 13:34:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13499 for ; Sun, 13 Jan 2002 13:34:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PpLP-000LAe-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 10:26:59 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PpLO-000LAX-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 10:26:58 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PpLO-000PbM-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 10:26:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4096A5293@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Derek Atkins , "Hallam-Baker, Phillip" Cc: Roy Arends , Ted Lindgreen , namedroppers Subject: RE: DS and Opt-in - a proposal Date: Sun, 13 Jan 2002 10:24:49 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C19C5F.95E2F5F0 Content-Type: text/plain; charset="iso-8859-1" OK so we are talking about 2.02*S rather than 0.02*S ?? So I was wrong! The difference between opt-in and not is TWO orders of magnitude... Debating points asside. I do not believe that any other group in the IETF would raise the bar to admitting a protocol modification to 'proove to us that there is absolutely no other way possible'. On any reasonable grounds we have demonstrated that the cost difference is overwhelming. Do we really have to continue to argue over whether the cost difference is the choice between negligible (and scalable) cost for Opt-in versus increasing the capacity of DNS 10 fold, or only 6 fold. OPT-IN scales, 2535 does not. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Saturday, January 12, 2002 10:37 PM > To: Hallam-Baker, Phillip > Cc: Roy Arends; Ted Lindgreen; namedroppers > Subject: Re: DS and Opt-in - a proposal > > > No, I understand the point. I was arguing that just because > you need to support the maxima of (1+X)*2*S does not mean > that you should expect to have two sets of SIGs at all times. > Considering that the current assumption is that X=.01 at > this time, we're talking about 2.02*S. > > -derek > > "Hallam-Baker, Phillip" writes: > > > Derek is missing the point here, the NOC has to have capacity > > for the peak load. The fact that key rollover is infrequent is > > irrelevant since you still have to plan capacity so you have > > that capability. > > > > > > Phillip Hallam-Baker FBCS C.Eng. > > Principal Scientist > > VeriSign Inc. > > pbaker@verisign.com > > 781 245 6996 x227 > > > > > > > -----Original Message----- > > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > > Sent: Saturday, January 12, 2002 3:59 PM > > > To: Roy Arends > > > Cc: Ted Lindgreen; namedroppers > > > Subject: Re: DS and Opt-in - a proposal > > > > > > > > > Roy Arends writes: > > > > > > > I was assuming that one will sign a zone with more then one > > > key, which > > > > will create more then one signature. If I want to do a > scheduled key > > > > rollover, then at some point before the rollover date I > > > signed the zone > > > > with 2 keys, and after the rollover with 2 keys, while the > > > two signing > > > > events share at least one key. To smoothen the rollover, > > > I'll sign with 3 > > > > keys. > > > > > > Ok, so the steady state of DS is (1+X)*S, with local maxima of > > > (1+X)*2*S during (infrequent) times of key rollover. > > > > > > > Example: > > > > > > > > at point 1, there are 2 keys, key A and B. Now, I want to > > > roll key A over > > > > to key C. > > > > > > Why would you have two keys at any particular steady-state time? > > > Sure, you need a second key during a rollover, but that > does not mean > > > you need to keep around a second set of signatures at all times. > > > > > > -derek > > > -- > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > Member, MIT Student Information Processing Board (SIPB) > > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > > warlord@MIT.EDU PGP key available > > > > > > > > > to unsubscribe send a message to > > > namedroppers-request@ops.ietf.org with > > > the word 'unsubscribe' in a single line as the message text body. > > > > > > > > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > ------_=_NextPart_000_01C19C5F.95E2F5F0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C19C5F.95E2F5F0-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 13:58:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13839 for ; Sun, 13 Jan 2002 13:58:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Ppi8-000Ljx-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 10:50:28 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Ppi7-000Ljr-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 10:50:27 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Ppi7-0000Gp-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 10:50:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20020113175833.AFFC928EEA@as.vix.com> In-Reply-To: <20020113175833.AFFC928EEA@as.vix.com> Message-ID: To: Paul A Vixie Cc: namedroppers@ops.ietf.org Subject: Re: paternalism, or just xenophobia? (was Re: DS and Opt-in - a proposal) From: Derek Atkins Date: 13 Jan 2002 13:41:00 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie writes: > > this discussion is hard enough already. let's not drift into who acts how > > and who loves whom, please. thanks. > > then you must disallow all arguments of the form "whether or not a distant > zone editor is able to choose which of their subdomains to authenticate is > something i care about for reason XYZ." > > i don't think you could or should do that. it is easier to have this > argument than to try to prevent it. You can choose not to authenticate a child zone. That is not the issue at hand. The quesiton is whether you can only authenticate part of a zone, and I think that the cut should be at the zone level. If you want to go through the extra step to make an unauthenticated portion of your network, you are more than welcome to do so. There is a very well-defined mechanism for doing so. We don't need Opt-In to make it possible. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 13:59:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13865 for ; Sun, 13 Jan 2002 13:59:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Pphy-000Ljo-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 10:50:18 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Pphx-000Lji-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 10:50:17 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Pphx-0000GX-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 10:50:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <2F3EC696EAEED311BB2D009027C3F4F4096A5293@vhqpostal.verisign.com> In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4096A5293@vhqpostal.verisign.com> Message-ID: To: "Hallam-Baker, Phillip" Cc: Roy Arends , Ted Lindgreen , namedroppers Subject: Re: DS and Opt-in - a proposal From: Derek Atkins Date: 13 Jan 2002 13:38:07 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Hallam-Baker, Phillip" writes: > OK so we are talking about 2.02*S rather than 0.02*S ?? > > So I was wrong! The difference between opt-in and not is > TWO orders of magnitude... What are you smoking, Phill? Whatever it is, can you get me some? How does a multiplier of 2 result in two orders of magnitude? Also, as has been said, with DS you don't get the 2.02*S, because you never need to have two complete sets of signatures. You only need two sets of KEY records with associated DS to the parents, but you never need to completely sign your zone with two keys to perform a key rollover. So, it really is 1.01*S. And that's the _additional_ data, not the ratio. We'd still need the zone-size and number-of-children zones in .COM to accurately determine this size increase. > On any reasonable grounds we have demonstrated that the > cost difference is overwhelming. Do we really have to > continue to argue over whether the cost difference is > the choice between negligible (and scalable) cost for > Opt-in versus increasing the capacity of DNS 10 fold, > or only 6 fold. Is a factor of 4-6 really overwhelming? > OPT-IN scales, 2535 does not. Who's talking 2535 Phill (well, except you)? Everyone else is assuming DS, except of course Verisign. Maybe because you feel DS makes Opt-in unimportant for pretty much anyone else and therefore oblitertes most of your arguments? > Phill -derek PS: At this point in time I believe this WG has hit a roadblock. I do not believe we can come to concensus on the importance of Opt-In. Perhaps the chairs can ask the ADs/IESG for guidance? -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 14:08:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14130 for ; Sun, 13 Jan 2002 14:08:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Ppt9-000M3A-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 11:01:51 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Ppt9-000M33-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 11:01:51 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Ppt9-0000Zx-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 11:01:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201131059.g0DAxDS11854@nic-naa.net> In-Reply-To: Message from "Hallam-Baker, Phillip" of "Sun, 13 Jan 2002 10:24:49 PST." <2F3EC696EAEED311BB2D009027C3F4F4096A5293@vhqpostal.verisign.com> To: "Hallam-Baker, Phillip" cc: Derek Atkins , Roy Arends , Ted Lindgreen , namedroppers , brunner@nic-naa.net Subject: Re: DS and Opt-in - a proposal Date: Sun, 13 Jan 2002 02:59:13 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Debating points asside. I do not believe that any other > group in the IETF would raise the bar to admitting a > protocol modification to 'proove to us that there is > absolutely no other way possible'. You missed the months long dance in provreg over whether registries could initiate instances of communication, or if notice of pending state update (registrar initiated inst-o-com) distribution was better, for some value of "better". I could mention IDN and the recent reordering and conversion issues, both being "intermediate mapping (tables) between subsets of iso10646" attempts contrary to the holy write of Unicode, and impossible to advance even when the "absolutely no other way possible" test has been met, but that would be a distraction into a real swamp. My point being that I don't share the perception that this WG is unreasonable. Eric to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 14:21:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14253 for ; Sun, 13 Jan 2002 14:21:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Pq42-000MM9-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 11:13:06 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Pq42-000MM2-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 11:13:06 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Pq42-0000sc-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 11:13:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from Derek Atkins of "13 Jan 2002 13:41:00 EST." Message-Id: <20020113190830.72B1728EEA@as.vix.com> From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: paternalism, or just xenophobia? Date: Sun, 13 Jan 2002 11:08:30 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > You can choose not to authenticate a child zone. That is not the > issue at hand. The quesiton is whether you can only authenticate > part of a zone, and I think that the cut should be at the zone level. ...for all zones, no matter what the wishes of the owners of those zones. > If you want to go through the extra step to make an unauthenticated > portion of your network, you are more than welcome to do so. There is > a very well-defined mechanism for doing so. We don't need Opt-In to > make it possible. ...as long as the zone owner is willing to split her zone and thus split her namespace in order to maintain this security model purity. if dns is a distributed, coherent, reliable, autonomous database, then will we now sacrifice "autonomous" in order to add "secure", resulting in a distributed, coherent, secure, reliable database? that may seem to some assembled here to be "a small thing". maybe it is a small thing (even though i don't think it is a small thing) but if so then its smallness should be debated in its own right, and not be some kind of implicit comealong. taking away some autonomy in order to add some security is antithetical to most internet services, protocols, and communities as i understand them. "whose zone is it, anyway?" to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 14:40:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14376 for ; Sun, 13 Jan 2002 14:40:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PqPa-000MxT-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 11:35:22 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PqPZ-000MxN-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 11:35:21 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PqPZ-0001TL-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 11:35:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20020113190830.72B1728EEA@as.vix.com> In-Reply-To: <20020113190830.72B1728EEA@as.vix.com> Message-ID: To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: paternalism, or just xenophobia? From: Derek Atkins Date: 13 Jan 2002 14:22:49 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul, There are tons of "rules" that DNS operators must live by: - A records must be of a certain form, and must be sent on the wire in a certain form. Same for every other record. Why can't you send data in any format you wish? - Node names are limited to a subset of ascii. Why can't you include any character that you want in your node names? - Host names must begin with an alpha character. Why can't I have a host named "1234"? There are tons of rules. We have to live by them. They exist to make sure there is a clear understanding between the person that puts the data into the system and the person that is using that data at the other end. DNSSec is just like this. It is a data format requirement. It's not saying anything about _what_ you put in the DNS. It's just saying _HOW_ you must put it in the DNS. You are still free to name your hosts whatever you want, put whatever information you care to in your zone. But if you want to provide authenticated information, this is how you do it. I don't see a problem with that. -derek Paul Vixie writes: > > You can choose not to authenticate a child zone. That is not the > > issue at hand. The quesiton is whether you can only authenticate > > part of a zone, and I think that the cut should be at the zone level. > > ...for all zones, no matter what the wishes of the owners of those zones. > > > If you want to go through the extra step to make an unauthenticated > > portion of your network, you are more than welcome to do so. There is > > a very well-defined mechanism for doing so. We don't need Opt-In to > > make it possible. > > ...as long as the zone owner is willing to split her zone and thus split > her namespace in order to maintain this security model purity. > > if dns is a distributed, coherent, reliable, autonomous database, then > will we now sacrifice "autonomous" in order to add "secure", resulting in > a distributed, coherent, secure, reliable database? > > that may seem to some assembled here to be "a small thing". maybe it is > a small thing (even though i don't think it is a small thing) but if so > then its smallness should be debated in its own right, and not be some > kind of implicit comealong. > > taking away some autonomy in order to add some security is antithetical > to most internet services, protocols, and communities as i understand them. > > "whose zone is it, anyway?" > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 14:40:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14387 for ; Sun, 13 Jan 2002 14:40:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PqPC-000Mwu-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 11:34:58 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PqPC-000Mwo-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 11:34:58 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PqPC-0001Sf-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 11:34:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201131913.g0DJDai09518@birch.ripe.net> In-Reply-To: Message from Roy Arends of "Sun, 13 Jan 2002 14:09:56 +0100." <20020113132416.H54445-100000@node10c4d.a2000.nl> To: Roy Arends cc: Derek Atkins , namedroppers , Ted Lindgreen Subject: Re: DS and Opt-in - a proposal Date: Sun, 13 Jan 2002 20:13:36 +0100 From: Olaf Kolkman Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit * I've a lock on the front and back door of my house. That is by choice. * I will protest if I must have locks on every door, including the * kitchen-sink. * * Opt-In offers a choice. Some may not like that choice. I do. But your insurance company may force you to secure the kitchen sink door to make the system of houses as a whole more secure. Enabling more granularity makes the system less secure. I am not worried about OPT-IN at TLD level but for OPT-IN deployed at the end nodes. As mentioned before an "OPT-IN" that would not allow granularity on anything else but delegation records would solve my worries. The restriction would be worded something like: "Any name (key) in the DNS that has only NS RRs MAY not have a NXT (opt-in style) RR. Any other RR MUST have a NXT RR." This allows deployment in large G|TLDs and disallows the use of OPT in at end-node zones, providing fully secured zones. The complexity added is IMHO not prohibitively expensive. --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. From owner-namedroppers@ops.ietf.org Sun Jan 13 14:43:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14436 for ; Sun, 13 Jan 2002 14:43:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PqPK-000MxH-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 11:35:06 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PqPJ-000MxA-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 11:35:05 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PqPJ-0001Su-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 11:35:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200201131913.g0DJDai09518@birch.ripe.net> In-Reply-To: <200201131913.g0DJDai09518@birch.ripe.net> Message-ID: To: Olaf Kolkman Cc: Roy Arends , namedroppers , Ted Lindgreen Subject: Re: DS and Opt-in - a proposal From: Derek Atkins Date: 13 Jan 2002 14:16:33 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf Kolkman writes: > The restriction would be worded something like: "Any name (key) > in the DNS that has only NS RRs MAY not have a NXT (opt-in style) > RR. Any other RR MUST have a NXT RR." > > This allows deployment in large G|TLDs and disallows the use of OPT in > at end-node zones, providing fully secured zones. The complexity added > is IMHO not prohibitively expensive. What about glue A records at the TLDs? > --Olaf -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 15:48:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15075 for ; Sun, 13 Jan 2002 15:48:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PrH7-000ECU-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 12:30:41 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PrH6-000EBh-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 12:30:40 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PrH6-0003Er-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 12:30:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201132022.g0DKMJi19274@birch.ripe.net> In-Reply-To: Message from Paul Vixie of "Sun, 13 Jan 2002 09:25:27 PST." <20020113172527.BD66428EEA@as.vix.com> To: Paul Vixie cc: namedroppers Subject: Re: paternalism, or just xenophobia? (was Re: DS and Opt-in - a proposal) Date: Sun, 13 Jan 2002 21:22:19 +0100 From: Olaf Kolkman Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It's Sunday night, after a corpulent dinner I might have lost coherency in the argumentation, but let's give it a try. * opposition to opt-in on the grounds of preventing "too many choices" seems * to imply that "the set of all resolver owners" ought to have the ability * to control what a zone owner is allowed to publish. There are two parties that can make choices here. The zone holders and the resolver holders. Your arguments for the autonomy for zone holders is clear. But the resolver owners also have their autonomy. Resolver holders may choose not enable to enable security on their systems if there is to little data signed or if it is to expensive to troubleshoot problems. I am afraid that the incentive for resolver operators is not as high if only a few names in the DNS are secured; in an OPT-IN world that would be the case because the autonomy and the freedom of choice exists. Then again, in a non-opt-in world one could argue that resolver operators would not turn on security as long as it is not deployed in .com. I always thought that DNSSEC was designed to secure the DNS system as a whole. I would say that is something as a 'public good'. Not allowing the granularity introduced with opt-in would be of public interest but limits individual choice. Isn't it 'Politics' that is about finding the proper balance between public good and individual choice ;-) . Since the IETF is (should) not (be) doing politics it should not be trying to define the balance between 'choice' and 'good'. The balance should have been defined in the requirements. I have still not extracted the answer from the requirements but always understood that the system as a whole needed securing. Hence my (repeating) argument about not adding granularity or freedom of choice as others call it. --Olaf (I will try not to repeat myself in the future.. :-) ) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 15:48:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15086 for ; Sun, 13 Jan 2002 15:48:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PrHF-000EF4-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 12:30:49 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PrHE-000EEx-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 12:30:48 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PrHE-0003XP-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 12:30:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20020113132416.H54445-100000@node10c4d.a2000.nl> <200201131913.g0DJDai09518@birch.ripe.net> Message-Id: From: Randy Bush To: Olaf Kolkman Cc: namedroppers Subject: Re: DS and Opt-in - a proposal Date: Sun, 13 Jan 2002 12:25:33 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Enabling more granularity makes the system less secure. and harder to know what security one has randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 13 15:52:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15123 for ; Sun, 13 Jan 2002 15:52:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PrCN-000Agw-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 12:25:47 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16PrCM-000Agk-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 12:25:46 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16PrCM-0001KB-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 12:25:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201132013.g0DKDMi17899@birch.ripe.net> In-Reply-To: Message from Derek Atkins of "13 Jan 2002 14:16:33 EST." To: Derek Atkins cc: Roy Arends , namedroppers , Ted Lindgreen Subject: Re: DS and Opt-in - a proposal Date: Sun, 13 Jan 2002 21:13:21 +0100 From: Olaf Kolkman Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Derek Atkins writes: * What about glue A records at the TLDs? Those should be left alone... just as in 2535. "All data for which the zone holder is authoritative MUST have a NXT record. The NXT record MAY be used to authoritatively indicate that a delegation exist and is insecure." I think this formulation works since a zone is not authoritative for delegation NS and Glue. Each secured delegation would add a DS record for which the parent zone is authoritative, so the NXT must be present by virtue of the DS RR. The "MAY" clause reflects the "NULL key", providing authenticated denial of security for the child zone. --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. From owner-namedroppers@ops.ietf.org Sun Jan 13 17:19:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15545 for ; Sun, 13 Jan 2002 17:19:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Pso3-000Cvw-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 14:08:47 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Pso2-000Cvp-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 14:08:46 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Pso2-000HXu-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 14:08:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from Derek Atkins of "13 Jan 2002 14:22:49 EST." Message-Id: <20020113215733.C95D628EEA@as.vix.com> From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: paternalism, or just xenophobia? Date: Sun, 13 Jan 2002 13:57:33 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit derek wrote: > There are tons of "rules" that DNS operators must live by: yes indeed, we must follow the protocol or we risk not being understood. i am not arguing for the freedom to deviate from the protocol, because that would be meaningless. protocols, to be useful or meaningful, must be followed. (your examples were flawed in their details: names should not be completely numeric outside of in-addr.arpa but are allowed to start with digits; and, the protocol spec actually says you can send 8-bit data in name fields, but sloppily forgets to explain what non-ascii means at the presentation layer. however, this discussion doesn't depend on the accuracy of your examples -- let's just agree that we have to agree follow the protocol in order for it to _be_ a "protocol".) however, we're not in agreement as to the actual point under discussion, which is subtly different from whether we all plan to follow protocols. > There are tons of rules. We have to live by them. They exist to > make sure there is a clear understanding between the person that > puts the data into the system and the person that is using that > data at the other end. > > DNSSec is just like this. It is a data format requirement. It's > not saying anything about _what_ you put in the DNS. It's just > saying _HOW_ you must put it in the DNS. You are still free to > name your hosts whatever you want, put whatever information you > care to in your zone. But if you want to provide authenticated > information, this is how you do it. I don't see a problem with > that. nothing else in the protocol (which we all agree to follow, or else it won't _be_ a protocol or at least not a relevant or active one) attempts to ram policy down a zone owner's throat, even to the point of removing or limiting features that a protocol designer thinks would be bad for the internet. to pick one of your examples, the reason multilingual names didn't work on day 1 is that nobody who was doing the work cared enough to do all the hard definition-level work that we now see in the IDN WG. *NOT* because we thought multilingual names were a bad idea and that the whole world ought to be using 7-bit USASCII. leaving a proposed feature out is sometimes (often!) the right thing to do. "good" reasons for doing this include: expect it to take a lot of work and there's no volunteer expect it to take a lot of time and we don't want to wait nobody's asking for it except dwellers in some ivory tower there are workarounds that cost less than the added complexity what i'm seeing in the paternalistic debate pattern here is a "bad" reason: we don't think the internet ought to be allowed to work that way "whose zone is it anyway?" paul to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 14 01:40:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20902 for ; Mon, 14 Jan 2002 01:40:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Q0Ta-000AaH-00 for namedroppers-data@psg.com; Sun, 13 Jan 2002 22:20:10 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Q0TZ-000AaA-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 22:20:09 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Q0TZ-00037K-00 for namedroppers@ops.ietf.org; Sun, 13 Jan 2002 22:20:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020114061618.GA21507@zed.isi.edu> References: In-Reply-To: Date: Sun, 13 Jan 2002 22:16:18 -0800 From: Bill Manning To: Randy Bush Cc: namedroppers Subject: Re: draft minutes Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It would be helpful if full names (attrribution) could be provided. While there is only one vixie, there are several bills. --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 14 11:58:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06723 for ; Mon, 14 Jan 2002 11:58:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QA8i-000OIs-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 08:39:16 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16QA8h-000OIk-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 08:39:15 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16QA8h-000M1P-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 08:39:15 -0800 Message-Id: <200201092102.QAA15219@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-song-dnsext-nai-support-00.txt Date: Wed, 09 Jan 2002 16:02:11 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DNS RR type for NAI Author(s) : J. Song et al. Filename : draft-song-dnsext-nai-support-00.txt Pages : 6 Date : 08-Jan-02 This document proposes the use of the new DNS RR type 'NAI' to specify the most current location of the user(Host IP address). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-song-dnsext-nai-support-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-song-dnsext-nai-support-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-song-dnsext-nai-support-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. --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: <20020108150609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-song-dnsext-nai-support-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-song-dnsext-nai-support-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020108150609.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. From owner-namedroppers@ops.ietf.org Mon Jan 14 11:59:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06769 for ; Mon, 14 Jan 2002 11:59:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QA0O-000O7r-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 08:30:40 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16QA0O-000O7l-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 08:30:40 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16QA0O-000Lmu-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 08:30:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201140959.KAA18430@omval.tednet.nl> In-Reply-To: "Derek Atkins's message as of Jan 13, 19:41" From: ted@tednet.nl (Ted Lindgreen) Date: Mon, 14 Jan 2002 10:59:44 +0100 To: Derek Atkins Subject: The final word about size, was: DS and Opt-in - a proposal Cc: namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Derek Atkins, on Jan 13, 19:41, in "Re: DS and Opt-in - ..."] .... > PS: At this point in time I believe this WG has hit a roadblock. > I do not believe we can come to concensus on the importance of > Opt-In. Perhaps the chairs can ask the ADs/IESG for guidance? Hi Derek, I don't think it's that bad, on te contrary, I think this dispute has reached full consensus. After several people cleared up the misunderstading and explained that the need for double, threefold and even fivefold SIG sets is obsoleted by DS, it is both clear where the fear for giant zonefiles came from, and what the real numbers are. Let's compile it: - There was no dispute, that the number of RRs in a TLD zone file increase from 3N to 5N in one step without OptIn and smoothly with Opt-In. - About the size there was somewhat more variation, but all came in the end to something less than a factor of 6, and an actual signing experiment has shown it to be 4 for .com with a 768-bit signature. Perhaps some people want to argue a little more on the effect of above growth on the DNS operation, but I am convinced that nobody will dispute that this growth is survivable. And thus, this point is off the table. -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 14 12:22:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07971 for ; Mon, 14 Jan 2002 12:22:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QAS9-000Om9-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 08:59:21 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16QAS8-000Om3-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 08:59:20 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16QAS8-000MZh-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 08:59:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020114150336.0ecaad8e.olaf@ripe.net> In-Reply-To: References: <20020113132416.H54445-100000@node10c4d.a2000.nl> <200201131913.g0DJDai09518@birch.ripe.net> Date: Mon, 14 Jan 2002 15:03:36 +0100 From: "Olaf M. Kolkman" To: Randy Bush Cc: namedroppers@ops.ietf.org Subject: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 13 Jan 2002 12:25:33 -0800 Randy Bush wrote: > > Enabling more granularity makes the system less secure. > > and harder to know what security one has > Rephrasing an idea so that it stands out a little more. DNS administrators and users have all learned to deal with the concept of zones. In the DNS changes appear at zone cuts. Let's keep things easy for the troubleshooters and not allow 'security' changes within zones. If we allow for OPT-IN over delegations only we solve the apparent large zones problem and we keep security at zone levels. Suggested wording for the draft: "All data for which the zone holder is authoritative MUST have a NXT record. The NXT record MAY be used to authoritatively indicate that a delegation exist and is insecure." --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 14 12:35:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08645 for ; Mon, 14 Jan 2002 12:35:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QAgw-000P8p-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 09:14:38 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16QAgv-000P8j-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 09:14:37 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16QAgv-000Mzg-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 09:14:37 -0800 Message-Id: <200201141538.KAA04308@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-delegation-signer-05.txt Date: Mon, 14 Jan 2002 10:38:53 -0500 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 : Delegation Signer record in parent Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-delegation-signer-05.txt Pages : 13 Date : 11-Jan-02 The Delegation Signer Resource Record is inserted at a zone cut point to indicate tha the delegated zone is digitally signed and that the delegation zone recognizes the indicated key as a valid zone key for the delegated zone. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-delegation-signer-05.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-delegation-signer-05.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: <20020111152226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-delegation-signer-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020111152226.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. From owner-namedroppers@ops.ietf.org Mon Jan 14 12:38:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08856 for ; Mon, 14 Jan 2002 12:38:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QAoh-000PNH-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 09:22:39 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16QAog-000PNB-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 09:22:38 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16QAog-000NDt-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 09:22:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4096A5366@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Derek Atkins , "Hallam-Baker, Phillip" Cc: Roy Arends , Ted Lindgreen , namedroppers Subject: RE: DS and Opt-in - a proposal Date: Mon, 14 Jan 2002 08:31:01 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dereck writes > "Hallam-Baker, Phillip" writes: > > > OK so we are talking about 2.02*S rather than 0.02*S ?? > > > > So I was wrong! The difference between opt-in and not is > > TWO orders of magnitude... > > What are you smoking, Phill? Whatever it is, can you get me some? > > How does a multiplier of 2 result in two orders of magnitude? Also, > as has been said, with DS you don't get the 2.02*S, because you never > need to have two complete sets of signatures. 2.02 * S / 0.02 * S = 101 The point is the baseline you choose. So far we have been suckered into the bogus argument that the difficulty of running DNS is an acceptable baseline, it is not. The proper way to measure the difference in cost is: Additional cost of 2535 deployment / Additional cost of OPT IN > Is a factor of 4-6 really overwhelming? If you are the one who has to write the cheque, yes. Phill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 14 12:41:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08958 for ; Mon, 14 Jan 2002 12:41:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QAnC-000PLR-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 09:21:06 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16QAnC-000PLK-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 09:21:06 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16QAnC-000NB0-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 09:21:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4096A5363@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Derek Atkins , Roy Arends Cc: Olaf Kolkman , namedroppers , Ted Lindgreen Subject: RE: DS and Opt-in - a proposal Date: Mon, 14 Jan 2002 08:27:02 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > And if everyone in the universe gets this choice, we wont be any > better than we are now, because nobody is willing to go to the > extra effort to add security if they don't have to. > > When it comes to scurity, choices are a Bad Idea (TM). The more > choices you have, the more possibility you have to shoot yourself > in the foot. Derek, I am surprised that you make the mistake of confusing the number of options with the complexity of the solution. Options are one way of introducing unnecessary complexity, but they are not the only way. The issue is how the debate is framed. if the benchmark for comparison is the existing complexity of DNS then 2535 increases data volume by a factor of six or ten depending on the assumptions made. If however the comparison is made to the ADDITIONAL cost of deploying DNSSEC the picture looks entirely different. The first DNSSEC secured zone in dotcom requires a sixfold increase in the support infrastructure. That is a vast and unacceptable increase in the complexity of managing the TLD. Lack of choices is a far worse option when they prevent the deployment of the protocol or force the operators of the large TLDs to deploy a non-standard protocol. The proper terms in which to frame the debate is which solution is better, 2535 or 2535+OPT IN? The group has accepted a change that is not backwards compatible. The argument that OPT-IN will cause delay is now vaccated. The only argument being advanced in favor of 2535 is that it is the status quo. People in the group should wake up and realise that the status quo is non-deployment. The general opinion of the DNSSEC spec outside the group is that the group has been dragging its feet for too long and that the failure to deploy reflects on the quality of the spec. The rush to corronate 2535 as a standard while deployment remains at the experimental stage is not going to be very credible. Advancing a backwards incompatible change (DS) while refusing to admit OPT-IN is going to appear incredible. Phill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 14 12:52:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09472 for ; Mon, 14 Jan 2002 12:52:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QAzX-000Phy-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 09:33:51 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16QAzW-000Phs-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 09:33:50 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16QAzW-000NWz-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 09:33:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4096A5388@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Olaf Kolkman , Paul Vixie Cc: namedroppers Subject: RE: paternalism, or just xenophobia? (was Re: DS and Opt-in - a p roposal) Date: Mon, 14 Jan 2002 09:02:21 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Isn't it 'Politics' that is about finding the proper balance between > public good and individual choice ;-) . The group does not have the power to take away individual choice. What if OPT-IN is deployed in the largest zones before the group accepts the draft? Phill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 14 13:57:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12759 for ; Mon, 14 Jan 2002 13:57:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QC2r-0001Ya-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 10:41:21 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16QC2r-0001YU-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 10:41:21 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16QC2r-000PNs-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 10:41:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201141024.g0EAOYS14817@nic-naa.net> In-Reply-To: Message from "Hallam-Baker, Phillip" of "Mon, 14 Jan 2002 09:02:21 PST." <2F3EC696EAEED311BB2D009027C3F4F4096A5388@vhqpostal.verisign.com> To: "Hallam-Baker, Phillip" cc: Olaf Kolkman , Paul Vixie , namedroppers , brunner@nic-naa.net Subject: Re: paternalism, or just xenophobia? (was Re: DS and Opt-in - a p roposal) Date: Mon, 14 Jan 2002 02:24:34 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The group does not have the power to take away individual choice. > > What if OPT-IN is deployed in the largest zones before the group > accepts the draft? Like RACE? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 14 13:57:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12792 for ; Mon, 14 Jan 2002 13:57:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QC4V-0001a9-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 10:43:03 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16QC4V-0001a3-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 10:43:03 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16QC4V-000PQu-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 10:43:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from "Hallam-Baker, Phillip" of "Mon, 14 Jan 2002 09:02:21 PST." <2F3EC696EAEED311BB2D009027C3F4F4096A5388@vhqpostal.verisign.com> Message-Id: <20020114181950.528C928EFE@as.vix.com> From: Paul Vixie To: namedroppers Subject: Re: paternalism, or just xenophobia? (was Re: DS and Opt-in - a p roposal) Date: Mon, 14 Jan 2002 10:19:50 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > What if OPT-IN is deployed in the largest zones before the group > accepts the draft? then the community's will will become even more ill toward verisign than already seems to be the case. please don't dig your hole any deeper while several of us here are trying to get you out of the one you've dug earlier. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 14 14:02:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13023 for ; Mon, 14 Jan 2002 14:02:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QC42-0001Zx-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 10:42:34 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16QC41-0001Zn-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 10:42:33 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16QC41-000PQ8-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 10:42:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <2F3EC696EAEED311BB2D009027C3F4F4096A5388@vhqpostal.verisign.com> Message-Id: From: Randy Bush To: "Hallam-Baker, Phillip" Cc: namedroppers Subject: RE: paternalism, or just xenophobia? (was Re: DS and Opt-in - a p roposal) Date: Mon, 14 Jan 2002 10:39:03 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The group does not have the power to take away individual choice. indeed, you dan run decnet if you wish. > What if OPT-IN is deployed in the largest zones before the group > accepts the draft? we will all ignore it. we have all been here before. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 14 14:07:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13391 for ; Mon, 14 Jan 2002 14:07:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QC8k-0001jl-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 10:47:26 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16QC8k-0001jf-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 10:47:26 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16QC8k-000PZC-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 10:47:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <3C1E3607B37295439F7C409EFBA08E680E287E@COL-581-EXS01> From: "Loomis, Rip" To: "'Hallam-Baker, Phillip'" , Derek Atkins Cc: Roy Arends , Ted Lindgreen , namedroppers Subject: RE: DS and Opt-in - a proposal Date: Mon, 14 Jan 2002 13:45:20 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Monday, 14 January, 2002 11:31 > The proper way to measure the difference in cost is: > > Additional cost of 2535 deployment / Additional cost of OPT IN > > > Is a factor of 4-6 really overwhelming? > > If you are the one who has to write the cheque, yes. It is increasingly clear (to me at any rate) that 2535 is less and less likely to see widescale deployment without DS. Therefore it would appear that the proper way to measure the "difficulty factor" of signing .com without Opt-in is: Additional cost of (2535+DS) / Additional cost of (2535+DS+Opt-In) (Note that I believe the real-world time to implement 2535+DS in DNS software is essentially equivalent to the real-world time to implement 2535+DS+Opt-In.) I believe that the difficulty factor above is *not* two orders of magnitude. NEXT: On to my overly-long set of statements/comments, now that I've opened my mouth. Some of the discussions that have come up would appear to be strongly into the political and philosophic. I'm more of a libertarian and would prefer that DNS allow, "an it harm none, do what ye will". However, I would state that: - DNSSEC will cause much discombobulation, pain, and agony no matter which implementation is done at this point. DNSSEC is believed to be worth the pain and agony *not* because we're trying to protect a few specific nodes that have "higher" value--DNSSEC is needed to address basic weaknesses in the current protocol that have been exploited in the past. We're not just trying to do for DNS what SSL server certificates have done for HTTP. [0] - If Opt-in is allowed to be used at *all* levels of the DNS hierarchy, then the basic protocol issues will never be fully addressed. (I still occasionally wonder if DNS v2.0 is the right answer...) If Opt-in is allowed only on *specific* zones, it is not clear what reasonable set of restrictions can be used to limit it only to those zones that "really" need it. - Even if it is made clear that Opt-In is only allowable for zones that meet all three of these (notional) criteria: 1. Must be a gTLD or ccTLD 2. Must consist largely (>95%) of delegations 3. Must contain at least 10000 distinct and unique nodes then I still believe that Opt-In creates a scenario that causes more confusion to both users and administrators of the exact "is it secured?" status for each zone/node. That confusion will severely hamper the acceptance and usage of DNSSEC. I'm not part of The Security Mafia, but I'm here on behalf of a different security mafia with a decent-sized DNS hierarchy. If the only way that we can get .com to be signed is to accept Opt-In, then I believe that DNSSEC will never move very far beyond the "small pockets of signed zones" model. That is not, and has never been to my knowledge, the stated end goal of DNSSEC--and *that* is why I still can't back Opt-In. OTOH, if we can't get $LARGE_GTLD signed, we're also stuck in the "small pockets of signed zones" model for much of the net. I don't like that answer either, and it's become clear that VeriSign/NSI strongly believes that this is a point worth fighting. ICANN is unlikely to give instructions that require signing of .com using 2535+DS, and VeriSign would not appear interested in signing .com without Opt-In. [1] Can anyone of the well-qualified folks who bothered to read this far give a non-biased flame-free summary of the 5 most critical plusses/minuses of the current Opt-In proposal, to summarize the last 50 messages on the subject? I believe that we may in fact need to ask for guidance from on high, and I don't believe that we yet have such a summary of the status. Very Respectfully, -- Rip Loomis Senior Systems Security Engineer SAIC Center for Information Security Technology [2] [0] If DNSSEC had been fully fielded prior to HTTP, then SSL certificates would still have been worthwhile to provide for session privacy--but *some* of the sites that use HTTPS for essentially all transactions right now are doing it because DNSSEC is still not fielded. [1] If the necessary infrastructure improvements would be in the back-end database portion that gets billed equally to all registrars (and passed on by them to their customers), then it seems that the additional cost would not bankrupt VeriSign. Perhaps I just don't understand the business model well enough (which is likely). But...what *really* gets me torqued is that VeriSign has known for *years* that DNSSEC would likely happen one day, and that it *would* require additional resources. Do the additional resource requirements now come as a complete surprise? [2] Note that as an SAIC employee-owner, I have some financial interest in VeriSign/NetSol. I *still* want .com signed sooner rather than later, preferably the whole stinkin' thing. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 14 14:22:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14217 for ; Mon, 14 Jan 2002 14:22:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QCRp-0002HR-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 11:07:09 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16QCRp-0002HJ-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 11:07:09 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16QCRp-00009X-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 11:07:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201141900.OAA06836@error-messages.mit.edu> Date: Mon, 14 Jan 2002 14:00:13 -0500 From: Greg Hudson To: namedroppers@ops.ietf.org Subject: Opt-in for insecure delegations only Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit So, let's say we accept Olaf's proposal to allow opt-in only at insecure delegation points. That is, you MUST have NXT records for all data you are authoritative for, and you MAY have NXT records for insecure delegations. The lack of the opt-in bit indicates that you're using NXT records for insecure delegations, and thus protects against insertion of insecure delegations in most domains. Verisign should be happy because they can incrementally sign .com. Even if the .com servers could accept a four- to six-fold increase in the size of the zone, it seems technically superior to allow the largest zones to expand smoothly. The rest of us should all be happy because authoritative data gets signed on zone cuts. The only data which you can opt out of signing is an insecure delegation, which kicks you out of the protected world anyway. So what's left to argue about? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 14 15:04:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16313 for ; Mon, 14 Jan 2002 15:04:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QD4Z-0003Fu-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 11:47:11 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16QD4Z-0003Fo-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 11:47:11 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16QD4Z-0001Ju-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 11:47:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <20020114150336.0ecaad8e.olaf@ripe.net> Message-ID: <20020114134106.E25998-100000@hlid.dc.ogud.com> Date: Mon, 14 Jan 2002 14:38:27 -0500 (EST) From: Olafur Gudmundsson To: "Olaf M. Kolkman" cc: Randy Bush , Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 14 Jan 2002, Olaf M. Kolkman wrote: > On Sun, 13 Jan 2002 12:25:33 -0800 > Randy Bush wrote: > > > > Enabling more granularity makes the system less secure. > > > > and harder to know what security one has > > > Rephrasing an idea so that it stands out a little more. > > DNS administrators and users have all learned to deal with the concept of > zones. In the DNS changes appear at zone cuts. Let's keep things easy for > the troubleshooters and not allow 'security' changes within zones. > > If we allow for OPT-IN over delegations only we solve the apparent > large zones problem and we keep security at zone levels. This argument has been made before (by Olaf and myself) and has been pushed back by the advocates of opt-in and some others. The effect of opt-in is to create a "selective security" for any name in a DNS zone. The argument that I want to make is about the maintainance of zone with some names secured and some insecure, has the potential to be an administrative nightmare, as there must be an indicator for each name (or sequence of names) that indicates when to sign and generate NXT. Background: RFC2065 and RFC2535 allow any authoriized key to sign DNS data at and below that name, RFC3008 outlawed this and restricts signatures to zone key residing in at the top of the zone. The cost of supporting this choice was to add $SIGNER directives all over the zone file, frequently resulting in the attempt to sign data with the wrong key. Verifying the data was much harder as more keys where allowed to sign the data (apex zone key and some user/host keys). If only delegations can are covered by opt-in then it is simpler, opt-in, any delegation that has DS is signed, only insecure delegations that are to be signed need an flag to trigger signing. For organization like Verisign that generates their zone files from a backend database system and prefer to generate the appropriate NXT outside the signing tool, supporting Opt-in is trivial, but for the people that use standard flat text files things get harder. The fewer execptions features we allow, the better off we are in the long run. Is there anyone else out there that supports Olaf's position ? If Olaf and I are a minority of two, I will shut up about this. > > Suggested wording for the draft: > > "All data for which the zone holder is authoritative MUST have a NXT > record. The NXT record MAY be used to authoritatively indicate that a > delegation exist and is insecure." Slightly different wording: All names in a secure zone that have signed records MUST have a signed NXT, delegations MAY have a signed NXT to indicate that they exist and are insecure. 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. From owner-namedroppers@ops.ietf.org Tue Jan 15 00:26:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05067 for ; Tue, 15 Jan 2002 00:26:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QLx8-000Bo1-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 21:16:06 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QLx8-000Bnv-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 21:16:06 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QLx7-0003vl-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 21:16:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Randy Bush To: minutes@ietf.org Cc: namedroppers Subject: dnsext minutes Date: Mon, 14 Jan 2002 15:43:43 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ it is said that bill is a multicast address, but there was no help in disambiguation ] multicast dns - is this the right solution? ?: is it the same protocol, or new protocol? reuse of the port number, reuse of the packet format ?: when we started, "behavior just like DNS" operational problem, conceptual problem alain: icmp6 name lookup - one solution looked at (but was not provided for ipv4) aboba: no set of goals stated, document is ready for ietf last call something gone very wrong. is this solving the right problem? is there a better solution? mohta: zeroconf is not a good thing to pursue. if we don't want client configuration, dns servers having wellknown anycast addresses work fine ?: would like to do "infrared" thing that palm does, or appletalk. need some mechanism for resolving name. rob: there are people with different goals. ?: it is a good way to reuse DNS. we won't be able to solve the problem even if we start fresh aboba: if zeroconf requirement is broken? olafur: zeroconf is a part of requirement. --- dns threat model (rob) examine why dnssec was started dnssec ensures data item is the same when they are put in, and when they are pulled out lack of threat model? dnssec has dependency on time sync. --- delegation signer (olafur) motivation key record repeats the mistake of ns record in delegations, same record in two zones key at child is clumbersome parent advertises strong identifier of key used resolver verifies DS record from parent only verifies key if sig matches verified DS DS advantages information flow in key handshake is now identical to NS minimizes communication only when hcild changes KEY set signing key less data in parent DS much small than key DS only at secdure delegation child in full control of security status no conflicting key sets disadvantages: more work for resolvers. 3 implementations what change from the last IETF NODS in NXT bitmap at unsecured delegations DS can only pont at DS zone keys that can sign zone key size field dropped server returning... DS complicates life for resolvers chop off 2535, or DS, or opt-in next steps DS seem to work DS makes DNSSEC much/some easier for operations DS increments complexity in resolvers advance or discard? ?: is it really advantageous to have less data in parent? less state - similar to opt-in minimizes communication deployability difference for big zones how much better should combine discussion for opt-in it is advantageous that downstream reload does not happen when upstream key changes balance: decoupling child signing and parent signing - weakening security outband or inband? key rollover for .com - 6month, 2 key alive at one time (comments continue after opt-in talk) --- opt-in dnssec painful for large zones huge upfront cost null KEYS, nxt RR and signatures for child zones that are not secure little initial deployment high generation cost ordering re-signing distributing changes since 00 total rewrite goal is the same, different methods NXT indicates opt-in instead of KEY opt-in uses noSig techniques basically, finer granurality, opt-in 2535 choice can be made on per-record (instead of per-zone) 2535 NXT - authenticated denial of existence of names does not allow unsigned names opt-in NXT - authenticated denial of existence of SIGNED names does allow unsigned names 2535 - positive answer = this delegation is not signed the unsigned name exist (crypto verifiable) opt-in - negative answer = there exist no signed delgation between two signed names the unsigned name exist (not crypto verifiable) pros and cons every advantage has disadvantages positive: opt-in reduces the amount of crypto in a zone negative: opt-in gives up authenticated denial of existence for unsecured delegations (give up security for unsecured data item) don't "like" opt-in? sign it with 2535 opt-in does not obsolete 2535 positive side-effect traversing a zone through NXT recodrs gives only signed names and signed delegations a chain of secure delegations is possible without the requirement to sign the whole zone 2535 is not "better " ot "worse" than opt-in 2535 has advantages for the average zone opt-in has advantages for the delegation-only zone (large zone) randy: change in security model. attacking the problem of size by a protocol change, and security model change. assumption - the little part of zone gets signed. ?: it is already hard to keep up hardware with .com size. vixie: losing ability to cryptographically prove non-existence of names, or nonexistence of child signature, is it true? - not exactly. ?: it is up to zone owner. ?: we can mix 2535 and opt-in in a single zone. --- key desire to have algorithms separately documented. minimize dependency to 2535 key format draft documents standard moduli? --- AD bit outstanding issue ad draft status document passed working group last call, not sent out when can AD bit be set? AD = authenticated data AD draft says authoritative server can set the AD bit if local security policy allows comments on the mailing list afer last call disagree argument for text the issue only affects resolvers that trust server doing signature validation on all data loaded is expensive either slows loading or answers integrity of whole zones on servers can be protected by other means signed zone files, signed zone transfer against AD MUST only be set if signatures have been verified setting the AD bit under other conditions is wrong AA bit implies that the data is authentic suggestion authors must add text that clarify states that AD bit is not be set by default and MUST only be set if there are some other validity checks in place document must also document what [stub] resolvers are affected ?: 2535 says about AD bit - data satisfies the security policy of the server ?: what is "policy"? can you tell what kind of policy the server is implementing? ?: the situation happens only when you talk to authoritative zone. it should be your own domain, so you know the policy? ?: why you can't use AA bit for that? authors will update the draft. do we need DS? do we need opt-in? vixie: from test results, it seems (something like) DS is needed for key rollover opt-in is just a hack for one zone (.com) anyway we need to get this DONE. ?: opt-in is needed, to sign .com. can't deploy .com with 2535. ?: cost vs usefulness. cost is significant for large zones. ?: does opt-in break security of zones (= signed chain)? bill: interoperability between 2535 and DS? - yes, DS-capable resolvers can (but there is a flag day). olafur: we are doing this too long. for DS and opt-in, need go or nogo. ?: there are people who are trying to deploy 2535. too long wait. randy: agree with vixie. ?: not deployable as it is today. vixie: need to separate between deployability due to size, and other issues. does it matter if we sign .com today, or 2004? this needs to come to conclusion. during this week people will talk and try to come to conclusion, and then to the list. vixie: the reason why root is not signed is that dnssec is still seems to be in flux --- tkey securet key renewal mode necessary to refresh shared keys for tsig new mode for update procedure and mechanism in tkey renewal mode defined key has lifetime. during renewal, key lifetime overwraps tsig-signed query from client expiration time check server urges clients to send tkey renewal requests tkey secret key renewal request from client DH public key old key's name and algorithm answer from server establish new secret by DH TSIG-signed query with the new key from client server adopts the new key feature systematic control by server "renewal", not add/delete limit number of shared keys think about network errors. feel no need for this. server can delete the key when it expires. tkey is just for temporary measure. it is direciton we shouldn't go. --- dns mib proposed replacement for 1611 not ready for prime time yet. please read, test it and comment. need requirement document to start with. --- ngtrans dns op req problem: IPv4-only and IPv6-only nodes coexist, how to resolve? long term problem consequences - this working group has to do something. requirement single root requirement, applies for IPv4 and IPv6 dns is IP version independent application. need to be able to get the same data independent from data. we can change v6 things, we cannot change v4 things need some kind of bridging system, so that v6 only resolver can get data from v4 only server, or other ways need symmetry in bridging system? no. v4 resolver - no good way. zone needs to be served by dualstack node. v6 resolver - relaying system? leakage of information serve zones on dualstack node, period. --- dynamic update we assume that updated records gets eventually removed explicitly state an expiration time repeat of past effort. if we are going to repeat this one, requirement document is needed. we can't assume wall clock (powered off). there seem to be some need. --- application keys - limiting the scope of the key resource record simple idea - restrict KEY to dnssec. dnssec key vs application keys - looks like a different beast. reolver behavior is very different. separate rtype, SRV, KEY, ... protocol specific flag? attribute? should we separate pubkey and cert? we need a requirement document. (battery is out) -30- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 00:27:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05083 for ; Tue, 15 Jan 2002 00:27:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QLtc-000BkW-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 21:12:28 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QLtc-000BkH-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 21:12:28 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QLtX-0003vR-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 21:12:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201150035.g0F0Zns11746@drugs.dv.isc.org> In-reply-to: Your message of "Mon, 14 Jan 2002 14:38:27 CDT." <20020114134106.E25998-100000@hlid.dc.ogud.com> To: Olafur Gudmundsson Cc: "Olaf M. Kolkman" , Randy Bush , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Date: Tue, 15 Jan 2002 11:35:49 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Is there anyone else out there that supports Olaf's position ? > If Olaf and I are a minority of two, I will shut up about this. I think it is a reasonable compromise. Mark -- Mark Andrews, Internet Software Consortium 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. From owner-namedroppers@ops.ietf.org Tue Jan 15 00:52:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05352 for ; Tue, 15 Jan 2002 00:52:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QMJI-000CA9-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 21:39:00 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QMJI-000CA3-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 21:39:00 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QMJH-0003x4-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 21:38:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20020114150336.0ecaad8e.olaf@ripe.net> <20020114134106.E25998-100000@hlid.dc.ogud.com> Message-Id: From: Randy Bush To: Olafur Gudmundsson Cc: namedroppers Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Date: Mon, 14 Jan 2002 14:56:31 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > All names in a secure zone that have signed records MUST have a signed > NXT, delegations MAY have a signed NXT to indicate that they exist and > are insecure. so, you are trying to kinda help authenticated denial. but, if the resolver does not know if the zone has NXTs for the insecure delegations or not, then the information seems not too useful. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 01:01:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05474 for ; Tue, 15 Jan 2002 01:01:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QMYY-000CRW-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 21:54:46 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QMYY-000CRP-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 21:54:46 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QMYX-0003xf-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 21:54:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: Date: Tue, 15 Jan 2002 00:47:50 -0500 (EST) From: Greg Hudson To: Randy Bush cc: namedroppers Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 14 Jan 2002, Randy Bush wrote: > > All names in a secure zone that have signed records MUST have a signed > > NXT, delegations MAY have a signed NXT to indicate that they exist and > > are insecure. > > so, you are trying to kinda help authenticated denial. but, if the resolver > does not know if the zone has NXTs for the insecure delegations or not, then > the information seems not too useful. I believe you're missing (because Olafur glossed over it) that the NXT records would still contain the bit saying whether or not the domain has NXT records for insecure delegations. That's already in the opt-in specification. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 03:03:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14930 for ; Tue, 15 Jan 2002 03:03:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QO2U-000DiS-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 23:29:46 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QO2T-000DiB-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 23:29:45 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QNzk-00041h-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 23:26:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from Greg Hudson of "Tue, 15 Jan 2002 00:47:50 EST." Message-Id: <20020115072535.3E4E428EB3@as.vix.com> From: Paul Vixie To: namedroppers Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Date: Mon, 14 Jan 2002 23:25:35 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I believe you're missing (because Olafur glossed over it) that the NXT > records would still contain the bit saying whether or not the domain has > NXT records for insecure delegations. That's already in the opt-in > specification. so the opt-in status of the zone (not domain) is itself optional? this raises the complexity to a new level. is there payback for this? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 03:12:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15069 for ; Tue, 15 Jan 2002 03:12:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QO2V-000DiV-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 23:29:47 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QO2U-000DiB-01 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 23:29:46 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QNzJ-00041Z-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 23:26:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from Mark.Andrews@isc.org of "Tue, 15 Jan 2002 11:35:49 +1100." <200201150035.g0F0Zns11746@drugs.dv.isc.org> Message-Id: <20020115072143.CE81528EB3@as.vix.com> From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Date: Mon, 14 Jan 2002 23:21:43 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I think it is a reasonable compromise. > > Mark well maybe, except it isn't enforceable. if someone somewhere decides to implement their NXT's without this restriction, the encoding will support them and convey unspecified meaning to resolvers. i'm more interested in the fact that this compromise is between two invalid positions. size arguments have been shown invalid by ted@nlnet, whereas paternalistic arguments have been shown invalid by me. rather than compromise between two invalid positions using an encoding which is undetectably violatable, i think we ought to reverse the sense of the poll. opt-in has been proposed. can anyone oppose it on grounds which are (a) technical and (b) not yet shown to be invalid? if not then i urge the chairs to put markk's latest draft out for last call. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 03:14:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15097 for ; Tue, 15 Jan 2002 03:14:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QO2V-000DiU-00 for namedroppers-data@psg.com; Mon, 14 Jan 2002 23:29:47 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QO2U-000DiB-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 23:29:46 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QNzZ-00041e-00 for namedroppers@ops.ietf.org; Mon, 14 Jan 2002 23:26:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from Randy Bush of "Mon, 14 Jan 2002 14:56:31 PST." Message-Id: <20020115072347.7A7B628EB3@as.vix.com> From: Paul Vixie To: namedroppers Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Date: Mon, 14 Jan 2002 23:23:47 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit to cause the break in tradition to be symmetric, "i agree with randy." > so, you are trying to kinda help authenticated denial. but, if the resolver > does not know if the zone has NXTs for the insecure delegations or not, then > the information seems not too useful. this is what i meant by "unenforceable" and "undetectably unspecified". to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 07:24:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19761 for ; Tue, 15 Jan 2002 07:24:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QSKS-000Hhb-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 04:04:36 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QSKS-000HhV-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 04:04:36 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QSKR-0004D9-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 04:04:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20020115003806.02f48490@localhost> In-Reply-To: References: <20020114150336.0ecaad8e.olaf@ripe.net> <20020114134106.E25998-100000@hlid.dc.ogud.com> Date: Tue, 15 Jan 2002 02:39:39 -0500 To: Randy Bush , Olafur Gudmundsson From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Cc: namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 05:56 PM 1/14/2002, Randy Bush wrote: > > All names in a secure zone that have signed records MUST have a signed > > NXT, delegations MAY have a signed NXT to indicate that they exist and > > are insecure. > >so, you are trying to kinda help authenticated denial. but, if the resolver >does not know if the zone has NXTs for the insecure delegations or not, then >the information seems not too useful. (I'm not glossing over any details this time so bear with me :-)). Resolver must be able to determine, current DS draft (05) requires that any time NS is in answer or authority section that DS and NXT for that name be added to the authority section, this does not cover the some of the cases that Opt-in creates (see below). Assumption #1: (Paranoid) resolver will attempt to determine the security status of the zone. Opt-in document allows the setting and omitting the NXT bit on any name, if NXT bit is set then there is no insecure name in between the name on the left hand side and the name on the right hand side. For secure zones the resolver will know by looking into the NXT what is the state of the name it is examining. There are 4 different cases: left hand name matches differs NXT bit set secure node name does not exist NXT bit clear secure node unsecured name may exist. This is unchanged by my text. What the my suggested text changes in Opt-in spec is: 1. Only Delegations are can be covered/omitted by opt-in. 2. Existence of some unsecured delegations can be authenticated. Opt-in (+DS) zones now have three different types of delegations fully secured "NS SIG [NXT] DS" and left hand name matches query provably exists "NS SIG [NXT]" and left hand name matches query not covered NXT names span the query name and does not have the NXT bit set. If my proposal is accepted, Opt-in will have only one kind of non delegation nodes: Secure. Current Opt-in draft assumes that names are either fully secure or not covered, the middle case is quire possible and might in the long run be more popular than fully secure. If DS dies, Opt-in needs to add text to require NXT to be handed out when available at delegation. If Opt-In passes in any form either DS or Opt-in Document needs to explicitly specify the NXT processing at "not covered" nodes. Finding the covering NXT might be quite expensive thus some care should go into this decision and there are significant tradeoffs here. Contrary to what most people think, NXT is the most expensive part of DNSSEC implementations due to the following: (this is not a complete list) Finding covering NXT dictates ordered data base. NXT generation requires whole zone to be available NXT maintenance forces on-line keys for zones allowing dynamic update. There are two different NXT sets at delegations (same name) that must be kept apart and both must be available. Chasing parent NXT (and NULL KEY) is frequently required but not always possible. NXT verification is needed on all negative answers. Doing crypto is easy compared to all this. 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. From owner-namedroppers@ops.ietf.org Tue Jan 15 07:31:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19948 for ; Tue, 15 Jan 2002 07:31:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QSZz-000Hva-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 04:20:39 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QSZz-000HvT-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 04:20:39 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QSZz-0004EE-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 04:20:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201150921.g0F9Ldg47919@open.nlnetlabs.nl> In-Reply-To: "Mark.Andrews@isc.org's message as of Jan 15, 6:33" From: ted@tednet.nl (Ted Lindgreen) Date: Tue, 15 Jan 2002 10:21:39 +0100 To: Mark.Andrews@isc.org, Olafur Gudmundsson Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Cc: "Olaf M. Kolkman" , Randy Bush , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Mark.Andrews@isc.org, on Jan 15, 6:33, in "Re: OPT-IN at delega ..."] > I think it is a reasonable compromise. Somehow, I have the feeling that from the trio reasonable compromise security 2 words can be combined, but not all 3. For quite some time I've heard "Opt-in is mostly harmless", and the Olaf/Olafur proposal seems even more harmless. But, it's the "mostly" and "even more" that keeps nagging. In other words, I concur with Vixie: [Quoting Paul Vixie, on Jan 15, 9:26, in "Re: OPT-IN at delega ..."] > rather than compromise between two invalid positions using an encoding > which is undetectably violatable, i think we ought to reverse the sense > of the poll. opt-in has been proposed. can anyone oppose it on grounds > which are (a) technical and (b) not yet shown to be invalid? Of course, when someone in the crowd can just pinpoint a weak spot, then it's over immediately. But if not, I'd still like us to seriously investigate: Does it really improve the protocol? In that decision, I think that security issues should weight a little more than conveniance issues. If the answer is yes, we adopt it, of not we forget it. -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 07:56:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20810 for ; Tue, 15 Jan 2002 07:56:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QSyW-000IHp-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 04:46:00 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QSyV-000IHj-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 04:46:00 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QSyV-0004Fj-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 04:45:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200201150035.g0F0Zns11746@drugs.dv.isc.org> <20020115072143.CE81528EB3@as.vix.com> Message-Id: From: Randy Bush To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Date: Tue, 15 Jan 2002 04:13:22 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > if not then i urge the chairs to put markk's latest draft out for last > call. we did. the call ended 2002.01.07, a week ago. there was no consensus. we're trying not to close the door, but rather encourage discussion to try and find if there is a reasonable, high-quality, position over which we can reach consensus. sad to say, none has yet emerged. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 11:07:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00522 for ; Tue, 15 Jan 2002 11:07:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QVuM-000L1z-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 07:53:54 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QVuL-000L1t-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 07:53:53 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QVuL-0004MP-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 07:53:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4096A55F6@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: ted@tednet.nl, Mark.Andrews@isc.org, Olafur Gudmundsson Cc: "Olaf M. Kolkman" , Randy Bush , namedroppers@ops.ietf.org Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) Date: Tue, 15 Jan 2002 07:43:30 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > In that decision, I think that security issues should weight a > little more than conveniance issues. I agree. But remember that security of a system is very different from security of a protocol. It is not a convenience issue if you cannot deploy without a change. At that point it becomes an operational requirement. The security of the system is unaffected by OPTIN. Anyone can purchase a dotcom domain name with a credit card. The record insertion attack is therefore not a risk in that application. The more complex management of large domains is made, the harder it is to maintain an acceptable level of security. Phill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 11:25:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01362 for ; Tue, 15 Jan 2002 11:25:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QWDX-000LMQ-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 08:13:43 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QWDX-000LMK-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 08:13:43 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QWDW-0004Np-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 08:13:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: <200201150035.g0F0Zns11746@drugs.dv.isc.org> <20020115072143.CE81528EB3@as.vix.com> Date: Tue, 15 Jan 2002 11:08:50 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: OPT-IN impasse, Re: OPT-IN ... Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 7:13 AM -0500 1/15/02, Randy Bush wrote: >we did. the call ended 2002.01.07, a week ago. there was no consensus. >we're trying not to close the door, but rather encourage discussion to >try and find if there is a reasonable, high-quality, position over which >we can reach consensus. sad to say, none has yet emerged. I really hate impasses, such as this one, which really have little technical basis. The problem is that at some point some group will have to decide one way or another. In this case, no decision is essentially a "don't do it." This is unfortunate because the IETF is all about open consensus, but when it comes to a yes/no question that isn't solved by a technical acheivement, something has to give. My largest concern is that, given there will be a "winning" and a "losing" side barring a compromise, is that the "losers" will feel slighted. I hope that isn't the case for long. (Although this message is a bit whiney about the situation, I am not disappointed in the activities. I think the thread has been pretty well behaved so far.) My personal bias is for OPT-IN. I have my two reasons - the reasons have been all over the mail list from other's fingers so I won't repeat them here. One of my reasons can be worked around. The other isn't a technical one, so there's no sense arguing it. When I think about this debate, OPT-IN isn't really that crucial an issue. It's become something to argue about. Let's not let the act of arguing delay the other work. I'm sure that whatever is decided will be forgotten in five years. PS - The one dilemma that I keep running into is the "I hate Verisign because they are this economic monolopy capable of strangling the net" versus "Versign has the most cummulative experience in operating DNS servers and registries." I hope that folks who really believe one of these two stop to consider the other side of the coin. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 11:39:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02307 for ; Tue, 15 Jan 2002 11:39:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QWR9-000Lbg-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 08:27:47 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QWR8-000LbZ-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 08:27:46 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QWR7-0004PE-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 08:27:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201151626.g0FGQS949080@open.nlnetlabs.nl> In-Reply-To: ""Hallam-Baker, Phillip"'s message as of Jan 15, 17:16" From: ted@tednet.nl (Ted Lindgreen) Date: Tue, 15 Jan 2002 17:26:28 +0100 To: "Hallam-Baker, Phillip" , ted@tednet.nl, Mark.Andrews@isc.org, Olafur Gudmundsson Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) Cc: "Olaf M. Kolkman" , Randy Bush , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting "Hallam-Baker, Phillip", on Jan 15, 17:16, in "RE: OPT-IN at delega ..."] > It is not a convenience issue if you cannot deploy without a > change. At that point it becomes an operational requirement. You can try to repeat this indefinitely, but mere repetition itself probably does not lead to consensus building. > The security of the system is unaffected by OPTIN. This is untrue, Opt-In changes the very basis of the system. Whether this is harmless or not is still being debated. -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 12:01:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05092 for ; Tue, 15 Jan 2002 12:01:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QWkT-000Lyw-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 08:47:45 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QWkS-000Lyq-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 08:47:44 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QWkS-0004Qj-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 08:47:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <20020115072143.CE81528EB3@as.vix.com> Message-ID: Date: Tue, 15 Jan 2002 11:37:03 -0500 (EST) From: Greg Hudson To: Paul Vixie cc: Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hey, I have a completely off-topic question: why are SIG records so big? People were saying that they're about 128 bytes. Couldn't we hash them down to 128-256 bits (16-32 bytes) plus a little overhead? It may be a little late in the game for such a change, though. Just curious. On Mon, 14 Jan 2002, Paul Vixie wrote: > > I think it is a reasonable compromise. > well maybe, except it isn't enforceable. if someone somewhere decides to > implement their NXT's without this restriction, the encoding will support > them and convey unspecified meaning to resolvers. I can't really tell what you mean. Under the compromise, a resolver should refuse to accept unsigned authoritative data in a signed zone, just like should refuse to do so now. The only new thing a resolver should be willing to accept is an unsigned insecure delegation at a zone which indicates it's using opt-in. That seems enforceable to me, and very much specified. > i'm more interested in the fact that this compromise is between two invalid > positions. size arguments have been shown invalid by ted@nlnet, whereas > paternalistic arguments have been shown invalid by me. Writing a message opposing a position does not constitute "showing the position invalid." Ted's argument boiled down to "I can't imagine anyone saying that a 4-fold to 6-fold initial size increase in the .com zone is unacceptable," and your position on paternalism, while valid, is not shared by everyone in the group. Essentially: Verisign says they can't deploy DNSSEC with such a large initial increase in cost. (And I know of no incentive for them to make that argument dishonestly, since they can already charge extra for KEY records as things stand.) The group can't get consensus on supporting fine-grained security of authoritative data. We have a compromise which should make both sets of people happy. Is there any reason, other than pigheaded obstructionism, why we're not just taking the compromise and running with it? (Yes, there is a reason: opt-in raises complexity a little, and only helps a small number of zones. But they are very large zones which get used a lot, and it's not a great deal of complexity, so that's not a compelling argument.) > rather than compromise between two invalid positions using an encoding > which is undetectably violatable, i think we ought to reverse the sense > of the poll. opt-in has been proposed. can anyone oppose it on grounds > which are (a) technical and (b) not yet shown to be invalid? People oppose it because they see it as likely that only a small amount of DNS will be protected if we support fine-grained protection. You may not agree with that position, but you haven't "shown it to be invalid" to the extent of getting consensus. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 12:09:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05507 for ; Tue, 15 Jan 2002 12:09:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QWt8-000M92-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 08:56:42 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QWt8-000M8w-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 08:56:42 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QWt7-0004R9-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 08:56:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <200201150921.g0F9Ldg47919@open.nlnetlabs.nl> Message-ID: Date: Tue, 15 Jan 2002 11:54:28 -0500 (EST) From: Greg Hudson To: Ted Lindgreen cc: Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 15 Jan 2002, Ted Lindgreen wrote: > Somehow, I have the feeling that from the trio > reasonable > compromise > security > 2 words can be combined, but not all 3. This (and the following paragraph) are complete FUD. If opt-in does something harmful to DNSSEC, say what it is. Don't merely repeat that you're nervous about it. We know exactly what opt-in-at-delegations-only gives up: for domains which choose to use it, it gives up authenticated denial of insecure delegations, and allows the insertion of insecure delegations where no authoritative data exists in the domain. Because of that, we expect that opt-in would only be used in domains where insertion of insecure delegations would be harmless, such as the .com domain. (There is no motivation to use it in a regular domain full of mostly authoritative data.) > But if not, I'd still like us to seriously investigate: > > Does it really improve the protocol? Yes, it does. It allows a large domain full of insecure delegations to deploy the protocol without wasting a lot of resources on protecting those insecure delegations. I'm not personally very excited about that because I don't run a large domain, but I have yet to see an even vaguely convincing reason why we shouldn't do it for the sake of people who do run such domains. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 12:44:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06850 for ; Tue, 15 Jan 2002 12:44:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QXMI-000MfX-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 09:26:50 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QXMH-000MfP-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 09:26:49 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QXMC-0004T3-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 09:26:44 -0800 Message-ID: <20020115171842.GH18641@research.netsol.com> References: <200201151626.g0FGQS949080@open.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="0qt3EE9wi45a2ZFX" Content-Disposition: inline In-Reply-To: <200201151626.g0FGQS949080@open.nlnetlabs.nl> Date: Tue, 15 Jan 2002 12:18:43 -0500 From: Mike Schiraldi To: namedroppers@ops.ietf.org Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --0qt3EE9wi45a2ZFX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > The security of the system is unaffected by OPTIN. > > This is untrue, Opt-In changes the very basis of the system. > Whether this is harmless or not is still being debated. Could you elaborate on that? I don't understand what you mean by "changes the very basis" and i thought that the security risk was one of the few points that we all agreed on. To spell it out one more time: The only new security consideration is that a middleman can insert fake unsecure records under names that don't really exist. As long as the zone operator is aware of this, he can either decide that this risk is harmless and go with opt-in or harmful and use 2535. Who is still debating this? --=20 Mike Schiraldi VeriSign Applied Research --0qt3EE9wi45a2ZFX Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIKIAYJKoZIhvcNAQcCoIIKETCCCg0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B6wwggR2MIID36ADAgECAhAyACTCO7tQsBTRNUR0/tTjMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMDMyMjAwMDAw MFoXDTAyMDMyMjIzNTk1OVowggEaMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pa2UgU2NoaXJhbGRpMSgwJgYJKoZI hvcNAQkBFhlyYWxkaUByZXNlYXJjaC5uZXRzb2wuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDu28IxMPojtN900dqX3LO3rfhirsJstpbSOzKVwPH9GwIgycFIn3YFkmOpeB40 cBkqNC1HzreGuFFAo9f3Y9xPjbvnEWlNo6oBu/wGL53gUtsUcNcj7tOngfjTr/4V3rohPuWU 4qRAZxjd5qaFUSP3bLh/U/7MoRwRB2Sz82HCqwIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAYOkgLNF2 HYrK+ucdU0TN2PIAtbB3vV0cLhHJfE6zzyL9u5PlAKnxqwVYozd5S/u4Lg1WvDFE3vG3mVIE Fobol2RmSNIo6kOgED48B6oWgU/21lysVZ6DRPnGTSX7FsIH12L0mHj7jSDkzTqtkbzY6is/ YBkKDmeAuXnmljJ7H7wwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG 9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNV BAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN OTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBl cnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQW u1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0Rc qkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqn sX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4w PAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOB gQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s 3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg 5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAyACTCO7tQsBTRNUR0/tTjMAkGBSsOAwIa BQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwMTE1 MTcxODQyWjAjBgkqhkiG9w0BCQQxFgQUt8GArAqu8VgEApaWBz2DK9w0/MEwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB/7qTyfaP18VGEYV67rgO3 Cn2Dmr0WXUGIPoZix+CHqBM4w4Hc/wbBc3fxGc6PoPi1CYZOjpZuss46AyQ2A/PlsWrpl8Pl Xk12+/Qm5LPL6fMfu+G5P+EGe8PZYTEf7hGchI1kvLbkFa0o2CpxOavF5QGLV93Rf+GqIMiV mu/wvg== --0qt3EE9wi45a2ZFX-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 13:00:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07282 for ; Tue, 15 Jan 2002 13:00:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QXe8-000N06-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 09:45:16 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QXe8-000N00-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 09:45:16 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QXe7-0004UU-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 09:45:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200201150921.g0F9Ldg47919@open.nlnetlabs.nl> Message-Id: From: Randy Bush To: Greg Hudson Cc: namedroppers@ops.ietf.org Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Date: Tue, 15 Jan 2002 09:44:37 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Because of that, we expect that opt-in would only be used in domains > where insertion of insecure delegations would be harmless, such as the > .com domain. i suspect that, if we could really ensure that this was the case, many people would feel more comfortable. fear of the mass of mis-guided zone admins may underly much of people's discomfort. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 18:51:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16528 for ; Tue, 15 Jan 2002 18:51:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QdA0-0002AJ-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 15:38:32 -0800 Received: from dhcp64-134-94-44.hicv.lax.wayport.net ([64.134.94.44] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QdA0-0002AC-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:38:32 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16Qd9z-0004aG-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:38:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4096A5694@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Randy Bush , Paul Vixie Cc: namedroppers@ops.ietf.org Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) Date: Tue, 15 Jan 2002 10:17:27 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > we did. the call ended 2002.01.07, a week ago. there was no > consensus. > we're trying not to close the door, but rather encourage discussion to > try and find if there is a reasonable, high-quality, position > over which > we can reach consensus. sad to say, none has yet emerged. Perhaps then we should consider the points that have been raised so far in the debate and which do not seem to be in dispute. 1) The additional cost of deploying DNSSEC. X = The number of signed delegations Z = The size of the zone S = The size of a signature 2535 (2Z + 2X) S 2535 + DS (Z + 2X) S 2535 + DS + OPTIN 2X S S = 1024 bits for RSA, 320 bits for DSA 1a) RSA is to be preferred as a signature algorithm. Although the signature size is larger for RSA the verification time is very much faster (order of magnitude according to EKR). 1b) The size of the .com, .net, .org zones is a total of 30 million names 1a) The cost of deployment in .com, .net, .org If X is small: 2535 Increases data volume by factor of 6 2535+DS Increases data volume by factor of 3.5 2535+DS+OPTIN Has negligible impact on data size. 2) The DS modification is a necessary change to the specification that is not backwards compatible. 3) OPT-IN does not weaken the security model for its intended scope of use. Anyone can apply for an unregistered domain name, ergo a record insertion attack is not a threat. 4) OPT-IN may be used in inappropriate circumstances in which the record insertion attack is a threat. There is however no consensus on the following point: 5) Whether the group should attempt to prohibit 'inappropriate' use of OPTIN. 5a) Whether this is desirable Might a military zone 5b) Whether this is actually possible There are objections of the following form: 6) There might exist some objection to OPT-IN that the objector has not yet thought of but might do so in the future. 7) The cost of deploying DNSSEC _should_ be made prohibitively high for operators of large zones. 8) If the cost of deployment is too high the cost should be met by increasing the registration fees rather than modifying the protocol. [While I have great sympathy with this position, I doubt that ICANN would find it persuasive] Phill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 18:51:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16539 for ; Tue, 15 Jan 2002 18:51:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Qd93-000298-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 15:37:33 -0800 Received: from dhcp64-134-94-44.hicv.lax.wayport.net ([64.134.94.44] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16Qd93-000292-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:37:33 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16Qd91-0004aA-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:37:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from Randy Bush of "Tue, 15 Jan 2002 09:44:37 PST." Message-Id: <20020115180444.3295E28EB3@as.vix.com> From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Date: Tue, 15 Jan 2002 10:04:44 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Because of that, we expect that opt-in would only be used in domains > > where insertion of insecure delegations would be harmless, such as the > > .com domain. > > i suspect that, if we could really ensure that this was the case, many > people would feel more comfortable. fear of the mass of mis-guided zone > admins may underly much of people's discomfort. but, but, that way lies madness. most zone owners don't have multiple NS's on different networks, either. but even if it were possible to modify the protocol to require this, we WOULD NOT DO IT. why not? because it's up to zone owners to decide how to serve their zones. protecting other people from their own stupidity, against their expressed will, is "paternalism". that's not our business here. arguments of the form "dns will not be as secure as it could be if opt-in is adopted" are rife with the logical fallacy of "begging the question" and are completely subjective/judgemental. that's not our business here, either. (will dns be more secure if more zones are signed? will opt-in make it easier for more zones to be signed? and so on. let's just not go there.) "who is still debating this?" to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 18:51:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16550 for ; Tue, 15 Jan 2002 18:51:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QdCA-0002D2-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 15:40:46 -0800 Received: from dhcp64-134-94-44.hicv.lax.wayport.net ([64.134.94.44] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QdCA-0002Cw-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:40:46 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QdC8-0004aU-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:40:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20020114134106.E25998-100000@hlid.dc.ogud.com> In-Reply-To: <20020114134106.E25998-100000@hlid.dc.ogud.com> (Olafur Gudmundsson's message of "Mon, 14 Jan 2002 14:38:27 -0500 (EST)") Message-ID: To: Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) From: David Blacka Date: Tue, 15 Jan 2002 13:40:20 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "ogud" == Olafur Gudmundsson writes: ogud> ogud> On Mon, 14 Jan 2002, Olaf M. Kolkman wrote: >> If we allow for OPT-IN over delegations only we solve the apparent >> large zones problem and we keep security at zone levels. >From the perspective of VeriSign, this compromise is perfectly fine. However, from my own perspective, I either do not understand or possibly just don't agree with the arguments that have led to this. ogud> The argument that I want to make is about the maintainance of ogud> zone with some names secured and some insecure, has the ogud> potential to be an administrative nightmare, as there must be ogud> an indicator for each name (or sequence of names) that ogud> indicates when to sign and generate NXT. This seems to me to entirely be a tools issue. For sure, a zone signer could be implemented that makes opt-in hard. But there are zillions of ways to implement a zone signer interface, and many of them won't create administrative nightmares. Olaf writes: I always thought that DNSSEC was designed to secure the DNS system as a whole. I would say that is something as a 'public good'. And others have written that the goal of DNSSEC was to "protect the DNS infrastructure", which I'm guessing means the same thing. I can sort of understand this as a noble goal. But, since 2535 allows for insecure zones, I have a hard time seeing this actually happen with or without Opt-In. Unless we have a flag day at some point and *force* people to secure their zones, it seems to me that there will always be insecure zones. Changing the granularity doesn't seem to change the situation at all. A general fear seems to be that opt-in will lead to dramatically less of the whole DNS being secured. I'm not really convinced that this is the case, but even so, why does this have to be enforced by the *protocol*? The draft already states that opt-in should only be used where necessary, and I should hope that the tool writers will communicate this by never making opt-in the default. I guess I don't see why the language in the security implications section of the draft isn't enough to prevent the majority of folks from using it. -- David Blacka Sr. Research 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. From owner-namedroppers@ops.ietf.org Tue Jan 15 18:52:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16562 for ; Tue, 15 Jan 2002 18:52:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QdAz-0002BS-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 15:39:33 -0800 Received: from dhcp64-134-94-44.hicv.lax.wayport.net ([64.134.94.44] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QdAy-0002BM-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:39:32 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QdAx-0004aQ-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:39:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from ted@tednet.nl (Ted Lindgreen) of "Tue, 15 Jan 2002 10:21:39 +0100." <200201150921.g0F9Ldg47919@open.nlnetlabs.nl> Message-Id: <20020115182038.267EB28EB3@as.vix.com> From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Date: Tue, 15 Jan 2002 10:20:38 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Of course, when someone in the crowd can just pinpoint a weak spot, > then it's over immediately. subject to the vagueries of the word "pinpoint", that sounds true. (but getting this crowd to agree that something has been pinpointed seems unlikely, so i think we'd better not count on this happening.) > But if not, I'd still like us to seriously investigate: > > Does it really improve the protocol? > > In that decision, I think that security issues should weight a > little more than conveniance issues. i do not consider those two issue-types to be separable or distinct. if it is too inconvenient, some zones won't be signed, which will lower the overall impact of DNSSEC even though it won't change the security level enjoyed by producers and consumers of zones which ARE signed. and so on. > If the answer is yes, we adopt it, of not we forget it. i don't think that's a workable approach. rather, we have some very strong arguments on the table from some zone-operators who say they need a specific feature (opt-in) for their own zones. and we have some other very strong arguments on the table from some resolver-operators who say they do not want (some or all, depending) zone-operator anywhere to have the opt-in feature. neither side has shown any flexibility. as protocol designers, we can't decide this issue by looking at the quality of the arguments, since they aren't arguments about the same issue. one side is arguing from zone operability, the other from resolver operability. so we have to ignore the arguments and decide which basis is more relevant. should the inflexible resolver-operators dictate the presence or absence of this feature, or shall the inflexible zone-operators dictate it? remember, both sides have effective workarounds. resolver operators will be able to tell whether the data they are seeing is secure or not. zone operators can wait for moore's law to catch up a little. either way, the inflexible arguments themselves are all going to be moot by the time we get it deployed. "whose data is it, anyway?" to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 18:52:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16573 for ; Tue, 15 Jan 2002 18:52:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QdAq-0002BI-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 15:39:24 -0800 Received: from dhcp64-134-94-44.hicv.lax.wayport.net ([64.134.94.44] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QdAq-0002BC-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:39:24 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QdAo-0004aN-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:39:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020115181841.GC10658@slam.admin.cto.netsol.com> References: <20020115072143.CE81528EB3@as.vix.com> In-Reply-To: Date: Tue, 15 Jan 2002 13:18:41 -0500 From: Mark Kosters To: Greg Hudson Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, Jan 15, 2002 at 11:37:03AM -0500, Greg Hudson wrote: > Essentially: Verisign says they can't deploy DNSSEC with such a large > initial increase in cost. (And I know of no incentive for them to make > that argument dishonestly, since they can already charge extra for KEY > records as things stand.) The group can't get consensus on supporting > fine-grained security of authoritative data. We have a compromise which > should make both sets of people happy. Is there any reason, other than > pigheaded obstructionism, why we're not just taking the compromise and > running with it? In the teleconf we had before Christmas, the objections made to restricting opt-in only to delegation points that I remember were: 1) code complexity to enforce this (an alternative is restricting by policy and common convention). 2) those who wish to hide non-secure rr sets from nxt walking. 3) benefits only large zone maintainers. But, if restricting opt-in to delegation points reduces the fear in those who are opposed to opt-in, the authors have no problems in placing text to that effect in the next version. > (Yes, there is a reason: opt-in raises complexity a little, and only helps > a small number of zones. But they are very large zones which get used a > lot, and it's not a great deal of complexity, so that's not a compelling > argument.) Agreed. > People oppose it because they see it as likely that only a small amount of > DNS will be protected if we support fine-grained protection. You may not > agree with that position, but you haven't "shown it to be invalid" to the > extent of getting consensus. I don't follow some of this "closed-case" reasoning either. I think trying to force people to secure all their zones data by placing restrictions in the protocol is misguided. One needs to do this by showing the usefulness of securing their rr sets within dnssec. I personally believe they should have a choice on what they want to do with their own data. But again, if adding text that restricts opt-in only to delegation points gains more acceptance, the authors are fine with this. Mark -- Mark Kosters markk@netsol.com 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. From owner-namedroppers@ops.ietf.org Tue Jan 15 18:52:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16584 for ; Tue, 15 Jan 2002 18:52:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QdAN-0002Ag-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 15:38:55 -0800 Received: from dhcp64-134-94-44.hicv.lax.wayport.net ([64.134.94.44] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QdAM-0002Aa-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:38:54 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QdAL-0004aJ-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:38:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4096A5693@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Greg Hudson , Paul Vixie Cc: namedroppers@ops.ietf.org Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) Date: Tue, 15 Jan 2002 10:17:27 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Hey, I have a completely off-topic question: why are SIG > records so big? > People were saying that they're about 128 bytes. Couldn't we > hash them > down to 128-256 bits (16-32 bytes) plus a little overhead? > It may be a > little late in the game for such a change, though. Just curious. It is the way that the RSA algorithm works. To verify the signature you need the 1024 bit signature, a digest is not sufficient. It is likely that DSA is optimal in terms of space efficiency and that does use digests - two of them. the signature is a validated correspondence between the two 160 bit values. The problem with DSA is that the signature verification process is very expensive. Generation is cheap and so in schemes like NetBill the client did cheap to verify RSA and the server did cheap to generate DSA. If my only concern was the registry side of things then I might propose DSA (if my QA system did not involve test verifications :-). However the big problem with DSA is that the cost of doing DNSSEC rises tenfold on the client (i.e. secure resolver) side. > Essentially: Verisign says they can't deploy DNSSEC with such a large > initial increase in cost. (And I know of no incentive for > them to make > that argument dishonestly, since they can already charge extra for KEY > records as things stand.) The group can't get consensus on supporting > fine-grained security of authoritative data. We have a > compromise which > should make both sets of people happy. Is there any reason, > other than > pigheaded obstructionism, why we're not just taking the compromise and > running with it? I have no personal problems with such a proposal. The stakeholders that might are: A) The people who write the code. B) People who might want to deploy OPTIN in applications where preventing zone traversal is more important than preventing record insertion. In addition there is a question of the manner of the restriction: 1) A beefed up Security considerations section "Do not use OPTIN unless you really really know what you are doing". 2) Some MUST or SHOULD condition on generation 3) Some MUST or SHOULD condition on consumption These sets interact. Coders are unlikely to object to 1 but are very likely to see difficulties with 3. If the set B is empty, or if the group does not want to support them 2 or 3 become options. Phill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 18:55:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16660 for ; Tue, 15 Jan 2002 18:55:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QdHo-0002Lq-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 15:46:36 -0800 Received: from dhcp64-134-94-44.hicv.lax.wayport.net ([64.134.94.44] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QdHn-0002Lk-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:46:35 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QdHm-0004am-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:46:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4096A56A8@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Ted.Lindgreen@tednet.nl, "Hallam-Baker, Phillip" , Mark.Andrews@isc.org, Olafur Gudmundsson Cc: "Olaf M. Kolkman" , Randy Bush , namedroppers@ops.ietf.org Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) Date: Tue, 15 Jan 2002 11:38:26 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > [Quoting "Hallam-Baker, Phillip", on Jan 15, 17:16, in "RE: > OPT-IN at delega ..."] > > > It is not a convenience issue if you cannot deploy without a > > change. At that point it becomes an operational requirement. > > You can try to repeat this indefinitely, but mere repetition > itself probably does not lead to consensus building. You can repeat ad-infinitum that you have 'concerns'. However you have thus far failled to identify any risk that constitutes a threat under the proposed domain of application that is controlled in 2535 but not controlled under OPTIN. Phill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 18:58:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16749 for ; Tue, 15 Jan 2002 18:58:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QdKm-0002Rk-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 15:49:40 -0800 Received: from dhcp64-134-94-44.hicv.lax.wayport.net ([64.134.94.44] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QdKm-0002Ra-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:49:40 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QdKl-0004aw-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:49:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201152010.g0FKAJl49685@open.nlnetlabs.nl> In-Reply-To: "Mike Schiraldi's message as of Jan 15, 18:56" From: ted@tednet.nl (Ted Lindgreen) Date: Tue, 15 Jan 2002 21:10:18 +0100 To: Mike Schiraldi , namedroppers@ops.ietf.org Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Mike Schiraldi, on Jan 15, 18:56, in "Re: OPT-IN at delega ..."] > > This is untrue, Opt-In changes the very basis of the system. > > Whether this is harmless or not is still being debated. > > Could you elaborate on that? OK, Opt-In changes the definition of the NXT RR from: authenticated denial of existance of any name into authenticated denial of existance of a secured name Sounds basic to me. > Who is still debating this? A number of people believe that the granularity influences how users and ISP's perceive the security, and that in turn will influence the speed of the roll out. -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 19:06:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16857 for ; Tue, 15 Jan 2002 19:06:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QdU4-0002km-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 15:59:16 -0800 Received: from dhcp64-134-94-44.hicv.lax.wayport.net ([64.134.94.44] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QdU3-0002kg-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:59:15 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QdU3-0004bO-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 15:59:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: Date: Tue, 15 Jan 2002 16:42:28 -0500 (EST) From: Greg Hudson To: Randy Bush cc: Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 15 Jan 2002, Randy Bush wrote: > > Because of that, we expect that opt-in would only be used in domains > > where insertion of insecure delegations would be harmless, such as the > > .com domain. > > i suspect that, if we could really ensure that this was the case, many > people would feel more comfortable. fear of the mass of mis-guided zone > admins may underly much of people's discomfort. Well, if opt-in is only allowed for insecure delegations, then there shouldn't be much call to implement it on the server side in major implementations like BIND. (I'm assuming that Verisign is planning on using some kind of custom code, not BIND, to sign the .com zone, yes?) If it isn't widely implemented on the server side, there isn't much danger of it being misused. (Of course, opt-in has to be implemented widely on the client side or it won't do what it's supposed to do.) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 19:14:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16914 for ; Tue, 15 Jan 2002 19:14:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QdZw-0002u9-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 16:05:20 -0800 Received: from dhcp64-134-94-44.hicv.lax.wayport.net ([64.134.94.44] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QdZv-0002u3-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 16:05:19 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QdZv-0004bc-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 16:05:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20020115072143.CE81528EB3@as.vix.com> In-Reply-To: <20020115072143.CE81528EB3@as.vix.com> Message-ID: To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) From: Derek Atkins Date: 15 Jan 2002 17:06:59 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie writes: > > I think it is a reasonable compromise. > > > > Mark > > well maybe, except it isn't enforceable. if someone somewhere decides to > implement their NXT's without this restriction, the encoding will support > them and convey unspecified meaning to resolvers. Except it wouldn't be unspecified to a compliant resolver. If a resolver sees a response that looks like: foo.example.com. in a 10.0.0.1 example.example.com. in nxt good.example.com. ... example.example.com. in sig nxt ... where the nxt has no-opt set (i.e. nxt bit clear), then a compliant resolver would know that foo was a forged response (because you're not allowed to put authoritative data in an opt-in area). In other words, the nxt shown above says "the only information that can exist between example.example.com. and good.example.com. are non-authoritative data (NS records and non-authoritative glue A records). Anything else that appears is deemed by the resolver to be garbage, because it's not allowed. This is 100% specified to a compliant resolver. Obviously if an implementator makes a non-compliant resolver then all bets are off, but we're already talking about resolvers that comply with the spec, right? So, where is the confusion? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 15 19:16:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16927 for ; Tue, 15 Jan 2002 19:16:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QdaS-0002ug-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 16:05:52 -0800 Received: from dhcp64-134-94-44.hicv.lax.wayport.net ([64.134.94.44] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QdaS-0002ua-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 16:05:52 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QdaS-0004bg-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 16:05:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from Derek Atkins of "15 Jan 2002 17:06:59 EST." Message-Id: <20020115222026.53CA328EB3@as.vix.com> From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Date: Tue, 15 Jan 2002 14:20:26 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > ... > In other words, the nxt shown above says "the only information that > can exist between example.example.com. and good.example.com. are > non-authoritative data (NS records and non-authoritative glue A > records). Anything else that appears is deemed by the resolver to be > garbage, because it's not allowed. > > This is 100% specified to a compliant resolver. Obviously if an > implementator makes a non-compliant resolver then all bets are off, > but we're already talking about resolvers that comply with the spec, > right? > > So, where is the confusion? > ... in my head. thanks for clearing it up. i withdraw my objection to olafur's restated version of this "only delegations can opt out" proposal. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 16 03:08:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02430 for ; Wed, 16 Jan 2002 03:08:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QkfO-0009Su-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 23:39:26 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QkfN-0009So-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 23:39:25 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QkfN-0004jp-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 23:39:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201160214.g0G2ENs18497@drugs.dv.isc.org> In-reply-to: Your message of "Tue, 15 Jan 2002 10:17:27 -0800." <2F3EC696EAEED311BB2D009027C3F4F4096A5694@vhqpostal.verisign.com> To: "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) Date: Wed, 16 Jan 2002 13:14:23 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 3) OPT-IN does not weaken the security model for its intended scope > of use. Anyone can apply for an unregistered domain name, ergo a > record insertion attack is not a threat. OPT-IN also allows for records (delegations) to appear to be *deleted* from a zone. This is a weaker security model. People for the most part don't care about data being added to COM. The do however care very much about data disappearing from COM. Just look at all the bad press from the stuff ups in the past. What you are saying to all the existing domain holders under COM is: "If you want your delegation to be protected from DoS attacks you have to submit a DS record." Mark -- Mark Andrews, Internet Software Consortium 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. From owner-namedroppers@ops.ietf.org Wed Jan 16 03:22:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02606 for ; Wed, 16 Jan 2002 03:22:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QkxK-0009kL-00 for namedroppers-data@psg.com; Tue, 15 Jan 2002 23:57:58 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QkxK-0009kF-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 23:57:58 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QkxJ-0004l0-00 for namedroppers@ops.ietf.org; Tue, 15 Jan 2002 23:57:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: References: <200201150035.g0F0Zns11746@drugs.dv.isc.org> <20020115072143.CE81528EB3@as.vix.com> Message-ID: <3805.1011167365@brandenburg.cs.mu.OZ.AU> From: Robert Elz To: namedroppers@ops.ietf.org Subject: Re: OPT-IN impasse, Re: OPT-IN ... Date: Wed, 16 Jan 2002 14:49:25 +0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Tue, 15 Jan 2002 11:08:50 -0500 From: Edward Lewis Message-ID: | I really hate impasses, such as this one, which really have little | technical basis. I generally stay out of dnssec (what used to be dnssec) arguments, as I don't have the true security background to avoid making a fool of myself. But from what I have been able to conclude from reading all of this, there are no technical arguments here at all. The whole argument is gibberish (on both sides). The calculations of extra load (done by both sides) are utter nonsense - not necessarily so much because the numbers are wrong (though I actually believe that both sides are fudging), but because truly the whole question is irrelevant. Running a registry is running an infrastructure business, and infrastructure, by its very nature, tends to require the occasional large up front investment, which is then recouped over the operating lifetime. DNS registries (as opposed to registrars, who are just resellers, and hence a service industry) should be expecting to have to make capital investments, and then make profits from them later. What's more, I can't believe for a second that Verisign doesn't understand that perfectly well - obviously they'd prefer not to have to spend if it can be avoided, but that cannot rationally be any kind of genuine argument. More than that, if dnssec deployment happens anything like the way other internet technologies have been deployed, and I can't imagine why it wouldn't, there will be (after availability, whenever that is) a period of almost zero use, followed by a sudden upsurge of demand, which I'd guess might take .COM from about 2-3% secure to 40-50% secure in a 6-8 month timeframe (the issue will hit the popular/trade press somewhere, and all the lemmimg managers will suddenly decide they they also need this, right now). Versign have to be expecting something like that, and planning for it, which means developing the means to handle the zone file when it is almost completely signed, which I think everyone agrees means about the same load, with or without OPT-IN. To do otherwise would be foolish. On the other hand, the arguments against OPT-IN seem to be missing completely. I understand this "change the nature of dnssec" stuff - but we have no dnssec at the minute, it is just a dream, and changing the nature of a dream doesn't seem to me to be something that needs to be avoided at all costs - especially when the change seems to be so comparatively trival. I'd suggest that we should do as Paul Vixie suggested a couple of days ago, and return to first principles. Assume that the whole thing was just being designed now, except with us having all the knowledge that we actually have about how all of this works, and what it costs. If the result of that would be that OPT-IN, as he asserted, then that is what should be done. Just everyone please stop repeating the previous set of non-arguments, both ways, over and over again. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 16 09:16:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08095 for ; Wed, 16 Jan 2002 09:16:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QqVP-000EmH-00 for namedroppers-data@psg.com; Wed, 16 Jan 2002 05:53:31 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QqVO-000Em9-00 for namedroppers@ops.ietf.org; Wed, 16 Jan 2002 05:53:30 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QqVO-0004zB-00 for namedroppers@ops.ietf.org; Wed, 16 Jan 2002 05:53:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201160936.g0G9apc52757@open.nlnetlabs.nl> In-Reply-To: "Paul Vixie's message as of Jan 16, 1:00" From: ted@tednet.nl (Ted Lindgreen) Date: Wed, 16 Jan 2002 10:36:51 +0100 To: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Paul Vixie, on Jan 16, 1:00, in "Re: OPT-IN at delega ..."] > why not? because it's up to zone owners to decide how to serve their zones. I am all for freedom of choice, but the problem with this is that while it seems perfectly valid from the zoneholders point of view, it's not from the resolvers point of view. Please note, that DNSSEC is not: to protect zones/RRs against bad users/resolvers but was aimed: to protect users/resolvers against bad zones/RRs -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 16 09:18:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08234 for ; Wed, 16 Jan 2002 09:18:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QqVz-000Eme-00 for namedroppers-data@psg.com; Wed, 16 Jan 2002 05:54:07 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16QqVz-000EmY-00 for namedroppers@ops.ietf.org; Wed, 16 Jan 2002 05:54:07 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16QqVy-0004zH-00 for namedroppers@ops.ietf.org; Wed, 16 Jan 2002 05:54:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from ted@tednet.nl (Ted Lindgreen) of "Wed, 16 Jan 2002 10:36:51 +0100." <200201160936.g0G9apc52757@open.nlnetlabs.nl> Message-Id: <20020116094337.29CCC28EB3@as.vix.com> From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a proposal) Date: Wed, 16 Jan 2002 01:43:37 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Please note, that DNSSEC is not: > to protect zones/RRs against bad users/resolvers > but was aimed: > to protect users/resolvers against bad zones/RRs i'm actually glad to see this thread continue beyond the pale of death, since some things are dredging up that are useful and illuminating. like, had there been a statement of work for dnssec, it would not have said anything like either of the above. i was there, i remember it clearly enough. the point of the exercise was (and in my view, remains): to make sure that the data seen by resolvers is that published by zone owners if it's some other data, pretending to be zone data, then it ought to fail authenticity. of course, this doesn't help resolve the opt-in debate. now, with the currently-proposed compromise, none of this matters. i think we are done. but it's interesting what can happen when there's no written scope of work. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 16 09:39:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09104 for ; Wed, 16 Jan 2002 09:39:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Qr26-000FNn-00 for namedroppers-data@psg.com; Wed, 16 Jan 2002 06:27:18 -0800 Received: from dhcp64-134-94-52.hicv.lax.wayport.net ([64.134.94.52] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16Qr25-000FNh-00 for namedroppers@ops.ietf.org; Wed, 16 Jan 2002 06:27:18 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16Qr25-00051a-00 for namedroppers@ops.ietf.org; Wed, 16 Jan 2002 06:27:17 -0800 In-Reply-To: <200201160214.g0G2ENs18497@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed, 16 Jan 2002 09:24:13 -0500 (EST) From: Greg Hudson To: cc: Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 16 Jan 2002 Mark.Andrews@isc.org wrote: > What you are saying to all the existing domain holders under > COM is: "If you want your delegation to be protected from > DoS attacks you have to submit a DS record." This statement is true with or without opt-in. If your delegation isn't signed, the spoofer can just attack the query to your name servers, instead of the query to the .com name servers. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 16 11:11:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12606 for ; Wed, 16 Jan 2002 11:11:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QsPH-000GoN-00 for namedroppers-data@psg.com; Wed, 16 Jan 2002 07:55:19 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.33 #1) id 16QsPG-000GoH-00 for namedroppers@ops.ietf.org; Wed, 16 Jan 2002 07:55:18 -0800 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g0GFpqR28957; Wed, 16 Jan 2002 07:51:52 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 07:56:05 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869901@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'ted@tednet.nl'" , Mike Schiraldi , namedroppers@ops.ietf.org Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) Date: Wed, 16 Jan 2002 07:55:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C19EA6.4644AC70" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C19EA6.4644AC70 Content-Type: text/plain; charset="iso-8859-1" ould you elaborate on that? > > OK, Opt-In changes the definition of the NXT RR from: > > authenticated denial of existance of any name > into > authenticated denial of existance of a secured name But neither of those is a primary security threat. The actual security threat is a downgrade attack in which the attacker represents a secured name as unsecured. The authenticated denial of existence of a secured name is a control on that threat. The authenticated denial of existance of a name is not a necessary control against any threat that is in scope for large domains. > Sounds basic to me You seem to have confused a control with a threat which is a pretty basic error. > > Who is still debating this? > > A number of people believe that the granularity influences how > users and ISP's perceive the security, and that in turn will > influence the speed of the roll out. So making it impossible for the operator of 85% of the DNS domain names to deploy DNSSEC will speed up the roll out? Phill ------_=_NextPart_000_01C19EA6.4644AC70 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C19EA6.4644AC70-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 16 11:57:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13919 for ; Wed, 16 Jan 2002 11:57:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Qt3K-000HVt-00 for namedroppers-data@psg.com; Wed, 16 Jan 2002 08:36:42 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.33 #1) id 16Qt3J-000HVm-00 for namedroppers@ops.ietf.org; Wed, 16 Jan 2002 08:36:41 -0800 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g0GGXIR07131; Wed, 16 Jan 2002 08:33:18 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 08:37:32 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869902@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Paul Vixie'" , namedroppers@ops.ietf.org Subject: Statement of work Date: Wed, 16 Jan 2002 08:37:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C19EAC.104F4AC0" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C19EAC.104F4AC0 Content-Type: text/plain; charset="iso-8859-1" > but it's interesting what can happen when there's no written > scope of work. The problem here is that at the moment there is no commonly agreed methodology for analysing and presenting a security model in a form suitable for use in a standards process. While the one line statement you give is a good start I think we really need some means of adding structure to the analysis. The approach that I have been using is currently proprietary for the far from good reason that I have never had time to write it up for the public. The case studies done for clients are of course client confidential. First off, I would observe that attempts to apply the 'waterfall' model of requirements analysis fail in most applications and particularly so in the security field. The main puspose of a waterfall model appears to be for use by consultants to allow them to delay the customers expectation of a deliverable for as long as possible (measured in billable hours). So we are not really talking about a sequence of events used to construct a structured security model, we are talking about a means of presentation. What I use is a combination of the European Space Agency requirements analysis methodology and the SAS 70 audit methodology. The basic idea is that the report (I emphasize report, in fact I often begin with controls or attacks) starts off analysing the assets under consideration: Assets: [A-NAME] The binding of a domain name to a protocol address [A-DEL] The binding of a domain name to a delegation Next we consider the risks. A risk is something that is intrinsic to an asset. It may or may not be considered a threat depending on the circumstance. Using the standard threat tree approach we consider the Confidentiality, Integrity and Availability (CIA) risks of each information asset. If we were considering a physical asset we might consider theft, loss and destruction. The idea of the methodology is to facilitate the construction of a handbook giving the standard risks for specific assets. Risks: [R-NAME-C] Disclosure of the asset to an unauthorized party [R-NAME-I] Modification of the asset [R-NAME-A] Availability of the asset [R-DEL-C] [R-DEL-I] [R-DEL-A] ditto Immediately we se that there are certain risks that are out of scope. We do not consider the confidentiality of the name binding further because in our particular application it does not constitute a threat. We might consider the confidentiality of name lookups however. to do this we would add in an asset to represent the retreival process 'data in transit'. Threats: [T-NAME-I] Modification of the name binding [T-DEL-I] Modification of the delegation binding [T-DEL-INS] Insertion of a spurious delegation point [T-DEL-DEL] Deletion of a genuine delegation point [T-DEL-MOD] Modification of a delegation point Analysis of threats is an area where you frequently discover additional assets that have to be considered. In this case for example I discovered that the NAME asset could only be secured if the DEL binding was. Here I would normally go through a lot of cycles to generate perhaps twenty odd threats that were specific instances of the generic threat. This is where the record insertion issue would appear for example. Attacks: Not formally part of the security model, but often a useful adjunct. Attacks are simply very specific threats. In many cases they are sumaries of actual attacks. Controls: [C-SIG] Delegation Record Signature Controls [T-DEL-MOD] [C-NXT] NXT Record Signature Controls [T-DEL-DEL] [T-DEL-INS] [C-NXT-OPT] OPT-IN Record Signature Controls [T-DEL-DEL] Consistency: The next stage is to establish the consistency of the security model: Forward: Every Risk must be to an Asset Every Threat must realise a risk Every Attack must specialise a Threat Every control must control one or more threats Backward: Every Threat must be controlled by at least one Control or be stated to be out of scope in the environment Every Risk must generate at least one Threat or be stated to be out of scope in the environment Every asset must consider the set of risks associated with its class In this particular instance it appears that the methodology should be tewaked to allow separate consideration of specific environments. This is something that we have done in the past by developing separate security models for the different applications. However in this case the degree of similarity between the environments (large zone, small zone) is very much greater. Note that the above analysis is incomplete for DNSSEC as a whole, I have only been focusing on the DNSSEC issues specific to NXT and OPT in. This is actually quite usual, there are very few commercial applications where it is possible to persuade a client to develop a genuinely comprehensive security model, at least at my consulting rates. The approach is rather more justifiable when you are writing a specification and the effort will be reused a lot of times. Phill ------_=_NextPart_000_01C19EAC.104F4AC0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C19EAC.104F4AC0-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 16 12:20:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14637 for ; Wed, 16 Jan 2002 12:20:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QtLe-000HmA-00 for namedroppers-data@psg.com; Wed, 16 Jan 2002 08:55:38 -0800 Received: from h240.s231.netsol.com ([216.168.231.240] helo=tron.admin.cto.netsol.com) by psg.com with esmtp (Exim 3.33 #1) id 16QtLd-000Hm4-00 for namedroppers@ops.ietf.org; Wed, 16 Jan 2002 08:55:37 -0800 Received: (from raldi@localhost) by tron.admin.cto.netsol.com (8.11.6/8.11.6) id g0GGtaA07551 for namedroppers@ops.ietf.org; Wed, 16 Jan 2002 11:55:36 -0500 Date: Wed, 16 Jan 2002 11:55:36 -0500 From: Mike Schiraldi To: namedroppers@ops.ietf.org Subject: Re: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) Message-ID: <20020116165536.GB7013@research.netsol.com> References: <200201160214.g0G2ENs18497@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="WhfpMioaduB5tiZL" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i X-Last-Reboot: January 9, 2002 (6 days ago) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --WhfpMioaduB5tiZL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > This statement is true with or without opt-in. If your delegation isn't > signed, the spoofer can just attack the query to your name servers, > instead of the query to the .com name servers. Additionally, making a domain look like it doesn't exist essentially amounts to a denial of service attack*. If a DoS attack is one's goal, and one has the ability to manipulate your DNS packets, no amount of crypto or other security measures can prevent it. *There may be more subtle attacks based on making an unsecure domain look like it doesn't exist, but as you said, this can be done even without opt-in by attacking the child zone. And again, this can't be done with a secure zone. --=20 Mike Schiraldi VeriSign Applied Research --WhfpMioaduB5tiZL Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIKIAYJKoZIhvcNAQcCoIIKETCCCg0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B6wwggR2MIID36ADAgECAhAyACTCO7tQsBTRNUR0/tTjMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMDMyMjAwMDAw MFoXDTAyMDMyMjIzNTk1OVowggEaMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pa2UgU2NoaXJhbGRpMSgwJgYJKoZI hvcNAQkBFhlyYWxkaUByZXNlYXJjaC5uZXRzb2wuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDu28IxMPojtN900dqX3LO3rfhirsJstpbSOzKVwPH9GwIgycFIn3YFkmOpeB40 cBkqNC1HzreGuFFAo9f3Y9xPjbvnEWlNo6oBu/wGL53gUtsUcNcj7tOngfjTr/4V3rohPuWU 4qRAZxjd5qaFUSP3bLh/U/7MoRwRB2Sz82HCqwIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAYOkgLNF2 HYrK+ucdU0TN2PIAtbB3vV0cLhHJfE6zzyL9u5PlAKnxqwVYozd5S/u4Lg1WvDFE3vG3mVIE Fobol2RmSNIo6kOgED48B6oWgU/21lysVZ6DRPnGTSX7FsIH12L0mHj7jSDkzTqtkbzY6is/ YBkKDmeAuXnmljJ7H7wwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG 9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNV BAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN OTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBl cnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQW u1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0Rc qkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqn sX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4w PAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOB gQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s 3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg 5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAyACTCO7tQsBTRNUR0/tTjMAkGBSsOAwIa BQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwMTE2 MTY1NTM2WjAjBgkqhkiG9w0BCQQxFgQU/lEYbme+qOwDqHm3O/CeghVrA7IwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBKtO1F2DUJMmjhMsQf455M XefTEp1RZHXDC1sNGlo5q5SBozjJPkiI+IHUzjCR+scuiniM86PPPms5i32XaOLHDY8GjBOS veYmlLgP2TVCkjIyk8lylo+6+gjmLQP/Q/v6+0OS8QJ1SMHCnbDkUChGiv/BGzsSJBKY/NNc Ax9+Ng== --WhfpMioaduB5tiZL-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 16 18:22:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23469 for ; Wed, 16 Jan 2002 18:22:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Qz7I-000Noi-00 for namedroppers-data@psg.com; Wed, 16 Jan 2002 15:05:12 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.33 #1) id 16Qz7G-000NoV-00 for namedroppers@ops.ietf.org; Wed, 16 Jan 2002 15:05:11 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16Qz78-0005YK-00; Wed, 16 Jan 2002 15:05:02 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) References: <2F3EC696EAEED311BB2D009027C3F4F405869901@vhqpostal.verisign.com> Message-Id: Date: Wed, 16 Jan 2002 15:05:02 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So making it impossible for the operator of 85% of the DNS > domain names to deploy DNSSEC will speed up the roll out? please stop trying to throw corporate weight. it will only justify pissing contests. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 17 07:31:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13215 for ; Thu, 17 Jan 2002 07:31:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16RBQE-000ASX-00 for namedroppers-data@psg.com; Thu, 17 Jan 2002 04:13:34 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.33 #1) id 16RBQE-000ASO-00 for namedroppers@ops.ietf.org; Thu, 17 Jan 2002 04:13:34 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 3D79F31922; Thu, 17 Jan 2002 04:13:31 -0800 (PST) Date: Thu, 17 Jan 2002 13:11:52 +0100 (CET) From: Roy Arends X-X-Sender: To: Cc: , , Subject: proposal to the wg regarding Opt-in Message-ID: <20020117130319.F65646-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Trying to "move on"... As I see it, we (the authors) have the following options: 1) leave the draft as-is, or 2) change the draft so it effectively states that: [currently] o In Opt-In, tagged NXT records indicate the existence or non- existence of all SECURE nodes in the zone. [proposed] o In Opt-In, tagged NXT records indicate the existence or non- existence of all authoritative RRsets in the zone. (this assumes DS, and that DS at delegation point is authoritative data) We would like to ask the wg, in light of the recent discussions and mudthrowing, which path to follow. Note from the authors: We favour the first, and are (reluctantly) willing to go for the second, if that would decrease the amount of fear, uncertainty and doubt to some level, in order to reach consensus. However, real motivations for this option are favoured (so we can include it in the draft). Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 17 12:14:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26897 for ; Thu, 17 Jan 2002 12:14:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16RFpz-000F0E-00 for namedroppers-data@psg.com; Thu, 17 Jan 2002 08:56:27 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.33 #1) id 16RFpy-000F08-00; Thu, 17 Jan 2002 08:56:26 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g0HGr3R01792; Thu, 17 Jan 2002 08:53:03 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 08:57:17 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40586990C@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Randy Bush'" , "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) Date: Thu, 17 Jan 2002 08:57:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C19F77.FBB98A90" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C19F77.FBB98A90 Content-Type: text/plain; charset="iso-8859-1" Randy, Is the point untrue or otherwise factually incorrect? Is the point irrelevant? If the argument is advanced that a particular choice will speed adoption it would seem to me to be very relevant to consider the real world factors that would shape that outcome. The inability to deploy DNSSEC in dotCOM would appear to me to be a very relevant consideration when considering the likely outcome. The co-chair may not consider the issue to be significant, other members of the IESG believe it to be very significant indeed. If Ted's original claim was on point then the rebuttal will surely be. The co-chair can engage in "pissing contests" if he chooses, that is his choice. I am only interested in the technical issues here. Needless inefficiency is offensive to my sight, particularly if I have to pay the resulting costs. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Wednesday, January 16, 2002 6:05 PM > To: Hallam-Baker, Phillip > Cc: namedroppers@ops.ietf.org > Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a > propo sal) > > > > So making it impossible for the operator of 85% of the DNS > > domain names to deploy DNSSEC will speed up the roll out? > > please stop trying to throw corporate weight. it will only justify > pissing contests. > > randy > ------_=_NextPart_000_01C19F77.FBB98A90 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C19F77.FBB98A90-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 17 12:38:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27764 for ; Thu, 17 Jan 2002 12:38:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16RGKb-000Fa9-00 for namedroppers-data@psg.com; Thu, 17 Jan 2002 09:28:05 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.33 #1) id 16RGKa-000Fa1-00; Thu, 17 Jan 2002 09:28:04 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g0HHOeR09048; Thu, 17 Jan 2002 09:24:40 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 09:28:55 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40586990E@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "Hallam-Baker, Phillip" , "'Randy Bush'" Cc: "'namedroppers@ops.ietf.org'" Subject: Resolver efficiency - a NEW technical argument Date: Thu, 17 Jan 2002 09:28:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C19F7C.66AD0260" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C19F7C.66AD0260 Content-Type: text/plain; charset="iso-8859-1" All, So far the discussion has centered on the operations center side issues for OPTIN. There are also efficiency benefits on the resolver side. The point is that with a sparsely secured zone OPTIN NXT records may be cached. If the cache tracks the fact that signature validation has taken place, that may also be cached. Thus the cost of supporting OPTIN in the servers is reduced to a factor roughly proportional to the proportion of secured names in the zone rather than a fixed overhead on every lookup. This might have a significant impact on uptake of DNSSEC at the resolution end. Although the impact of DNSSEC on modern hardware is not high, many installations do not use modern hardware. DNS load can often be easilly supported on an ageing Sun SLC that would otherwise have gone in the skip. Deployment of DNSSEC on the servers will take considerably longer if it requires new hardware to be purchased, particularly in the initial stages when uptake is low. There is a potential chicken and egg problem in which people don't deploy DNSSEC until the servers do and vice versa. For example say we were running DNS on 10 year old Sun SLC. The load is low and so even though the machine only has a 20MHz processor lookup latency is acceptable. Turning DNSSEC on forces the server to do a signature validation on practically every lookup, even if the number of secure zones will initially be negligible. With opt in however the impact of DNSSEC is very much lower. Say there are 10 million dotcom names of which 1,000 are secured. The server looks up 10,000 unique names each day but only needs to check 1000 signatures at worst to respond to queries for insecure zones. People are more likely to deploy DNSSEC lookups despite sparse deployment if the impact is small. There are a lot of ISPs etc where we need to persuade them to deploy DNSSEC on lookups even though they may not secure their own zone (or even have a proper zone of their own). Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 ------_=_NextPart_000_01C19F7C.66AD0260 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C19F7C.66AD0260-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 17 13:30:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29371 for ; Thu, 17 Jan 2002 13:30:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16RH4H-000GTx-00 for namedroppers-data@psg.com; Thu, 17 Jan 2002 10:15:17 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16RH4H-000GTr-00 for namedroppers@ops.ietf.org; Thu, 17 Jan 2002 10:15:17 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16RH4H-000GiL-00 for namedroppers@ops.ietf.org; Thu, 17 Jan 2002 10:15:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020117191238.6c9541fc.olaf@ripe.net> In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40586990E@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F40586990E@vhqpostal.verisign.com> Date: Thu, 17 Jan 2002 19:12:38 +0100 From: "Olaf M. Kolkman" To: "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: Re: Resolver efficiency - a NEW technical argument Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 17 Jan 2002 09:28:39 -0800 "Hallam-Baker, Phillip" wrote: > So far the discussion has centered on the operations center side > issues for OPTIN. No the discussion hasn't centered on that; my, previously voiced, worries are about cost/benefit at the resolver side. > There are also efficiency benefits on the resolver side. I agree with your analysis with respect to increased load. Although my feeling that the costs involved in training somebody to deploy at the 'client' side is probably more than upgrading to a new machine. Operational deployment of DNSSEC in resolvers involves understanding and errors will be made that will render parts of the tree invisible, misconfigured secure entry points and such. I still think introducing granularity will increase the complexity for the guys that have to operate the client side. The 'delegation only' compromise still addresses your worries as well as mine. --Olaf P.S. Although I am still digesting it, I liked your "statement of work" posting. Do you have references available to the "European Space Agency requirements analysis methodology and the SAS 70 audit method", such as books or the like? --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 17 15:52:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12328 for ; Thu, 17 Jan 2002 15:52:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16RJE6-000JJI-00 for namedroppers-data@psg.com; Thu, 17 Jan 2002 12:33:34 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16RJE5-000JJC-00 for namedroppers@ops.ietf.org; Thu, 17 Jan 2002 12:33:33 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16RJE5-000Khi-00 for namedroppers@ops.ietf.org; Thu, 17 Jan 2002 12:33:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201172017.g0HKHHZ58516@open.nlnetlabs.nl> In-Reply-To: ""Hallam-Baker, Phillip"'s message as of Jan 17, 18:29" From: ted@tednet.nl (Ted Lindgreen) Date: Thu, 17 Jan 2002 21:17:17 +0100 To: namedroppers@ops.ietf.org Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting "Hallam-Baker, Phillip", on Jan 17, 18:29, in "RE: OPT-IN at delega ..."] ... > > -----Original Message----- > > From: Randy Bush [mailto:randy@psg.com] > > Sent: Wednesday, January 16, 2002 6:05 PM > > To: Hallam-Baker, Phillip > > Cc: namedroppers@ops.ietf.org > > Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a > > propo sal) > > > > > So making it impossible for the operator of 85% of the DNS > > > domain names to deploy DNSSEC will speed up the roll out? > > > > please stop trying to throw corporate weight. it will only justify > > pissing contests. > > > > randy ... > If Ted's original claim was on point then the rebuttal will > surely be. I thought that Randy's suggestion to throwing the same arguments at each other over and over again was very good, and I refrained from replying. However, it seems Phillip demands my answer, even though all arguments have been repeated many, many, too many, times :-( OK, but this is really my last post on this subject: 1. Yes, Phillip's statement is incorrect: no-one disputes that using non-Opt-In may lead to more startup cost, but also no-one supports Phillip's claim that non-Opt-In makes it IMPOSSIBLE to deploy DNSSEC at large TLDs. 2. I am not concerned, that TLDs, both the non-profit TLDs and for-profit TLDs will jump on DNSSEC as soon as: 1. The standard has been finalised. 2. Serious domainholder demand is expected. Likely, VeriSign will be a frontrunner, Opt-In or non-Opt-In. 3. However, I am really concerned, that users (read: the domainholder's clients) may not embrace DNSSEC soon enough that it leads to great domainholder demand. That will lead to only some scattered secured zones and perhaps even only a few RRs. This, in turn will lead to even less users interest, and the process will stop there. The reason that I am concerned about the users interest is based on: 1. Most of discussion on this list is from a DNS-manager or domainholder perspective. I have hardly read anything from the resolver perspective. I looks like users and their tool, the resolver, are a little ignored. 2. At least two software packages to serve domainholders are available, and people are actively improving it. But little is available on the resolver side. BIND-8 has a sig/key checker/chaser ("host -s"), but it's broken. BIND-9 lacks even such a basic tool (NLnet Labs has produced an addition to both "host" and "dig" to implement a checker/chaser in BIND-9. This was offered to Nominum, but not included (yet?)). It looks that there is really little interest in doing anything with the costly KEYs and SIGs... I think, that looking at DNSSEC from the resolver perspective needs much more attention, and soon, otherwise DNSSEC will likely remain limited to scattered parts of the DNS tree. Back to Opt-In: from the resolver perspective, Opt-In does not seem helpfull to give users a warm, secured feeling, because it further obscures what's secured and what's not. -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 17 18:37:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15609 for ; Thu, 17 Jan 2002 18:37:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16RLoZ-000MIU-00 for namedroppers-data@psg.com; Thu, 17 Jan 2002 15:19:23 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16RLoZ-000MIN-00 for namedroppers@ops.ietf.org; Thu, 17 Jan 2002 15:19:23 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16RLoZ-000Pcm-00 for namedroppers@ops.ietf.org; Thu, 17 Jan 2002 15:19:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869916@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'ted@tednet.nl'" , namedroppers@ops.ietf.org Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) Date: Thu, 17 Jan 2002 14:34:21 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit OK now you have fully explained your objection it sounds to be that we are returning to the issue that Paul originally identified, the need for a clear statement of work that describes what DNSSEC is meant to secure and what it is not. I don't agree that it is harder to explain OPTIN to that audience. In either case we have to explain to them that there will be specific authenticity and integrity guarantees provided to parties querying your domain if you sign your zone and register your signing key and that other wise there will be no security. It would appear to me that it is much easier to communicate this message if the OPTIN NXT records only cover the zones that have a signing key registered. Otherwise what we are doing is like a car manufacturer installing a lock and alarm system on the driver side doors alone and claiming that the car is theft proof. We may have removed 50% of the original vulnerability but we have no more security since the car thief will simply concentrate his attack on the unsecured passenger side door. A secure delegation to an insecure server does not achieve much if anything. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: ted@tednet.nl [mailto:ted@tednet.nl] > Sent: Thursday, January 17, 2002 3:17 PM > To: namedroppers@ops.ietf.org > Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a > propo sal) > > > [Quoting "Hallam-Baker, Phillip", on Jan 17, 18:29, in "RE: > OPT-IN at delega ..."] > ... > > > -----Original Message----- > > > From: Randy Bush [mailto:randy@psg.com] > > > Sent: Wednesday, January 16, 2002 6:05 PM > > > To: Hallam-Baker, Phillip > > > Cc: namedroppers@ops.ietf.org > > > Subject: RE: OPT-IN at delegation points only (Re: DS and > Opt-in - a > > > propo sal) > > > > > > > So making it impossible for the operator of 85% of the DNS > > > > domain names to deploy DNSSEC will speed up the roll out? > > > > > > please stop trying to throw corporate weight. it will > only justify > > > pissing contests. > > > > > > randy > ... > > If Ted's original claim was on point then the rebuttal will > > surely be. > > I thought that Randy's suggestion to throwing the same arguments > at each other over and over again was very good, and I refrained > from replying. However, it seems Phillip demands my answer, even > though all arguments have been repeated many, many, too many, > times :-( > > OK, but this is really my last post on this subject: > > 1. Yes, Phillip's statement is incorrect: no-one disputes that using > non-Opt-In may lead to more startup cost, but also no-one supports > Phillip's claim that non-Opt-In makes it IMPOSSIBLE to deploy > DNSSEC at large TLDs. > > 2. I am not concerned, that TLDs, both the non-profit TLDs and > for-profit TLDs will jump on DNSSEC as soon as: > 1. The standard has been finalised. > 2. Serious domainholder demand is expected. > Likely, VeriSign will be a frontrunner, Opt-In or non-Opt-In. > > 3. However, I am really concerned, that users (read: the > domainholder's > clients) may not embrace DNSSEC soon enough that it leads to great > domainholder demand. That will lead to only some scattered secured > zones and perhaps even only a few RRs. This, in turn will lead to > even less users interest, and the process will stop there. > > The reason that I am concerned about the users interest is based on: > > 1. Most of discussion on this list is from a DNS-manager or > domainholder > perspective. I have hardly read anything from the resolver > perspective. > I looks like users and their tool, the resolver, are a > little ignored. > 2. At least two software packages to serve domainholders are > available, and > people are actively improving it. > But little is available on the resolver side. BIND-8 has a sig/key > checker/chaser ("host -s"), but it's broken. BIND-9 lacks even such > a basic tool (NLnet Labs has produced an addition to both > "host" and > "dig" to implement a checker/chaser in BIND-9. This was offered > to Nominum, but not included (yet?)). It looks that there is really > little interest in doing anything with the costly KEYs and SIGs... > > I think, that looking at DNSSEC from the resolver perspective needs > much more attention, and soon, otherwise DNSSEC will likely remain > limited to scattered parts of the DNS tree. > > Back to Opt-In: from the resolver perspective, Opt-In does not > seem helpfull to give users a warm, secured feeling, because it > further obscures what's secured and what's not. > > -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 17 21:23:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17741 for ; Thu, 17 Jan 2002 21:23:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ROTK-000P8Q-00 for namedroppers-data@psg.com; Thu, 17 Jan 2002 18:09:38 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16ROTK-000P8K-00 for namedroppers@ops.ietf.org; Thu, 17 Jan 2002 18:09:38 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16ROTK-00085u-00 for namedroppers@ops.ietf.org; Thu, 17 Jan 2002 18:09:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <200201172017.g0HKHHZ58516@open.nlnetlabs.nl> Message-ID: Date: Thu, 17 Jan 2002 18:05:37 -0800 (PST) From: Brian Wellington To: Ted Lindgreen cc: Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 17 Jan 2002, Ted Lindgreen wrote: > 2. At least two software packages to serve domainholders are available, and > people are actively improving it. > But little is available on the resolver side. BIND-8 has a sig/key > checker/chaser ("host -s"), but it's broken. BIND-9 lacks even such > a basic tool (NLnet Labs has produced an addition to both "host" and > "dig" to implement a checker/chaser in BIND-9. This was offered > to Nominum, but not included (yet?)). It looks that there is really > little interest in doing anything with the costly KEYs and SIGs... For the record, my objection to this at the time was the fact that what was provided was not a "basic tool", but an extension to an already overcomplicated program, that would have had strange interactions with existing features of the overcomplicated program. If someone were to submit a basic tool that just verified a chain of signatures, I see no reason why it wouldn't be included in future releases of BIND 9. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 20 16:16:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16291 for ; Sun, 20 Jan 2002 16:16:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16SOth-000Fs5-00 for namedroppers-data@psg.com; Sun, 20 Jan 2002 12:49:01 -0800 Received: from dhcp317.ripemtg.ripe.net ([193.0.5.61] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16SOtf-000Frz-00 for namedroppers@ops.ietf.org; Sun, 20 Jan 2002 12:48:59 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16SOtb-0000IJ-00 for namedroppers@ops.ietf.org; Sun, 20 Jan 2002 21:48:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3C4AEE10.20A1DAF9@trab.se> Date: Sun, 20 Jan 2002 17:19:28 +0100 From: Dan Oscarsson To: namedroppers@ops.ietf.org Subject: Native UCS support in DNS versus IDNA Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As the DNSEXT group have many experts on DNS I would like your comments on the following. As you may know the IDN working group is working on how to be able to use domain names with non-ASCII characters, often called IDNs. This has resulted in a way to encode IDNs into ASCII using an ASCII Compatible Encoding (ACE) to make it possible for old software only expecting ASCII, to be able to access IDNs. And two main solutions to how DNS should work: 1) The IDNA solution. This does not modify the DNS protocol and does not require anything new from the DNS servers. In this the client converts the domain name into a case and form insensitive format and encodes it with an ACE. The client send sends the query into DNS. DNS servers handling IDNs have their domains loaded with the same ACE encoded case and form insensitive format of the name and need only do a binary compare. Only lables corresponding to "host names" are encoded. Other lables of character fileds in RRs are not handled. 2) The native UCS solution. This requires modification to the DNS protocol to be able to support non-IDN servers and clients with ACE encoded names, and modified servers. It uses UCS in the form of UTF-8 in lables and all other character data fields, but will respond with ACE encoded lables when the query is from a client that only understands ASCII. This fallback is like what the IDNA solution is using. I belong to those who think a native solution is better than a solution layered on top of DNS by encoding things into ASCII. As the IDNA has a single solution (there are several not yet fully ready native versions) it currently looks like it will be moved to RFC status soon, I have tried to see what IDNA would mean for a domain and if it would affect a native solution introduced later. I then found out that by allowing the IDNA solutions now, a native solution will require that many queries will have to be retried, once using native UCS and once using ACE. If effect doubling the calls done between client and server. This can be somewhat reduced by caching the failed 1:st try, just like you can cache if a server understands EDNS or not. Also, to reduce traffic, you cannot just use a flag bit to tell the server if the client understands native UCS, as this may be cleared on the way to the server, instead you have to use a protocol extension that will result in query failure. To show this I have tried to below show different cases. I have for some hours tried to get something you can understand, I hope you can. What I try to show is that, in the case where we allow the IDNA solution with unmodified servers having ACE encoded names, a future native UCS solution will require more retries and caching of state to reduce the overhead of retries. But if we only allow a native solution, it will work much simpler and get no overhead (except if EDNS is used, but then the EDNS state is the same as for all other EDNS requests) and it will work with both IDNA clients, all current clients and new native UCS clients. In my cases below, I show different cases with different clients and servers. First by direct connection between client to server and then with a intermediate server. For the UCS client cases I show the difference between using a flag indicating UCS awareness using a flag bit in the standard header or using a flag bit in the EDNS OPT RR. As said above, to reduce overhead, a flag bit will probably not be good enough if IDNA servers are allowed, instead an extension like a new label type which will result in call failure for both old a new EDNS servers may be required. I have not included what that may change because it will still result in nearly the same retries. Observer the difference when no IDNA servers are allowed. Please correct my cases or show that my thinking is wrong. After all this and after you have studied this, my questions to you are: - Should DNS natively handle non-ASCII character data? - If the answer to the above question is yes, and my analysis that IDNA will result in a native solution being more complex and requiring more overhead, is it acceptible that IDNA as it is defined today, is allowed? From what I can see, once IDNA is allowed, native handling of non-ASCII in DNS itself will never be easy. Dan Oscarsson Cases below. Definitions ADNS-SERVER - a server with no UCS support and only ASCII domain names and there exists no IDNA servers in the world IDNA-CLIENT - a client doing IDNA queries (ACE encoded domain names) IDNA-SERVER - a UCS unaware DNS server having ACE encoded domain names or just ASCII domain names, when IDNA is allowed UCS-CLIENT - a client doing native UCS queries or ACE encoded queries UCS-SERVER - a UCS aware DNS server having all data in UCS. Can answer both using native UCS or ACE encoded labels. IDNA-CLIENT(ACE) a IDNA client looking for non-ASCII domain name using ACE UCS-CLIENT(ACE) a UCS client looking for non-ASCII domain name using ACE UCS-CLIENT(UCS) a UCS client looking for non-ASCII domain name using UCS Query cases showing call chain for client to server and response to client -------------------------------------------------------------------------- : Looking for a non-ASCII domain name with IDNA servers Case: IDNA-SERVER, IDNA-CLIENT IDNA-CLIENT(ACE) -> IDNA-SERVER -> IDNA-CLIENT (found or not found) Case: IDNA-SERVER, UCS-CLIENT, UCS flag in standard query header UCS-CLIENT(UCS) -> IDNA-SERVER -> UCS-CLIENT (not found) need retry UCS-CLIENT(ACE) -> IDNA-SERVER -> UCS-CLIENT (found or not found) Case: IDNA-SERVER no EDNS, UCS-CLIENT, UCS flags in EDNS OPT RR UCS-CLIENT(UCS) -> IDNA-SERVER -> UCS-CLIENT (failure EDNS) need retry UCS-CLIENT(ACE) -> IDNA-SERVER -> UCS-CLIENT (found or not found) Case: IDNA-SERVER with EDNS, UCS-CLIENT, UCS flags in EDNS OPT RR UCS-CLIENT(UCS) -> IDNA-SERVER -> UCS-CLIENT (not found) need retry UCS-CLIENT(ACE) -> IDNA-SERVER -> UCS-CLIENT (found or not found) : Looking for a non-ASCII domain name with UCS servers : and NO IDNA servers are allowed Case: UCS-SERVER, IDNA-CLIENT IDNA-CLIENT(ACE) -> UCS-SERVER -> IDNA-CLIENT (found or not found) Case: UCS-SERVER, UCS-CLIENT, UCS flag in standard query header UCS-CLIENT(UCS) -> UCS-SERVER -> UCS-CLIENT (found or not found) Case: UCS-SERVER, UCS-CLIENT, UCS flags in EDNS OPT RR UCS-CLIENT(UCS) -> UCS-SERVER -> UCS-CLIENT (found or not found) Case: ADNS-SERVER, UCS-CLIENT, UCS flag in standard query header UCS-CLIENT(UCS) -> ADNS-SERVER -> UCS-CLIENT (not found) Case: ADNS-SERVER no EDNS, UCS-CLIENT, UCS flag in EDNS OPT RR UCS-CLIENT(UCS) -> ADNS-SERVER -> UCS-CLIENT (failure EDNS) need retry UCS-CLIENT(ACE) -> ADNS-SERVER -> UCS-CLIENT (not found) Case: ADNS-SERVER with EDNS, UCS-CLIENT, UCS flag in EDNS OPT RR UCS-CLIENT(UCS) -> ADNS-SERVER -> UCS-CLIENT (not found) Query cases showing call chain for client to server and response to client when there is a DNS server between client and final server -------------------------------------------------------------------------- : Looking for a non-ASCII domain name with IDNA servers Case: IDNA-SERVER, IDNA-CLIENT IDNA-CLIENT(ACE) -> IDNA-SERVER -> IDNA-SERVER IDNA-CLIENT <- IDNA-SERVER <-------! answer (found or not found) Case: IDNA-SERVER, UCS-CLIENT, UCS flag in standard query header UCS-CLIENT(UCS) -> IDNA-SERVER -> IDNA-SERVER UCS-CLIENT <- IDNA-SERVER <-------! answer: (not found) need retry UCS-CLIENT(ACE) -> IDNA-SERVER -> IDNA-SERVER UCS-CLIENT <- IDNA-SERVER <-------! answer (found or not found) Case: IDNA-SERVER no EDNS, UCS-CLIENT, UCS flags in EDNS OPT RR UCS-CLIENT(UCS) -> IDNA-SERVER UCS-CLIENT <-------! answer: (failure EDNS) need retry UCS-CLIENT(ACE) -> IDNA-SERVER -> IDNA-SERVER UCS-CLIENT <- IDNA-SERVER <-------! answer: (found or not found) Case: IDNA-SERVER with EDNS, next without, UCS-CLIENT, UCS flags in EDNS OPT RR UCS-CLIENT(UCS) -> IDNA-SERVER -> IDNA-SERVER UCS-CLIENT <- IDNA-SERVER <-------! answer: (failure EDNS) need retry UCS-CLIENT(ACE) -> IDNA-SERVER -> IDNA-SERVER UCS-CLIENT <- IDNA-SERVER <-------! answer: (found or not found) Case: IDNA-SERVER with EDNS, next with EDNS, UCS-CLIENT,UCS flags in EDNS OPT RR UCS-CLIENT(UCS) -> IDNA-SERVER -> IDNA-SERVER UCS-CLIENT <- IDNA-SERVER <-------! answer: (not found) need retry UCS-CLIENT(ACE) -> IDNA-SERVER -> IDNA-SERVER UCS-CLIENT <- IDNA-SERVER <-------! answer: (found or not found) : Looking for a non-ASCII domain name with UCS servers : and NO IDNA-SERVERS Case: UCS-SERVER, IDNA-CLIENT IDNA-CLIENT(ACE) -> UCS-SERVER -> UCS-SERVER IDNA-CLIENT <- UCS-SERVER <------! answer: (found or not found) Case: UCS-SERVER, UCS-CLIENT, UCS flag in standard query header UCS-CLIENT(UCS) -> UCS-SERVER -> UCS-SERVER UCS-CLIENT <- UCS-SERVER <------! answer: (found or not found) Case: UCS-SERVER, ADNS-SERVER, UCS-CLIENT, UCS flag in standard query header UCS-CLIENT(UCS) -> UCS-SERVER -> ADNS-SERVER UCS-CLIENT <- UCS-SERVER <------! answer: (not found) Cases with EDNS gets even more complex : Looking for a non-ASCII domain name with UCS servers : and also allow IDNA servers Case: UCS-SERVER, IDNA-CLIENT IDNA-CLIENT(ACE) -> UCS-SERVER -> UCS-SERVER IDNA-CLIENT <- UCS-SERVER <------! answer: (found or not found) Case: UCS-SERVER, UCS-CLIENT, UCS flag in standard query header UCS-CLIENT(UCS) -> UCS-SERVER -> UCS-SERVER UCS-CLIENT <- UCS-SERVER <------! answer: (found or not found), if not found => retry because an IDNA server may have answerd UCS-CLIENT(ACE) -> UCS-SERVER -> UCS-SERVER UCS-CLIENT <- UCS-SERVER <------! answer: (found or not found) Case: UCS-SERVER, ADNS-SERVER, UCS-CLIENT, UCS flag in standard query header UCS-CLIENT(UCS) -> UCS-SERVER -> IDNA-SERVER UCS-CLIENT <- UCS-SERVER <------! answer: (not found) need retry UCS-CLIENT(ACE) -> UCS-SERVER -> IDNA-SERVER UCS-CLIENT <- UCS-SERVER <------! answer: (found or not found) Cases with EDNS gets even more complex to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 21 18:45:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28277 for ; Mon, 21 Jan 2002 18:45:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Snle-000JjQ-00 for namedroppers-data@psg.com; Mon, 21 Jan 2002 15:22:22 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.33 #1) id 16Snld-000JjK-00 for namedroppers@ops.ietf.org; Mon, 21 Jan 2002 15:22:21 -0800 Received: from bebop.France.Sun.COM ([129.157.179.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06941; Mon, 21 Jan 2002 16:22:11 -0700 (MST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0LNM1F05581; Tue, 22 Jan 2002 00:22:01 +0100 (MET) Date: Tue, 22 Jan 2002 00:18:37 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Native UCS support in DNS versus IDNA To: Dan Oscarsson Cc: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <3C4AEE10.20A1DAF9@trab.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > 2) The native UCS solution. This requires modification to the > DNS protocol to be able to support non-IDN servers and clients > with ACE encoded names, and modified servers. > It uses UCS in the form of UTF-8 in lables and all other > character data fields, but will respond with ACE encoded > lables when the query is from a client that only understands > ASCII. This fallback is like what the IDNA solution is using. I should really ask for the name of your Internet-Draft since I suspect that the issues are a bit too complex to understand from an email exchange. How is your idea different than draft-hall-dm-idns-00.txt? They sound rather similar. Does the above "response with ACE encoded labels" imply that the server has both an ACE record and a UTF-8 record in the zone file for the same actual name? If not, how does this work with DNSSEC and offline keys for signing the zone? Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 22 00:58:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04329 for ; Tue, 22 Jan 2002 00:58:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Stgh-0001NS-00 for namedroppers-data@psg.com; Mon, 21 Jan 2002 21:41:39 -0800 Received: from dhcp317.ripemtg.ripe.net ([193.0.5.61] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16Stgg-0001NL-00 for namedroppers@ops.ietf.org; Mon, 21 Jan 2002 21:41:39 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16Stgb-000EBL-00 for namedroppers@ops.ietf.org; Tue, 22 Jan 2002 06:41:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <001501c1a2ee$1d290bf0$0a0aa8c0@labs.ntrg.com> References: From: "Eric A. Hall" To: "Erik Nordmark" , "Dan Oscarsson" Cc: Subject: Re: Native UCS support in DNS versus IDNA Date: Mon, 21 Jan 2002 20:40:09 -0600 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Erik Nordmark" wrote: > I should really ask for the name of your Internet-Draft since I suspect > that the issues are a bit too complex to understand from an email exchange. > > How is your idea different than draft-hall-dm-idns-00.txt? > They sound rather similar. Actually, Dan had a draft out before mine. I don't think he's talking about that approach however. He seems to be talking about not tagging the labels via EDNS (apologies to Dan if this is incorrect), which is not an approach that I advocate. > If not, how does this work with DNSSEC and offline keys for signing > the zone? Not to steal Dan's thread, but since you brought these issues up, I've devised a scheme for dealing with this and am incorporating it into the next version of the draft, ETA next week. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 22 12:44:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01928 for ; Tue, 22 Jan 2002 12:44:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16T4YH-000CpF-00 for namedroppers-data@psg.com; Tue, 22 Jan 2002 09:17:41 -0800 Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se) by psg.com with esmtp (Exim 3.33 #1) id 16T4YF-000Cog-00 for namedroppers@ops.ietf.org; Tue, 22 Jan 2002 09:17:39 -0800 Received: from maila.telia.se (localhost [127.0.0.1]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g0MHHRu05092 for ; Tue, 22 Jan 2002 18:17:27 +0100 (MET) Received: from trab.se (terra.malmo.trab.se [131.115.48.22]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g0MHHQ605083; Tue, 22 Jan 2002 18:17:26 +0100 (MET) Message-ID: <3C4D9E6D.3A2C1D42@trab.se> Date: Tue, 22 Jan 2002 18:16:29 +0100 From: Dan Oscarsson X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: Erik.Nordmark@eng.sun.com, namedroppers@ops.ietf.org Subject: Re: Native UCS support in DNS versus IDNA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >I should really ask for the name of your Internet-Draft since I suspect >that the issues are a bit too complex to understand from an email >exchange. >How is your idea different than draft-hall-dm-idns-00.txt? >They sound rather similar. My current draft is called: draft-ietf-idn-udns-03.txt and is quite like Eric's. It has also changed several times. In short I think you could say that to let the server know if the client can handle UCS, it has to inform the server in some way. My original ideas was to use the last unassigned flag bit in the query header because this would allow non-ASCII to be handled without having to add EDNS. Later versions have switched to EDNS even though I still think using the last free bit is nicest at gives least overhead. When a server got a request from a client indicating it understands UCS, it will give the answer in UCS. Otherwise it will ACE encode the answer so that it can be handled by clients unable to handle non-ASCII. This will work fine as long as all servers handling zones with non-ASCII characters are of the above UCS understanding type. But as IDNA is defined, it allowes servers only understanding ASCII to serve domain with non-ASCII by having its zone loaded with the ACE-encoded form of a name. These servers will not match a lookup for a name coming in using UCS. It will therefore force the client to first identify if the server can handle UCS, and then either send the query using UCS if it can handle it or use ACE if not. Without IDNA the client need not know if the server can handle UCS, if can just send away the query. So with IDNA a client wanting to use UCS will have to do two queries, one to test if the server understands UCS and one to send the query. It some cases this can be combined, but you will get an overhead for many years forward, especially if what the IDNA people says is true: that it will be a long time before a significant amount of the current DNS servers are upgraded. >Does the above "response with ACE encoded labels" imply that the >server has both an ACE record and a UTF-8 record in the zone file for >the same >actual name? As I would expect it, a UCS aware server will have all labels in UTF-8 (or UCS) internally. Only one format. Conversion to ACE will only be done when sending answers to old non-UCS aware clients. >If not, how does this work with DNSSEC and offline keys for signing the >zone? I think DNSSEC will have to enhanced with how to handle non-ASCII. Basically sorting now is defined on the same base as matching: case-insensitivity by making all lower case, the same can be applied on UCS but more letters will be changed before sorting. I have not looked at the rules for signing and how offline signing is done, but it is not much different when using UCS. All you have to agree on is to do it on the same format. When you include non-ASCII, the data should be in native format (UCS-4 or in UTF-8), not some encoded form like ACE. ACE is for backward compatibility. I would not expect servers doing DNSSEC to be that ancient. Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 22 13:35:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03976 for ; Tue, 22 Jan 2002 13:35:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16T5Vm-000E2Z-00 for namedroppers-data@psg.com; Tue, 22 Jan 2002 10:19:10 -0800 Received: from mercury.sun.com ([192.9.25.1]) by psg.com with esmtp (Exim 3.33 #1) id 16T5Vl-000E2T-00 for namedroppers@ops.ietf.org; Tue, 22 Jan 2002 10:19:09 -0800 Received: from bebop.France.Sun.COM ([129.157.179.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12915; Tue, 22 Jan 2002 10:19:02 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0MIIrF23137; Tue, 22 Jan 2002 19:18:58 +0100 (MET) Date: Tue, 22 Jan 2002 19:15:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Native UCS support in DNS versus IDNA To: Dan Oscarsson Cc: Erik.Nordmark@eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <3C4D9E6D.3A2C1D42@trab.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > As I would expect it, a UCS aware server will have all labels > in UTF-8 (or UCS) internally. Only one format. Conversion to ACE > will only be done when sending answers to old non-UCS aware clients. > >If not, how does this work with DNSSEC and offline keys for signing the > >zone? > I think DNSSEC will have to enhanced with how to handle non-ASCII. Why? DNS can handle any string of bytes including DNSsec. > Basically sorting now is defined on the same base as matching: > case-insensitivity by making all lower case, the same can be applied > on UCS but more letters will be changed before sorting. The fact that DNSsec requires an order (what you call "sorting") is irrelevant. An order based on the byte values in a string of bytes is sufficient to have NXT be well-defined. > I have not > looked at the rules for signing and how offline signing is done, > but it is not much different when using UCS. All you have to agree > on is to do it on the same format. When you include non-ASCII, > the data should be in native format (UCS-4 or in UTF-8), not some > encoded form like ACE. > ACE is for backward compatibility. I would not expect servers doing > DNSSEC to be that ancient. That isn't the point. If you allow offline signing (or even if you have the key online but don't want to sign ACE records on the fly) you need the zone to have a SIG record for both the UTF-8 name and the ACE name. Since SIG records are significantly larger than e.g. A/AAAA records you are not saving much space by having the ACE A/AAAA record to be generated on the fly. Thus it seems just as simple to say that the zone contains IN A 1.2.3.4 IN A 1.2.3.4 IN SIG ... IN SIG ... It is true that the first record above can be generated on the fly, but it doesn't save much space when the records are signed. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 24 10:37:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23871 for ; Thu, 24 Jan 2002 10:37:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16TlZl-000KG8-00 for namedroppers-data@psg.com; Thu, 24 Jan 2002 07:14:05 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.33 #1) id 16TlZj-000KG2-00 for namedroppers@ops.ietf.org; Thu, 24 Jan 2002 07:14:04 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23105; Thu, 24 Jan 2002 10:13:59 -0500 (EST) Message-Id: <200201241513.KAA23105@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-01.txt Date: Thu, 24 Jan 2002 10:13:59 -0500 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 : Limiting the Scope of the KEY Resource Record Author(s) : D. Massey, S. Rose Filename : draft-ietf-dnsext-restrict-key-for-dnssec-01.txt Pages : 9 Date : 23-Jan-02 This document limits the KEY resource record to only DNSSEC keys. The original KEY resource record used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys in one record was a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RDATA. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are removed. Three existing application key sub-types are changed to historic, but the format of the KEY record is not changed. This document updates RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-restrict-key-for-dnssec-01.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-restrict-key-for-dnssec-01.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: <20020123143009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-restrict-key-for-dnssec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020123143009.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. From owner-namedroppers@ops.ietf.org Thu Jan 24 11:48:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26736 for ; Thu, 24 Jan 2002 11:48:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16TmfO-000MHE-00 for namedroppers-data@psg.com; Thu, 24 Jan 2002 08:23:58 -0800 Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se) by psg.com with esmtp (Exim 3.33 #1) id 16TmfN-000MH7-00 for namedroppers@ops.ietf.org; Thu, 24 Jan 2002 08:23:57 -0800 Received: from maila.telia.se (localhost [127.0.0.1]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g0OGNtl08450 for ; Thu, 24 Jan 2002 17:23:55 +0100 (MET) Received: from trab.se (terra.malmo.trab.se [131.115.48.22]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g0OGNrc08435; Thu, 24 Jan 2002 17:23:53 +0100 (MET) Message-ID: <3C5034E6.3AE369E7@trab.se> Date: Thu, 24 Jan 2002 17:23:02 +0100 From: Dan Oscarsson X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: Erik.Nordmark@eng.sun.com, namedroppers@ops.ietf.org Subject: Re: Native UCS support in DNS versus IDNA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I think DNSSEC will have to enhanced with how to handle non-ASCII. > >Why? DNS can handle any string of bytes including DNSsec. Yes, but to do case-insensitive matching on UCS you have to expand the matching algorithm comared to today. >Thus it seems just as simple to say that the zone contains > IN A 1.2.3.4 > IN A 1.2.3.4 > IN SIG ... > IN SIG ... >It is true that the first record above can be generated on the fly, but >it doesn't save much space when the records are signed. The ACE-version of the name is not part of the zone. ACE is only for backward compatibility. If I do a lookup in DNS, or a zone transfer, with a UCS aware client, it will only get UCS encoded data back if the server is UCS aware. Convertion to ACE is done if the client cannot handle UCS. I would recommend that DNSSEC is not done on ACE encoded data. The original format of the zone is native UCS in the form of UTF-8, not ACE format. You do not want to require a zone to contain two versions of every record with labels containg non-ASCII? Nobody would like to enter two versions of the same name and what would happen with the IDNA solution? The IDNA solution does only contain records with ACE labels. This may be an additional complication apart from my original query if IDNA should be introduced due to the additional overhead it will produce for a native solution. Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 25 08:02:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01009 for ; Fri, 25 Jan 2002 08:02:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16U5aT-000O3S-00 for namedroppers-data@psg.com; Fri, 25 Jan 2002 04:36:09 -0800 Received: from mercury.sun.com ([192.9.25.1]) by psg.com with esmtp (Exim 3.33 #1) id 16U5aS-000O3M-00 for namedroppers@ops.ietf.org; Fri, 25 Jan 2002 04:36:08 -0800 Received: from bebop.France.Sun.COM ([129.157.179.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA10879; Fri, 25 Jan 2002 04:36:07 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0PCa1F25334; Fri, 25 Jan 2002 13:36:01 +0100 (MET) Date: Fri, 25 Jan 2002 13:32:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Native UCS support in DNS versus IDNA To: Dan Oscarsson Cc: Erik.Nordmark@eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <3C5034E6.3AE369E7@trab.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The ACE-version of the name is not part of the zone. ACE is only for > backward compatibility. If I do a lookup in DNS, or a zone transfer, > with a UCS aware client, it will only get UCS encoded data back > if the server is UCS aware. Convertion to ACE is done if the client > cannot handle UCS. I would recommend that DNSSEC is not done > on ACE encoded data. The original format of the zone is native UCS > in the form of UTF-8, not ACE format. You do not want to > require a zone to contain two versions of every record with labels > containg non-ASCII? Nobody would like to enter two versions > of the same name and what would happen with the IDNA solution? > The IDNA solution does only contain records with ACE labels. Taking your claim that you don'tever want dual records for the same underlying name it seems like there is two choices: 1. IDNA forever - SIG records for the ACE-name records etc 2. ACE-name record generated on the fly by server. No SIG records for ACE-names. I agree with your argument that #1 is not the most efficient encoding of IDN names, but I think that #2 either will not happen in practise or that it will further delay DNSsec. Not happen at all because: I assume folks want IDN support tomorrow thus some zones want to do this without waiting for new DNS server software (and we can't prevent them from doing so). Thus they takes today's DNS server software and places ACE names in the zone. If the also see a benefit in providing DNSsec they sign the zone. Thus there would be some secure zones containing ACE names. How can they be conviced that they should drop the DNSsec (no more SIGs for the ACE names) for some better efficiency in the names over the wire? Will further delay DNSsec deployment because: For the zones that actually deploy the new 'ACE on the fly' DNS server and then want to deploy DNSsec the clients will only be able to take advantage of DNSsec if all the DNS servers on the path from the client to the authoritative servers support the new scheme used to distinguish UCS labels from ASCII labels. So while the final point of UCS support in all servers and no ACE looks attractive, there are significant issues around getting from here to there that makes it look a lot less attractive. Of course, #2 also assumes that the security property is not per zone but per name/RR in the zone. Others might have issues with such an approach... Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 27 08:43:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29499 for ; Sun, 27 Jan 2002 08:43:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16UpE6-000JOt-00 for namedroppers-data@psg.com; Sun, 27 Jan 2002 05:20:06 -0800 Received: from mail.telia.se ([131.115.15.109] helo=mailb.telia.se) by psg.com with esmtp (Exim 3.33 #1) id 16UpE5-000JOl-00 for namedroppers@ops.ietf.org; Sun, 27 Jan 2002 05:20:05 -0800 Received: from mailb.telia.se (localhost [127.0.0.1]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g0RDK3B03166 for ; Sun, 27 Jan 2002 14:20:03 +0100 (MET) Received: from trab.se (terra.malmo.trab.se [131.115.48.22]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g0RDK0t03155; Sun, 27 Jan 2002 14:20:00 +0100 (MET) Message-ID: <3C53FE4E.8D4DCDC8@trab.se> Date: Sun, 27 Jan 2002 14:19:10 +0100 From: Dan Oscarsson X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: Erik.Nordmark@eng.sun.com, namedroppers@ops.ietf.org Subject: Re: Native UCS support in DNS versus IDNA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Taking your claim that you don'tever want dual records for the same >underlying name it seems like there is two choices: >1. IDNA forever - SIG records for the ACE-name records etc >2. ACE-name record generated on the fly by server. No SIG records for > ACE-names. > >I agree with your argument that #1 is not the most efficient encoding of IDN >names, but I think that #2 either will not happen in practise or that it >will further delay DNSsec. >Not happen at all because: I assume folks want IDN support tomorrow >thus some zones want to do this without waiting for new DNS server software >(and we can't prevent them from doing so). >Thus they takes today's DNS server software and places ACE names in the zone. >If the also see a benefit in providing DNSsec they sign the zone. >Thus there would be some secure zones containing ACE names. >How can they be conviced that they should drop the DNSsec (no more SIGs for the >ACE names) for some better efficiency in the names over the wire? I would expect that if you do the trouble of changing DNS server to get DNSsec you could as well move to one that can handle UCS. UCS in DNS server is faire simple to implement, DNSsec is much more difficult. There exists DNS servers handling native UCS today (for example the nubind) though not following any defined standard as there is none. For me it would be much simpler to update my DNS server to handle UCS than to get all needed applications on my system to use IDNA. But the world is not as simple as the two choices above. IDNA defines that the labels that are "host names" are to be ACE encoded. So not all labels in IDNA are ACE encoded and the choice on which labels are host names is up to the zone manager/applications. By using native UCS in DNS all labels will use the same character encoding (UTF-8). This includes all the labels INDA do not encode or cannot represent as its does a conversion which destroys information before encoding into ACE. An old (non-UCS aware client) will from a UCS aware server see the zone as one containg labels in ASCII, non-ASCII labels are converted into ACE. DNSsec could treat the zone like that and sign it as that. A new (UCS aware) client will from a UCS aware server see the zone as one containg labels in UTF-8 and DNSsec could sign that. A UCS aware client should not get any ACE encoded labels from a UCS aware server (but it may get ACE labels from a IDNA server). The DNS server here do not have to generate ACE on the fly, it can do it when loading the zone. But both forms should not be included in an answer. Then clients would have to handle things like: xxxxx IN PTR ucs-name. xxxxx IN PTR ACE-name. giving unnecessary complexity and is it acceptible for DNSsec that when responding to "old" clients only use ACE records and when responding to UCS clients with both? For me it feels like a client should only see one format. Otherwise the client have to spend time identifying which represent the same record and should be treated as one. Of course one way to go could be to treat the IDNA world as totally separate from the UCS world and have the UCS world be invisible for the "old" ASCII world (by not doing conversion to ACE and not returning any records with non-ASCII in). So where should we go? IDNA only, IDNA plus ACE encoding everything else in non-ASCII, native UCS in DNS with or without ACE to support the old world, or something else. Currently I have a strong feeling that DNS is going from the clear simple service to something very complex, CPU expensive and unfullfilling. Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 27 17:09:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04011 for ; Sun, 27 Jan 2002 17:09:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Ux1Q-000ODO-00 for namedroppers-data@psg.com; Sun, 27 Jan 2002 13:39:32 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.33 #1) id 16Ux1P-000ODI-00 for namedroppers@ops.ietf.org; Sun, 27 Jan 2002 13:39:31 -0800 Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id E3D903190D for ; Sun, 27 Jan 2002 13:39:30 -0800 (PST) Date: Sun, 27 Jan 2002 13:39:30 -0800 (PST) From: Brian Wellington To: Subject: LOC record rounding policy Message-ID: <20020127133254.D95163-100000@shell.nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The LOC record spec (RFC 1876) says that the latitude and longitude are specified to thousandths of a second of arc. It does not say how text input that specifies additional precision should be handled. The sample code in the RFC reads up to three digits following the decimal point in the seconds field, and ignores all remaining text until the next whitespace. Randy Bush mentioned that he thinks rounding to the nearest thousandth of a second would be a better policy. I don't really care either way, but I'm hesitant to change existing code to do rounding if it's not specified in either the draft's text or sample code. Does anyone care about this? If so, is consensus on the list enough? (A clarification draft seems like overkill) Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 27 18:36:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04693 for ; Sun, 27 Jan 2002 18:36:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16UyeV-000PMJ-00 for namedroppers-data@psg.com; Sun, 27 Jan 2002 15:23:59 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.33 #1) id 16UyeT-000PMD-00 for namedroppers@ops.ietf.org; Sun, 27 Jan 2002 15:23:58 -0800 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g0RNLps95310; Mon, 28 Jan 2002 10:21:51 +1100 (EST) (envelope-from marka@isc.org) Message-Id: <200201272321.g0RNLps95310@drugs.dv.isc.org> To: Brian Wellington Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: LOC record rounding policy In-reply-to: Your message of "Sun, 27 Jan 2002 13:39:30 -0800." <20020127133254.D95163-100000@shell.nominum.com> Date: Mon, 28 Jan 2002 10:21:51 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The LOC record spec (RFC 1876) says that the latitude and longitude are > specified to thousandths of a second of arc. It does not say how text > input that specifies additional precision should be handled. The sample > code in the RFC reads up to three digits following the decimal point in > the seconds field, and ignores all remaining text until the next > whitespace. Simple. It is format error to specify more than thousandths of a second. If you round or truncate it will be wrong for someone. Force the decision back to the person entering the data. Mark > Randy Bush mentioned that he thinks rounding to the nearest thousandth of > a second would be a better policy. I don't really care either way, but > I'm hesitant to change existing code to do rounding if it's not specified > in either the draft's text or sample code. > > Does anyone care about this? If so, is consensus on the list enough? (A > clarification draft seems like overkill) > > Brian > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Mark Andrews, Internet Software Consortium 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. From owner-namedroppers@ops.ietf.org Sun Jan 27 19:04:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04931 for ; Sun, 27 Jan 2002 19:04:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16UzAP-000Pkc-00 for namedroppers-data@psg.com; Sun, 27 Jan 2002 15:56:57 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16UzAO-000PkW-00 for namedroppers@ops.ietf.org; Sun, 27 Jan 2002 15:56:56 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16UzAM-000208-00; Sun, 27 Jan 2002 15:56:54 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mark.Andrews@isc.org Cc: namedroppers@ops.ietf.org Subject: Re: LOC record rounding policy References: <20020127133254.D95163-100000@shell.nominum.com> <200201272321.g0RNLps95310@drugs.dv.isc.org> Message-Id: Date: Sun, 27 Jan 2002 15:56:54 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Simple. It is format error to specify more than thousandths of > a second. so, you contend that in s1, s2: [0 .. 59.999] (seconds latitude/longitude) 59.999 is in fixed point arithmetic with a limited precision. if so, it would be best if it said so explicitly. the normal reader would see it as any real number in the range. in fact, that is how bind8 implemented it. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 27 20:34:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05645 for ; Sun, 27 Jan 2002 20:34:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16V0XQ-0000kv-00 for namedroppers-data@psg.com; Sun, 27 Jan 2002 17:24:48 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.33 #1) id 16V0XQ-0000kp-00 for namedroppers@ops.ietf.org; Sun, 27 Jan 2002 17:24:48 -0800 Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 5EE563190D; Sun, 27 Jan 2002 17:24:47 -0800 (PST) Date: Sun, 27 Jan 2002 17:24:47 -0800 (PST) From: Brian Wellington To: Cc: Subject: Re: LOC record rounding policy In-Reply-To: <200201272321.g0RNLps95310@drugs.dv.isc.org> Message-ID: <20020127172226.B95163-100000@shell.nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 28 Jan 2002 Mark.Andrews@isc.org wrote: > > The LOC record spec (RFC 1876) says that the latitude and longitude are > > specified to thousandths of a second of arc. It does not say how text > > input that specifies additional precision should be handled. The sample > > code in the RFC reads up to three digits following the decimal point in > > the seconds field, and ignores all remaining text until the next > > whitespace. > > Simple. It is format error to specify more than thousandths of > a second. If you round or truncate it will be wrong for someone. > Force the decision back to the person entering the data. This strongly violates the "be generous with what you accept" principle. It's specified as being sent on the wire in thousandths of an arc second, not in text format. Rejecting something as being too precise seems absurd. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 27 20:48:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05773 for ; Sun, 27 Jan 2002 20:48:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16V0in-0000w4-00 for namedroppers-data@psg.com; Sun, 27 Jan 2002 17:36:33 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16V0in-0000vx-00 for namedroppers@ops.ietf.org; Sun, 27 Jan 2002 17:36:33 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16V0im-0007JO-00; Sun, 27 Jan 2002 17:36:32 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: LOC record rounding policy References: <20020127172226.B95163-100000@shell.nominum.com> <20020128013330.D2E2E28EF7@as.vix.com> Message-Id: Date: Sun, 27 Jan 2002 17:36:32 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> This strongly violates the "be generous with what you accept" principle. >> It's specified as being sent on the wire in thousandths of an arc second, >> not in text format. Rejecting something as being too precise seems >> absurd. > and yet, silently truncating violates the principal of least astonishment. i will 'fess up. i was the instigator of this. imiho, if you are not going to terminate with a hard diagnostic, at least round as opposed to truncate. > i suggest a warning in the operations log be emitted whenever the zone > file contains something that the wire format can only approximate. i can live with this too, but please round. less surprise. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jan 27 20:52:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05809 for ; Sun, 27 Jan 2002 20:52:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16V0hD-0000te-00 for namedroppers-data@psg.com; Sun, 27 Jan 2002 17:34:55 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16V0hC-0000tY-00 for namedroppers@ops.ietf.org; Sun, 27 Jan 2002 17:34:54 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16V0hC-0007Dm-00 for namedroppers@ops.ietf.org; Sun, 27 Jan 2002 17:34:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from Brian Wellington of "Sun, 27 Jan 2002 17:24:47 PST." <20020127172226.B95163-100000@shell.nominum.com> Message-Id: <20020128013330.D2E2E28EF7@as.vix.com> From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: LOC record rounding policy Date: Sun, 27 Jan 2002 17:33:30 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This strongly violates the "be generous with what you accept" principle. > It's specified as being sent on the wire in thousandths of an arc second, > not in text format. Rejecting something as being too precise seems > absurd. and yet, silently truncating violates the principal of least astonishment. i suggest a warning in the operations log be emitted whenever the zone file contains something that the wire format can only approximate. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 28 00:02:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10018 for ; Mon, 28 Jan 2002 00:02:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16V3GC-00039W-00 for namedroppers-data@psg.com; Sun, 27 Jan 2002 20:19:12 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.33 #1) id 16V3GA-000393-00 for namedroppers@ops.ietf.org; Sun, 27 Jan 2002 20:19:11 -0800 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g0S4H5s96039 for ; Mon, 28 Jan 2002 15:17:09 +1100 (EST) (envelope-from marka@isc.org) Message-Id: <200201280417.g0S4H5s96039@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: LOC record rounding policy In-reply-to: Your message of "Sun, 27 Jan 2002 17:36:32 -0800." Date: Mon, 28 Jan 2002 15:17:05 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >> This strongly violates the "be generous with what you accept" principle. > >> It's specified as being sent on the wire in thousandths of an arc second, > >> not in text format. Rejecting something as being too precise seems > >> absurd. > > and yet, silently truncating violates the principal of least astonishment. > > i will 'fess up. i was the instigator of this. imiho, if you are not going > to terminate with a hard diagnostic, at least round as opposed to truncate. > > > i suggest a warning in the operations log be emitted whenever the zone > > file contains something that the wire format can only approximate. > > i can live with this too, but please round. less surprise. I hate warnings. They get ignored. Too many times we have issued warnings in the past only to have to turn them into errors because they caused operational errors, bug reports etc. If you know the input is in error you should emit a error. Randy why knowing that the precision is thousandths of a second do you want to continue adding data specified to a precision that cannot be handled by the protocol? Mark -- Mark Andrews, Internet Software Consortium 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. From owner-namedroppers@ops.ietf.org Mon Jan 28 03:08:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20144 for ; Mon, 28 Jan 2002 03:08:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16V6Zs-0005MJ-00 for namedroppers-data@psg.com; Sun, 27 Jan 2002 23:51:44 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.33 #1) id 16V6Zr-0005M7-00 for namedroppers@ops.ietf.org; Sun, 27 Jan 2002 23:51:44 -0800 Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id ED5EE31924; Sun, 27 Jan 2002 23:51:42 -0800 (PST) Date: Sun, 27 Jan 2002 23:51:42 -0800 (PST) From: Brian Wellington To: Cc: Subject: Re: LOC record rounding policy In-Reply-To: <200201280417.g0S4H5s96039@drugs.dv.isc.org> Message-ID: <20020127234938.C95163-100000@shell.nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 28 Jan 2002 Mark.Andrews@isc.org wrote: > Randy why knowing that the precision is thousandths of a second > do you want to continue adding data specified to a precision that > cannot be handled by the protocol? Out of curiosity, how is this different from normal computer floating point arithmetic? There's less precision, sure, but it's basically the same thing. You wouldn't want scanf() to return an error if you specified too many decimal places when reading a float, would you? Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 28 06:59:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22743 for ; Mon, 28 Jan 2002 06:59:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16VA9f-00083R-00 for namedroppers-data@psg.com; Mon, 28 Jan 2002 03:40:55 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.33 #1) id 16VA9e-00083J-00 for namedroppers@ops.ietf.org; Mon, 28 Jan 2002 03:40:54 -0800 Received: from bebop.France.Sun.COM ([129.157.179.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29366; Mon, 28 Jan 2002 04:40:43 -0700 (MST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0SBeJF11890; Mon, 28 Jan 2002 12:40:20 +0100 (MET) Date: Mon, 28 Jan 2002 12:36:42 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Native UCS support in DNS versus IDNA To: Dan Oscarsson Cc: Erik.Nordmark@eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <3C53FE4E.8D4DCDC8@trab.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > For me it would be much simpler to update my DNS server to handle UCS > than > to get all needed applications on my system to use IDNA. You need to update all the applications to do some form of unicode normalization in any case. Otherwise you need gazillion SIG records to capture all the un-normalized Unicode variants that normalize to the same thing. For existing applications (as opposed to potential new "IDN only" applications) you also need to update them to be able to interoperate with non-IDN aware peers. So it's impossible to avoid upgrading the applications. Full stop. > IDNA defines that the labels that are "host names" are to be ACE > encoded. > So not all labels in IDNA are ACE encoded and the choice on which labels > are host names is up to the zone manager/applications. To the extent that much of the discussion has been about host names (with the syntax restricted by the applications) I agree that there needs to be more discussion about other domain names such as the allowed syntax for Internationalized mailbox names (or whatever they are called). In such a case it might be sufficient to just do some well-chosen unicode normalization then ACE encoding i.e. no need to prohibit "dot-like" and "space-like" characters as needs to be done for host names. > But both forms should not be included in an answer. Then clients > would have to handle things like: > xxxxx IN PTR ucs-name. > xxxxx IN PTR ACE-name. > giving unnecessary complexity and is it acceptible for DNSsec that when > responding to "old" clients only use ACE records and when responding to > UCS clients with both? > > For me it feels like a client should only see one format. Otherwise the > client have to spend time identifying which represent the same record > and > should be treated as one. There is complexity here due to caching in the DNS. A cache either needs to have the whole RRset or none of it. Thus the server can't choose to return a subset of the RRset as you propose. Also, the SIG is for the RRset and not for an individual RR. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 28 08:43:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25045 for ; Mon, 28 Jan 2002 08:43:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16VBsS-0009Je-00 for namedroppers-data@psg.com; Mon, 28 Jan 2002 05:31:16 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.33 #1) id 16VBsQ-0009JX-00 for namedroppers@ops.ietf.org; Mon, 28 Jan 2002 05:31:15 -0800 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g0SDT2s96676; Tue, 29 Jan 2002 00:29:02 +1100 (EST) (envelope-from marka@isc.org) Message-Id: <200201281329.g0SDT2s96676@drugs.dv.isc.org> To: Brian Wellington Cc: Mark_Andrews@isc.org, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: LOC record rounding policy In-reply-to: Your message of "Sun, 27 Jan 2002 23:51:42 -0800." <20020127234938.C95163-100000@shell.nominum.com> Date: Tue, 29 Jan 2002 00:29:02 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Mon, 28 Jan 2002 Mark.Andrews@isc.org wrote: > > > Randy why knowing that the precision is thousandths of a second > > do you want to continue adding data specified to a precision that > > cannot be handled by the protocol? > > Out of curiosity, how is this different from normal computer floating > point arithmetic? There's less precision, sure, but it's basically the > same thing. You wouldn't want scanf() to return an error if you specified > too many decimal places when reading a float, would you? Floating point introduces errors. This is fixed point arithmetic. The field is defined to be specified in thousandths of a second. This in no different to dollars and cents except that it would be dollars and millis. If someone asked you to enter the amount in dollars and cents would you start entering it in tenths of a cent, hundredths of a cent? Mark -- Mark Andrews, Internet Software Consortium 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. From owner-namedroppers@ops.ietf.org Tue Jan 29 03:13:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27865 for ; Tue, 29 Jan 2002 03:13:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16VT25-00054y-00 for namedroppers-data@psg.com; Mon, 28 Jan 2002 23:50:21 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.33 #1) id 16VT25-00054s-00 for namedroppers@ops.ietf.org; Mon, 28 Jan 2002 23:50:21 -0800 Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 5879431925; Mon, 28 Jan 2002 23:50:20 -0800 (PST) Date: Mon, 28 Jan 2002 23:50:20 -0800 (PST) From: Brian Wellington To: Cc: Subject: Re: LOC record rounding policy In-Reply-To: <200201281329.g0SDT2s96676@drugs.dv.isc.org> Message-ID: <20020128234654.D46771-100000@shell.nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 29 Jan 2002 Mark.Andrews@isc.org wrote: > > > On Mon, 28 Jan 2002 Mark.Andrews@isc.org wrote: > > > > > Randy why knowing that the precision is thousandths of a second > > > do you want to continue adding data specified to a precision that > > > cannot be handled by the protocol? > > > > Out of curiosity, how is this different from normal computer floating > > point arithmetic? There's less precision, sure, but it's basically the > > same thing. You wouldn't want scanf() to return an error if you specified > > too many decimal places when reading a float, would you? > > Floating point introduces errors. This is fixed point > arithmetic. The field is defined to be specified in > thousandths of a second. > > This in no different to dollars and cents except that it > would be dollars and millis. If someone asked you to enter > the amount in dollars and cents would you start entering it > in tenths of a cent, hundredths of a cent? I wouldn't, but I'd expect the application to handle it sanely if I did. Sanely doesn't include rejecting it outright. As an example, try entering "1.111 dollars" into units. It accepts it. Try entering a number with more decimal places than are in a double. units still accepts it, even though the precision is meaningless. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 29 05:50:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29642 for ; Tue, 29 Jan 2002 05:50:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16VVUJ-0008h0-00 for namedroppers-data@psg.com; Tue, 29 Jan 2002 02:27:39 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.33 #1) id 16VVUI-0008gt-00 for namedroppers@ops.ietf.org; Tue, 29 Jan 2002 02:27:38 -0800 Received: from bebop.France.Sun.COM ([129.157.179.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23130; Tue, 29 Jan 2002 03:27:25 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0TARNF03129; Tue, 29 Jan 2002 11:27:23 +0100 (MET) Date: Tue, 29 Jan 2002 11:23:51 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Comments on draft-ietf-dnsext-gss-tsig-04.txt To: namedroppers@ops.ietf.org Cc: skwan@microsoft.com, praeritg@microsoft.com, jamesg@microsoft.com, levone@microsoft.com, randyhall@lucent.com, jwesth@microsoft.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Here are some comments on the draft. Once we can resolve them, which I think means an updated I-D, then I can get the IETF wide last call started. Erik --- Change from The Secret Key Transaction Signature for DNS (TSIG) [RFC2845] protocol to Secret Key Transaction Authentication for DNS (TSIG) [RFC2845] protocol since that is the correct title for TSIG. In section 3 it says: > and servers that support GSS-TSIG it is required that security Since this is about ensuring interoperability I think the intent is captured by replaceing /required/REQUIRED/ Section 3.1.1 What is the meaning of abandon the algorithm? Try the next one? Is there a list of algorithms that the application can choose from? It makes sense to make this more clear. Section 3.1.1: Note: if the original client call to GSS_Init_sec_context returned any major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE, then the client MUST NOT send TKEY query. What should the client do instead? section 3.1.3.1 of the query. The response MUST be signed with a TSIG record. The signature in the TSIG record MUST be verified using the procedure detailed in section 5, Sending and Verifying Signed Messages. If the response is not signed, OR if the response is signed but signature is invalid, then an attacker has tampered with the message in transit or has attempted to send the client a false response. The client MAY continue waiting for a response to its last TKEY query until the time Is the "continue waiting" restricted to the unsigned on invalid signature case? Or does it apply in the valid signature case as well? If the former it would make sense to e.g. s/The client MAY/In this case the client MAY/ section 3.1.3.2 what does "abandon this negotiation sequence" mean? Where does it continue? section 4.1.1 doesn't seem to specify what do do when the context is expired. ------ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 29 09:03:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03385 for ; Tue, 29 Jan 2002 09:03:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16VYfk-000DWo-00 for namedroppers-data@psg.com; Tue, 29 Jan 2002 05:51:40 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.33 #1) id 16VYfj-000DWi-00 for namedroppers@ops.ietf.org; Tue, 29 Jan 2002 05:51:39 -0800 Received: by sentry.gw.tislabs.com; id IAA16234; Tue, 29 Jan 2002 08:56:58 -0500 (EST) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xmab16216; Tue, 29 Jan 02 08:56:07 -0500 X-Sender: lewis@pop.gw.tislabs.com (Unverified) Message-Id: In-Reply-To: <20020127133254.D95163-100000@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Jan 2002 08:49:37 -0500 To: Brian Wellington From: Edward Lewis Subject: Re: LOC record rounding policy Cc: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 4:39 PM -0500 1/27/02, Brian Wellington wrote: >Does anyone care about this? If so, is consensus on the list enough? (A >clarification draft seems like overkill) If the original draft is incorrect, it (the document) should be fixed. Remember, the IETF is about interoperability above all else. A new code base author should be able to read the documents and generate an interoperable implementation without resorting to What ever is decided (regarding rounding), please update the draft and do not rely on any one implementation as a reference plaftorm, no matter how well-intentioned the effort is. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jan 29 18:37:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24495 for ; Tue, 29 Jan 2002 18:36:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16VhRS-0005QG-00 for namedroppers-data@psg.com; Tue, 29 Jan 2002 15:13:30 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16VhRR-0005QA-00 for namedroppers@ops.ietf.org; Tue, 29 Jan 2002 15:13:29 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16VhRR-000IvE-00 for namedroppers@ops.ietf.org; Tue, 29 Jan 2002 15:13:29 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers Subject: moving along Message-Id: Date: Tue, 29 Jan 2002 15:13:29 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit before tackling difficult issues (i.e. we will ride other hobby horses next week), as co-chairs, we would like to confirm that o we believe that we reached positive consensus on delegation signer, draft-ietf-dnsext-delegation-signer-05.txt. but, imiho, it needs an edit before being shipped to the area director for review. o we believe that we have reached positive consensus on key restrict, draft-ietf-dnsext-restrict-key-for-dnssec-01.txt, though i am told it is about to get a mild update. if you disagree with either of these two sets of assertions, now would be a good time to say so. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 07:24:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16088 for ; Wed, 30 Jan 2002 07:24:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16VtQk-000IiZ-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 04:01:34 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.33 #1) id 16VtQj-000IiT-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 04:01:33 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15433; Wed, 30 Jan 2002 07:01:30 -0500 (EST) Message-Id: <200201301201.HAA15433@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-obsolete-iquery-03.txt Date: Wed, 30 Jan 2002 07:01:30 -0500 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 : Obsoleting IQUERY Author(s) : D. Lawrence Filename : draft-ietf-dnsext-obsolete-iquery-03.txt Pages : 4 Date : 29-Jan-02 The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using PTR queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation and updates RFC 1035 to declare it entirely obsolete. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-obsolete-iquery-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-obsolete-iquery-03.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-obsolete-iquery-03.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: <20020129135715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-obsolete-iquery-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-obsolete-iquery-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020129135715.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. From owner-namedroppers@ops.ietf.org Wed Jan 30 08:59:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18678 for ; Wed, 30 Jan 2002 08:59:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Vv3Q-000K7v-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 05:45:36 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.33 #1) id 16Vv3P-000K7p-00; Wed, 30 Jan 2002 05:45:35 -0800 Received: by sentry.gw.tislabs.com; id IAA05030; Wed, 30 Jan 2002 08:50:55 -0500 (EST) Received: from dyn175.gw.tislabs.com(10.33.10.175) by sentry.gw.tislabs.com via smap (V5.5) id xmaa05022; Wed, 30 Jan 02 08:50:48 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Jan 2002 20:45:01 -0500 To: Randy Bush From: Edward Lewis Subject: Re: moving along Cc: namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 6:13 PM -0500 1/29/02, Randy Bush wrote: >before tackling difficult issues (i.e. we will ride other hobby horses >next week), as co-chairs, we would like to confirm that > > o we believe that we reached positive consensus on delegation signer, > draft-ietf-dnsext-delegation-signer-05.txt. but, imiho, it needs an > edit before being shipped to the area director for review. Just asking, but given the mistakes made with 2535 and not having sufficient operational testing before "progressing," shouldn't there be some exercising of the DS code in an operational setting before such a step? I don't mean to sound facetious, but it would be good to have at least a reference code set (one of which is progressing I understand) for "sympathetic" testing. There's been some talk about how DS plays into key rollover. In particular, I'd like to see that mature before setting DS in stone. Perhaps I'm overreacting. Would DS be headed for experimental (as an alternative to 2535) or standards track at this time? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 10:21:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22041 for ; Wed, 30 Jan 2002 10:21:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16VwKK-000LCs-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 07:07:08 -0800 Received: from porter.east.isi.edu ([65.114.168.20] helo=east.east.isi.edu) by psg.com with esmtp (Exim 3.33 #1) id 16VwKJ-000LCm-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 07:07:07 -0800 Received: from isi.edu (they102.east.isi.edu [65.114.168.102]) by east.east.isi.edu (8.11.3/8.11.3) with ESMTP id g0UF76g22362; Wed, 30 Jan 2002 10:07:06 -0500 (EST) Message-ID: <3C580CA0.F64E3A7B@isi.edu> Date: Wed, 30 Jan 2002 10:09:20 -0500 From: Daniel Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Wildcards and Opt-In Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The use of wildcards in DNSSEC is somewhat awkward at best and I think it becomes a severe problem if Opt-In is used. Suppose you have a entry such as: *.edu. MX 10 mail.junk.edu SIG by edu. Now suppose a query for nge.isi.edu MX returns: nge.isi.edu. MX 10 mail.junk.edu SIG by edu. (with label = 1) Is this a valid answer or a response from an attacker? if isi.edu does NOT exist, then this is valid use of wildcards and should be believed. if isi.edu does exist, then the wildcard should not apply and perhaps an attacker is trying to prevent me from learning the real nge.isi.edu MX record by replaying the edu. wildcard entry. With opt-in, how can I distinguish a valid, signed response from an attacker's intentionally incorrect replay of wildcard? Perhaps we should rethink the use of wildcards or at least rethink how wildcards would interact with opt-in. Dan PS The DNSSEC use of wildcards is not currently implemented but is described in RFC 2535 sections: section 4.1.3 (labels field in the SIG RR) section 5.3 (NXT and proving no wildcard matches) and some minor stuff in 8.1 and 8.3 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 11:06:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23516 for ; Wed, 30 Jan 2002 11:06:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Vwyv-000Lm6-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 07:49:05 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.33 #1) id 16Vwyu-000Lm0-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 07:49:04 -0800 Received: by sentry.gw.tislabs.com; id KAA07455; Wed, 30 Jan 2002 10:54:23 -0500 (EST) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xma007443; Wed, 30 Jan 02 10:54:13 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <3C580CA0.F64E3A7B@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Jan 2002 10:47:46 -0500 To: Daniel Massey From: Edward Lewis Subject: Re: Wildcards and Opt-In Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk When we discussed wildcards a couple of years ago, we noted the need to send along NXT's to prove that the use of the wildard was warrented. E.g., if nge.isi.edu, then the proper response would be: nge.isi.edu. MX 10 mail.junk.edu SIG by edu. (with label = 1) NXT showing no nge.isi.edu SIG (NXT) by edu. I don't know if the need for the NXT has been maintained in the document history since then, nor in the code. The short answer to your question (how can I distinguish) is that the proper NXT or NXTs are needed in the answer. At 10:09 AM -0500 1/30/02, Daniel Massey wrote: >Hi, > >The use of wildcards in DNSSEC is somewhat awkward at best and >I think it becomes a severe problem if Opt-In is used. > >Suppose you have a entry such as: > *.edu. MX 10 mail.junk.edu > SIG by edu. > >Now suppose a query for nge.isi.edu MX returns: > nge.isi.edu. MX 10 mail.junk.edu > SIG by edu. (with label = 1) > >Is this a valid answer or a response from an attacker? > if isi.edu does NOT exist, then this is valid use of > wildcards and should be believed. > if isi.edu does exist, then the wildcard should not apply > and perhaps an attacker is trying to prevent me from > learning the real nge.isi.edu MX record by replaying > the edu. wildcard entry. > >With opt-in, how can I distinguish a valid, signed response >from an attacker's intentionally incorrect replay of wildcard? > >Perhaps we should rethink the use of wildcards or at least >rethink how wildcards would interact with opt-in. > >Dan > >PS The DNSSEC use of wildcards is not currently implemented > but is described in RFC 2535 sections: > section 4.1.3 (labels field in the SIG RR) > section 5.3 (NXT and proving no wildcard matches) > and some minor stuff in 8.1 and 8.3 > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 14:39:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00437 for ; Wed, 30 Jan 2002 14:39:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W0HI-000OmO-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 11:20:16 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.33 #1) id 16W0HG-000OmH-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 11:20:14 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g0UJK9p10261; Wed, 30 Jan 2002 14:20:09 -0500 (EST) Message-Id: <200201301920.g0UJK9p10261@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: iesg@ietf.org cc: namedroppers@ops.ietf.org Subject: Re: Last Call: Obsoleting IQUERY to Proposed Standard In-reply-to: Your message of "Wed, 30 Jan 2002 11:25:25 EST." <200201301625.LAA24065@ietf.org> Date: Wed, 30 Jan 2002 14:20:09 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I fully support the intent behind this effort, but I think it's odd for an RFC to state that it is "updating" specific text in another RFC, or providing "new text for RFC 1035". This seems confusing as it might be taken to imply that the text in RFC 1035 itself should be altered. I recommend that sections 1.2 and 2 be reworded slightly to describe the effect of the change, instead of implying that changes should be made to the RFC 1035 text. e.g. (delete section 1.2) 2 - Effect on RFC 1035 The effect of this document is to change the definition of opcode 1 from that originally defined in section 4.1.1 of RFC 1035, and to entirely supersede section 6.4 (including subsections) of RFC 1035. The definition of opcode 1 is hereby changed to: "1 an inverse query (IQUERY) (obsolete)" The text in section 6.4 of RFC 1035 is now considered obsolete. The following is an applicability statement regarding the IQUERY opcode: Inverse queries using the IQUERY opcode were originally described as the ability to look up the names that are associated with a particular RR. Their implementation was optional and never achieved widespread use. Therefore IQUERY is now obsolete, and name servers SHOULD return a "Not Implemented" error when an IQUERY request is received. Keith to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 17:45:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04039 for ; Wed, 30 Jan 2002 17:45:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W3Hp-0001PY-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 14:33:01 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.33 #1) id 16W3Hp-0001PS-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 14:33:01 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 9B50231921; Wed, 30 Jan 2002 14:32:59 -0800 (PST) Date: Wed, 30 Jan 2002 23:32:49 +0100 (CET) From: Roy Arends X-X-Sender: To: Daniel Massey Cc: Subject: Re: Wildcards and Opt-In In-Reply-To: <3C580CA0.F64E3A7B@isi.edu> Message-ID: <20020130222428.L27580-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 30 Jan 2002, Daniel Massey wrote: > Hi, > > The use of wildcards in DNSSEC is somewhat awkward at best and > I think it becomes a severe problem if Opt-In is used. > > Suppose you have a entry such as: > *.edu. MX 10 mail.junk.edu > SIG by edu. > > Now suppose a query for nge.isi.edu MX returns: > nge.isi.edu. MX 10 mail.junk.edu > SIG by edu. (with label = 1) > > Is this a valid answer or a response from an attacker? > if isi.edu does NOT exist, then this is valid use of > wildcards and should be believed. > if isi.edu does exist, then the wildcard should not apply > and perhaps an attacker is trying to prevent me from > learning the real nge.isi.edu MX record by replaying > the edu. wildcard entry. > > With opt-in, how can I distinguish a valid, signed response > from an attacker's intentionally incorrect replay of wildcard? Okay, lets look at these entries: ("l=x" where x is the value of the labels field in the signature) edu. SOA edu. SIG SOA (l=1) edu. NS a.edu. edu. SIG NS (l=1) edu. MX 10 a.edu. edu. SIG MX (l=1) edu. KEY ... edu. SIG KEY (l=1) edu. NXT *.edu. SOA NS MX SIG NXT edu. SIG NXT (l=1) *.edu. MX 10 mail.junk.edu. *.edu. SIG MX (l=1) *.edu. NXT a.edu. MX SIG NXT *.edu. SIG NXT (l=1) a.edu. A 10.0.0.1 a.edu. SIG A (l=2) a.edu. NXT mail.junk.edu. A SIG NXT a.edu. SIG NXT (l=2) mail.junk.edu. A 10.0.0.2 mail.junk.edu. SIG A (l=3) mail.junk.edu. NXT edu. A SIG NXT mail.junk.edu. SIG NXT (l=3) Okidook, now look at some responses query(nge.isi.edu., MX): response: nge.isi.edu. MX 10 mail.junk.edu. ;expanded wildcard nge.isi.edu. SIG MX (l=1) ;expanded wildcard since l=1 a.edu. NXT mail.junk.edu. A SIG NXT ;proof of not a more specific name a.edu. SIG NXT (l=2) ;exists This whole thing assumes 2535, not opt-in. ------------------------- Now with opt-in: Assume in the above the following: a.edu. A 10.0.0.1 a.edu. SIG A (l=2) a.edu. NXT mail.junk.edu. A SIG ;no NXT bit -> OPT-IN a.edu. SIG NXT (l=2) isi.edu NS query(nge.isi.edu., MX): forged, but valid response: nge.isi.edu. MX 10 mail.junk.edu. ;expanded wildcard nge.isi.edu. SIG MX (l=1) ;expanded wildcard since l=1 a.edu. NXT mail.junk.edu. A SIG ;proof of not a more specific SIGNED name a.edu. SIG NXT (l=2) ; (i.e. no signed isi.edu delegation) (this is forged, since the server would have given an unsigned referral) What does the above response mean: 1) The resolver is able to verify that the signature over nge.isi.edu. MX is really an expanded wildcard. 2) The resolver is able to verify that there does not exist a more specific SIGNED name. Conclusion: Since the isi.edu. has chosen not to be signed, a malicious entity can forge everything under and including isi.edu. No news here. To avoid all of the above: its your zone, your choice, sign everything or leave wildcards unsigned, or better, avoid using them. Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 18:45:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04896 for ; Wed, 30 Jan 2002 18:45:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W4B0-0002Hu-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 15:30:02 -0800 Received: from h236.s231.netsol.com ([216.168.231.236]) by psg.com with esmtp (Exim 3.33 #1) id 16W4Ay-0002Hl-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 15:30:00 -0800 Received: (from markk@localhost) by h236.s231.netsol.com (8.11.0/8.11.0) id g0UNTuQ03459; Wed, 30 Jan 2002 18:29:56 -0500 (EST) Date: Wed, 30 Jan 2002 18:29:56 -0500 From: Mark Kosters To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: Wildcards and Opt-In Message-ID: <20020130232956.GI2791@slam.admin.cto.netsol.com> References: <3C580CA0.F64E3A7B@isi.edu> <20020130222428.L27580-100000@node10c4d.a2000.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020130222428.L27580-100000@node10c4d.a2000.nl> User-Agent: Mutt/1.3.25i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Jan 30, 2002 at 11:32:49PM +0100, Roy Arends wrote: > Since the isi.edu. has chosen not to be signed, a malicious entity can > forge everything under and including isi.edu. No news here. > > To avoid all of the above: its your zone, your choice, sign everything or > leave wildcards unsigned, or better, avoid using them. What Roy said. Plus, in testing that I was doing to make sure that I'm not missing something, dnssec-signzone (9.2.0) comes back saying: dnssec-signzone: warning: BIND 9 doesn't properly handle wildcards in secure zones: - wildcard nonexistence proof is not generated by the server - wildcard nonexistence proof is not required by the resolver dnssec-signzone: warning: wildcard name seen: *.edu Mark -- Mark Kosters markk@netsol.com 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. From owner-namedroppers@ops.ietf.org Wed Jan 30 20:23:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05819 for ; Wed, 30 Jan 2002 20:23:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W5gK-0003wR-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 17:06:28 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16W5gK-0003wL-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 17:06:28 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16W5gJ-000Hra-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 17:06:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200201301625.LAA24065@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: Obsoleting IQUERY to Proposed Standard Date: Wed, 30 Jan 2002 11:25:25 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has received a request from the DNS Extensions Working Group to consider Obsoleting IQUERY as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 13, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-obsolete-iquery-03.txt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 21:11:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06406 for ; Wed, 30 Jan 2002 21:11:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W6WP-0004rt-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 18:00:17 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.33 #1) id 16W6WN-0004rk-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 18:00:16 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0S8tvx06386; Mon, 28 Jan 2002 15:55:57 +0700 (ICT) From: Robert Elz To: Mark.Andrews@isc.org cc: namedroppers@ops.ietf.org Subject: Re: LOC record rounding policy In-Reply-To: <200201280417.g0S4H5s96039@drugs.dv.isc.org> References: <200201280417.g0S4H5s96039@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Jan 2002 15:55:57 +0700 Message-ID: <6384.1012208157@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 28 Jan 2002 15:17:05 +1100 From: Mark.Andrews@isc.org Message-ID: <200201280417.g0S4H5s96039@drugs.dv.isc.org> | Randy why knowing that the precision is thousandths of a second | do you want to continue adding data specified to a precision that | cannot be handled by the protocol? Most people don't know. But I can't begin to think why we're discussing this here, as long as the correct thing is on the wire (ie: 1000'ths) then how that is input is a quality of implementation issue - for me, I don't think I'd want to be dealing in radians (or their fractions) at all, I still prefer degrees, minutes, ... (including decimals of a second if appropriate). If an implementation insists on issuing warnings or errors about stupidities, then I'll fix or replace the implementation. If an implementation when given precise input (actually specified to 3 decimal places of radians) doesn't put exactly that value in the RR when it sends it, then I will fix or replace it. Anything else (rounding when I give more digits, what it does with 3.1234 seconds, etc) is just frills, and can be dealt with, it just should be documented. So Brian, round, truncate, whatever you like ... This is only an issue for human edited files, zone files obtained via *XFR or DynDNS will have a precise value in 1/1000 radian units, which should be preserved and reissued without change. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 21:25:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06469 for ; Wed, 30 Jan 2002 21:25:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W6mu-0005EG-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 18:17:20 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.33 #1) id 16W6ms-0005E9-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 18:17:19 -0800 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g0V2Ems10916 for ; Thu, 31 Jan 2002 13:14:52 +1100 (EST) (envelope-from marka@isc.org) Message-Id: <200201310214.g0V2Ems10916@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: LOC record rounding policy In-reply-to: Your message of "Mon, 28 Jan 2002 15:55:57 +0700." <6384.1012208157@brandenburg.cs.mu.OZ.AU> Date: Thu, 31 Jan 2002 13:14:48 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Date: Mon, 28 Jan 2002 15:17:05 +1100 > From: Mark.Andrews@isc.org > Message-ID: <200201280417.g0S4H5s96039@drugs.dv.isc.org> > > | Randy why knowing that the precision is thousandths of a second > | do you want to continue adding data specified to a precision that > | cannot be handled by the protocol? > > Most people don't know. > > But I can't begin to think why we're discussing this here, as long as the > correct thing is on the wire (ie: 1000'ths) then how that is input is a > quality of implementation issue - for me, I don't think I'd want to be dealin > g > in radians (or their fractions) at all, I still prefer degrees, minutes, ... > (including decimals of a second if appropriate). Because master files are defined to be a transport format in RFC 103[45]. They should be able to be read by all implementations. It is bad thing if the same input does not produce the same results on all servers. > If an implementation insists on issuing warnings or errors about stupidities, > then I'll fix or replace the implementation. If an implementation when given > precise input (actually specified to 3 decimal places of radians) doesn't put > exactly that value in the RR when it sends it, then I will fix or replace it. > Anything else (rounding when I give more digits, what it does with 3.1234 > seconds, etc) is just frills, and can be dealt with, it just should be > documented. > > So Brian, round, truncate, whatever you like ... This is only an issue for > human edited files, zone files obtained via *XFR or DynDNS will have a > precise value in 1/1000 radian units, which should be preserved and reissued > without change. If one implementation rounds and one truncates then there is a 50% probability that a LOC record signed zone (assuming the LOC passes through unchanged) will cause verification failures when loaded on the other implementation. Ftp, scp etc. are still used to get zones onto master servers. Mark -- Mark Andrews, Internet Software Consortium 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. From owner-namedroppers@ops.ietf.org Wed Jan 30 21:43:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07552 for ; Wed, 30 Jan 2002 21:43:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W739-0005ZZ-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 18:34:07 -0800 Received: from lornadoon.donet.com ([205.133.113.5] helo=lornadoon.akc.com) by psg.com with esmtp (Exim 3.33 #1) id 16W738-0005ZS-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 18:34:06 -0800 Received: from backup ([64.253.39.41]) by lornadoon.akc.com (8.9.3/8.9.3) with SMTP id WAA27920; Wed, 30 Jan 2002 22:24:20 -0500 Message-ID: <002a01c1a937$931aff40$2927fd40@akc.com> Reply-To: "Al Costanzo" From: "Al Costanzo" To: "Robert Elz" , Cc: References: <200201280417.g0S4H5s96039@drugs.dv.isc.org> <6384.1012208157@brandenburg.cs.mu.OZ.AU> Subject: Re: LOC record rounding policy Date: Tue, 29 Jan 2002 21:41:07 -0500 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0026_01C1A90D.A8EDA4A0"; type="multipart/alternative" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C1A90D.A8EDA4A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0027_01C1A90D.A8EDA4A0" ------=_NextPart_001_0027_01C1A90D.A8EDA4A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is this discussion a good example of why the draft I wrote on GPOS = should be turned into an RFC? Plain and simple addresses, no precision, = no rounding. Regards, Al Costanzo -------------------------------------------------------------------------= ------- Promote Your Website with the Pros -- Dynamic Submission 2000=20 Best Internet Services:=20 Domain Registration - Web Hosting - DialUp - FrameRelay - T1 -DSL=20 AKC Computer Service Corporation SINCE 1989 ----- Original Message -----=20 From: Robert Elz=20 To: Mark.Andrews@isc.org=20 Cc: namedroppers@ops.ietf.org=20 Sent: Monday, January 28, 2002 3:55 AM Subject: Re: LOC record rounding policy=20 Date: Mon, 28 Jan 2002 15:17:05 +1100 From: Mark.Andrews@isc.org Message-ID: <200201280417.g0S4H5s96039@drugs.dv.isc.org> | Randy why knowing that the precision is thousandths of a second | do you want to continue adding data specified to a precision that | cannot be handled by the protocol? Most people don't know. But I can't begin to think why we're discussing this here, as long as = the correct thing is on the wire (ie: 1000'ths) then how that is input is = a quality of implementation issue - for me, I don't think I'd want to be = dealing in radians (or their fractions) at all, I still prefer degrees, = minutes, ... (including decimals of a second if appropriate). If an implementation insists on issuing warnings or errors about = stupidities, then I'll fix or replace the implementation. If an implementation = when given precise input (actually specified to 3 decimal places of radians) = doesn't put exactly that value in the RR when it sends it, then I will fix or = replace it. Anything else (rounding when I give more digits, what it does with = 3.1234 seconds, etc) is just frills, and can be dealt with, it just should be documented. So Brian, round, truncate, whatever you like ... This is only an = issue for human edited files, zone files obtained via *XFR or DynDNS will have a precise value in 1/1000 radian units, which should be preserved and = reissued without change. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org = with the word 'unsubscribe' in a single line as the message text body. ------=_NextPart_001_0027_01C1A90D.A8EDA4A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is this discussion a good example of = why the draft=20 I wrote on GPOS should be turned into an RFC?  Plain and simple = addresses,=20 no precision, no rounding.
 
Regards,
 
Al Costanzo
 Promote Your Website with the = Pros -- Dynamic Submission=20 2000=20

Best Internet = Services:=20
Domain=20 Registration -  Web=20 Hosting - DialUp - = FrameRelay - T1 -DSL

AKC Computer Service Corporation SINCE=20 1989

----- Original Message -----
From:=20 Robert = Elz=20
Sent: Monday, January 28, 2002 = 3:55=20 AM
Subject: Re: LOC record = rounding policy=20

   =20 Date:        Mon, 28 Jan 2002 = 15:17:05=20 +1100
    = From:        Mark.Andrews@isc.org
 &n= bsp; =20 Message-ID:  <200201280417.g= 0S4H5s96039@drugs.dv.isc.org>

 =20 | Randy why knowing that the precision is thousandths of a = second
  |=20 do you want to continue adding data specified to a precision = that
  |=20 cannot be handled by the protocol?

Most people don't = know.

But I=20 can't begin to think why we're discussing this here, as long as = the
correct=20 thing is on the wire (ie: 1000'ths) then how that is input is = a
quality of=20 implementation issue - for me, I don't think I'd want to be = dealing
in=20 radians (or their fractions) at all, I still prefer degrees, minutes,=20 ...
(including decimals of a second if appropriate).

If an=20 implementation insists on issuing warnings or errors about=20 stupidities,
then I'll fix or replace the implementation.  If = an=20 implementation when given
precise input (actually specified to 3 = decimal=20 places of radians) doesn't put
exactly that value in the RR when it = sends=20 it, then I will fix or replace it.
Anything else (rounding when I = give more=20 digits, what it does with 3.1234
seconds, etc) is just frills, and = can be=20 dealt with, it just should be
documented.

So Brian, round, = truncate,=20 whatever you like ...  This is only an issue for
human edited = files,=20 zone files obtained via *XFR or DynDNS will have a
precise value in = 1/1000=20 radian units, which should be preserved and reissued
without=20 change.

kre


to unsubscribe send a message to namedroppers-request@op= s.ietf.org=20 with
the word 'unsubscribe' in a single line as the message text=20 body.
------=_NextPart_001_0027_01C1A90D.A8EDA4A0-- ------=_NextPart_000_0026_01C1A90D.A8EDA4A0 Content-Type: image/gif; name="akc-sm-wt.gif" Content-Transfer-Encoding: base64 Content-ID: <002501c1a937$91c3aca0$2927fd40@akc.com> Content-Transfer-Encoding: base64 R0lGODlhIQAaANcAAAAAAJxBQUM3N3E4OJNkZOlSUoI6OqEoKNwwMNqjo////6icnP7+/t8AAPHO zkFBQSIhIefU1BsaGocAAD8AAK0ICFJRUeSCgmFhYfzMzKKhoXFxcQoKCoqKincAADo6OurDw2pq asNRUREREdmCgunc3JmZmb96eveBgaMAAIKCgrKyspGRkdYjI3l5edHR0bm5ucDAwPzc3MrKyvaj o89gYCoqKuacnMMAALMAAEpKSlpaWssAANCsrPUAAPFJScBwcDIyMtnZ2QsBAfLGxqqqqoYKCuHh 4chDQ+a9vS4AAPvu7mMAAOB6evQoKJIAANtRUaoAAN7ExPPW1urq6vi8vNWcnNtoaJMhIdt5edB5 eeIREboAAOSVldCWls8wMM2Dg5sAAJ4REdIrK69CQqAJCfzl5cicnGkAAOW0tL9iYulAQPPs7OvN zeOtrficnOYqKvPl5esNDfeUlOsAALIwMNu8vPitrdG8vLBpadMAAOPMzBIAACMAAMA5OUoAAKMx MeYZGd5hYeekpPG2tqcYGFsBAc+1tdNDQ84JCapLS9U7O89YWHQREa8QEO97e6U4OPRqauzj462G hvvU1K0mJsOTk7sbG5gaGvHx8b2np+AJCbtFRcG4uL8JCc5ycogcHN+NjatSUpQrK74qKvYKCvca GhsCAs8SEuRWVvmMjPcREditrfvExFUBAfq0tPZRUXhzc5UyMuBycvBycvPc3EQbG5QMDOyEhOYi IvNiYsykpPYiIl8PD4pkZMBqarIYGPc6OvdaWtrLy5NZWecyMnAkJMCEhGkJCeqMjLJhYfYyMosx MYcqKkMKCq9xcdoSEnwqKokSEtFqaqxaWmImJvZBQek7O9sZGcCMjKNmZv309INCQswZGYRUVFYb GyUODntkZLKVlepbW2RMTFIlJaSEhIxJSdKMjF9CQjMPD9DDw29ERKx6esAREcZKStxGRnYJCduU lONra8QcHHcwMPt7e7I6OmpUVJd0dI14eJKNjVcwMOFPT7idnU8UFCH/C05FVFNDQVBFMi4wAwHo AwAh+QQJZAAKACwAAAAAIQAaAAcI/AAVCBxIkKCMVzTutNrGgEHBhxAJmlG1zIdFi6tgvXIYsaPA OaYuirwIi5JHiNuEjVxp0VSVkwRTWizlo9SiWRcuMMIm0lQrjidV1SxVqp+UgmxCbbnIywxMSkRL rWqyLSKIQBbtVT2pq6apWQ23saFyhIGQFy8ytQn0ZoYGE3BXQDRDdNUyNgq2zYBRxAQVFzt0zGAQ p4gEDkOGfBACkUbNVcnyzpgRY4WGvxgsxMjUYcSIIRww4IUY6XEbNpQpW87kAoOOFSEgjOAwwkRD oASt1YQjZEWM3zBWmGDT+sEDG7IhwDhZsRQnExpWwHhh2S/gBx8gSNDBmLkPSPuxOsCdkemtCiqx LDwIIkGCC5gK1jDbgcGFin0wMplQ4YKK6w82tMfBDpngVhAV5HygA32xuLDCNi7EggEVO3wQhAtB zMbBBy9EJIQONgShoAU77JNJJiHsYAEVOgRhAwwl6IDYEBLIVdAMGUIAgYgP6KACA5lYoMMDRxyn HJCxzMjBjxwdocMHHzwggC3llMPPPgow0IEK5/EXQocCFYHBmBjY+FArIi3SBkRxNDHPPIIIIoOB ENkjkhyCuBFBHFQkMQtWFwnTEEzbdDVSA4iuZM1W8G2jCk0siaTLEvAVlIEwkK4UzEaVQiQDDZHA Yo01wqDwE52dpvpQQAAh+QQJAQAKACwAAAAAIQAaAAcI/AAVCBxIcOA2Ga9eVVnCoKDDhw7NPHJC h06DBnLW0NgGsaPBZIF8WKx48eK1DB4hLklFRyRJiyUbbKmSsuA2KC59yCnQhESNS3pKbmlVc2AW kSJhySC47QywknAY1tyzyYfISA0dRqh0MZeMrB5rWPXxgwGDbTHSvhDCVoojOCCOyKWSCaKkRFbl UGKQyQKAv37/rgBxyMZfAEGEgCWYYCwsBVQeHAYQGMCKGBIOPzjScdrYN0KCTAaw4zCGEYct1O2I aOwuCJM5UB79N4RZj4us8gB3OAjq2bE7mF3sMDeOPoclvMgM/PCIGMQfIuJyavQR2M2dr6jJjQ/t 66GAe8sGwIFFx22xyI/WwAB75SIdxgNwEX0bBtp/obs/vB0Gc9IcDdTXaPLFoIALIYSggQoqdPCC QEesAAMMMWQCFhUrSBiDODngoAcPY0zhUBxqfDFGCy04UJQCnlVERyCPVCHJEXuAAVRJWK14k4sN WKTHjzE1UECAOtIix0hBljTONtHV1MoPMAVZDA1NrqgAJXNEMs4P46BQxW1WhllTQAAh+QQJAQAK ACwAAAAAIQAaAAcI/AAVCBxIkGAtEElqFVzIsKEkLaQSccHhaVGahhgXsiqEoyMOLiC5XGFAMmND VhVw8Og4EWQOLjVKmizYxhGPlTi+ZPmFJQWXHDnkzSzIgJNKHokuLBG45FgYoMDMDB3oJsdNHhcW oksB9MZUgSKOImKgYEaMGC+OSOKUg9FXBWYqXCWkQAMHAHgBcEgHBgMEGw80zHTD5WYLBkXu5sW7 I1ZeCyTJYiRxVNCKEYvzYsb7gc3QGlcVbc682MaRqYxu4qBAOrOEF18ZqWSi+UPrIFS+1sCBJvOD zIp1eB4KhLZv4HkxRM5IxXZmFTsyW7CQ14VJNjpaa8CQeceSHXgcRkCAgfF7awAaTGAIocKEiSIR 7ERY3hDGAwsYyBnyMOEJmeECRVBHBVFEkYZkQy1xgEodIeKGJHscU0gUQCEh01R2iIHTR1xE8dNP wEzx1kA9aPgRhx8CA8KIBEUgSg4UhZQDEg6wuFAEXVzBCCNZJHGhjUAOFBAAIfkECQEACgAsAAAA ACEAGgAHCPwAFQgcSHAggwhSpDBYWLChQ4dSZHmYMEFWm4cYH4IQQ5GiBywlMooUuIRUmI4dRY0U GSrHE4qimnnwYATEyocMxkR5eUJBHEgTPOS56ZAIjzBPAC1k4KDChFEMiBbExePJEy9UVsQ4wijF CYZSBRbA8eRWHAsA0g6pJkDHhiVhFcDhklRDWg5302KIu2QLlwkBIKQdjHeEkKhSZTTY+WcwALxp N8RVQGnxEwqOIUugMllxFA9DHD8GYANuXMUp+oQW/bgDYqlmeDDJyxoCldc3GdhifRdyiLgmREPW ++ABBrArj0gQPWIHhg76zPWYvAPAiD5KKPTCI1DLyQA1k6kIKXEJ6QRIUsyd9GBp8kAwJztO/MjG PUlAKD2esT8wArP8Q/E3EBvi5CFKHqwIqKACAQEAIfkECQEACgAsAAAAACEAGgAHCNsAFQgcSJCg mXUlCipcyHAgAyxovi1h0LAiQzcpmFDQZLFjwVk5/lDI57GkAng5KPxhZ9Ijtii9JlRradFMgxQE gDViwJPmwgx0woQbhcVnwyo+nvABICHERKMF7/iYsJTDiCVQC9KYWvVD1oJvpg4BwAHDV4JzxHLg 0IHiWQVhPZDlYOKtwLRM5oZwe/YNnT9zH/D9SgPw3BE8BxsldArA3B1Y365zDOAUu8RvTThWFwZU z7cvpHn442GA3YF+wlCg4Ou0wE9hRE5yrcCOB1fOhtFWMImYud1QAwIAIfkECQEACgAsAAAAACEA GgAHCNQAFQgcSJDgkmF7CipcyJDgJA9G8DScOPEcmhRqKGosyKARkxSkGDDYuDECk4+JlpDciMeD hxR6iKzUeCYMpDAN7sykeIjLryd03uycOMzDkAl0VA1t+AIAAA8+UCxluEQCADQ+aE1l+OCqj0hb F4bwCjZswQ1e/Zgt2BXrLZVrFTCwiqaBBxhxFQhx6uEJABV5hTwY4mECAAt590zyNcEDAAlwzfYI U6ix0xlxpbh8wsXSiiNxzbhC86TCEpF5o6GZUCfvQG1oPDxzLXAPMQIlaE8NCAAh+QQJAQAKACwA AAAAIQAaAAcI/AAVCBxIkGCtJBGWFFzIsKECBlpSRAkDKhsDhxgXokvBMUqUJycyilQwpUwYiRKj lAExEuOvMGGMiALmMce7lg2XiAkzIZsCEI5y5Kgw5SJOgklgchpIQiiXUEcLLqmUIw0DITE0VcjB BVHUgUIwfANlQQKAs0a4dmPANmomG2dHnD1riCuOKV8FapjLl4JQHlXyPgzC96wSrjwGCVYAozCA Pn9pGP06w/HhHIkX67D8V3HeFY4BUIjCJYq3vAwIA+DA15VQQwA0fBWy48GGD3M5eBBKAQAEKl9r nTmEB0aHEPhSCD11dsPklm1gFsKrYFqUHGFs2eAwYsbXezhhnoyyQ8LjxCQKqGRqezQBzJMpw5Bh n3fJvRQno3A0wnKxwAiVcMRRI2f4R1AcWjCiRjsRGOhgQAAh+QQJAQAKACwAAAAAIQAaAAcI/AAV CBxIcCCDKlUcMFjIoKDDhwUlPULVQE+DbozsQNzokEgLPSArNmjgKQ9DjhAddOMB0qLFkTxEnURJ kMEiljxSKCIxbtPIBlyO0XSYjAcPLqP2DCSS62eZCEMJIuKB4wBUgpQCwVQWdWCGbilYKWAgSciM GQrmOJU0lAGGB0FsaZshgQMHAHhDMNAK1EpUGCPw2tCAtzBeF4+2di1SOLDhwtx+QuqqoMPjy31+ YmrYdcNlw3yczqTJ4rOEBwBCjyzDkDPHIncvS/gAIPNIMa5RxnAcu/BsABR+NkJL8wUEvBIsG5YQ A4CHkXr6QBCC0q0NCEFiNF8uCQCXkXc5hgCwwZYmiD2SJMEoYqLDBhWSmLz0UDhIeY5QcHCpAGTh wDs+NcCDASy4EAIGMOT2EBGJGJWDIj1IQgktATZQhh0K0nSBUSzhwNJLQOVBmUGCGKUHSyIBpc1o XTGQTCItuUTKGRmOKMkcgqQyzgVJtDbijxAFBAAh+QQJAQAKACwAAAAAIQAaAAcI/AAVCBxIUOC2 DFWqtFpSsKFDh5QimfJB0ccqYa8eaiS4DcUqOj5AVqQIa8rGh9tggRQ5smIgECcb6qKzMtG7Jhci 8RopJ0nMgW9o0tEjKgJHVasqtojzU8EjmnqeMWDQsEpSip9ibsuU6ZEealzjCDkiZMYRqjQqQiuh MdOOESOG2JgkCQYHABwsANirYiqsimA2ut0LQAIMGEP26iAMIASDOxWRnNy2gfCIyooJJ97B5qq7 TDE7JGYMYPHe0TqKUWwQgepJDXcZ60gsQULsFKvx/JwhYXRmAB/s4sXto4HukzAkME5sOvheDjlW DztZJDaAIISbwwAwZEgDiqk4imxkEZsDi+2/PzBQAeBPxTASVrjm6IKwYQXoSyf+oMAEgOgUGTKC BCbMJxADQrzwwgxUCHSEBiZosIIKLmjAQBHxVKTHKRzAZYJG87TQAgJ+HNLQNnOMJAJZCwphIEGU yCFUIiL0UIIkDtAQzEjYsNXUHTIK1cCQLFH0UlMDvRKIUCuFVNEybSBJkAy6BOkkSE6oso2UDZkx RyQ//KALCq9syeWZGwUEACH5BAkBAAoALAAAAAAhABoABwj8ABUIHEhQwTZKd2jcybCtoMOHDs3Y 4+WjYkVTwqpA3Dhwm6pVFkNahGWGAUeHS4SJ9FFqJa9WJwlug2WxVKlFTS40gbIlpCmYMRWoqonI QUE2oXpWdLIkaCuKpT41fNgml8VIEDPBiLH1hYNg0xhkGptpWyYqmQS2UVpKBsQVNmx80OEiQtoZ K2LMeLHCBAshAi9YRLHxhY65GFQAnqF3hpAVGli4iKFgidJlHKnE0oHBRYcXL2DsfVykg4sQRRhA qVjKDEcGJjDEUqEhr97HGjrEwqCjQyiLrUxynDGbRZEVK/YWYbFCxY4HH+pZfCV8IxUVs01oKBIj hgkV4o4xPLDxzeKd6g9nYLAQwoWKDixirNAdw/CHIL2mc9TwYe4OFqa5AEMRsYQAgxAPBAGBERax kpULEtgQxAOpsYBBCBposIMFKzCwAgQQ8FCRHhIU4dARD4wggQQ6zGCSCjpYEJkOFCrwYSMWPTEE ByZUx4AG78FHxUAxZMiYBibMoIAQ1TRgETc0PqDkQ10IYqUgbjy0DQlyWCQMehC10lJFdCCSQASS SJJEKHCExItrQdEwpkUN1OlSBkENdIcpK61kDSV5EiRDJCD1ucwbUwVKkBlvRPKDNT8Io0pwilYa VEAAIfkECQEACgAsAAAAACEAGgAHCPwAFQgcSFCBjFZv5tDIULChQ4cZdMmhQ5FOg1yPZDzcOJBB JDk+fFS02IBOIBocH8pYQyfkSIskGzxiwCDlwJUtRQaKFEqeFj88GghtgMvmwE8hQ+rSSNCOHz1C N7WqaVOGnwY+ijqUIYLHpgbFqDaMESJErFgq1okYp2BGjBgvhMilKaMO1AZ3NnYYwYEDAAgwaEIA AAADYQA2hChIw0VoAY4rBvsdsYLBYAAhDiN+waCO0C00Qzd88eEwhw4SCIfwO4QwhBdg7jpIKcOw ZtV+NUNoh0MoypQMVLTWHCu3DdONG8wxOmPwcMy5NTzIHUXo8pRF+N5eTbhIkNa1Q5K/4cjARW4A QUbg7q4DwJA+d71srE3YrwUhQdYDKCLELxOheoCzgkP45TZCB4LpV4QMfiWXAgCUFYSfDTYE8cGA AsWCQSwrdKBCB5yRM8FQv5igAYYP7ZHGIIPcQIlDaVwyVFg0pTRISxTJQYsDDMgQQRoi4PBVA5tU YZRAF1AkkkWJoBLUUESOd6RAyUxUUUlQNhBIXlMOlMEPFGE51BZLddlQK4/8AAcca0QyB1NmxslR QAAh+QQJAQAKACwAAAAAIQAaAAcI/AAVCBxIUAEbQhcudHFQsKFDhyXUuOOBAwcXHEhAPNxYkBUw HhQrWuTiLhQDjhtZVQAZsiKXl55uoHTYxhFLHl+6WMkjJgdMhjMJeonCchaDowpqKYri8x3SjZmo HD15guiVhpmQpOCSgxDKFzZGSAjyIRYQJJ00FInx4oXUWo581jjJESyAuwA2MNiAF+8GBZ98Ass0 80iQvi749r2rgQjXHESCHnnQV8LiuyM60cuRQ2ZQNjouX4ZQiSuJoAIzWRC9mAJXLXSDmmAN4MNd Ja9RK9DAgbaN26ZjczTRmzZlAK64ggnKojiAIKEXw7g7gbOtF8IbqnD+4YjivobT+3BOMSRIpuwC GcTq+4CKAhMPLGBwoYLFEW8TuIpwi14glQ4mFAHDDJmwUcIebBQEQiE+daWbAmcU4kkOONBzAwOZ OHBCGZxx4dSDmUACkkj0ABPFSz5dUsuDApUACA4tXcQVF5dExmKL1FQgkow5vDPFjQVJoQUi7tDz RQ2E9AfkkgoEBAAh+QQJAQAKACwAAAAAIQAaAAcI/AAVCBxIUKCdYydOtCnIsKFDBtQmSJxgxJLD iw7VPJko0UgPBhhDKnATZSPHCVgYqFQpsiADUik2Ysp2zsMED9laPuQU5smtJCojehilcyADDRpg vJBS4QmQgTKAGfHQBmRRFQCycjCAJZwJpTKO5ZhgsagCBg+yAoCAQe1aEDwmKDMrMAIEDlrdAlCB LUwAugJXAMCrdy2CKKOs0nWhlzAADzmkKTbL4INbx3xyGFk5uSXWxlmjbO7ccobjvAAyS2ZZlAEE tacBKImCBbCCEIXz/gmD7AVpjEUIc7Cs12avDmbtqnXBAkKQHS5MRAvjoaxOBhsg6NjAgrPKJD8V bkawfRZIAEzSqDHogenmX/IKRISZsFGazZu74Ctoc8skR0WskdfDfRPJIoN+Ax1yDigo5XEgggQx 8KBZAQEAIfkECQEACgAsAAAAACEAGgAHCOoAFQgcSHCgDHPEDhVcyLDhQDBP/rBj4LCiQ1JPKDiT YbEjwSk4JlCgoMmjyUE8PPz5M4kBRZMVQeTw0GyCL5gVV2CIVeYJmBzncDpcAQBAn0b+eDAT2pAB h6IjOETBwrThDqgAnmB6WZWgiaJP0YhxybVrhBFgKVQgS7argg9g+1Tg6JbgVQAc+qRgW1YoA7RF wa1l6zZG0aLqxrZ1q+IwB2eK6wqEixeAK6qSFZwtKiFdGWZ9q2oAMKIDgxtRgmaO8OKFomiNPNzM LDDNTAosaQuUIcbDSDy6BZLx/Y9w5l1M/pgLbjCC0IAAIfkECQEACgAsAAAAACEAGgAHCMQAFQgc SJAgg3bPpDAoyLChQ4E90EwA9LBixWdMJkSZYrFjwXMSudzwSFKBMTQecDQp2ZFNvFtGcoRiaTHC BD/VKISjWVGKh28AAOzg+fAQgCFBWRB1qClo0BlLG2pwKoGB1agEOyAFYAErwxBOO3gtqMOpibEE bTjdsBAtFQ5OP6AVOONoUA5U5sbYGhTGXAULlGxV8demGLUW2o51OaFRI3F/FURDmYNEZGJMPKRw EzlbZiNxIpdoZEhbZIFxSlhVXDEgACH5BAkBAAoALAAAAAAhABoABwj8ABUIHEiQIAN007TsYsCQ QcGHEAvKIJMiSpQwoyI4jMixIAMyUSpGyZHigIyOKAVaScHSYg6SalJ2ZFApxRNQx5C8zOEogsyI ScKkkCZFwcSXhY78hPhJqJaBaXJMIGZCxYqlBO+lqKAJRgerAwCI5QADq0AZmHL8ESv2gQS2scwK bBMmzBC2eAEEabjxZ5owa/OKHTGDodwEE+4KBqBC7kArFBYDeGDY8ZkhivM2diwwhGQAI15wFjLi 8+SGZjeYFttBLoO3iyVwGDzD9Yt6hpiQs2BjRAgMbD/wxdo0BSe+QkLogDCChWMQdZ/kYWClUCFI yjT2NUuxrhiXJykwDZcLokxLi1EmWOJMEJ159BOoVWavwE2dKGKaTUJNf6CM+SgFBAAh+QQJAQAK ACwAAAAAIQAaAAcI/AAVCBxIkKAZGrhw0ZhSsKFDh0twQdPToGIiJD0eaiwoY5EeihVD4sjDgMHG h0s8fmwAMiQPZSVPNpynh4eeKGTk3Ri3KSSXbDILVklU89YZkwIJbamIQ1RQglBslslYkNAmHpAk UTnyQghSjTKI5vh1ZAaMFSZYsGBzoZeEERwAcOgg8wYPHhUOSQDAt6+QGCP6cmARVBAPHJA+9F2s YS/fESa+blzEg4uzxYvj8uWg4amCFjzQYB4NYEQRzwpQPRlCevGIFagZADvVF0JrG2xQs1G32DHp B7mfhshsuzUA4EFNYH7gYrSFxQ+onJwRePEHFaNfbGDNN3pMh3xsZsRYEA8NE2MwNmCw8AGCjSMK mvf9IF1mVB451CwhyCBCBDYraNCBCyF0JhMRidiUAyQ95JYBPA3wkMgl2qAm0AV3fYSDOy0kElID YkhhoQIMzGPTRxS1VAFVIyqQDCoogqRHJXi0SJAMF8CDDTQICGJFSZLZKNB3MgUEACH5BAkBAAoA LAAAAAAhABoABwj8ABUIHEiQoIw7qt7QoFSwocOGDO78KOWjoo9Swd4w2PiwowIZsCyKtBiMiMeH lJz4oDNy5KpBJwuaccLSRwN6NdDdeBRMZKk0MQeGZOnpBBuCDN6YskhvCYOYd+gQ7fGw1VJUVINa Y4nDkgIhM2DAmFFEwwoFVeiJixUiRCwXK542zCCVDhkGMUYA2IsBAAcOG1fYkAAhyAcTG+USRCEV x668e/n6BaxhxAjCH852FCbVUZERQyID6AtghIu/lx/MOLlMaiO9okf73YvaAhXFD2lG4RMZQmTS HCbHOhozVwree3WwiBwicnAJMYIqABQ68uHftGdL0BCzSHDRrTpMMN87wsbkESqIO/QeGwAb8ZJL H9ER3PIOKuu/x34feQd5BmycxoFlD7xQEAMmqOCCC9UY4sofzuAVwg4hsKDDAzokVgQElklgAwwd 0VCXHmqoN9ASgwziRhp2SELFEULg1xEsdd0Exh5HsfGGShYhklhMZmxVl008QFOTRQjEIZ1AZtAo 1Uot+fBDHLgFlRRNLB3pAy9zVLmkAhHR8sMyTiyjCw1LfKnmSQEBACH+MEZJTEUgSURFTlRJVFkN CkNyZWF0ZWQgb3IgbW9kaWZpZWQgYnkNCmNhZHRvb24NCgAh/upVTlJFR0lTVEVSRUQgU0hBUkVX QVJFDQoNCkFzc2VtYmxlZCB3aXRoIEdJRiBDb25zdHJ1Y3Rpb24gU2V0Og0KDQpBbGNoZW15IE1p bmR3b3JrcyBJbmMuDQpCb3ggNTAwDQpCZWV0b24sIE9ODQpMMEcgMUEwDQpDQU5BREEuDQoNCmh0 dHA6Ly93d3cubWluZHdvcmtzaG9wLmNvbQ0KDQpUaGlzIGNvbW1lbnQgd2lsbCBub3QgYXBwZWFy IGluIGZpbGVzIGNyZWF0ZWQgd2l0aCBhIHJlZ2lzdGVyZWQgdmVyc2lvbi4AIf8LR0lGQ09ObmIx LjACEQAODQACAAUAAAAAAAAAAAANU20wMjAwMDEuZ2lmAA4NAAIABwAAAAAAAAAAAA1TbTAyMDAw Mi5naWYADg0AAgAJAAAAAAAAAAAADVNtMDIwMDAzLmdpZgAODQACAAsAAAAAAAAAAAANU20wMjAw MDQuZ2lmAA4NAAIADQAAAAAAAAAAAA1TbTAyMDAwNS5naWYADg0AAgAPAAAAAAAAAAAADVNtMDIw MDA2LmdpZgAODQACABEAAAAAAAAAAAANU20wMjAwMDcuZ2lmAA4NAAIAEwAAAAAAAAAAAA1TbTAy MDAwOC5naWYADg0AAgAVAAAAAAAAAAAADVNtMDIwMDA5LmdpZgAODQACABcAAAAAAAAAAAANU20w MjAwMTAuZ2lmAA4NAAIAGQAAAAAAAAAAAA1TbTAyMDAxMS5naWYADg0AAgAbAAAAAAAAAAAADVNt MDIwMDEyLmdpZgAODQACAB0AAAAAAAAAAAANU20wMjAwMTMuZ2lmAA4NAAIAHwAAAAAAAAAAAA1T bTAyMDAxNC5naWYADg0AAgAhAAAAAAAAAAAADVNtMDIwMDE1LmdpZgAODQACACMAAAAAAAAAAAAN U20wMjAwMTYuZ2lmAA4NAAIAJQAAAAAAAAAAAA1TbTAyMDAxNy5naWYAADs= ------=_NextPart_000_0026_01C1A90D.A8EDA4A0-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 21:49:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07606 for ; Wed, 30 Jan 2002 21:49:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W7BP-0005lC-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 18:42:39 -0800 Received: from virgo.cus.cam.ac.uk ([131.111.8.20]) by psg.com with esmtp (Exim 3.33 #1) id 16W7BO-0005l6-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 18:42:39 -0800 Received: from cet1 by virgo.cus.cam.ac.uk with local (Exim 3.953) id 16W7BM-000229-00; Thu, 31 Jan 2002 02:42:36 +0000 Subject: Re: LOC record rounding policy To: kre@munnari.OZ.AU (Robert Elz) Date: Thu, 31 Jan 2002 02:42:36 +0000 (GMT) Cc: Mark.Andrews@isc.org, namedroppers@ops.ietf.org In-Reply-To: <6384.1012208157@brandenburg.cs.mu.OZ.AU> from "Robert Elz" at Jan 28, 2 03:55:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Chris Thompson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit kre@munnari.OZ.AU (Robert Elz) writes [...] > > But I can't begin to think why we're discussing this here, I sort of assumed that 1 April had come early this year. > as long as the > correct thing is on the wire (ie: 1000'ths) then how that is input is a > quality of implementation issue - for me, I don't think I'd want to be dealing > in radians (or their fractions) at all, I still prefer degrees, minutes, ... > (including decimals of a second if appropriate). No-one (and that includes RFC 1876) has even mentioned radians! > If an implementation insists on issuing warnings or errors about stupidities, > then I'll fix or replace the implementation. If an implementation when given > precise input (actually specified to 3 decimal places of radians) doesn't put > exactly that value in the RR when it sends it, then I will fix or replace it. > Anything else (rounding when I give more digits, what it does with 3.1234 > seconds, etc) is just frills, and can be dealt with, it just should be > documented. > > So Brian, round, truncate, whatever you like ... This is only an issue for > human edited files, zone files obtained via *XFR or DynDNS will have a > precise value in 1/1000 radian units, which should be preserved and reissued > without change. Well striking out all that nonsense about radians, there is indeed just one and only one important point: the conversion from on-the-wire format to master-file format and back must be idempotent. Please bear in mind that 0.001" on the surface of the earth is about 3.1 cm (1.2 in). [0.001" of longtitude may be less, of course, depending on latitude.] Someone might indeed feed in more significant digits as a result of some sort of automation, but no-one is going to be devastated by losing them, whatever the rounding/truncation algorithm used. ["Fred, help me move this rack one inch to the north-east: we've got to do it to make the LOC record right."] Chris Thompson Email: cet1@cam.ac.uk to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 21:50:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07625 for ; Wed, 30 Jan 2002 21:50:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W7Cr-0005pr-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 18:44:09 -0800 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.33 #1) id 16W7Cq-0005pk-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 18:44:08 -0800 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Wed, 30 Jan 2002 18:44:03 -0800 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 30 Jan 2002 18:44:08 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 30 Jan 2002 18:44:03 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 30 Jan 2002 18:44:03 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Wed, 30 Jan 2002 18:41:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6132.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: LOC record rounding policy Date: Wed, 30 Jan 2002 18:41:46 -0800 Message-ID: Thread-Topic: LOC record rounding policy Thread-Index: AcGp/iivl+vMKv+MR1mD97djLTB3DQAAZM/A From: "Christian Huitema" To: "Robert Elz" , Cc: X-OriginalArrivalTime: 31 Jan 2002 02:41:46.0989 (UTC) FILETIME=[D399F9D0:01C1AA00] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA07625 > But I can't begin to think why we're discussing this here, as long as the > correct thing is on the wire (ie: 1000'ths) then how that is input is a > quality of implementation issue - for me, I don't think I'd want to be > dealing > in radians (or their fractions) at all, I still prefer degrees, minutes, > ... > (including decimals of a second if appropriate). A 1/1000th of a second of arc is about 3.1 centimeters at the equator or along a meridian -- not much more than an inch. What exactly is the application that: (a) needs a better precision; (b) needs that better precision stored in the DNS; and (c) needs the better precision so much that it would break on a rounding error ?.. -- Christian Huitema to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 22:08:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07776 for ; Wed, 30 Jan 2002 22:08:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W7NU-0006wh-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 18:55:08 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16W7NU-0006wb-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 18:55:08 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16W7NQ-000KlB-00; Wed, 30 Jan 2002 18:55:04 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: namedroppers Subject: Re: LOC record rounding policy References: <200201280417.g0S4H5s96039@drugs.dv.isc.org> <6384.1012208157@brandenburg.cs.mu.OZ.AU> Message-Id: Date: Wed, 30 Jan 2002 18:55:04 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > But I can't begin to think why we're discussing this here, as long as the > correct thing is on the wire (ie: 1000'ths) then how that is input is a > quality of implementation issue - for me, it is a quirk of history that the format of the zone files is a matter of ietf standard. blame rob, pvm, ... randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 22:19:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07871 for ; Wed, 30 Jan 2002 22:19:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W7cz-0007Ke-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 19:11:09 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16W7cy-0007KY-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 19:11:08 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16W7cy-000LCc-00; Wed, 30 Jan 2002 19:11:08 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Christian Huitema" Cc: namedroppers@ops.ietf.org Subject: RE: LOC record rounding policy References: Message-Id: Date: Wed, 30 Jan 2002 19:11:08 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit i run a cron against the readings of the gps. it looks to see how stable a reading it gets over time, now approaching three years. it prints the string that is stable. the device may or may not have some precision. i don't really care. i just run a script which produces a loc rr. if the wire format wants less digits of precision, it should round. if it wants more precision, it should add zeros. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 22:35:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08956 for ; Wed, 30 Jan 2002 22:35:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W7kz-0007Wu-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 19:19:25 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.33 #1) id 16W7ky-0007Wm-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 19:19:24 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA19345; Wed, 30 Jan 2002 22:19:21 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA13602; Wed, 30 Jan 2002 22:19:21 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id WAA26086; Wed, 30 Jan 2002 22:19:20 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id WAA06390; Wed, 30 Jan 2002 22:19:20 -0500 (EST) To: Robert Elz Cc: Mark.Andrews@isc.org, namedroppers@ops.ietf.org Subject: Re: LOC record rounding policy References: <200201280417.g0S4H5s96039@drugs.dv.isc.org> <6384.1012208157@brandenburg.cs.mu.OZ.AU> From: Derek Atkins Date: 30 Jan 2002 22:19:20 -0500 In-Reply-To: <6384.1012208157@brandenburg.cs.mu.OZ.AU> Message-ID: Lines: 20 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > So Brian, round, truncate, whatever you like ... This is only an issue for > human edited files, zone files obtained via *XFR or DynDNS will have a > precise value in 1/1000 radian units, which should be preserved and reissued > without change. Um, not quite. If you plan to sign the data you need to make sure that what goes into your signature algorithm == what is transmitted on the wire, otherwise the signature will fail on the receiving end. > kre -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 22:42:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09220 for ; Wed, 30 Jan 2002 22:42:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W7xK-0007pd-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 19:32:10 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.33 #1) id 16W7xJ-0007pT-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 19:32:09 -0800 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g0V3Ths11842 for ; Thu, 31 Jan 2002 14:29:43 +1100 (EST) (envelope-from marka@isc.org) Message-Id: <200201310329.g0V3Ths11842@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: LOC record rounding policy In-reply-to: Your message of "Wed, 30 Jan 2002 19:11:08 -0800." Date: Thu, 31 Jan 2002 14:29:43 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > i run a cron against the readings of the gps. it looks to see how stable > a reading it gets over time, now approaching three years. it prints the > string that is stable. the device may or may not have some precision. i > don't really care. i just run a script which produces a loc rr. No. You produce something looks vaguely like a LOC record. If there is more than three decimal places in the seconds fields then it is not a LOC record. I suggest that you fix the script. > if the > wire format wants less digits of precision, it should round. Well if you want it to round please write the new draft and then everyone that has implemented LOC can rev their implementation. > if it wants more precision, it should add zeros. That was already allowed. Mark > > randy > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Mark Andrews, Internet Software Consortium 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. From owner-namedroppers@ops.ietf.org Wed Jan 30 22:58:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09357 for ; Wed, 30 Jan 2002 22:58:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W87P-00084V-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 19:42:35 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.33 #1) id 16W87M-00084M-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 19:42:32 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0V3mGW06188; Thu, 31 Jan 2002 10:48:17 +0700 (ICT) From: Robert Elz To: Mark.Andrews@isc.org cc: namedroppers@ops.ietf.org Subject: Re: LOC record rounding policy In-Reply-To: <200201310214.g0V2Ems10916@drugs.dv.isc.org> References: <200201310214.g0V2Ems10916@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Jan 2002 10:48:16 +0700 Message-ID: <6186.1012448896@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 31 Jan 2002 13:14:48 +1100 From: Mark.Andrews@isc.org Message-ID: <200201310214.g0V2Ems10916@drugs.dv.isc.org> | Because master files are defined to be a transport format in | RFC 103[45]. They should be able to be read by all | implementations. And this is how $GENERATE and $TTL and other useful stuff like that appeared, right? Master files as a transfer format was always a silly idea (even if it proved useful to help around implementation bugs for long time). These days less and less people actually use master files in human editable form. | It is bad thing if the same input does not produce the same | results on all servers. Yes, it is, but it isn't fatal - and it only matters if someone actually gives excess precision (so if you give just the amount that is defined, you should get the same result everywhere - if you give more then you can get (slightly) undefined results - big deal). | If one implementation rounds and one truncates then there is a | 50% probability that a LOC record signed zone (assuming the LOC | passes through unchanged) will cause verification failures when | loaded on the other implementation. We're signing the text format of the records now? Since when? As long as the records are signed in their internal form (which is the only thing that makes sense) then if it is correctly signed on the implementation that loads the zone, it will verify correctly everywhere. If you sign using one implementation and then load that into something that reads the data in a different manner, and you have taken advantage of the differences, then yes of course you lose. | Ftp, scp etc. are still used to get zones onto master servers. Yes, as are SQL servers, and all kinds of other things. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 23:07:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09444 for ; Wed, 30 Jan 2002 23:07:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W8MK-0008Q1-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 19:58:00 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.33 #1) id 16W8MI-0008P7-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 19:57:59 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0V40pW06209; Thu, 31 Jan 2002 11:00:51 +0700 (ICT) From: Robert Elz To: "Christian Huitema" cc: Mark.Andrews@isc.org, namedroppers@ops.ietf.org Subject: Re: LOC record rounding policy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Jan 2002 11:00:51 +0700 Message-ID: <6207.1012449651@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 30 Jan 2002 18:41:46 -0800 From: "Christian Huitema" Message-ID: | A 1/1000th of a second of arc is about 3.1 centimeters at the equator or | along a meridian -- not much more than an inch. What exactly is the | application that: (a) needs a better precision; (b) needs that better | precision stored in the DNS; and (c) needs the better precision so much | that it would break on a rounding error ?.. There are none ... but it is important that the RRs can be specified precisely. But that's fine now, specifying 3 decimal places exactly does that, and no-one is planning on altering that. The only question is what should be done when someone for whatever reason (perhaps reacting to 33 1/3 seconds somewhere and producing 33.33333333) gives more than is specified, what should be done. I still don't care, and nothing I have seen yet has convinced me that there's any reason at all for anyone else to care either. If the user does care, he can just specify the exact 3 decimal digits, then everyone knows exactly what will happen. More than 3, and the implementation does whatever it likes. Let's just move on to issues that are worthy of debate (and by all means, Randy, or anyone, can express opinions to the various implementors about how the implementations they use should behave, and the implementors will, usually anyway, take those kinds of opinions into account). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 23:13:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09512 for ; Wed, 30 Jan 2002 23:13:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W8UO-0008d9-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 20:06:20 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16W8UN-0008d2-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 20:06:19 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16W8UI-000Mhj-00; Wed, 30 Jan 2002 20:06:14 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Daniel Massey Cc: namedroppers Subject: Re: Wildcards ( not and Opt-In ) References: <3C580CA0.F64E3A7B@isi.edu> Message-Id: Date: Wed, 30 Jan 2002 20:06:14 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit i suggest that the questions we might be asking, in kind of priority order, are as follows: o are the semantics of wildcards well defined in the presence of dnssec (or vice versa)? does 2535 really cover it? if not, do we think they can be? o does it really require the complexity of 2535? if so, is it worth it? o does the possibility of wildcards change/weaken security, even if a signed zone does not use them? o does the presense of wildcards in a signed zone change/weaken the security of that zone? o Does the presence of a wild card in a signed zone change/weaken the security of delegations from that zone? o do wildcards in a signed zone interact badly with other parts of the standard or with other work we are contemplating now. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 23:14:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09526 for ; Wed, 30 Jan 2002 23:14:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W8R8-0008VC-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 20:02:58 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.33 #1) id 16W8R6-0008V0-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 20:02:56 -0800 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g0V40Us11928 for ; Thu, 31 Jan 2002 15:00:30 +1100 (EST) (envelope-from marka@isc.org) Message-Id: <200201310400.g0V40Us11928@drugs.dv.isc.org> to: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: LOC record rounding policy In-reply-to: Your message of "Thu, 31 Jan 2002 10:48:16 +0700." <6186.1012448896@brandenburg.cs.mu.OZ.AU> Date: Thu, 31 Jan 2002 15:00:30 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Date: Thu, 31 Jan 2002 13:14:48 +1100 > From: Mark.Andrews@isc.org > Message-ID: <200201310214.g0V2Ems10916@drugs.dv.isc.org> > > | Because master files are defined to be a transport format in > | RFC 103[45]. They should be able to be read by all > | implementations. > > And this is how $GENERATE and $TTL and other useful stuff like > that appeared, right? $GENERATE is clearly documented as being a extention. LOC is standardised. $TTL is standardised. > Master files as a transfer format was always a silly idea (even if it proved > useful to help around implementation bugs for long time). These days less > and less people actually use master files in human editable form. > > | It is bad thing if the same input does not produce the same > | results on all servers. > > Yes, it is, but it isn't fatal - and it only matters if someone > actually gives excess precision (so if you give just the amount that > is defined, you should get the same result everywhere - if you give more > then you can get (slightly) undefined results - big deal). > > | If one implementation rounds and one truncates then there is a > | 50% probability that a LOC record signed zone (assuming the LOC > | passes through unchanged) will cause verification failures when > | loaded on the other implementation. > > We're signing the text format of the records now? No. Nothing in DNSSEC says that you have to write out the entire zone contents. A signer could just as easily just generate the SIG and NXT records and append them to the master file, create a seperate file with just the SIG and NXT records that could then be $INCLUDED. Either of these perfectly reasonable behaviours would preserve the textual form of the LOC record but would result in invalid signatures. > Since when? As long > as the records are signed in their internal form (which is the only thing > that makes sense) then if it is correctly signed on the implementation that > loads the zone, it will verify correctly everywhere. If you sign using one > implementation and then load that into something that reads the data in a > different manner, and you have taken advantage of the differences, then yes > of course you lose. So now I can't sign my zone using whatever DNSSEC implementation ship it to my ISP who happens use something else and have it work. > > | Ftp, scp etc. are still used to get zones onto master servers. > > Yes, as are SQL servers, and all kinds of other things. SQL servers arn't part of the standard. Transmitting in master file format is. Mark > > kre > -- Mark Andrews, Internet Software Consortium 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. From owner-namedroppers@ops.ietf.org Wed Jan 30 23:15:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09562 for ; Wed, 30 Jan 2002 23:15:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W8Vg-0008fM-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 20:07:40 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16W8Vf-0008fG-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 20:07:39 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16W8Ve-000MkH-00; Wed, 30 Jan 2002 20:07:38 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mark.Andrews@isc.org Cc: namedroppers@ops.ietf.org Subject: Re: LOC record rounding policy References: <200201310329.g0V3Ths11842@drugs.dv.isc.org> Message-Id: Date: Wed, 30 Jan 2002 20:07:38 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> i run a cron against the readings of the gps. it looks to see how stable >> a reading it gets over time, now approaching three years. it prints the >> string that is stable. the device may or may not have some precision. i >> don't really care. i just run a script which produces a loc rr. > No. You produce something looks vaguely like a LOC record. > If there is more than three decimal places in the seconds > fields then it is not a LOC record. > > I suggest that you fix the script. as your assertion is not well supported by the rfc, i suggest you need to first fix the rfc. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 23:24:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09632 for ; Wed, 30 Jan 2002 23:24:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W8ea-0008wy-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 20:16:52 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16W8eZ-0008ws-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 20:16:51 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16W8eY-000N0R-00; Wed, 30 Jan 2002 20:16:50 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Edward Lewis Cc: namedroppers Subject: Re: moving along References: Message-Id: Date: Wed, 30 Jan 2002 20:16:50 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> o we believe that we reached positive consensus on delegation signer, >> draft-ietf-dnsext-delegation-signer-05.txt. but, imiho, it needs an >> edit before being shipped to the area director for review. > Just asking, but given the mistakes made with 2535 and not having > sufficient operational testing before "progressing," shouldn't there be > some exercising of the DS code in an operational setting before such a > step? if we do not have reason to doubt the path, then 2026 tells us that is what happens between ps and ds. but if we doubt the path, then i, for one, would support being more conservative. how goes the isi ds experiment? but i can sure see reclassifying 2535 as experimental, one we know does not work well. :-)/2 randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 23:31:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10144 for ; Wed, 30 Jan 2002 23:31:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W8jE-00096a-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 20:21:40 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16W8jE-00096U-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 20:21:40 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16W8jE-000N96-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 20:21:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020131041937.19859.qmail@cr.yp.to> References: <6384.1012208157@brandenburg.cs.mu.OZ.AU> <200201310214.g0V2Ems10916@drugs.dv.isc.org> Date: 31 Jan 2002 04:19:37 -0000 From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: LOC record rounding policy Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark.Andrews@isc.org writes: > Because master files are defined to be a transport format in > RFC 103[45]. They should be able to be read by all > implementations. Hypocrite. Your format extensions ($GENERATE, new record types, etc.) allowed master files that were _not_ readable to other implementations, even your own previous implementations. People who replicated zone files through FTP had to avoid the extensions or use the same software on both sides. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jan 30 23:45:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10388 for ; Wed, 30 Jan 2002 23:45:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W8ys-0009X2-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 20:37:50 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.33 #1) id 16W8yr-0009Wv-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 20:37:49 -0800 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g0V4ZMs12054 for ; Thu, 31 Jan 2002 15:35:22 +1100 (EST) (envelope-from marka@isc.org) Message-Id: <200201310435.g0V4ZMs12054@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: LOC record rounding policy In-reply-to: Your message of "Wed, 30 Jan 2002 20:07:38 -0800." Date: Thu, 31 Jan 2002 15:35:22 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >> i run a cron against the readings of the gps. it looks to see how stable > >> a reading it gets over time, now approaching three years. it prints the > >> string that is stable. the device may or may not have some precision. i > >> don't really care. i just run a script which produces a loc rr. > > No. You produce something looks vaguely like a LOC record. > > If there is more than three decimal places in the seconds > > fields then it is not a LOC record. > > > > I suggest that you fix the script. > > as your assertion is not well supported by the rfc, i suggest you need to > first fix the rfc. If the RFC had wanted to allow for extra precision it would have stated that the field should be rounded or truncated, in words in the main part of the RFC. We would not be having this discussion now if the intent was to allow for more than thousandths of a second. The sample code has considerable flaws in it, it does not reflect the intent of the main body of the RFC. It will handle valid input correctly. Invalid input however is not rejected and in many cases not detected. Mark > > randy -- Mark Andrews, Internet Software Consortium 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. From owner-namedroppers@ops.ietf.org Wed Jan 30 23:54:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10601 for ; Wed, 30 Jan 2002 23:54:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W96u-0009mM-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 20:46:08 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.33 #1) id 16W96t-0009mG-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 20:46:07 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id F344E28EE8 for ; Wed, 30 Jan 2002 20:46:06 -0800 (PST) (envelope-from vixie@as.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: LOC record rounding policy In-Reply-To: Message from Derek Atkins of "30 Jan 2002 22:19:20 EST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 30 Jan 2002 20:46:06 -0800 Message-Id: <20020131044607.F344E28EE8@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Um, not quite. If you plan to sign the data you need to make sure > that what goes into your signature algorithm == what is transmitted > on the wire, otherwise the signature will fail on the receiving end. conceptually, what's being signed is "whatever would go out in an AXFR". some known DNS implementations do not parse "zone file format" at all, preferring to take all of their zone data in the form of RFC2136 dynamic updates. i agree with randy (second time this year): standardizing zone file format was always silly, and gets sillier every year. 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 Jan 31 00:08:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10867 for ; Thu, 31 Jan 2002 00:08:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W9KO-000A8T-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 21:00:04 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.33 #1) id 16W9KL-000A6x-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 21:00:02 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g0V55bW13481; Thu, 31 Jan 2002 12:05:38 +0700 (ICT) From: Robert Elz To: Mark.Andrews@isc.org cc: namedroppers@ops.ietf.org Subject: Re: LOC record rounding policy In-Reply-To: <200201310435.g0V4ZMs12054@drugs.dv.isc.org> References: <200201310435.g0V4ZMs12054@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Jan 2002 12:05:37 +0700 Message-ID: <13479.1012453537@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 31 Jan 2002 15:35:22 +1100 From: Mark.Andrews@isc.org Message-ID: <200201310435.g0V4ZMs12054@drugs.dv.isc.org> | If the RFC had wanted to allow for extra precision it would | have stated that the field should be rounded or truncated, | in words in the main part of the RFC. Perhaps it should have done, but it doesn't. I suspect that it is impossible to determine what was "wanted" out of a doc that has been through the WG process, when dealing with an issue that was simply forgotten (sometimes it is clear from the WG discussions, and all that was missed was transcription into the doc - that isn't what I believe happened here, the whole issue was simply ignored by the WG until now). | The sample code has considerable flaws in it, it does not | reflect the intent of the main body of the RFC. It will | handle valid input correctly. Invalid input however is not | rejected and in many cases not detected. What is the intent is incredibly unclear. All it says about the master file format is ... s1, s2: [0 .. 59.999] (seconds latitude/longitude) for the relevant data. The [ n .. m ] notation and its meaning is defined nowhere. From that, all that is reasonable is to conclude that normal mathematical notation is used, which would imply any data in the closed interval between (and including) 0 and (and including) 59.999 is OK. 33.333333333 is certainly inside that interval. One might perhaps conclude that 59.9991 is illegal though. The doc certainly doesn't say anywhere that excess digits are incorrect. This is the kind of thing that implementation experience is supposed to find - places where it is possible to read the docs in different ways. Clearly this one is going to need to be updated before it can advance to DS. Exactly how it should be updated should probably be debated when that is about to happen. kre 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 Jan 31 00:16:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11006 for ; Thu, 31 Jan 2002 00:16:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W9Ro-000AJy-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 21:07:44 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16W9Ro-000AJs-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 21:07:44 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16W9Ro-000OX4-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 21:07:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <3C580CA0.F64E3A7B@isi.edu> In-Reply-To: Message-ID: To: Randy Bush Cc: Daniel Massey , namedroppers Subject: Re: Wildcards ( not and Opt-In ) From: Bob Halley Date: 30 Jan 2002 21:05:18 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush writes: > i suggest that the questions we might be asking, in kind of priority order, > are as follows: > > o are the semantics of wildcards well defined in the presence of dnssec > (or vice versa)? does 2535 really cover it? if not, do we think they > can be? The semantics are well defined. > o does it really require the complexity of 2535? if so, is it worth > it? The NXT proof specified by RFC 2535 is required, since otherwise a wildcard can be used to obscure more specific secure data. The other complexity (e.g. the label count number) is required otherwise verifiable signatures cannot be generated. > o does the possibility of wildcards change/weaken security, even if a > signed zone does not use them? > > o does the presense of wildcards in a signed zone change/weaken the > security of that zone? > > o Does the presence of a wild card in a signed zone change/weaken the > security of delegations from that zone? > > o do wildcards in a signed zone interact badly with other parts of the > standard or with other work we are contemplating now. Wildcards are a pain in the butt, and I often dislike them, but they can be made to work. I think the answers to the above are all no. The main issue with wildcard proof has been the complexity of generating it and validating it efficiently especially if binary labels are present. The obvious "try every possibility" algorithm seemed like a bad idea if you had to do 100+ iterations of the algorithm due to long IPV6 binary labels. Better algorithms which use more info from the NXT records are possible (I think) but a little tricky. If binary labels are going away, this won't be a problem :). /Bob 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 Jan 31 00:16:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11038 for ; Thu, 31 Jan 2002 00:16:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16W9T9-000AMx-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 21:09:07 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16W9T9-000AMr-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 21:09:07 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16W9T9-000OZQ-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 21:09:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <3C580CA0.F64E3A7B@isi.edu> In-Reply-To: <3C580CA0.F64E3A7B@isi.edu> Message-ID: To: Daniel Massey Cc: namedroppers@ops.ietf.org Subject: Re: Wildcards and Opt-In From: Bob Halley Date: 30 Jan 2002 21:08:05 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Daniel Massey writes: > Suppose you have a entry such as: > *.edu. MX 10 mail.junk.edu > SIG by edu. > > Now suppose a query for nge.isi.edu MX returns: > nge.isi.edu. MX 10 mail.junk.edu > SIG by edu. (with label = 1) > > Is this a valid answer or a response from an attacker? It's invalid as a secure response because there is no NXT proof that nge.isi.edu and isi.edu don't exist. Responses from the secure subzone must include all relevant proof. Let's consider a few cases about isi.edu, and what a secure validator would expect. (The same kind of reasoning would also apply for nge.isi.edu.) isi.edu. does not exist at all in the zone. In this case it doesn't exist in the secure subzone either, so there will be some NXT in the secure subzone which proves it doesn't exist. A secure validator will expect this proof and not be fooled. If the NXT bit is set on the NXT records, the validator would know that isi.edu. is in the non-secure part of an opt-in zone if it exists at all. That's all you ever know with non-secure data, so there's no problem here. isi.edu. does exist, and is in the secure part of the zone. In this case no NXT proving its nonexistence will exist, and the attacker cannot forge a believable secure response because he will not have the required NXT proof. isi.edu. does exist, and is in the non-secure part of the zone. As far as validation goes, this case is the same as the first case. Note that in all cases a secure validator can identify whether or not isi.edu is in the secure part of the zone or not, and the required nonexistence proof for secure wildcards will always be available. > With opt-in, how can I distinguish a valid, signed response > from an attacker's intentionally incorrect replay of wildcard? The valid signed response would include the relevant NXT proof. /Bob 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 Jan 31 02:41:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21169 for ; Thu, 31 Jan 2002 02:41:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WBcf-000DNe-00 for namedroppers-data@psg.com; Wed, 30 Jan 2002 23:27:05 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.33 #1) id 16WBce-000DNY-00 for namedroppers@ops.ietf.org; Wed, 30 Jan 2002 23:27:04 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id EF8FC28EE8 for ; Wed, 30 Jan 2002 23:27:03 -0800 (PST) (envelope-from vixie@as.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: LOC record rounding policy In-Reply-To: Message from Robert Elz of "Thu, 31 Jan 2002 12:05:37 +0700." <13479.1012453537@brandenburg.cs.mu.OZ.AU> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 30 Jan 2002 23:27:03 -0800 Message-Id: <20020131072704.EF8FC28EE8@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i want to clear up one thing. > | If the RFC had wanted to allow for extra precision it would > | have stated that the field should be rounded or truncated, > | in words in the main part of the RFC. > > Perhaps it should have done, but it doesn't. I suspect that it is > impossible to determine what was "wanted" out of a doc that has been > through the WG process, when dealing with an issue that was simply forgotten > (sometimes it is clear from the WG discussions, and all that was missed > was transcription into the doc - that isn't what I believe happened here, > the whole issue was simply ignored by the WG until now). LOC was never a WG product. it can be made into one, and probably this should be done so that it can advance, with appropriate editorial mods, to DS. but had LOC been a WG product, it would not have existed at all, because frankly gentlemen, we would still be arguing about it. (same for SRV.) the platonic ideal of a WG product is something more like, say, DNSSEC. or A6 and DNAME. we'll use RSA! no, we'll add ALG_ID. no, we'll use DSA! we'll use nybbles-in-ascii! no, we'll use binary labels! no, we really will use nybbles-in-ascii! it's like the weather in portland, of whom the natives say, "if you don't like it, just wait 20 minutes." there's certainly no way IP, or TCP, or DNS, or SMTP, could ever have been standardized had "WG's" existed way back when. and neither could LOC, or SRV. so when discussing the history of LOC, please don't mis-dignify it with the presumption that it went though a "WG process." thankfully, and mercifully, it did not, because the authors knew nothing of WG's at that time. i've come to see the label, "experimental", as a badge of, well, progress. 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 Jan 31 13:09:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06235 for ; Thu, 31 Jan 2002 13:09:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WLHv-0000OD-00 for namedroppers-data@psg.com; Thu, 31 Jan 2002 09:46:19 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.33 #1) id 16WLHu-0000O7-00 for namedroppers@ops.ietf.org; Thu, 31 Jan 2002 09:46:18 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.3/8.11.3) with ESMTP id g0VHkDK04263 for ; Thu, 31 Jan 2002 12:46:14 -0500 (EST) (envelope-from ogud@ogud.com) Date: Thu, 31 Jan 2002 12:46:13 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list Subject: IETF-53 DNSEXT agenda requests Message-ID: <20020131124220.R4197-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I have requested a 2.5 hour slot and we are currently scheduled to meet on Monday night (again). Send in requests for agenda items to me, in the requests send pointer to any appropriate drafts. Deadline for requests is March 4'th. 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 Thu Jan 31 15:48:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12030 for ; Thu, 31 Jan 2002 15:48:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WNne-00040e-00 for namedroppers-data@psg.com; Thu, 31 Jan 2002 12:27:14 -0800 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.33 #1) id 16WNnc-00040Y-00 for namedroppers@ops.ietf.org; Thu, 31 Jan 2002 12:27:12 -0800 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Thu, 31 Jan 2002 12:27:05 -0800 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 31 Jan 2002 12:27:09 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 31 Jan 2002 12:27:04 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 31 Jan 2002 12:27:03 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Thu, 31 Jan 2002 12:24:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6132.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C1AA95.53972F74" Subject: RE: Comments on draft-ietf-dnsext-gss-tsig-04.txt Date: Thu, 31 Jan 2002 12:24:47 -0800 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD03251FAA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes Thread-Topic: Comments on draft-ietf-dnsext-gss-tsig-04.txt Thread-Index: AcGorz/6Md+hKTjgQLitu3uwREZn9AB5CWvg From: "Levon Esibov" To: "Erik Nordmark" Cc: "Stuart Kwan" , "Praerit Garg" , "James Gilroy" , , "Jeff Westhead" , X-OriginalArrivalTime: 31 Jan 2002 20:24:47.0826 (UTC) FILETIME=[53F15B20:01C1AA95] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1AA95.53972F74 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Erik, Thanks for your feedback! We updated the draft to clarify the text in all instances you enumerated in your message. The latest version of the draft is attached. Please let us know if further clarifications are needed. =20 Clarify for namedroppers: no modifications were made to the GSS-TSIG algorithm itself. The updates only clarify the text per Erik's comments. Regards, Levon. -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]=20 Sent: Tuesday, January 29, 2002 2:24 AM To: namedroppers@ops.ietf.org Cc: Stuart Kwan; Praerit Garg; James Gilroy; Levon Esibov; randyhall@lucent.com; Jeff Westhead Subject: Comments on draft-ietf-dnsext-gss-tsig-04.txt Here are some comments on the draft. Once we can resolve them, which I think means an updated I-D, then I can get the IETF wide last call started. Erik --- Change from The Secret Key Transaction Signature for DNS (TSIG) [RFC2845] protocol to =20 Secret Key Transaction Authentication for DNS (TSIG) [RFC2845] protocol since that is the correct title for TSIG. In section 3 it says: > and servers that support GSS-TSIG it is required that security Since this is about ensuring interoperability I think the intent is captured by replaceing /required/REQUIRED/ Section 3.1.1 What is the meaning of abandon the algorithm? Try the next one? Is there a list of algorithms that the application can choose from? It makes sense to make this more clear. Section 3.1.1: Note: if the original client call to GSS_Init_sec_context returned any major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE, then the client MUST NOT send TKEY query. What should the client do instead? section 3.1.3.1 of the query. The response MUST be signed with a TSIG record. The signature in the TSIG record MUST be verified using the procedure detailed in section 5, Sending and Verifying Signed Messages. If the response is not signed, OR if the response is signed but signature is invalid, then an attacker has tampered with the message in transit or has attempted to send the client a false response. The client MAY continue waiting for a response to its last TKEY query until the time Is the "continue waiting" restricted to the unsigned on invalid signature case? Or does it apply in the valid signature case as well? If the former it would make sense to e.g. s/The client MAY/In this case the client MAY/ section 3.1.3.2 what does "abandon this negotiation sequence" mean? Where does it continue? section 4.1.1 doesn't seem to specify what do do when the context is expired. ------ ------_=_NextPart_001_01C1AA95.53972F74 Content-Type: text/plain; name="draft-ietf-dnsext-gss-tsig-05.txt" Content-Description: draft-ietf-dnsext-gss-tsig-05.txt Content-Disposition: attachment; filename="draft-ietf-dnsext-gss-tsig-05.txt" Content-Transfer-Encoding: base64 DQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgU3R1YXJ0IEt3YW4NCjxkcmFmdC1pZXRmLWRuc2V4dC1nc3MtdHNpZy0wNS50eHQ+ICAg ICAgICAgICAgICAgICAgICAgICAgIFByYWVyaXQgR2FyZw0KSmFudWFyeSAzMCwgMjAwMiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSmFtZXMgR2lscm95DQpFeHBp cmVzIEp1bHkgMzAsIDIwMDIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBM ZXZvbiBFc2lib3YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSmVmZiBXZXN0aGVhZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWljcm9zb2Z0IENvcnAuDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJhbmR5 IEhhbGwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgTHVjZW50IFRlY2hub2xvZ2llcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KDQoNCiAgICAgICAgICAgICAgICAgR1NTIEFsZ29yaXRobSBm b3IgVFNJRyAoR1NTLVRTSUcpDQoNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQpUaGlzIGRvY3Vt ZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBpbiBmdWxsIGNvbmZvcm1hbmNlDQp3aXRo IGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4NCg0KSW50ZXJuZXQtRHJh ZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNClRh c2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3Rl IHRoYXQNCm90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRz IGFzDQpJbnRlcm5ldC1EcmFmdHMuDQoNCkludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1l bnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4DQptb250aHMgYW5kIG1heSBiZSB1cGRhdGVk LCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyDQpkb2N1bWVudHMgYXQgYW55IHRpbWUu ICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC0NCkRyYWZ0cyBhcyByZWZlcmVu Y2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMNCiJ3b3JrIGluIHByb2dy ZXNzLiINCg0KVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vz c2VkIGF0DQpodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQNCg0KVGhl IGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3Nl ZCBhdA0KaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KDQpBYnN0cmFjdA0KDQpU aGUgVFNJRyBwcm90b2NvbCBwcm92aWRlcyB0cmFuc2FjdGlvbiBsZXZlbCBhdXRoZW50aWNhdGlv biBmb3IgRE5TLg0KVFNJRyBpcyBleHRlbnNpYmxlIHRocm91Z2ggdGhlIGRlZmluaXRpb24gb2Yg bmV3IGFsZ29yaXRobXMuICBUaGlzDQpkb2N1bWVudCBzcGVjaWZpZXMgYW4gYWxnb3JpdGhtIGJh c2VkIG9uIHRoZSBHZW5lcmljIFNlY3VyaXR5IFNlcnZpY2UNCkFwcGxpY2F0aW9uIFByb2dyYW0g SW50ZXJmYWNlIChHU1MtQVBJKSAoUkZDMjc0MykuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpF eHBpcmVzIEp1bHkgMzAsIDIwMDIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFtQYWdlIDFdDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgIEdTUy1UU0lH ICAgICAgICAgICAgIEphbnVhcnkgMzAsIDIwMDINCg0KVGFibGUgb2YgQ29udGVudHMNCg0KMTog SW50cm9kdWN0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMg0KMjogQWxnb3JpdGhtIE92ZXJ2aWV3Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMw0KICAyLjE6IEdTUyBEZXRhaWxzLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNA0KMzogQ2xpZW50IFByb3Rv Y29sIERldGFpbHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNA0K ICAzLjE6IE5lZ290aWF0aW5nIENvbnRleHQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uNA0KICAgIDMuMS4xOiBDYWxsIEdTU19Jbml0X3NlY19jb250ZXh0Li4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNQ0KICAgIDMuMS4yOiBTZW5kIFRLRVkgUXVlcnkg dG8gU2VydmVyLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNg0KICAgIDMuMS4zOiBS ZWNlaXZlIFRLRVkgUXVlcnktUmVzcG9uc2UgZnJvbSBTZXJ2ZXIuLi4uLi4uLi4uLi4uLi4uLi4u Nw0KICAzLjI6IENvbnRleHQgRXN0YWJsaXNoZWQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uOQ0KICAgIDMuMi4xOiBUZXJtaW5hdGluZyBhIENvbnRleHQuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMA0KNDogU2VydmVyIFByb3RvY29sIERldGFp bHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMA0KICA0LjE6IE5l Z290aWF0aW5nIENvbnRleHQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4xMA0KICAgIDQuMS4xOiBSZWNlaXZlIFRLRVkgUXVlcnkgZnJvbSBDbGllbnQuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4xMA0KICAgIDQuMS4yOiBDYWxsIEdTU19BY2NlcHRfc2VjX2NvbnRl eHQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMQ0KICAgIDQuMS4zOiBTZW5kIFRLRVkg UXVlcnktUmVzcG9uc2UgdG8gQ2xpZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMQ0KICA0LjI6 IENvbnRleHQgRXN0YWJsaXNoZWQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4xMw0KICAgIDQuMi4xOiBUZXJtaW5hdGluZyBhIENvbnRleHQuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4xMw0KNTogU2VuZGluZyBhbmQgVmVyaWZ5aW5nIFNpZ25lZCBN ZXNzYWdlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMw0KICA1LjE6IFNlbmRpbmcgYSBT aWduZWQgTWVzc2FnZSAtIENhbGwgR1NTX0dldE1JQy4uLi4uLi4uLi4uLi4uLi4uLi4xMw0KICA1 LjI6IFZlcmlmeWluZyBhIFNpZ25lZCBNZXNzYWdlIC0gQ2FsbCBHU1NfVmVyaWZ5TUlDLi4uLi4u Li4uLi4uLi4xNA0KNjogRXhhbXBsZSB1c2FnZSBvZiBHU1MtVFNJRyBhbGdvcml0aG0uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNQ0KNzogU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xOQ0KODogSUFOQSBDb25zaWRl cmF0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xOQ0K OTogQ29uZm9ybWFuY2UuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4xOQ0KMTA6QWNrbm93bGVkZ2VtZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMA0KMTE6UmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMA0KDQoNCjEuIEludHJv ZHVjdGlvbg0KDQpUaGUgU2VjcmV0IEtleSBUcmFuc2FjdGlvbiBBdXRoZW50aWNhdGlvbiBmb3Ig RE5TIChUU0lHKSBbUkZDMjg0NV0NCnByb3RvY29sIHdhcyBkZXZlbG9wZWQgdG8gcHJvdmlkZSBh IGxpZ2h0d2VpZ2h0IGF1dGhlbnRpY2F0aW9uIGFuZA0KaW50ZWdyaXR5IG9mIG1lc3NhZ2VzIGJl dHdlZW4gdHdvIEROUyBlbnRpdGllcywgc3VjaCBhcyBjbGllbnQgYW5kDQpzZXJ2ZXIgb3Igc2Vy dmVyIGFuZCBzZXJ2ZXIuIFRTSUcgY2FuIGJlIHVzZWQgdG8gcHJvdGVjdCBkeW5hbWljDQp1cGRh dGUgbWVzc2FnZXMsIGF1dGhlbnRpY2F0ZSByZWd1bGFyIG1lc3NhZ2Ugb3IgdG8gb2ZmLWxvYWQN CmNvbXBsaWNhdGVkIEROU1NFQyBbUkZDMjUzNV0gcHJvY2Vzc2luZyBmcm9tIGEgY2xpZW50IHRv IGEgc2VydmVyIGFuZA0Kc3RpbGwgYWxsb3cgdGhlIGNsaWVudCB0byBiZSBhc3N1cmVkIG9mIHRo ZSBpbnRlZ3JpdHkgb2YgdGhlIGFuc3dlcnMuDQoNClRoZSBUU0lHIHByb3RvY29sIFtSRkMyODQ1 XSBpcyBleHRlbnNpYmxlIHRocm91Z2ggdGhlIGRlZmluaXRpb24gb2YgbmV3DQphbGdvcml0aG1z LiAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gYWxnb3JpdGhtIGJhc2VkIG9uIHRoZSBHZW5l cmljDQpTZWN1cml0eSBTZXJ2aWNlIEFwcGxpY2F0aW9uIFByb2dyYW0gSW50ZXJmYWNlIChHU1Mt QVBJKSBbUkZDMjc0M10uDQpHU1MtQVBJIGlzIGEgZnJhbWV3b3JrIHRoYXQgcHJvdmlkZXMgYW4g YWJzdHJhY3Rpb24gb2Ygc2VjdXJpdHkgdG8gdGhlDQphcHBsaWNhdGlvbiBwcm90b2NvbCBkZXZl bG9wZXIuICBUaGUgc2VjdXJpdHkgc2VydmljZXMgb2ZmZXJlZCBjYW4NCmluY2x1ZGUgYXV0aGVu dGljYXRpb24sIGludGVncml0eSwgYW5kIGNvbmZpZGVudGlhbGl0eS4NCg0KVGhlIEdTUy1BUEkg ZnJhbWV3b3JrIGhhcyBzZXZlcmFsIGJlbmVmaXRzOg0KKiBNZWNoYW5pc20gYW5kIHByb3RvY29s IGluZGVwZW5kZW5jZS4gIFRoZSB1bmRlcmx5aW5nIG1lY2hhbmlzbXMgdGhhdA0KcmVhbGl6ZSB0 aGUgc2VjdXJpdHkgc2VydmljZXMgY2FuIGJlIG5lZ290aWF0ZWQgb24gdGhlIGZseSBhbmQgdmFy aWVkDQpvdmVyIHRpbWUuICBGb3IgZXhhbXBsZSwgYSBjbGllbnQgYW5kIHNlcnZlciBNQVkgdXNl IEtlcmJlcm9zIFtSRkMxOTY0XQ0KZm9yIG9uZSB0cmFuc2FjdGlvbiwgd2hlcmVhcyB0aGF0IHNh bWUgc2VydmVyIE1BWSB1c2UgU1BLTSBbUkZDMjAyNV0NCndpdGggYSBkaWZmZXJlbnQgY2xpZW50 Lg0KDQpFeHBpcmVzIEp1bHkgMzAsIDIwMDIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDJdDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgIEdT Uy1UU0lHICAgICAgICAgICAgIEphbnVhcnkgMzAsIDIwMDINCg0KKiBUaGUgcHJvdG9jb2wgZGV2 ZWxvcGVyIGlzIHJlbW92ZWQgZnJvbSB0aGUgcmVzcG9uc2liaWxpdHkgb2YNCmNyZWF0aW5nIGFu ZCBtYW5hZ2luZyBhIHNlY3VyaXR5IGluZnJhc3RydWN0dXJlLiAgRm9yIGV4YW1wbGUsIHRoZQ0K ZGV2ZWxvcGVyIGRvZXMgbm90IG5lZWQgdG8gY3JlYXRlIG5ldyBrZXkgZGlzdHJpYnV0aW9uIG9y IGtleQ0KbWFuYWdlbWVudCBzeXN0ZW1zLiAgSW5zdGVhZCB0aGUgZGV2ZWxvcGVyIHJlbGllcyBv biB0aGUgc2VjdXJpdHkNCnNlcnZpY2UgbWVjaGFuaXNtIHRvIG1hbmFnZSB0aGlzIG9uIGl0cyBi ZWhhbGYuDQoNClRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50IGlzIGxpbWl0ZWQgdG8gdGhlIGRl c2NyaXB0aW9uIG9mIGFuDQphdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gb25seS4gSXQgZG9lcyBu b3QgZGlzY3VzcyBhbmQvb3IgcHJvcG9zZSBhbg0KYXV0aG9yaXphdGlvbiBtZWNoYW5pc20uICBS ZWFkZXJzIHRoYXQgYXJlIHVuZmFtaWxpYXIgd2l0aCBHU1MtQVBJDQpjb25jZXB0cyBhcmUgZW5j b3VyYWdlZCB0byByZWFkIHRoZSBjaGFyYWN0ZXJpc3RpY3MgYW5kIGNvbmNlcHRzIHNlY3Rpb24N Cm9mIFtSRkMyNzQzXSBiZWZvcmUgZXhhbWluaW5nIHRoaXMgcHJvdG9jb2wgaW4gZGV0YWlsLiBJ dCBpcyBhbHNvDQphc3N1bWVkIHRoYXQgdGhlIHJlYWRlciBpcyBmYW1pbGlhciB3aXRoIFtSRkMy ODQ1XSwgW1JGQzI5MzBdLCBbUkZDMTAzNF0NCmFuZCBbUkZDMTAzNV0uDQoNClRoZSBrZXkgd29y ZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hPVUxEIiwgIlNIT1VMRCBOT1Qi LA0KIlJFQ09NTUVOREVEIiwgYW5kICJNQVkiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGlu dGVycHJldGVkIGFzDQpkZXNjcmliZWQgaW4gUkZDIDIxMTkgW1JGQzIxMTldLg0KDQoNCjIuIEFs Z29yaXRobSBPdmVydmlldw0KDQpJbiBHU1MsIGNsaWVudCBhbmQgc2VydmVyIGludGVyYWN0IHRv IGNyZWF0ZSBhICJzZWN1cml0eSBjb250ZXh0Ii4NClRoZSBzZWN1cml0eSBjb250ZXh0IGNhbiBi ZSB1c2VkIHRvIGNyZWF0ZSBhbmQgdmVyaWZ5IHRyYW5zYWN0aW9uDQpzaWduYXR1cmVzIG9uIG1l c3NhZ2VzIGJldHdlZW4gdGhlIHR3byBwYXJ0aWVzLiAgQSB1bmlxdWUgc2VjdXJpdHkNCmNvbnRl eHQgaXMgcmVxdWlyZWQgZm9yIGVhY2ggdW5pcXVlIGNvbm5lY3Rpb24gYmV0d2VlbiBjbGllbnQg YW5kDQpzZXJ2ZXIuDQoNCkNyZWF0aW5nIGEgc2VjdXJpdHkgY29udGV4dCBpbnZvbHZlcyBhIG5l Z290aWF0aW9uIGJldHdlZW4gY2xpZW50IGFuZA0Kc2VydmVyLiAgT25jZSBhIGNvbnRleHQgaGFz IGJlZW4gZXN0YWJsaXNoZWQsIGl0IGhhcyBhIGZpbml0ZSBsaWZldGltZQ0KZm9yIHdoaWNoIGl0 IGNhbiBiZSB1c2VkIHRvIHNlY3VyZSBtZXNzYWdlcy4gIFRodXMgdGhlcmUgYXJlIHRocmVlDQpz dGF0ZXMgb2YgYSBjb250ZXh0IGFzc29jaWF0ZWQgd2l0aCBhIGNvbm5lY3Rpb246DQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICBWICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgfA0KICAgICAgICAgICAg ICAgICAgIHwgVW5pbml0aWFsaXplZCB8ICB8DQogICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgIHwgIHwNCiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgfA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAg ICAgICAgICBWICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t KyAgfA0KICAgICAgICAgICAgICAgICAgIHwgTmVnb3RpYXRpbmcgICB8ICB8DQogICAgICAgICAg ICAgICAgICAgfCBDb250ZXh0ICAgICAgIHwgIHwNCiAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tKyAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICB8DQog ICAgICAgICAgICAgICAgICAgICAgICAgICBWICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAg ICArLS0tLS0tLS0tLS0tLS0tKyAgfA0KICAgICAgICAgICAgICAgICAgIHwgQ29udGV4dCAgICAg ICB8ICB8DQogICAgICAgICAgICAgICAgICAgfCBFc3RhYmxpc2hlZCAgIHwgIHwNCiAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgfA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSsN Cg0KRXhwaXJlcyBKdWx5IDMwLCAyMDAyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSAzXQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICBHU1Mt VFNJRyAgICAgICAgICAgICBKYW51YXJ5IDMwLCAyMDAyDQoNCg0KRXZlcnkgY29ubmVjdGlvbiBi ZWdpbnMgaW4gdGhlIHVuaW5pdGlhbGl6ZWQgc3RhdGUuDQoNCg0KMi4xIEdTUyBEZXRhaWxzDQoN CkNsaWVudCBhbmQgc2VydmVyIE1VU1QgYmUgbG9jYWxseSBhdXRoZW50aWNhdGVkIGFuZCBoYXZl IGFjcXVpcmVkDQpkZWZhdWx0IGNyZWRlbnRpYWxzIGJlZm9yZSB1c2luZyB0aGlzIHByb3RvY29s IGFzIHNwZWNpZmllZCBpbg0KU2VjdGlvbiAxLjEuMSAiQ3JlZGVudGlhbHMiIGluIFJGQyAyNzQz IFtSRkMyNzQzXS4NCg0KVGhlIEdTUy1UU0lHIGFsZ29yaXRobSBjb25zaXN0cyBvZiB0d28gc3Rh Z2VzOg0KDQpJLiBFc3RhYmxpc2ggc2VjdXJpdHkgY29udGV4dC4gVGhlIENsaWVudCBhbmQgU2Vy dmVyIHVzZSB0aGUNCkdTU19Jbml0X3NlY19jb250ZXh0IGFuZCBHU1NfQWNjZXB0X3NlY19jb250 ZXh0IEFQSXMgdG8gZ2VuZXJhdGUgdGhlDQp0b2tlbnMgdGhhdCB0aGV5IHBhc3MgdG8gZWFjaCBv dGhlciB1c2luZyBbUkZDMjkzMF0gYXMgYSB0cmFuc3BvcnQNCm1lY2hhbmlzbS4NCg0KSUkuIE9u Y2UgdGhlIHNlY3VyaXR5IGNvbnRleHQgaXMgZXN0YWJsaXNoZWQgaXQgaXMgdXNlZCB0byBnZW5l cmF0ZSBhbmQNCnZlcmlmeSBzaWduYXR1cmVzIHVzaW5nIEdTU19HZXRNSUMgYW5kIEdTU19WZXJp ZnlNSUMgQVBJcy4gVGhlc2UNCnNpZ25hdHVyZXMgYXJlIGV4Y2hhbmdlZCBieSB0aGUgQ2xpZW50 IGFuZCBTZXJ2ZXIgYXMgYSBwYXJ0IG9mIHRoZSBUU0lHDQpyZWNvcmRzIGV4Y2hhbmdlZCBpbiBE TlMgbWVzc2FnZXMgc2VudCBiZXR3ZWVuIHRoZSBDbGllbnQgYW5kIFNlcnZlciwNCmFzIGRlc2Ny aWJlZCBpbiBbUkZDMjg0NV0uDQoNCg0KMy4gIENsaWVudCBQcm90b2NvbCBEZXRhaWxzDQoNCkEg dW5pcXVlIGNvbnRleHQgaXMgcmVxdWlyZWQgZm9yIGVhY2ggc2VydmVyIHRvIHdoaWNoIHRoZSBj bGllbnQgc2VuZHMNCnNlY3VyZSBtZXNzYWdlcy4gIEEgY29udGV4dCBpcyBpZGVudGlmaWVkIGJ5 IGEgY29udGV4dCBoYW5kbGUuIEENCmNsaWVudCBtYWludGFpbnMgYSBtYXBwaW5nIG9mIHNlcnZl cnMgdG8gaGFuZGxlcywNCg0KICAgICAodGFyZ2V0X25hbWUsIGtleV9uYW1lLCBjb250ZXh0X2hh bmRsZSkNCg0KVGhlIHZhbHVlIGtleV9uYW1lIGFsc28gaWRlbnRpZmllcyBhIGNvbnRleHQgaGFu ZGxlLiBUaGUga2V5X25hbWUgaXMNCnRoZSBvd25lciBuYW1lIG9mIHRoZSBUS0VZIGFuZCBUU0lH IHJlY29yZHMgc2VudCBiZXR3ZWVuIGEgY2xpZW50IGFuZCBhDQpzZXJ2ZXIgdG8gaW5kaWNhdGUg dG8gZWFjaCBvdGhlciB3aGljaCBjb250ZXh0IE1VU1QgYmUgdXNlZCB0byBwcm9jZXNzDQp0aGUg Y3VycmVudCByZXF1ZXN0Lg0KDQpETlMgY2xpZW50IGFuZCBzZXJ2ZXIgTUFZIHVzZSB2YXJpb3Vz IHVuZGVybHlpbmcgc2VjdXJpdHkgbWVjaGFuaXNtcyB0bw0KZXN0YWJsaXNoIHNlY3VyaXR5IGNv bnRleHQgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb25zIDMgYW5kIDQuIEF0IHRoZQ0Kc2FtZSB0aW1l LCBpbiBvcmRlciB0byBndWFyYW50ZWUgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIEROUyBjbGll bnRzDQphbmQgc2VydmVycyB0aGF0IHN1cHBvcnQgR1NTLVRTSUcgaXQgaXMgUkVRVUlSRUQgdGhh dCBzZWN1cml0eQ0KbWVjaGFuaXNtIHVzZWQgYnkgY2xpZW50IGVuYWJsZXMgdXNlIG9mIEtlcmJl cm9zIHY1IChzZWUgU2VjdGlvbiA5DQpmb3IgbW9yZSBpbmZvcm1hdGlvbikuDQoNCg0KMy4xICBO ZWdvdGlhdGluZyBDb250ZXh0DQoNCkluIEdTUywgZXN0YWJsaXNoaW5nIGEgc2VjdXJpdHkgY29u dGV4dCBpbnZvbHZlcyB0aGUgcGFzc2luZyBvZiBvcGFxdWUNCnRva2VucyBiZXR3ZWVuIHRoZSBj bGllbnQgYW5kIHRoZSBzZXJ2ZXIuICBUaGUgY2xpZW50IGdlbmVyYXRlcyB0aGUNCmluaXRpYWwg dG9rZW4gYW5kIHNlbmRzIGl0IHRvIHRoZSBzZXJ2ZXIuICBUaGUgc2VydmVyIHByb2Nlc3NlcyB0 aGUNCnRva2VuIGFuZCBpZiBuZWNlc3NhcnksIHJldHVybnMgYSBzdWJzZXF1ZW50IHRva2VuIHRv IHRoZSBjbGllbnQuICBUaGUNCmNsaWVudCBwcm9jZXNzZXMgdGhpcyB0b2tlbiwgYW5kIHNvIG9u LCB1bnRpbCB0aGUgbmVnb3RpYXRpb24gaXMNCmNvbXBsZXRlLiAgVGhlIG51bWJlciBvZiB0aW1l cyB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgZXhjaGFuZ2UgdG9rZW5zDQoNCkV4cGlyZXMgSnVseSAz MCwgMjAwMiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0N Cg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgR1NTLVRTSUcgICAgICAgICAgICAg SmFudWFyeSAzMCwgMjAwMg0KDQpkZXBlbmRzIG9uIHRoZSB1bmRlcmx5aW5nIHNlY3VyaXR5IG1l Y2hhbmlzbS4gIEEgY29tcGxldGVkIG5lZ290aWF0aW9uDQpyZXN1bHRzIGluIGEgY29udGV4dCBo YW5kbGUuDQoNClRoZSBUS0VZIHJlc291cmNlIHJlY29yZCBbUkZDMjkzMF0gaXMgdXNlZCBhcyB0 aGUgdmVoaWNsZSB0byB0cmFuc2Zlcg0KdG9rZW5zIGJldHdlZW4gY2xpZW50IGFuZCBzZXJ2ZXIu ICBUaGUgVEtFWSByZWNvcmQgaXMgYSBnZW5lcmFsDQptZWNoYW5pc20gZm9yIGVzdGFibGlzaGlu ZyBzZWNyZXQga2V5cyBmb3IgdXNlIHdpdGggVFNJRy4gIEZvciBtb3JlDQppbmZvcm1hdGlvbiwg c2VlIFtSRkMyOTMwXS4NCg0KDQozLjEuMSBDYWxsIEdTU19Jbml0X3NlY19jb250ZXh0DQoNClRv IG9idGFpbiB0aGUgZmlyc3QgdG9rZW4gdG8gYmUgc2VudCB0byBhIHNlcnZlciwgYSBjbGllbnQg TVVTVCBjYWxsDQpHU1NfSW5pdF9zZWNfY29udGV4dCBBUEkuDQpUaGUgZm9sbG93aW5nIGlucHV0 IHBhcmFtZXRlcnMgTVVTVCBiZSB1c2VkLiBUaGUgb3V0Y29tZSBvZiB0aGUgY2FsbCBpcw0KaW5k aWNhdGVkIHdpdGggdGhlIG91dHB1dCB2YWx1ZXMgYmVsb3cuICBDb25zdWx0IFNlY3Rpb25zIDIu Mi4xDQoiR1NTX0luaXRfc2VjX2NvbnRleHQgY2FsbCIgb2YgW1JGQzI3NDNdIGZvciBzeW50YXgg ZGVmaW5pdGlvbnMuDQoNCiAgIElOUFVUUw0KICAgICBDUkVERU5USUFMIEhBTkRMRSBjbGFpbWFu dF9jcmVkX2hhbmRsZSA9IE5VTEwgKE5VTEwgc3BlY2lmaWVzICJ1c2UNCiAgICAgICAgIGRlZmF1 bHQiKS4gQ2xpZW50IE1BWSBpbnN0ZWFkIHNwZWNpZnkgc29tZSBvdGhlciB2YWxpZCBoYW5kbGUN CiAgICAgICAgIHRvIGl0cyBjcmVkZW50aWFscy4NCiAgICAgQ09OVEVYVCBIQU5ETEUgaW5wdXRf Y29udGV4dF9oYW5kbGUgID0gMA0KICAgICBJTlRFUk5BTCBOQU1FICB0YXJnX25hbWUgICAgICAg ICAgICAgPSAiRE5TQDx0YXJnZXRfc2VydmVyX25hbWU+Ig0KICAgICBPQkpFQ1QgSURFTlRJRklF UiBtZWNoX3R5cGUgICAgICAgICAgPSBVbmRlcmx5aW5nIHNlY3VyaXR5DQogICAgICAgICBtZWNo YW5pc20gY2hvc2VuIGJ5IGltcGxlbWVudGVycy4gVG8gZ3VhcmFudGVlDQogICAgICAgICBpbnRl cm9wZXJhYmlsaXR5IG9mIHRoZSBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIEdTUy1UU0lHDQogICAg ICAgICBtZWNoYW5pc20gY2xpZW50IE1VU1Qgc3BlY2lmeSBhIHZhbGlkIHVuZGVybHlpbmcgc2Vj dXJpdHkNCiAgICAgICAgIG1lY2hhbmlzbSB0aGF0IGVuYWJsZXMgdXNlIG9mIEtlcmJlcm9zIHY1 IChzZWUgU2VjdGlvbiA5IGZvcg0KICAgICAgICAgbW9yZSBpbmZvcm1hdGlvbikuDQogICAgIE9D VEVUIFNUUklORyAgIGlucHV0X3Rva2VuICAgICAgICAgICA9IE5VTEwNCiAgICAgQk9PTEVBTiAg ICAgICAgcmVwbGF5X2RldF9yZXFfZmxhZyAgID0gVFJVRQ0KICAgICBCT09MRUFOICAgICAgICBt dXR1YWxfcmVxX2ZsYWcgICAgICAgPSBUUlVFDQogICAgIEJPT0xFQU4gICAgICAgIGRlbGVnX3Jl cV9mbGFnICAgICAgICA9IFRSVUUNCiAgICAgQk9PTEVBTiAgICAgICAgc2VxdWVuY2VfcmVxX2Zs YWcgICAgID0gVFJVRQ0KICAgICBCT09MRUFOICAgICAgICBhbm9uX3JlcV9mbGFnICAgICAgICAg PSBGQUxTRQ0KICAgICBCT09MRUFOICAgICAgICBpbnRlZ19yZXFfZmxhZyAgICAgICAgPSBUUlVF DQogICAgIElOVEVHRVIgICAgICAgIGxpZmV0aW1lX3JlcSAgICAgICAgICA9IDAgKDAgcmVxdWVz dHMgYSBkZWZhdWx0DQogICAgICAgICB2YWx1ZSkuIENsaWVudCBNQVkgaW5zdGVhZCBzcGVjaWZ5 IGFub3RoZXIgdXBwZXIgYm91bmQgZm9yIHRoZQ0KICAgICAgICAgbGlmZXRpbWUgb2YgdGhlIGNv bnRleHQgdG8gYmUgZXN0YWJsaXNoZWQgaW4gc2Vjb25kcy4NCiAgICAgT0NURVQgU1RSSU5HICAg Y2hhbl9iaW5kaW5ncyAgICAgICAgID0gQW55IHZhbGlkIGNoYW5uZWwgYmluZGluZ3MNCiAgICAg ICAgIGFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDEuMS42ICJDaGFubmVsIEJpbmRpbmdzIiBpbiBb UkZDMjc0M10NCg0KICAgT1VUUFVUUw0KICAgICBJTlRFR0VSICAgICAgICBtYWpvcl9zdGF0dXMN CiAgICAgQ09OVEVYVCBIQU5ETEUgb3V0cHV0X2NvbnRleHRfaGFuZGxlDQogICAgIE9DVEVUIFNU UklORyAgIG91dHB1dF90b2tlbg0KICAgICBCT09MRUFOICAgICAgICByZXBsYXlfZGV0X3N0YXRl DQogICAgIEJPT0xFQU4gICAgICAgIG11dHVhbF9zdGF0ZQ0KICAgICBJTlRFR0VSICAgICAgICBt aW5vcl9zdGF0dXMNCiAgICAgT0JKRUNUIElERU5USUZJRVIgbWVjaF90eXBlDQogICAgIEJPT0xF QU4gICAgICAgIGRlbGVnX3N0YXRlDQogICAgIEJPT0xFQU4gICAgICAgIHNlcXVlbmNlX3N0YXRl DQogICAgIEJPT0xFQU4gICAgICAgIGFub25fc3RhdGUNCg0KRXhwaXJlcyBKdWx5IDMwLCAyMDAy ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDQpJTlRF Uk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICBHU1MtVFNJRyAgICAgICAgICAgICBKYW51YXJ5 IDMwLCAyMDAyDQoNCiAgICAgQk9PTEVBTiAgICAgICAgdHJhbnNfc3RhdGUNCiAgICAgQk9PTEVB TiAgICAgICAgcHJvdF9yZWFkeV9zdGF0ZQ0KICAgICBCT09MRUFOICAgICAgICBjb25mX2F2YWls DQogICAgIEJPT0xFQU4gICAgICAgIGludGVnX2F2YWlsDQogICAgIElOVEVHRVIgICAgICAgIGxp ZmV0aW1lX3JlYw0KDQpJZiByZXR1cm5lZCBtYWpvcl9zdGF0dXMgaXMgc2V0IHRvIG9uZSBvZiB0 aGUgZm9sbG93aW5nIGVycm9ycw0KDQogICAgIEdTU19TX0RFRkVDVElWRV9UT0tFTg0KICAgICBH U1NfU19ERUZFQ1RJVkVfQ1JFREVOVElBTA0KICAgICBHU1NfU19CQURfU0lHIChHU1NfU19CQURf TUlDKQ0KICAgICBHU1NfU19OT19DUkVEDQogICAgIEdTU19TX0NSRURFTlRJQUxTX0VYUElSRUQN CiAgICAgR1NTX1NfQkFEX0JJTkRJTkdTDQogICAgIEdTU19TX09MRF9UT0tFTg0KICAgICBHU1Nf U19EVVBMSUNBVEVfVE9LRU4NCiAgICAgR1NTX1NfTk9fQ09OVEVYVA0KICAgICBHU1NfU19CQURf TkFNRVRZUEUNCiAgICAgR1NTX1NfQkFEX05BTUUNCiAgICAgR1NTX1NfQkFEX01FQ0gNCiAgICAg R1NTX1NfRkFJTFVSRQ0KDQp0aGVuIHRoZSB0aGUgY2xpZW50IE1VU1QgYWJhbmRvbiB0aGUgYWxn b3JpdGhtIGFuZCBNVVNUIE5PVCB1c2UgdGhlDQpHU1MtVFNJRyBhbGdvcml0aG0gdG8gZXN0YWJs aXNoIHRoaXMgc2VjdXJpdHkgY29udGV4LiBUaGlzIGRvY3VtZW50DQpkb2VzIG5vdCBwcmVzY3Jp YmUgd2hpY2ggb3RoZXIgbWVjaGFuaXNtIGNvdWxkIGJlIHVzZWQgdG8gZXN0YWJsaXNoDQphIHNl Y3VyaXR5IGNvbnRleHQuIE5leHQgdGltZSB3aGVuIHRoaXMgY2xpZW50IG5lZWRzIHRvIGVzdGFi bGlzaA0Kc2VjdXJpdHkgY29udGV4dCwgdGhlIGNsaWVudCBNQVkgdXNlIEdTUy1UU0lHIGFsZ29y aXRobS4NCg0KU3VjY2VzcyB2YWx1ZXMgb2YgbWFqb3Jfc3RhdHVzIGFyZSBHU1NfU19DT05USU5V RV9ORUVERUQgYW5kDQpHU1NfU19DT01QTEVURS4gVGhlIGV4YWN0IHN1Y2Nlc3MgY29kZSBpcyBp bXBvcnRhbnQgZHVyaW5nIGxhdGVyDQpwcm9jZXNzaW5nLg0KDQpUaGUgdmFsdWVzIG9mIHJlcGxh eV9kZXRfc3RhdGUgYW5kIG11dHVhbF9zdGF0ZSBpbmRpY2F0ZSBpZiB0aGUNCnNlY3VyaXR5IHBh Y2thZ2UgcHJvdmlkZXMgcmVwbGF5IGRldGVjdGlvbiBhbmQgbXV0dWFsIGF1dGhlbnRpY2F0aW9u LA0KcmVzcGVjdGl2ZWx5LiBJZiByZXR1cm5lZCBtYWpvcl9zdGF0dXMgaXMgR1NTX1NfQ09NUExF VEUgQU5EIG9uZSBvciBib3RoDQpvZiB0aGVzZSB2YWx1ZXMgYXJlIEZBTFNFLCB0aGUgY2xpZW50 IE1VU1QgYWJhbmRvbiB0aGlzIGFsZ29yaXRobS4NCg0KQ2xpZW50J3MgYmVoYXZpb3IgTUFZIGRl cGVuZCBvbiBvdGhlciBPVVRQVVQgcGFyYW1ldGVycyBhY2NvcmRpbmcNCnRvIHRoZSBwb2xpY3kg bG9jYWwgdG8gdGhlIGNsaWVudC4NCg0KVGhlIGhhbmRsZSBvdXRwdXRfY29udGV4dF9oYW5kbGUg aXMgdW5pcXVlIHRvIHRoaXMgbmVnb3RpYXRpb24gYW5kDQppcyBzdG9yZWQgaW4gdGhlIGNsaWVu dCdzIG1hcHBpbmcgdGFibGUgYXMgdGhlIGNvbnRleHRfaGFuZGxlIHRoYXQNCm1hcHMgdG8gdGFy Z2V0X25hbWUuDQoNCg0KDQozLjEuMiBTZW5kIFRLRVkgUXVlcnkgdG8gU2VydmVyDQoNCkFuIG9w YXF1ZSBvdXRwdXRfdG9rZW4gcmV0dXJuZWQgYnkgR1NTX0luaXRfc2VjX2NvbnRleHQgaXMgdHJh bnNtaXR0ZWQNCnRvIHRoZSBzZXJ2ZXIgaW4gYSBxdWVyeSByZXF1ZXN0IHdpdGggUVRZUEU9VEtF WS4gIFRoZSB0b2tlbiBpdHNlbGYNCndpbGwgYmUgcGxhY2VkIGluIGEgS2V5IERhdGEgZmllbGQg b2YgdGhlIFJEQVRBIGZpZWxkIGluIHRoZSBUS0VZDQpyZXNvdXJjZSByZWNvcmQgaW4gdGhlIGFk ZGl0aW9uYWwgcmVjb3JkcyBzZWN0aW9uIG9mIHRoZSBxdWVyeS4gVGhlDQpvd25lciBuYW1lIG9m IHRoZSBUS0VZIHJlc291cmNlIHJlY29yZCBzZXQgcXVlcmllZCBmb3IgYW5kIHRoZSBvd25lcg0K DQpFeHBpcmVzIEp1bHkgMzAsIDIwMDIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDZdDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgIEdTUy1U U0lHICAgICAgICAgICAgIEphbnVhcnkgMzAsIDIwMDINCg0KbmFtZSBvZiB0aGUgc3VwcGxpZWQg VEtFWSByZXNvdXJjZSByZWNvcmQgaW4gdGhlIGFkZGl0aW9uYWwgcmVjb3Jkcw0Kc2VjdGlvbiBN VVNUIGJlIHRoZSBzYW1lLiBUaGlzIG5hbWUgdW5pcXVlbHkgaWRlbnRpZmllcyB0aGUgc2VjdXJp dHkNCmNvbnRleHQgdG8gYm90aCB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIsIGFuZCB0aHVzIHRoZSBj bGllbnQgU0hPVUxEIHVzZQ0KYSB2YWx1ZSB3aGljaCBpcyBnbG9iYWxseSB1bmlxdWUgYXMgZGVz Y3JpYmVkIGluIFtSRkMyOTMwXS4gVG8gYWNoaWV2ZQ0KZ2xvYmFsIHVuaXF1ZW5lc3MsIHRoZSBu YW1lIE1BWSBjb250YWluIGEgVVVJRC9HVUlEIFtJU08xMTU3OF0uDQoNCiAgIFRLRVkgUmVjb3Jk DQogICAgIE5BTUUgPSBjbGllbnQtZ2VuZXJhdGVkIGdsb2JhbGx5IHVuaXF1ZSBkb21haW4gbmFt ZSBzdHJpbmcNCiAgICAgICAgICAgIChhcyBkZXNjcmliZWQgaW4gW1JGQzI5MzBdKQ0KICAgICBS REFUQQ0KICAgICAgICBBbGdvcml0aG0gTmFtZSAgICAgID0gZ3NzLXRzaWcNCiAgICAgICAgTW9k ZSAgICAgICAgICAgICAgICA9IDMgKEdTUy1BUEkgbmVnb3RpYXRpb24gLSBwZXIgW1JGQzI5MzBd KQ0KICAgICAgICBLZXkgU2l6ZSAgICAgICAgICAgID0gc2l6ZSBvZiBvdXRwdXRfdG9rZW4gaW4g b2N0ZXRzDQogICAgICAgIEtleSBEYXRhICAgICAgICAgICAgPSBvdXRwdXRfdG9rZW4NCg0KVGhl IHJlbWFpbmluZyBmaWVsZHMgaW4gdGhlIFRLRVkgUkRBVEEsIGkuZS4gSW5jZXB0aW9uLCBFeHBp cmF0aW9uLA0KRXJyb3IsIE90aGVyIFNpemUgYW5kIERhdGEgRmllbGRzLCBNVVNUIGJlIHNldCBh Y2NvcmRpbmcgdG8gW1JGQzI5MzBdLg0KDQpUaGUgcXVlcnkgaXMgdHJhbnNtaXR0ZWQgdG8gdGhl IHNlcnZlci4NCg0KTm90ZTogaWYgdGhlIG9yaWdpbmFsIGNsaWVudCBjYWxsIHRvIEdTU19Jbml0 X3NlY19jb250ZXh0IHJldHVybmVkIGFueQ0KbWFqb3Jfc3RhdHVzIG90aGVyIHRoYW4gR1NTX1Nf Q09OVElOVUVfTkVFREVEIG9yIEdTU19TX0NPTVBMRVRFLCB0aGVuDQp0aGUgY2xpZW50IE1VU1Qg Tk9UIHNlbmQgVEtFWSBxdWVyeS4gQ2xpZW50J3MgYmVoYXZpb3IgaW4gdGhpcyBjYXNlIGlzDQpk ZXNjcmliZWQgYWJvdmUgaW4gU2VjdGlvbiAzLjEuMS4NCg0KDQozLjEuMyBSZWNlaXZlIFRLRVkg UXVlcnktUmVzcG9uc2UgZnJvbSBTZXJ2ZXINCg0KVXBvbiB0aGUgcmVjZXB0aW9uIG9mIHRoZSBU S0VZIHF1ZXJ5IEROUyBzZXJ2ZXIgTVVTVCByZXNwb25kIGFjY29yZGluZw0KdG8gdGhlIGRlc2Ny aXB0aW9uIGluIFNlY3Rpb24gNC4gVGhpcyBTZWN0aW9uIHNwZWNpZmllcyB0aGUgYmVoYXZpb3IN Cm9mIHRoZSBjbGllbnQgYWZ0ZXIgaXQgcmVjZWl2ZXMgdGhlIG1hdGNoaW5nIHJlc3BvbnNlIHRv IGl0cyBxdWVyeS4NCg0KVGhlIG5leHQgcHJvY2Vzc2luZyBzdGVwIGRlcGVuZHMgb24gdGhlIHZh bHVlIG9mIG1ham9yX3N0YXR1cyBmcm9tIHRoZQ0KbW9zdCByZWNlbnQgY2FsbCB0aGF0IGNsaWVu dCBwZXJmb3JtZWQgdG8gR1NTX0luaXRfc2VjX2NvbnRleHQ6IGVpdGhlcg0KR1NTX1NfQ09NUExF VEUgb3IgR1NTX1NfQ09OVElOVUUuDQoNCg0KDQozLjEuMy4xIFZhbHVlIG9mIG1ham9yX3N0YXR1 cyA9PSBHU1NfU19DT01QTEVURQ0KDQpJZiB0aGUgbGFzdCBjYWxsIHRvIEdTU19Jbml0X3NlY19j b250ZXh0IHlpZWxkZWQgYSBtYWpvcl9zdGF0dXMgdmFsdWUNCm9mIEdTU19TX0NPTVBMRVRFIGFu ZCBhIG5vbi1OVUxMIG91dHB1dF90b2tlbiB3YXMgc2VudCB0byB0aGUgc2VydmVyLA0KdGhlbiB0 aGUgY2xpZW50IHNpZGUgY29tcG9uZW50IG9mIHRoZSBuZWdvdGlhdGlvbiBpcyBjb21wbGV0ZSBh bmQgdGhlDQpjbGllbnQgaXMgYXdhaXRpbmcgY29uZmlybWF0aW9uIGZyb20gdGhlIHNlcnZlci4N Cg0KQ29uZmlybWF0aW9uIGlzIGluIHRoZSBmb3JtIG9mIGEgcXVlcnkgcmVzcG9uc2Ugd2l0aCBS Q09ERT1OT0VSUk9SDQphbmQgd2l0aCB0aGUgbGFzdCBjbGllbnQgc3VwcGxpZWQgVEtFWSByZWNv cmQgaW4gdGhlIGFuc3dlciBzZWN0aW9uDQpvZiB0aGUgcXVlcnkuICBUaGUgcmVzcG9uc2UgTVVT VCBiZSBzaWduZWQgd2l0aCBhIFRTSUcgcmVjb3JkLiBUaGUNCnNpZ25hdHVyZSBpbiB0aGUgVFNJ RyByZWNvcmQgTVVTVCBiZSB2ZXJpZmllZCB1c2luZyB0aGUgcHJvY2VkdXJlDQpkZXRhaWxlZCBp biBzZWN0aW9uIDUsIFNlbmRpbmcgYW5kIFZlcmlmeWluZyBTaWduZWQgTWVzc2FnZXMuIElmIHRo ZQ0KcmVzcG9uc2UgaXMgbm90IHNpZ25lZCwgT1IgaWYgdGhlIHJlc3BvbnNlIGlzIHNpZ25lZCBi dXQgc2lnbmF0dXJlIGlzDQppbnZhbGlkLCB0aGVuIGFuIGF0dGFja2VyIGhhcyB0YW1wZXJlZCB3 aXRoIHRoZSBtZXNzYWdlIGluIHRyYW5zaXQgb3INCmhhcyBhdHRlbXB0ZWQgdG8gc2VuZCB0aGUg Y2xpZW50IGEgZmFsc2UgcmVzcG9uc2UuIEluIHRoaXMgY2FzZSB0aGUNCg0KRXhwaXJlcyBKdWx5 IDMwLCAyMDAyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA3 XQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICBHU1MtVFNJRyAgICAgICAgICAg ICBKYW51YXJ5IDMwLCAyMDAyDQoNCg0KY2xpZW50IE1BWSBjb250aW51ZSB3YWl0aW5nIGZvciBh IHJlc3BvbnNlIHRvIGl0cyBsYXN0IFRLRVkgcXVlcnkgdW50aWwNCnRoZSB0aW1lIHBlcmlvZCBz aW5jZSB0aGUgY2xpZW50IHNlbnQgbGFzdCBUS0VZIHF1ZXJ5IGV4cGlyZXMuIFN1Y2ggYQ0KdGlt ZSBwZXJpb2QgaXMgc3BlY2lmaWVkIGJ5IHRoZSBwb2xpY3kgbG9jYWwgdG8gdGhlIGNsaWVudC4g VGhpcyBpcyBhDQpuZXcgb3B0aW9uIHRoYXQgYWxsb3dzIEROUyBjbGllbnQgdG8gYWNjZXB0IG11 bHRpcGxlIGFuc3dlcnMgZm9yIG9uZQ0KcXVlcnkgSUQgYW5kIHNlbGVjdCBvbmUgKG5vdCBuZWNl c3NhcmlseSB0aGUgZmlyc3Qgb25lKSBiYXNlZCBvbiBzb21lDQpjcml0ZXJpYS4NCg0KSWYgdGhl IHNpZ25hdHVyZSBpcyB2ZXJpZmllZCAgdGhlIGNvbnRleHQgc3RhdGUgaXMgYWR2YW5jZWQgdG8g Q29udGV4dA0KRXN0YWJsaXNoZWQuICBQcm9jZWVkIHRvIHNlY3Rpb24gMy4yIGZvciB1c2FnZSBv ZiB0aGUgc2VjdXJpdHkgY29udGV4dC4NCg0KDQozLjEuMy4yIFZhbHVlIG9mIG1ham9yX3N0YXR1 cyA9PSBHU1NfU19DT05USU5VRQ0KDQpJZiB0aGUgbGFzdCBjYWxsIHRvIEdTU19Jbml0X3NlY19j b250ZXh0IHlpZWxkZWQgYSBtYWpvcl9zdGF0dXMgdmFsdWUNCm9mIEdTU19TX0NPTlRJTlVFLCB0 aGVuIHRoZSBuZWdvdGlhdGlvbiBpcyBub3QgeWV0IGNvbXBsZXRlLiBUaGUgc2VydmVyDQp3aWxs IHJldHVybiB0byB0aGUgY2xpZW50IGEgcXVlcnktcmVzcG9uc2Ugd2l0aCBhIFRLRVkgcmVjb3Jk IGluIHRoZQ0KQW5zd2VyIHNlY3Rpb24uIElmIHRoZSBETlMgbWVzc2FnZSBlcnJvciBpcyBub3Qg Tk9fRVJST1Igb3IgZXJyb3IgZmllbGQNCmluIHRoZSBUS0VZIHJlY29yZCBpcyBub3QgMCAoaS5l LiBubyBlcnJvciksIHRoZW4gdGhlIGNsaWVudCBNVVNUDQphYmFuZG9uIHRoaXMgbmVnb3RpYXRp b24gc2VxdWVuY2UuIFRoZSBjbGllbnQgTVVTVCBkZWxldGUgYW4gYWN0aXZlDQpjb250ZXh0IGJ5 IGNhbGxpbmcgR1NTX0RlbGV0ZV9zZWNfY29udGV4dCBwcm92aWRpbmcgdGhlIGFzc29jaWF0ZWQN CmNvbnRleHRfaGFuZGxlLiBUaGUgY2xpZW50IE1BWSByZXBlYXQgdGhlIG5lZ290aWF0aW9uIHNl cXVlbmNlIHN0YXJ0aW5nDQp3aXRoIHRoZSB1bmluaXRpYWxpemVkIHN0YXRlIGFzIGRlc2NyaWJl ZCBpbiBzZWN0aW9uIDMuMS4gVG8gcHJldmVudA0KaW5maW5pdGUgbG9vcGluZyB0aGUgbnVtYmVy IG9mIGF0dGVtcHRzIHRvIGVzdGFibGlzaCBhIHNlY3VyaXR5IGNvbnRleHQNCk1VU1QgYmUgbGlt aXRlZCB0byB0ZW4gb3IgbGVzcy4NCg0KSWYgdGhlIEROUyBtZXNzYWdlIGVycm9yIGlzIE5PX0VS Uk9SIGFuZCBlcnJvciBmaWxlZCBpbiB0aGUgVEtFWSByZWNvcmQNCmlzIDAgKGkuZS4gbm8gZXJy b3IpLCB0aGVuIHRoZSBjbGllbnQgTVVTVCBwYXNzIGEgdG9rZW4gc3BlY2lmaWVkIGluIHRoZQ0K S2V5IERhdGEgZmllbGQgaW4gdGhlIFRLRVkgcmVzb3VyY2UgcmVjb3JkIHRvIEdTU19Jbml0X3Nl Y19jb250ZXh0DQp1c2luZyB0aGUgc2FtZSBwYXJhbWV0ZXJzIHZhbHVlcyBhcyBpbiBwcmV2aW91 cyBjYWxsIGV4Y2VwdCB2YWx1ZXMgZm9yDQpDT05URVhUIEhBTkRMRSBpbnB1dF9jb250ZXh0X2hh bmRsZSBhbmQgT0NURVQgU1RSSU5HIGlucHV0X3Rva2VuIGFzDQpkZXNjcmliZWQgYmVsb3c6DQoN CiAgIElOUFVUUw0KICAgICBDT05URVhUIEhBTkRMRSBpbnB1dF9jb250ZXh0X2hhbmRsZSAgPSBj b250ZXh0X2hhbmRsZSAodGhpcyBpcyB0aGUNCiAgICAgICAgICBjb250ZXh0X2hhbmRsZSBjb3Jy ZXNwb25kaW5nIHRvIHRoZSBrZXlfbmFtZSB3aGljaCBpcyB0aGUNCiAgICAgICAgICBvd25lciBu YW1lIG9mIHRoZSBUS0VZIHJlY29yZCBpbiB0aGUgYW5zd2VyIHNlY3Rpb24gaW4gdGhlDQogICAg ICAgICAgVEtFWSBxdWVyeSByZXNwb25zZSkNCiAgICAgT0NURVQgU1RSSU5HICAgaW5wdXRfdG9r ZW4gICAgICAgICAgID0gdG9rZW4gZnJvbSBLZXkgZmllbGQgb2YNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgVEtFWSByZWNvcmQNCg0KRGVwZW5kaW5nIG9uIHRo ZSBmb2xsb3dpbmcgT1VUUFVUIHZhbHVlcyBvZiBHU1NfSW5pdF9zZWNfY29udGV4dA0KICAgICBJ TlRFR0VSICAgICAgICBtYWpvcl9zdGF0dXMNCiAgICAgT0NURVQgU1RSSU5HICAgb3V0cHV0X3Rv a2VuDQp0aGUgY2xpZW50IE1VU1QgdGFrZSBvbmUgb2YgdGhlIGZvbGxvd2luZyBhY3Rpb25zOg0K DQpJZiBPVVRQVVQgbWFqb3Jfc3RhdHVzIGlzIHNldCB0byBvbmUgb2YgdGhlIGZvbGxvd2luZyB2 YWx1ZXMNCiAgICAgR1NTX1NfREVGRUNUSVZFX1RPS0VODQogICAgIEdTU19TX0RFRkVDVElWRV9D UkVERU5USUFMDQogICAgIEdTU19TX0JBRF9TSUcgKEdTU19TX0JBRF9NSUMpDQogICAgIEdTU19T X05PX0NSRUQNCiAgICAgR1NTX1NfQ1JFREVOVElBTFNfRVhQSVJFRA0KICAgICBHU1NfU19CQURf QklORElOR1MNCg0KRXhwaXJlcyBKdWx5IDMwLCAyMDAyICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAg ICAgICBHU1MtVFNJRyAgICAgICAgICAgICBKYW51YXJ5IDMwLCAyMDAyDQoNCiAgICAgR1NTX1Nf T0xEX1RPS0VODQogICAgIEdTU19TX0RVUExJQ0FURV9UT0tFTg0KICAgICBHU1NfU19OT19DT05U RVhUDQogICAgIEdTU19TX0JBRF9OQU1FVFlQRQ0KICAgICBHU1NfU19CQURfTkFNRQ0KICAgICBH U1NfU19CQURfTUVDSA0KICAgICBHU1NfU19GQUlMVVJFDQoNCnRoZSBjbGllbnQgTVVTVCBhYmFu ZG9uIHRoaXMgbmVnb3RpYXRpb24gc2VxdWVuY2UuIFRoaXMgbWVhbnMgdGhhdCB0aGUNCmNsaWVu dCBNVVNUIGRlbGV0ZSBhbiBhY3RpdmUgY29udGV4dCBieSBjYWxsaW5nIEdTU19EZWxldGVfc2Vj X2NvbnRleHQNCnByb3ZpZGluZyB0aGUgYXNzb2NpYXRlZCBjb250ZXh0X2hhbmRsZS4gVGhlIGNs aWVudCBNQVkgcmVwZWF0IHRoZQ0KbmVnb3RpYXRpb24gc2VxdWVuY2Ugc3RhcnRpbmcgd2l0aCB0 aGUgdW5pbml0aWFsaXplZCBzdGF0ZSBhcyBkZXNjcmliZWQNCmluIHNlY3Rpb24gMy4xLiBUbyBw cmV2ZW50IGluZmluaXRlIGxvb3BpbmcgdGhlIG51bWJlciBvZiBhdHRlbXB0cyB0bw0KZXN0YWJs aXNoIGEgc2VjdXJpdHkgY29udGV4dCBNVVNUIGJlIGxpbWl0ZWQgdG8gdGVuIG9yIGxlc3MuDQoN CklmIE9VVFBVVCBtYWpvcl9zdGF0dXMgaXMgR1NTX1NfQ09OVElOVUVfTkVFREVEIE9SIEdTU19T X0NPTVBMRVRFIHRoZW4NCmNsaWVudCBNVVNUIGFjdCBhcyBkZXNjcmliZWQgYmVsb3cuDQoNCklm IHRoZSByZXNwb25zZSBmcm9tIHRoZSBzZXJ2ZXIgd2FzIHNpZ25lZCwgYW5kIHRoZSBPVVRQVVQg bWFqb3Jfc3RhdHVzDQppcyBHU1NfU19DT01QTEVURSx0aGVuIHRoZSBzaWduYXR1cmUgaW4gdGhl IFRTSUcgcmVjb3JkIE1VU1QgYmUgdmVyaWZpZWQNCnVzaW5nIHRoZSBwcm9jZWR1cmUgZGV0YWls ZWQgaW4gc2VjdGlvbiA1LCBTZW5kaW5nIGFuZCBWZXJpZnlpbmcgU2lnbmVkDQpNZXNzYWdlcy4g SWYgdGhlIHNpZ25hdHVyZSBpcyBpbnZhbGlkLCB0aGVuIHRoZSBjbGllbnQgTVVTVCBhYmFuZG9u IHRoaXMNCm5lZ290aWF0aW9uIHNlcXVlbmNlLiBUaGlzIG1lYW5zIHRoYXQgdGhlIGNsaWVudCBN VVNUIGRlbGV0ZSBhbiBhY3RpdmUNCmNvbnRleHQgYnkgY2FsbGluZyBHU1NfRGVsZXRlX3NlY19j b250ZXh0IHByb3ZpZGluZyB0aGUgYXNzb2NpYXRlZA0KY29udGV4dF9oYW5kbGUuIFRoZSBjbGll bnQgTUFZIHJlcGVhdCB0aGUgbmVnb3RpYXRpb24gc2VxdWVuY2Ugc3RhcnRpbmcNCndpdGggdGhl IHVuaW5pdGlhbGl6ZWQgc3RhdGUgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMy4xLiBUbyBwcmV2 ZW50DQppbmZpbml0ZSBsb29waW5nIHRoZSBudW1iZXIgb2YgYXR0ZW1wdHMgdG8gZXN0YWJsaXNo IGEgc2VjdXJpdHkgY29udGV4dA0KTVVTVCBiZSBsaW1pdGVkIHRvIHRlbiBvciBsZXNzLg0KDQpJ ZiBtYWpvcl9zdGF0dXMgaXMgR1NTX1NfQ09OVElOVUVfTkVFREVEIHRoZSBuZWdvdGlhdGlvbiBp cyBub3QgeWV0DQpmaW5pc2hlZC4gIFRoZSB0b2tlbiBvdXRwdXRfdG9rZW4gTVVTVCBiZSBwYXNz ZWQgdG8gdGhlIHNlcnZlciBpbiBhIFRLRVkNCnJlY29yZCBieSByZXBlYXRpbmcgdGhlIG5lZ290 aWF0aW9uIHNlcXVlbmNlIGJlZ2lubmluZyB3aXRoIHNlY3Rpb24NCjMuMS4yLiAgVGhlIGNsaWVu dCBNVVNUIHBsYWNlIGEgbGltaXQgb24gdGhlIG51bWJlciBvZiBjb250aW51YXRpb25zIGluDQph IGNvbnRleHQgbmVnb3RpYXRpb24gdG8gcHJldmVudCBlbmRsZXNzIGxvb3BpbmcuIFN1Y2ggbGlt aXQgU0hPVUxEIE5PVA0KZXhjZWVkIHZhbHVlIG9mIDEwLg0KDQpJZiBtYWpvcl9zdGF0dXMgaXMg R1NTX1NfQ09NUExFVEUgYW5kIG91dHB1dF90b2tlbiBpcyBub24tTlVMTCwgdGhlDQpjbGllbnQt c2lkZSBjb21wb25lbnQgb2YgdGhlIG5lZ290aWF0aW9uIGlzIGNvbXBsZXRlIGJ1dCB0aGUgdG9r ZW4NCm91dHB1dF90b2tlbiBNVVNUIGJlIHBhc3NlZCB0byB0aGUgc2VydmVyIGJ5IHJlcGVhdGlu ZyB0aGUgbmVnb3RpYXRpb24NCnNlcXVlbmNlIGJlZ2lubmluZyB3aXRoIHNlY3Rpb24gMy4xLjIu DQoNCklmIG1ham9yX3N0YXR1cyBpcyBHU1NfU19DT01QTEVURSBhbmQgb3V0cHV0X3Rva2VuIGlz IE5VTEwsIGNvbnRleHQNCm5lZ290aWF0aW9uIGlzIGNvbXBsZXRlLiAgVGhlIGNvbnRleHQgc3Rh dGUgaXMgYWR2YW5jZWQgdG8gQ29udGV4dA0KRXN0YWJsaXNoZWQuICBQcm9jZWVkIHRvIHNlY3Rp b24gMy4yIGZvciB1c2FnZSBvZiB0aGUgc2VjdXJpdHkgY29udGV4dC4NCg0KDQozLjIgIENvbnRl eHQgRXN0YWJsaXNoZWQNCg0KV2hlbiBjb250ZXh0IG5lZ290aWF0aW9uIGlzIGNvbXBsZXRlLCB0 aGUgaGFuZGxlIGNvbnRleHRfaGFuZGxlIE1VU1QgYmUNCnVzZWQgZm9yIHRoZSBnZW5lcmF0aW9u IGFuZCB2ZXJpZmljYXRpb24gb2YgdHJhbnNhY3Rpb24gc2lnbmF0dXJlcy4NCg0KVGhlIHByb2Nl ZHVyZXMgZm9yIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBzaWduZWQgbWVzc2FnZXMgYXJlIGRlc2Ny aWJlZA0KaW4gc2VjdGlvbiA1LCBTZW5kaW5nIGFuZCBWZXJpZnlpbmcgU2lnbmVkIE1lc3NhZ2Vz Lg0KDQpFeHBpcmVzIEp1bHkgMzAsIDIwMDIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDldDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgIEdT Uy1UU0lHICAgICAgICAgICAgIEphbnVhcnkgMzAsIDIwMDINCg0KDQozLjIuMSBUZXJtaW5hdGlu ZyBhIENvbnRleHQNCg0KV2hlbiB0aGUgY2xpZW50IGlzIG5vdCBpbnRlbmRlZCB0byBjb250aW51 ZSB1c2luZyB0aGUgZXN0YWJsaXNoZWQNCnNlY3VyaXR5IGNvbnRleHQsIHRoZSBjbGllbnQgU0hP VUxEIGRlbGV0ZSBhbiBhY3RpdmUgY29udGV4dCBieQ0KY2FsbGluZyBHU1NfRGVsZXRlX3NlY19j b250ZXh0IHByb3ZpZGluZyB0aGUgYXNzb2NpYXRlZCBjb250ZXh0X2hhbmRsZSwNCkFORCBjbGll bnQgU0hPVUxEIGRlbGV0ZSB0aGUgZXN0YWJsaXNoZWQgY29udGV4dCBvbiB0aGUgRE5TIHNlcnZl cg0KYnkgdXNpbmcgVEtFWSBSUiB3aXRoIHRoZSBNb2RlIGZpZWxkIHNldCB0byA1LCBpLmUuICJr ZXkgZGVsZXRpb24iDQpbUkZDMjkzMF0uDQoNCg0KDQo0LiAgU2VydmVyIFByb3RvY29sIERldGFp bHMNCg0KQXMgb24gdGhlIGNsaWVudC1zaWRlLCB0aGUgcmVzdWx0IG9mIGEgc3VjY2Vzc2Z1bCBj b250ZXh0IG5lZ290aWF0aW9uDQppcyBhIGNvbnRleHQgaGFuZGxlIHVzZWQgaW4gZnV0dXJlIGdl bmVyYXRpb24gYW5kIHZlcmlmaWNhdGlvbiBvZiB0aGUNCnRyYW5zYWN0aW9uIHNpZ25hdHVyZXMu DQoNCkEgc2VydmVyIE1BWSBiZSBtYW5hZ2luZyBzZXZlcmFsIGNvbnRleHRzIHdpdGggc2V2ZXJh bCBjbGllbnRzLg0KQ2xpZW50cyBpZGVudGlmeSB0aGVpciBjb250ZXh0cyBieSBwcm92aWRpbmcg YSBrZXkgbmFtZSBpbiB0aGVpcg0KcmVxdWVzdC4gIFRoZSBzZXJ2ZXIgbWFpbnRhaW5zIGEgbWFw cGluZyBvZiBrZXkgbmFtZXMgdG8gaGFuZGxlczoNCg0KICAgICAoa2V5X25hbWUsIGNvbnRleHRf aGFuZGxlKQ0KDQoNCg0KNC4xIE5lZ290aWF0aW5nIENvbnRleHQNCg0KQSBzZXJ2ZXIgTVVTVCBy ZWNvZ25pemUgVEtFWSBxdWVyaWVzIGFzIHNlY3VyaXR5IGNvbnRleHQgbmVnb3RpYXRpb24NCm1l c3NhZ2VzLg0KDQoNCjQuMS4xIFJlY2VpdmUgVEtFWSBRdWVyeSBmcm9tIENsaWVudA0KDQpVcG9u IHJlY2VpdmluZyBhIHF1ZXJ5IHdpdGggUVRZUEUgPSBUS0VZLCB0aGUgc2VydmVyIE1VU1QgZXhh bWluZQ0Kd2hldGhlciB0aGUgTW9kZSBhbmQgQWxnb3JpdGhtIE5hbWUgZmllbGRzIG9mIHRoZSBU S0VZIHJlY29yZCBpbiB0aGUNCmFkZGl0aW9uYWwgcmVjb3JkcyBzZWN0aW9uIG9mIHRoZSBtZXNz YWdlIGNvbnRhaW4gdmFsdWVzIG9mIDMgYW5kDQpnc3MtdHNpZywgcmVzcGVjdGl2ZWx5LiBJZiB0 aGV5IGRvLCB0aGVuIHRoZSAoa2V5X25hbWUsIGNvbnRleHRfaGFuZGxlKQ0KbWFwcGluZyB0YWJs ZSBpcyBzZWFyY2hlZCBmb3IgdGhlIGtleV9uYW1lIG1hdGNoaW5nIHRoZSBvd25lciBuYW1lIG9m DQp0aGUgVEtFWSByZWNvcmQgaW4gdGhlIGFkZGl0aW9uYWwgcmVjb3JkcyBzZWN0aW9uIG9mIHRo ZSBxdWVyeS4gSWYgdGhlDQpuYW1lIGlzIGZvdW5kIGluIHRoZSB0YWJsZSBhbmQgdGhlIHNlY3Vy aXR5IGNvbnRleHQgZm9yIHRoaXMgbmFtZSBpcw0KZXN0YWJsaXNoZWQgYW5kIG5vdCBleHBpcmVk LCB0aGVuIHRoZSBzZXJ2ZXIgTVVTVCByZXNwb25kIHRvIHRoZSBxdWVyeQ0Kd2l0aCBCQUROQU1F IGVycm9yIGluIHRoZSBUS0VZIGVycm9yIGZpZWxkLiAgSWYgdGhlIG5hbWUgaXMgZm91bmQgaW4g dGhlDQp0YWJsZSBhbmQgdGhlIHNlY3VyaXR5IGNvbnRleHQgaXMgbm90IGVzdGFibGlzaGVkLCB0 aGUgY29ycmVzcG9uZGluZw0KY29udGV4dF9oYW5kbGUgaXMgdXNlZCBpbiBzdWJzZXF1ZW50IEdT UyBvcGVyYXRpb25zLiBJZiB0aGUgbmFtZSBpcw0KZm91bmQgYnV0IHRoZSBzZWN1cml0eSBjb250 ZXh0IGlzIGV4cGlyZWQsIHRoZW4gdGhlIHNlcnZlciBkZWxldGVzIHRoaXMNCnNlY3VyaXR5IGNv bnRleHQsIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMi4xLCBhbmQgaW50ZXJwcmV0cyB0aGlz DQpxdWVyeSBhcyBhIHN0YXJ0IG9mIG5ldyBzZWN1cml0eSBjb250ZXh0IG5lZ290aWF0aW9uIGFu ZCBwZXJmb3Jtcw0Kb3BlcmF0aW9ucyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEuMiBhbmQgNC4x LjMuIElmIHRoZSBuYW1lIGlzIG5vdA0KZm91bmQsIHRoZW4gdGhlIHNlcnZlciBpbnRlcnByZXRz IHRoaXMgcXVlcnkgYXMgYSBzdGFydCBvZiBuZXcgc2VjdXJpdHkNCmNvbnRleHQgbmVnb3RpYXRp b24gYW5kIHBlcmZvcm1zIG9wZXJhdGlvbnMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4xLjINCmFu ZCA0LjEuMy4NCg0KDQpFeHBpcmVzIEp1bHkgMzAsIDIwMDIgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAg ICAgICAgIEdTUy1UU0lHICAgICAgICAgICAgIEphbnVhcnkgMzAsIDIwMDINCg0KDQo0LjEuMiBD YWxsIEdTU19BY2NlcHRfc2VjX2NvbnRleHQNCg0KVGhlIHNlcnZlciBwZXJmb3JtcyBpdHMgc2lk ZSBvZiBhIGNvbnRleHQgbmVnb3RpYXRpb24gYnkgY2FsbGluZw0KR1NTX0FjY2VwdF9zZWNfY29u dGV4dC4gVGhlIGZvbGxvd2luZyBpbnB1dCBwYXJhbWV0ZXJzIE1VU1QgYmUgdXNlZC4gVGhlDQpv dXRjb21lIG9mIHRoZSBjYWxsIGlzIGluZGljYXRlZCB3aXRoIHRoZSBvdXRwdXQgdmFsdWVzIGJl bG93LiAgQ29uc3VsdA0KU2VjdGlvbnMgMi4yLjIgIkdTU19BY2NlcHRfc2VjX2NvbnRleHQgY2Fs bCIgb2YgdGhlIFJGQyAyNzQzW1JGQzI3NDNdDQpmb3Igc3ludGF4IGRlZmluaXRpb25zLg0KDQog ICBJTlBVVFMNCiAgICAgQ09OVEVYVCBIQU5ETEUgaW5wdXRfY29udGV4dF9oYW5kbGUgID0gMCBp ZiBuZXcgbmVnb3RpYXRpb24sDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGNvbnRleHRfaGFuZGxlIG1hdGNoaW5nDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGtleV9uYW1lIGlmIG9uZ29pbmcgbmVnb3RpYXRpb24NCiAgICAgT0NU RVQgU1RSSU5HICAgaW5wdXRfdG9rZW4gICAgICAgICAgID0gdG9rZW4gc3BlY2lmaWVkIGluIHRo ZSBLZXkNCiAgICAgICAgICAgZmllbGQgZnJvbSBUS0VZIFJSIChmcm9tIEFkZGl0aW9uYWwgcmVj b3JkcyBTZWN0aW9uIG9mDQogICAgICAgICAgIHRoZSBjbGllbnQncyBxdWVyeSkNCiAgICAgQ1JF REVOVElBTCBIQU5ETEUgYWNjZXB0b3JfY3JlZF9oYW5kbGUgPSBOVUxMIChOVUxMIHNwZWNpZmll cyAidXNlDQogICAgICAgICAgIGRlZmF1bHQiKS4gU2VydmVyIE1BWSBpbnN0ZWFkIHNwZWNpZnkg c29tZSBvdGhlciB2YWxpZCBoYW5kbGUNCiAgICAgICAgICAgdG8gaXRzIGNyZWRlbnRpYWxzLg0K ICAgICBPQ1RFVCBTVFJJTkcgICBjaGFuX2JpbmRpbmdzICAgICAgICAgID0gQW55IHZhbGlkIGNo YW5uZWwgYmluZGluZ3MNCiAgICAgICAgICAgYXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gMS4xLjYg IkNoYW5uZWwgQmluZGluZ3MiIGluIFtSRkMyNzQzXQ0KDQogICBPVVRQVVRTDQogICAgIElOVEVH RVIgICAgICAgIG1ham9yX3N0YXR1cw0KICAgICBDT05URVhUX0hBTkRMRSBvdXRwdXRfY29udGV4 dF9oYW5kbGUNCiAgICAgT0NURVQgU1RSSU5HICAgb3V0cHV0X3Rva2VuDQogICAgIElOVEVHRVIg ICAgICAgIG1pbm9yX3N0YXR1cw0KICAgICBJTlRFUk5BTCBOQU1FICBzcmNfbmFtZQ0KICAgICBP QkpFQ1QgSURFTlRJRklFUiAgbWVjaF90eXBlDQogICAgIEJPT0xFQU4gICAgICAgIGRlbGVnX3N0 YXRlDQogICAgIEJPT0xFQU4gICAgICAgIG11dHVhbF9zdGF0ZQ0KICAgICBCT09MRUFOICAgICAg ICByZXBsYXlfZGV0X3N0YXRlDQogICAgIEJPT0xFQU4gICAgICAgIHNlcXVlbmNlX3N0YXRlDQog ICAgIEJPT0xFQU4gICAgICAgIGFub25fc3RhdGUNCiAgICAgQk9PTEVBTiAgICAgICAgdHJhbnNf c3RhdGUNCiAgICAgQk9PTEVBTiAgICAgICAgcHJvdF9yZWFkeV9zdGF0ZQ0KICAgICBCT09MRUFO ICAgICAgICBjb25mX2F2YWlsDQogICAgIEJPT0xFQU4gICAgICAgIGludGVnX2F2YWlsDQogICAg IElOVEVHRVIgICAgICAgIGxpZmV0aW1lX3JlYw0KICAgICBDT05URVhUX0hBTkRMRSBkZWxlZ2F0 ZWRfY3JlZF9oYW5kbGUNCg0KSWYgdGhpcyBpcyB0aGUgZmlyc3QgY2FsbCB0byBHU1NfQWNjZXB0 X3NlY19jb250ZXh0IGluIGEgbmV3DQpuZWdvdGlhdGlvbiwgdGhlbiBvdXRwdXRfY29udGV4dF9o YW5kbGUgaXMgc3RvcmVkIGluIHRoZSBzZXJ2ZXIncw0Ka2V5LW1hcHBpbmcgdGFibGUgYXMgdGhl IGNvbnRleHRfaGFuZGxlIHRoYXQgbWFwcyB0byB0aGUgbmFtZSBvZiB0aGUNClRLRVkgcmVjb3Jk Lg0KDQoNCjQuMS4zIFNlbmQgVEtFWSBRdWVyeS1SZXNwb25zZSB0byBDbGllbnQNCg0KVGhlIHNl cnZlciBNVVNUIHJlc3BvbmQgdG8gdGhlIGNsaWVudCB3aXRoIGEgVEtFWSBxdWVyeSByZXNwb25z ZSB3aXRoDQpSQ09ERSA9IE5PRVJST1IsIHRoYXQgY29udGFpbnMgYSBUS0VZIHJlY29yZCBpbiB0 aGUgYW5zd2VyIHNlY3Rpb24uDQoNCg0KDQpFeHBpcmVzIEp1bHkgMzAsIDIwMDIgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDQpJTlRFUk5FVC1EUkFG VCAgICAgICAgICAgICAgICAgICBHU1MtVFNJRyAgICAgICAgICAgICAgSmFudWFyeSAzMCwgMjAw Mg0KDQpJZiBPVVRQVVQgbWFqb3Jfc3RhdHVzIGlzIG9uZSBvZiB0aGUgZm9sbG93aW5nIGVycm9y cyB0aGUgZXJyb3IgZmllbGQNCmluIHRoZSBUS0VZIHJlY29yZCBzZXQgdG8gQkFES0VZLg0KDQog ICAgIEdTU19TX0RFRkVDVElWRV9UT0tFTg0KICAgICBHU1NfU19ERUZFQ1RJVkVfQ1JFREVOVElB TA0KICAgICBHU1NfU19CQURfU0lHIChHU1NfU19CQURfTUlDKQ0KICAgICBHU1NfU19EVVBMSUNB VEVfVE9LRU4NCiAgICAgR1NTX1NfT0xEX1RPS0VODQogICAgIEdTU19TX05PX0NSRUQNCiAgICAg R1NTX1NfQ1JFREVOVElBTFNfRVhQSVJFRA0KICAgICBHU1NfU19CQURfQklORElOR1MNCiAgICAg R1NTX1NfTk9fQ09OVEVYVA0KICAgICBHU1NfU19CQURfTUVDSA0KICAgICBHU1NfU19GQUlMVVJF DQoNCklmIE9VVFBVVCBtYWpvcl9zdGF0dXMgaXMgc2V0IHRvICBHU1NfU19DT01QTEVURSBvcg0K R1NTX1NfQ09OVElOVUVfTkVFREVEIHRoZW4gc2VydmVyIE1VU1QgYWN0IGFzIGRlc2NyaWJlZCBi ZWxvdy4NCg0KSWYgbWFqb3Jfc3RhdHVzIGlzIEdTU19TX0NPTVBMRVRFIHRoZSBzZXJ2ZXIgY29t cG9uZW50IG9mIHRoZQ0KbmVnb3RpYXRpb24gaXMgZmluaXNoZWQuIElmIG91dHB1dF90b2tlbiBp cyBub24tTlVMTCwgdGhlbiBpdCBNVVNUIGJlDQpyZXR1cm5lZCB0byB0aGUgY2xpZW50IGluIGEg S2V5IERhdGEgZmllbGQgb2YgdGhlIFJEQVRBIGluIFRLRVkuIFRoZQ0KZXJyb3IgZmllbGQgaW4g dGhlIFRLRVkgcmVjb3JkIGlzIHNldCB0byBOT0VSUk9SLiBUaGUgbWVzc2FnZSBNVVNUIGJlDQpz aWduZWQgd2l0aCBhIFRTSUcgcmVjb3JkIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDUsIFNlbmRp bmcgYW5kDQpWZXJpZnlpbmcgU2lnbmVkIE1lc3NhZ2VzLiBUaGUgY29udGV4dCBzdGF0ZSBpcyBh ZHZhbmNlZCB0byBDb250ZXh0DQpFc3RhYmxpc2hlZC4gU2VjdGlvbiA0LjIgZGlzY3Vzc2VzIHRo ZSB1c2FnZSBvZiB0aGUgc2VjdXJpdHkgY29udGV4dC4NCg0KSWYgbWFqb3Jfc3RhdHVzIGlzIEdT U19TX0NPTVBMRVRFIGFuZCBvdXRwdXRfdG9rZW4gaXMgTlVMTCwgdGhlbiB0aGUNClRLRVkgcmVj b3JkIHJlY2VpdmVkIGZyb20gdGhlIGNsaWVudCBNVVNUIGJlIHJldHVybmVkIGluIHRoZSBBbnN3 ZXINCnNlY3Rpb24gb2YgdGhlIHJlc3BvbnNlLiBUaGUgbWVzc2FnZSBNVVNUIGJlIHNpZ25lZCB3 aXRoIGEgVFNJRyByZWNvcmQNCmFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDUsIFNlbmRpbmcgYW5k IFZlcmlmeWluZyBTaWduZWQgTWVzc2FnZXMuIFRoZQ0KY29udGV4dCBzdGF0ZSBpcyBhZHZhbmNl ZCB0byBDb250ZXh0IEVzdGFibGlzaGVkLiBTZWN0aW9uIDQuMiBkaXNjdXNzZXMNCnRoZSB1c2Fn ZSBvZiB0aGUgc2VjdXJpdHkgY29udGV4dC4NCg0KSWYgbWFqb3Jfc3RhdHVzIGlzIEdTU19TX0NP TlRJTlVFLCB0aGUgc2VydmVyIGNvbXBvbmVudCBvZiB0aGUNCm5lZ290aWF0aW9uIGlzIG5vdCB5 ZXQgZmluaXNoZWQuICBUaGUgc2VydmVyIHJlc3BvbmRzIHRvIHRoZSBUS0VZDQpxdWVyeSB3aXRo IGEgc3RhbmRhcmQgcXVlcnkgcmVzcG9uc2UsIHBsYWNpbmcgaW4gdGhlIGFuc3dlciBzZWN0aW9u IGENClRLRVkgcmVjb3JkIGNvbnRhaW5pbmcgb3V0cHV0X3Rva2VuIGluIHRoZSBLZXkgRGF0YSBS REFUQSBmaWVsZC4gVGhlDQplcnJvciBmaWVsZCBpbiB0aGUgVEtFWSByZWNvcmQgaXMgc2V0IHRv IE5PRVJST1IuIFRoZSBzZXJ2ZXIgTVVTVCBsaW1pdA0KdGhlIG51bWJlciBvZiB0aW1lcyB0aGF0 IGEgZ2l2ZW4gY29udGV4dCBpcyBhbGxvd2VkIHRvIHJlcGVhdCwgdG8NCnByZXZlbnQgZW5kbGVz cyBsb29waW5nLiBTdWNoIGxpbWl0IFNIT1VMRCBOT1QgZXhjZWVkIHZhbHVlIG9mIDEwLg0KDQpJ biBhbGwgY2FzZXMgZXhjZXB0IGlmIG1ham9yX3N0YXR1cyBpcyBHU1NfU19DT01QTEVURSBhbmQg b3V0cHV0X3Rva2VuDQppcyBOVUxMIG90aGVyIFRLRVkgcmVjb3JkIGZpZWxkcyBNVVNUIGNvbnRh aW4gdGhlIGZvbGxvd2luZyB2YWx1ZXM6DQogICAgIE5BTUUgPSBrZXlfbmFtZQ0KICAgICBSREFU QQ0KICAgICAgICBBbGdvcml0aG0gTmFtZSAgICAgID0gZ3NzLXRzaWcNCiAgICAgICAgTW9kZSAg ICAgICAgICAgICAgICA9IDMgKEdTUy1BUEkgbmVnb3RpYXRpb24gLSBwZXIgW1JGQzI5MzBdKQ0K ICAgICAgICBLZXkgU2l6ZSAgICAgICAgICAgID0gc2l6ZSBvZiBvdXRwdXRfdG9rZW4gaW4gb2N0 ZXRzDQoNClRoZSByZW1haW5pbmcgZmllbGRzIGluIHRoZSBUS0VZIFJEQVRBLCBpLmUuIEluY2Vw dGlvbiwgRXhwaXJhdGlvbiwNCkVycm9yLCBPdGhlciBTaXplIGFuZCBEYXRhIEZpZWxkcywgTVVT VCBiZSBzZXQgYWNjb3JkaW5nIHRvIFtSRkMyOTMwXS4NCg0KDQoNCkV4cGlyZXMgSnVseSAzMCwg MjAwMiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoN CklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgIEdTUy1UU0lHICAgICAgICAgICAgICBK YW51YXJ5IDMwLCAyMDAyDQoNCg0KDQo0LjIgQ29udGV4dCBFc3RhYmxpc2hlZA0KDQpXaGVuIGNv bnRleHQgbmVnb3RpYXRpb24gaXMgY29tcGxldGUsIHRoZSBoYW5kbGUgY29udGV4dF9oYW5kbGUN CmlzIHVzZWQgZm9yIHRoZSBnZW5lcmF0aW9uIGFuZCB2ZXJpZmljYXRpb24gb2YgdHJhbnNhY3Rp b24gc2lnbmF0dXJlcy4NClRoZSBoYW5kbGUgaXMgdmFsaWQgZm9yIGEgZmluaXRlIGFtb3VudCBv ZiB0aW1lIGRldGVybWluZWQgYnkgdGhlDQp1bmRlcmx5aW5nIHNlY3VyaXR5IG1lY2hhbmlzbS4g QSBzZXJ2ZXIgTUFZIHVuaWxhdGVyYWxseSB0ZXJtaW5hdGUNCmEgY29udGV4dCBhdCBhbnkgdGlt ZSAoc2VlIHNlY3Rpb24gNC4yLjEpLg0KDQpTZXJ2ZXIgU0hPVUxEIGxpbWl0IHRoZSBhbW91bnQg b2YgbWVtb3J5IHVzZWQgdG8gY2FjaGUgZXN0YWJsaXNoZWQNCmNvbnRleHRzLg0KDQpUaGUgcHJv Y2VkdXJlcyBmb3Igc2VuZGluZyBhbmQgcmVjZWl2aW5nIHNpZ25lZCBtZXNzYWdlcyBhcmUgZ2l2 ZW4gaW4NCnNlY3Rpb24gNSwgU2VuZGluZyBhbmQgVmVyaWZ5aW5nIFNpZ25lZCBNZXNzYWdlcy4N Cg0KDQo0LjIuMSBUZXJtaW5hdGluZyBhIENvbnRleHQNCg0KQSBzZXJ2ZXIgY2FuIHRlcm1pbmF0 ZSBhbnkgZXN0YWJsaXNoZWQgY29udGV4dCBhdCBhbnkgdGltZS4gIFRoZQ0Kc2VydmVyIE1BWSBo aW50IHRvIHRoZSBjbGllbnQgdGhhdCB0aGUgY29udGV4dCBpcyBiZWluZyBkZWxldGVkIGJ5DQpp bmNsdWRpbmcgYSBUS0VZIFJSIGluIGEgcmVzcG9uc2Ugd2l0aCB0aGUgTW9kZSBmaWVsZCBzZXQg dG8gNSwgaS5lLg0KImtleSBkZWxldGlvbiIgW1JGQzI5MzBdLg0KQW4gYWN0aXZlIGNvbnRleHQg aXMgZGVsZXRlZCBieSBjYWxsaW5nIEdTU19EZWxldGVfc2VjX2NvbnRleHQNCnByb3ZpZGluZyB0 aGUgYXNzb2NpYXRlZCBjb250ZXh0X2hhbmRsZS4NCg0KDQo1LiBTZW5kaW5nIGFuZCBWZXJpZnlp bmcgU2lnbmVkIE1lc3NhZ2VzDQoNCjUuMSBTZW5kaW5nIGEgU2lnbmVkIE1lc3NhZ2UgLSBDYWxs IEdTU19HZXRNSUMNCg0KVGhlIHByb2NlZHVyZSBmb3Igc2VuZGluZyBhIHNpZ25hdHVyZS1wcm90 ZWN0ZWQgbWVzc2FnZSBpcyBzcGVjaWZpZWQNCmluIFtSRkMyODQ1XS4gIFRoZSBkYXRhIHRvIGJl IHBhc3NlZCB0byB0aGUgc2lnbmF0dXJlIHJvdXRpbmUgaW5jbHVkZXMNCnRoZSB3aG9sZSBETlMg bWVzc2FnZSB3aXRoIHNwZWNpZmljIFRTSUcgdmFyaWFibGVzIGFwcGVuZGVkLiAgRm9yIHRoZQ0K ZXhhY3QgZm9ybWF0LCBzZWUgW1JGQzI4NDVdLiAgRm9yIHRoaXMgcHJvdG9jb2wsIHVzZSB0aGUg Zm9sbG93aW5nDQpUU0lHIHZhcmlhYmxlIHZhbHVlczoNCg0KICAgVFNJRyBSZWNvcmQNCiAgICAg TkFNRSA9IGtleV9uYW1lIHRoYXQgaWRlbnRpZmllcyB0aGlzIGNvbnRleHQNCiAgICAgUkRBVEEN CiAgICAgICAgQWxnb3JpdGhtIE5hbWUgPSBnc3MtdHNpZw0KDQpBc3NpZ24gdGhlIHJlbWFpbmlu ZyBmaWVsZHMgaW4gdGhlIFRTSUcgUkRBVEEgYXBwcm9wcmlhdGUgdmFsdWVzDQphcyBkZXNjcmli ZWQgaW4gW1JGQzI4NDVdLg0KDQpUaGUgc2lnbmF0dXJlIGlzIGdlbmVyYXRlZCBieSBjYWxsaW5n IEdTU19HZXRNSUMuIFRoZSBmb2xsb3dpbmcgaW5wdXQNCnBhcmFtZXRlcnMgTVVTVCBiZSB1c2Vk LiBUaGUgb3V0Y29tZSBvZiB0aGUgY2FsbCBpcyBpbmRpY2F0ZWQgd2l0aCB0aGUNCm91dHB1dCB2 YWx1ZXMgc3BlY2lmaWVkIGJlbG93LiAgQ29uc3VsdCBTZWN0aW9ucyAyLjMuMSAiR1NTX0dldE1J Qw0KY2FsbCIgb2YgdGhlIFJGQyAyNzQzW1JGQzI3NDNdIGZvciBzeW50YXggZGVmaW5pdGlvbnMu DQoNCg0KDQoNCg0KRXhwaXJlcyBKdWx5IDMwLCAyMDAyICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBbUGFnZSAxM10NCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAg ICAgICAgR1NTLVRTSUcgICAgICAgICAgICAgIEphbnVhcnkgMzAsIDIwMDINCg0KICAgSU5QVVRT DQogICAgIENPTlRFWFQgSEFORExFIGNvbnRleHRfaGFuZGxlID0gY29udGV4dF9oYW5kbGUgZm9y IGtleV9uYW1lDQogICAgIE9DVEVUIFNUUklORyAgIG1lc3NhZ2UgICAgICAgID0gb3V0Z29pbmcg bWVzc2FnZSBwbHVzIFRTSUcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2 YXJpYWJsZXMgKHBlciBbUkZDMjg0NV0pDQogICAgIElOVEVHRVIgcW9wX3JlcSAgICAgICAgICAg ICAgID0gMCAoMCByZXF1ZXN0cyBhIGRlZmF1bHQNCiAgICAgICAgIHZhbHVlKS4gQ2FsbGVyIE1B WSBpbnN0ZWFkIHNwZWNpZnkgb3RoZXIgdmFsaWQgdmFsdWUgKGZvcg0KICAgICAgICAgZGV0YWls cyBzZWUgU2VjdGlvbiAxLjIuNCBpbiBbUkZDMjc0M10pDQoNCiAgIE9VVFBVVFMNCiAgICAgSU5U RUdFUiAgICAgICAgbWFqb3Jfc3RhdHVzDQogICAgIElOVEVHRVIgICAgICAgIG1pbm9yX3N0YXR1 cw0KICAgICBPQ1RFVCBTVFJJTkcgICBwZXJfbXNnX3Rva2VuDQoNCklmIG1ham9yX3N0YXR1cyBp cyBHU1NfU19DT01QTEVURSwgdGhlbiBzaWduYXR1cmUgZ2VuZXJhdGlvbg0Kc3VjY2VlZGVkLiAg VGhlIHNpZ25hdHVyZSBpbiBwZXJfbXNnX3Rva2VuIGlzIGluc2VydGVkIGludG8gdGhlDQpTaWdu YXR1cmUgZmllbGQgb2YgdGhlIFRTSUcgUlIgYW5kIHRoZSBtZXNzYWdlIGlzIHRyYW5zbWl0dGVk Lg0KDQpJZiBtYWpvcl9zdGF0dXMgaXMgR1NTX1NfQ09OVEVYVF9FWFBJUkVELCBHU1NfU19DUkVE RU5USUFMU19FWFBJUkVEIG9yDQpHU1NfU19GQUlMVVJFIHRoZSBjYWxsZXIgTVVTVCBkZWxldGUg dGhlIHNlY3VyaXR5IGNvbnRleHQsIHJldHVybiB0byB0aGUNCnVuaW5pdGlhbGl6ZWQgc3RhdGUg YW5kIFNIT1VMRCBuZWdvdGlhdGUgYSBuZXcgc2VjdXJpdHkgY29udGV4dCwgYXMNCmRlc2NyaWJl ZCBhYm92ZSBpbiBTZWN0aW9uIDMuMQ0KDQpJZiBtYWpvcl9zdGF0dXMgaXMgR1NTX1NfTk9fQ09O VEVYVCwgdGhlIGNhbGxlciBNVVNUIHJlbW92ZSB0aGUgZW50cnkNCmZvciBrZXlfbmFtZSBmcm9t IHRoZSAodGFyZ2V0XyBuYW1lLCBrZXlfbmFtZSwgY29udGV4dF9oYW5kbGUpIG1hcHBpbmcNCnRh YmxlLCByZXR1cm4gdG8gdGhlIHVuaW5pdGlhbGl6ZWQgc3RhdGUgYW5kIFNIT1VMRCBuZWdvdGlh dGUgYSBuZXcNCnNlY3VyaXR5IGNvbnRleHQsIGFzIGRlc2NyaWJlZCBhYm92ZSBpbiBTZWN0aW9u IDMuMQ0KDQpJZiBtYWpvcl9zdGF0dXMgaXMgR1NTX1NfQkFEX1FPUCwgdGhlIGNhbGxlciBTSE9V TEQgcmVwZWF0IHRoZQ0KR1NTX0dldE1JQyBjYWxsIHdpdGggYWxsb3dlZCBRT1AgdmFsdWUuIFRo ZSBudW1iZXIgb2Ygc3VjaCByZXBldGl0aW9ucw0KTVVTVCBiZSBsaW1pdGVkIHRvIHByZXZlbnQg aW5maW5pdGUgbG9vcHMuDQoNCg0KNS4yIFZlcmlmeWluZyBhIFNpZ25lZCBNZXNzYWdlIC0gQ2Fs bCBHU1NfVmVyaWZ5TUlDDQoNClRoZSBwcm9jZWR1cmUgZm9yIHZlcmlmeWluZyBhIHNpZ25hdHVy ZS1wcm90ZWN0ZWQgbWVzc2FnZSBpcyBzcGVjaWZpZWQNCmluIFtSRkMyODQ1XS4NClRoZSBOQU1F IG9mIHRoZSBUU0lHIHJlY29yZCBkZXRlcm1pbmVzIHdoaWNoIGNvbnRleHRfaGFuZGxlIG1hcHMg dG8NCnRoZSBjb250ZXh0IHRoYXQgTVVTVCBiZSB1c2VkIHRvIHZlcmlmeSB0aGUgc2lnbmF0dXJl LiAgSWYgdGhlIE5BTUUNCmRvZXMgbm90IG1hcCB0byBhbiBlc3RhYmxpc2hlZCBjb250ZXh0LCB0 aGUgc2VydmVyIE1VU1Qgc2VuZCBhDQpzdGFuZGFyZCBUU0lHIGVycm9yIHJlc3BvbnNlIHRvIHRo ZSBjbGllbnQgaW5kaWNhdGluZyBCQURLRVkgaW4gdGhlDQpUU0lHIGVycm9yIGZpZWxkIChhcyBk ZXNjcmliZWQgaW4gW1JGQzI4NDVdKS4NCg0KRm9yIHRoZSBHU1MgYWxnb3JpdGhtLCBhIHNpZ25h dHVyZSBpcyB2ZXJpZmllZCBieSB1c2luZyBHU1NfVmVyaWZ5TUlDOg0KICAgSU5QVVRTDQogICAg IENPTlRFWFQgSEFORExFIGNvbnRleHRfaGFuZGxlID0gY29udGV4dF9oYW5kbGUgZm9yIGtleV9u YW1lDQogICAgIE9DVEVUIFNUUklORyAgIG1lc3NhZ2UgICAgICAgID0gaW5jb21pbmcgbWVzc2Fn ZSBwbHVzIFRTSUcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2YXJpYWJs ZXMgKHBlciBbUkZDMjg0NV0pDQogICAgIE9DVEVUIFNUUklORyAgIHBlcl9tc2dfdG9rZW4gID0g U2lnbmF0dXJlIGZpZWxkIGZyb20gVFNJRyBSUg0KDQogICBPVVRQVVRTDQogICAgIElOVEVHRVIg ICAgICAgIG1ham9yX3N0YXR1cw0KICAgICBJTlRFR0VSICAgICAgICBtaW5vcl9zdGF0dXMNCiAg ICAgSU5URUdFUiAgICAgICAgcW9wX3N0YXRlDQoNCkV4cGlyZXMgSnVseSAzMCwgMjAwMiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoNCklOVEVSTkVU LURSQUZUICAgICAgICAgICAgICAgICAgIEdTUy1UU0lHICAgICAgICAgICAgICBKYW51YXJ5IDMw LCAyMDAyDQoNCklmIG1ham9yX3N0YXR1cyBpcyBHU1NfU19DT01QTEVURSwgdGhlIHNpZ25hdHVy ZSBpcyBhdXRoZW50aWMgYW5kIHRoZQ0KbWVzc2FnZSB3YXMgZGVsaXZlcmVkIGludGFjdC4gIFBl ciBbUkZDMjg0NV0sIHRoZSB0aW1lciB2YWx1ZXMgb2YgdGhlDQpUU0lHIHJlY29yZCBNVVNUIGFs c28gYmUgdmFsaWQgYmVmb3JlIGNvbnNpZGVyaW5nIHRoZSBtZXNzYWdlIHRvIGJlDQphdXRoZW50 aWMuICBUaGUgY2FsbGVyIE1VU1Qgbm90IGFjdCBvbiB0aGUgcmVxdWVzdCBvciByZXNwb25zZSBp biB0aGUNCm1lc3NhZ2UgdW50aWwgdGhlc2UgY2hlY2tzIGFyZSB2ZXJpZmllZC4NCg0KV2hlbiBh IHNlcnZlciBpcyBwcm9jZXNzaW5nIGEgY2xpZW50IHJlcXVlc3QsDQp0aGUgc2VydmVyIE1VU1Qg c2VuZCBhIHN0YW5kYXJkIFRTSUcgZXJyb3IgcmVzcG9uc2UgdG8gdGhlIGNsaWVudA0KaW5kaWNh dGluZyBCQURLRVkgaW4gdGhlIFRTSUcgZXJyb3IgZmllbGQgYXMgZGVzY3JpYmVkIGluIFtSRkMy ODQ1XSwNCmlmIG1ham9yX3N0YXR1cyBpcyBzZXQgdG8gb25lIG9mIHRoZSBmb2xsb3dpbmcgdmFs dWVzDQogICAgIEdTU19TX0RFRkVDVElWRV9UT0tFTg0KICAgICBHU1NfU19CQURfU0lHIChHU1Nf U19CQURfTUlDKQ0KICAgICBHU1NfU19EVVBMSUNBVEVfVE9LRU4NCiAgICAgR1NTX1NfT0xEX1RP S0VODQogICAgIEdTU19TX1VOU0VRX1RPS0VODQogICAgIEdTU19TX0dBUF9UT0tFTg0KICAgICBH U1NfU19DT05URVhUX0VYUElSRUQNCiAgICAgR1NTX1NfTk9fQ09OVEVYVA0KICAgICBHU1NfU19G QUlMVVJFDQoNCg0KSWYgdGhlIHRpbWVyIHZhbHVlcyBvZiB0aGUgVFNJRyByZWNvcmQgYXJlIGlu dmFsaWQsIHRoZSBtZXNzYWdlIE1VU1QNCk5PVCBiZSBjb25zaWRlcmVkIGF1dGhlbnRpYy4gSWYg dGhpcyBlcnJvciBjaGVja2luZyBmYWlscyB3aGVuIGEgc2VydmVyDQppcyBwcm9jZXNzaW5nIGEg Y2xpZW50IHJlcXVlc3QsIHRoZSBhcHByb3ByaWF0ZSBlcnJvciByZXNwb25zZSBNVVNUIGJlDQpz ZW50IHRvIHRoZSBjbGllbnQgYWNjb3JkaW5nIHRvIFtSRkMyODQ1XS4NCg0KDQo2LiBFeGFtcGxl IHVzYWdlIG9mIEdTUy1UU0lHIGFsZ29yaXRobQ0KDQpUaGlzIFNlY3Rpb24gZGVzY3JpYmVzIGFu IGV4YW1wbGUgd2hlcmUgYSBDbGllbnQsIGNsaWVudC5leGFtcGxlLmNvbSwNCmFuZCBhIFNlcnZl ciwgc2VydmVyLmV4YW1wbGUuY29tLCBlc3RhYmxpc2ggYSBzZWN1cml0eSBjb250ZXh0IGFjY29y ZGluZw0KdG8gdGhlIGFsZ29yaXRobSBkZXNjcmliZWQgYWJvdmUuDQoNCg0KICBJLiBDbGllbnQg aW5pdGlhbGl6ZXMgc2VjdXJpdHkgY29udGV4dCBuZWdvdGlhdGlvbg0KICBUbyBlc3RhYmxpc2gg YSBzZWN1cml0eSBjb250ZXh0IHdpdGggYSBzZXJ2ZXIsIHNlcnZlci5leGFtcGxlLmNvbSwgdGhl DQogIENsaWVudCBjYWxscyBHU1NfSW5pdF9zZWNfY29udGV4dCB3aXRoIHRoZSBmb2xsb3dpbmcg cGFyYW1ldGVycw0KICAoTm90ZSB0aGF0IHNvbWUgSU5QVVQgYW5kIE9VVFBVVCBwYXJhbWV0ZXJz IG5vdCBjcml0aWNhbCBmb3IgdGhpcw0KICBhbGdvcml0aG0gYXJlIG5vdCBkZXNjcmliZWQgaW4g dGhpcyBleGFtcGxlKQ0KICAgICBDT05URVhUIEhBTkRMRSBpbnB1dF9jb250ZXh0X2hhbmRsZSAg PSAwDQogICAgIElOVEVSTkFMIE5BTUUgIHRhcmdfbmFtZSAgICAgICAgICAgICA9ICJETlNAc2Vy dmVyLmV4YW1wbGUuY29tIg0KICAgICBPQ1RFVCBTVFJJTkcgICBpbnB1dF90b2tlbiAgICAgICAg ICAgPSBOVUxMDQogICAgIEJPT0xFQU4gICAgICAgIHJlcGxheV9kZXRfcmVxX2ZsYWcgICA9IFRS VUUNCiAgICAgQk9PTEVBTiAgICAgICAgbXV0dWFsX3JlcV9mbGFnICAgICAgID0gVFJVRQ0KDQog IFRoZSBPVVRQVVRTIHBhcmFtZXRlcnMgcmV0dXJuZWQgYnkgR1NTX0luaXRfc2VjX2NvbnRleHQg aW5jbHVkZQ0KICAgICBJTlRFR0VSICAgICAgICBtYWpvcl9zdGF0dXMgPSBHU1NfU19DT05USU5V RV9ORUVERUQNCiAgICAgQ09OVEVYVCBIQU5ETEUgb3V0cHV0X2NvbnRleHRfaGFuZGxlIGNvbnRl eHRfaGFuZGxlDQogICAgIE9DVEVUIFNUUklORyAgIG91dHB1dF90b2tlbiBvdXRwdXRfdG9rZW4N CiAgICAgQk9PTEVBTiAgICAgICAgcmVwbGF5X2RldF9zdGF0ZSA9IFRSVUUNCiAgICAgQk9PTEVB TiAgICAgICAgbXV0dWFsX3N0YXRlID0gVFJVRQ0KDQoNCg0KRXhwaXJlcyBKdWx5IDMwLCAyMDAy ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxNV0NCg0KSU5U RVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgR1NTLVRTSUcgICAgICAgICAgICAgIEphbnVh cnkgMzAsIDIwMDINCg0KICBDbGllbnQgdmVyaWZpZXMgdGhhdCByZXBsYXlfZGV0X3N0YXRlIGFu ZCBtdXR1YWxfc3RhdGUgdmFsdWVzIGFyZQ0KICBUUlVFLiBTaW5jZSB0aGUgbWFqb3Jfc3RhdHVz IGlzIEdTU19TX0NPTlRJTlVFX05FRURFRCwgd2hpY2ggaXMgYQ0KICBzdWNjZXNzIE9VVFBVVCBt YWpvcl9zdGF0dXMgdmFsdWUsIGNsaWVudCBzdG9yZXMgY29udGV4dF9oYW5kbGUgdGhhdA0KICBt YXBzIHRvICJETlNAc2VydmVyLmV4YW1wbGUuY29tIiBhbmQgcHJvY2VlZHMgdG8gdGhlIG5leHQg c3RlcC4NCg0KDQogIElJLiBDbGllbnQgc2VuZHMgYSBxdWVyeSB3aXRoIFFUWVBFID0gVEtFWSB0 byBzZXJ2ZXINCiAgQ2xpZW50IHNlbmRzIGEgcXVlcnkgd2l0aCBRVFlQRSA9IFRLRVkgZm9yIGEg Y2xpZW50LWdlbmVyYXRlZCBnbG9iYWxseQ0KICB1bmlxdWUgZG9tYWluIG5hbWUgc3RyaW5nLCA3 ODkuY2xpZW50LmV4YW1wbGUuY29tLnNlcnZlci5leGFtcGxlLmNvbS4NCiAgUXVlcnkgY29udGFp bnMgYSBUS0VZIHJlY29yZCBpbiBpdHMgQWRkaXRpb25hbCByZWNvcmRzIHNlY3Rpb24gd2l0aA0K ICB0aGUgZm9sbG93aW5nIGZpZWxkcyAoTm90ZSB0aGF0IHNvbWUgZmllbGRzIG5vdCBzcGVjaWZp YyB0byB0aGlzDQogIGFsZ29yaXRobSBhcmUgbm90IHNwZWNpZmllZCkNCg0KICAgICBOQU1FID0g Nzg5LmNsaWVudC5leGFtcGxlLmNvbS5zZXJ2ZXIuZXhhbXBsZS5jb20uDQogICAgIFJEQVRBDQog ICAgICAgIEFsZ29yaXRobSBOYW1lICAgICAgPSBnc3MtdHNpZw0KICAgICAgICBNb2RlICAgICAg ICAgICAgICAgID0gMyAoR1NTLUFQSSBuZWdvdGlhdGlvbiAtIHBlciBbUkZDMjkzMF0pDQogICAg ICAgIEtleSBTaXplICAgICAgICAgICAgPSBzaXplIG9mIG91dHB1dF90b2tlbiBpbiBvY3RldHMN CiAgICAgICAgS2V5IERhdGEgICAgICAgICAgICA9IG91dHB1dF90b2tlbg0KDQogIEFmdGVyIHRo ZSBrZXlfbmFtZSA3ODkuY2xpZW50LmV4YW1wbGUuY29tLnNlcnZlci5leGFtcGxlLmNvbS4NCiAg aXMgZ2VuZXJhdGVkIGl0IGlzIHN0b3JlZCBpbiB0aGUgY2xpZW50J3MgKHRhcmdldF9uYW1lLCBr ZXlfbmFtZSwNCiAgY29udGV4dF9oYW5kbGUpIG1hcHBpbmcgdGFibGUuDQoNCg0KICBJSUkuIFNl cnZlciByZWNlaXZlcyBhIHF1ZXJ5IHdpdGggUVRZUEUgPSBUS0VZDQogIFdoZW4gc2VydmVyIHJl Y2VpdmVzIGEgcXVlcnkgd2l0aCBRVFlQRSA9IFRLRVksIHRoZSBzZXJ2ZXIgdmVyaWZpZXMNCiAg dGhhdCBNb2RlIGFuZCBBbGdvcml0aG0gZmllbGRzIGluIHRoZSBUS0VZIHJlY29yZCBpbiB0aGUg QWRkaXRpb25hbA0KICByZWNvcmRzIHNlY3Rpb24gb2YgdGhlIHF1ZXJ5IGFyZSBzZXQgdG8gMyBh bmQgImdzcy10c2lnIiByZXNwZWN0aXZlbHkuDQogIEl0IGZpbmRzIHRoYXQgdGhlIGtleV9uYW1l IDc4OS5jbGllbnQuZXhhbXBsZS5jb20uc2VydmVyLmV4YW1wbGUuY29tLg0KICBpcyBub3QgbGlz dGVkIGluIGl0cyAoa2V5X25hbWUsIGNvbnRleHRfaGFuZGxlKSBtYXBwaW5nIHRhYmxlLg0KDQoN CiAgSVYuIFNlcnZlciBjYWxscyBHU1NfQWNjZXB0X3NlY19jb250ZXh0DQogIFRvIGNvbnRpbnVl IHNlY3VyaXR5IGNvbnRleHQgbmVnb3RpYXRpb24gc2VydmVyIGNhbGxzDQogIEdTU19BY2NlcHRf c2VjX2NvbnRleHQgd2l0aCB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgKE5vdGUgdGhhdCBzb21l DQogIElOUFVUIGFuZCBPVVRQVVQgcGFyYW1ldGVycyBub3QgY3JpdGljYWwgZm9yIHRoaXMgYWxn b3JpdGhtIGFyZSBub3QNCiAgZGVzY3JpYmVkIGluIHRoaXMgZXhhbXBsZSkNCiAgIElOUFVUUw0K ICAgICBDT05URVhUIEhBTkRMRSBpbnB1dF9jb250ZXh0X2hhbmRsZSAgPSAwDQogICAgIE9DVEVU IFNUUklORyAgIGlucHV0X3Rva2VuICAgICAgICAgICA9IHRva2VuIHNwZWNpZmllZCBpbiB0aGUg S2V5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmaWVsZCBmcm9tIFRLRVkgUlIgKGZy b20gQWRkaXRpb25hbA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVjb3JkcyBzZWN0 aW9uIG9mIHRoZSBjbGllbnQncyBxdWVyeSkNCiAgVGhlIE9VVFBVVFMgcGFyYW1ldGVycyByZXR1 cm5lZCBieSBHU1NfQWNjZXB0X3NlY19jb250ZXh0IGluY2x1ZGUNCiAgICAgSU5URUdFUiAgICAg ICAgbWFqb3Jfc3RhdHVzID0gR1NTX1NfQ09OVElOVUVfTkVFREVEDQogICAgIENPTlRFWFRfSEFO RExFIG91dHB1dF9jb250ZXh0X2hhbmRsZSBjb250ZXh0X2hhbmRsZQ0KICAgICBPQ1RFVCBTVFJJ TkcgICBvdXRwdXRfdG9rZW4gb3V0cHV0X3Rva2VuDQoNCiAgU2VydmVyIHN0b3JlcyB0aGUgbWFw cGluZyBvZiB0aGUNCiAgNzg5LmNsaWVudC5leGFtcGxlLmNvbS5zZXJ2ZXIuZXhhbXBsZS5jb20u IHRvIE9VVFBVVCBjb250ZXh0X2hhbmRsZQ0KICBpbiBpdHMgKGtleV9uYW1lLCBjb250ZXh0X2hh bmRsZSkgbWFwcGluZyB0YWJsZS4NCg0KDQoNCkV4cGlyZXMgSnVseSAzMCwgMjAwMiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoNCklOVEVSTkVULURS QUZUICAgICAgICAgICAgICAgICAgIEdTUy1UU0lHICAgICAgICAgICAgICBKYW51YXJ5IDMwLCAy MDAyDQoNCiAgVi4gU2VydmVyIHJlc3BvbmRzIHRvIHRoZSBUS0VZIHF1ZXJ5DQogIFNpbmNlIHRo ZSBtYWpvcl9zdGF0dXMgPSBHU1NfU19DT05USU5VRV9ORUVERUQgaW4gdGhlIGxhc3Qgc2VydmVy J3MNCiAgY2FsbCB0byBHU1NfQWNjZXB0X3NlY19jb250ZXh0LCB0aGUgc2VydmVyIHJlc3BvbmRz IHRvIHRoZSBUS0VZIHF1ZXJ5DQogIHBsYWNpbmcgaW4gdGhlIGFuc3dlciBzZWN0aW9uIGEgVEtF WSByZWNvcmQgY29udGFpbmluZyBvdXRwdXRfdG9rZW4gaW4NCiAgdGhlIEtleSBEYXRhIFJEQVRB IGZpZWxkLiBUaGUgZXJyb3IgZmllbGQgaW4gdGhlIFRLRVkgcmVjb3JkIGlzIHNldCB0bw0KICAw LiBUaGUgUkNPREUgaW4gdGhlIHF1ZXJ5IHJlc3BvbnNlIGlzIHNldCB0byBOT0VSUk9SLg0KDQoN CiAgVkkuIENsaWVudCBwcm9jZXNzZXMgdG9rZW4gcmV0dXJuZWQgYnkgc2VydmVyDQogIFdoZW4g dGhlIGNsaWVudCByZWNlaXZlcyB0aGUgVEtFWSBxdWVyeSByZXNwb25zZSBmcm9tIHRoZSBzZXJ2 ZXIsIHRoZQ0KICBjbGllbnQgY2FsbHMgR1NTX0luaXRfc2VjX2NvbnRleHQgd2l0aCB0aGUgZm9s bG93aW5nIHBhcmFtZXRlcnMgKE5vdGUNCiAgdGhhdCBzb21lIElOUFVUIGFuZCBPVVRQVVQgcGFy YW1ldGVycyBub3QgY3JpdGljYWwgZm9yIHRoaXMgYWxnb3JpdGhtDQogIGFyZSBub3QgZGVzY3Jp YmVkIGluIHRoaXMgZXhhbXBsZSkNCiAgICAgQ09OVEVYVCBIQU5ETEUgaW5wdXRfY29udGV4dF9o YW5kbGUgID0gdGhlIGNvbnRleHRfaGFuZGxlIHN0b3JlZA0KICAgICAgICAgIGluIHRoZSBjbGll bnQncyBtYXBwaW5nIHRhYmxlIGVudHJ5IChETlNAc2VydmVyLmV4YW1wbGUuY29tLiwNCiAgICAg ICAgICA3ODkuY2xpZW50LmV4YW1wbGUuY29tLnNlcnZlci5leGFtcGxlLmNvbS4sIGNvbnRleHRf aGFuZGxlKQ0KICAgICBJTlRFUk5BTCBOQU1FICB0YXJnX25hbWUgICAgICAgICAgICAgPSAiRE5T QHNlcnZlci5leGFtcGxlLmNvbSINCiAgICAgT0NURVQgU1RSSU5HICAgaW5wdXRfdG9rZW4gICAg ICAgICAgID0gdG9rZW4gZnJvbSBLZXkgZmllbGQgb2YgVEtFWQ0KICAgICAgICAgIHJlY29yZCBm cm9tIHRoZSBBbnN3ZXIgc2VjdGlvbiBvZiB0aGUgc2VydmVyJ3MgcmVzcG9uc2UNCiAgICAgQk9P TEVBTiAgICAgICAgcmVwbGF5X2RldF9yZXFfZmxhZyAgID0gVFJVRQ0KICAgICBCT09MRUFOICAg ICAgICBtdXR1YWxfcmVxX2ZsYWcgICAgICAgPSBUUlVFDQoNCg0KICBUaGUgT1VUUFVUUyBwYXJh bWV0ZXJzIHJldHVybmVkIGJ5IEdTU19Jbml0X3NlY19jb250ZXh0IGluY2x1ZGUNCiAgICAgSU5U RUdFUiAgICAgICAgbWFqb3Jfc3RhdHVzID0gR1NTX1NfQ09NUExFVEUNCiAgICAgQ09OVEVYVCBI QU5ETEUgb3V0cHV0X2NvbnRleHRfaGFuZGxlID0gY29udGV4dF9oYW5kbGUNCiAgICAgT0NURVQg U1RSSU5HICAgb3V0cHV0X3Rva2VuID0gb3V0cHV0X3Rva2VuDQogICAgIEJPT0xFQU4gICAgICAg IHJlcGxheV9kZXRfc3RhdGUgPSBUUlVFDQogICAgIEJPT0xFQU4gICAgICAgIG11dHVhbF9zdGF0 ZSA9IFRSVUUNCg0KICBTaW5jZSB0aGUgbWFqb3Jfc3RhdHVzIGlzIHNldCB0byBHU1NfU19DT01Q TEVURSB0aGUgY2xpZW50IHNpZGUNCiAgc2VjdXJpdHkgY29udGV4dCBpcyBlc3RhYmxpc2hlZCwg YnV0IHNpbmNlIHRoZSBvdXRwdXRfdG9rZW4gaXMgbm90DQogIE5VTEwgY2xpZW50IE1VU1Qgc2Vu ZCBhIFRLRVkgcXVlcnkgdG8gdGhlIHNlcnZlciBhcyBkZXNjcmliZWQgYmVsb3cuDQoNCg0KICBW SUkuIENsaWVudCBzZW5kcyBhIHF1ZXJ5IHdpdGggUVRZUEUgPSBUS0VZIHRvIHNlcnZlcg0KICBD bGllbnQgc2VuZHMgdG8gdGhlIHNlcnZlciBhIFRLRVkgcXVlcnkgZm9yIHRoZQ0KICA3ODkuY2xp ZW50LmV4YW1wbGUuY29tLnNlcnZlci5leGFtcGxlLmNvbS4gbmFtZS4gUXVlcnkgY29udGFpbnMg YSBUS0VZDQogIHJlY29yZCBpbiBpdHMgQWRkaXRpb25hbCByZWNvcmRzIHNlY3Rpb24gd2l0aCB0 aGUgZm9sbG93aW5nIGZpZWxkcw0KICAoTm90ZSB0aGF0IHNvbWUgSU5QVVQgYW5kIE9VVFBVVCBw YXJhbWV0ZXJzIG5vdCBjcml0aWNhbCB0byB0aGlzDQogIGFsZ29yaXRobSBhcmUgbm90IGRlc2Ny aWJlZCBpbiB0aGlzIGV4YW1wbGUpDQogICAgIE5BTUUgPSA3ODkuY2xpZW50LmV4YW1wbGUuY29t LnNlcnZlci5leGFtcGxlLmNvbS4NCiAgICAgUkRBVEENCiAgICAgICAgQWxnb3JpdGhtIE5hbWUg ICAgICA9IGdzcy10c2lnDQogICAgICAgIE1vZGUgICAgICAgICAgICAgICAgPSAzIChHU1MtQVBJ IG5lZ290aWF0aW9uIC0gcGVyIFtSRkMyOTMwXSkNCiAgICAgICAgS2V5IFNpemUgICAgICAgICAg ICA9IHNpemUgb2Ygb3V0cHV0X3Rva2VuIGluIG9jdGV0cw0KICAgICAgICBLZXkgRGF0YSAgICAg ICAgICAgID0gb3V0cHV0X3Rva2VuDQoNCg0KDQoNCg0KDQoNCkV4cGlyZXMgSnVseSAzMCwgMjAw MiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTddDQoNCklO VEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgIEdTUy1UU0lHICAgICAgICAgICAgICBKYW51 YXJ5IDMwLCAyMDAyDQoNCiAgVklJSS4gU2VydmVyIHJlY2VpdmVzIGEgVEtFWSBxdWVyeQ0KICBX aGVuIHRoZSBzZXJ2ZXIgcmVjZWl2ZXMgYSBUS0VZIHF1ZXJ5LCB0aGUgc2VydmVyIHZlcmlmaWVz IHRoYXQgTW9kZQ0KICBhbmQgQWxnb3JpdGhtIGZpZWxkcyBpbiB0aGUgVEtFWSByZWNvcmQgaW4g dGhlIEFkZGl0aW9uYWwgcmVjb3Jkcw0KICBzZWN0aW9uIG9mIHRoZSBxdWVyeSBhcmUgc2V0IHRv IDMgYW5kIGdzcy10c2lnLCByZXBlY3RpdmVseS4gSXQNCiAgZmluZHMgdGhhdCB0aGUga2V5X25h bWUgNzg5LmNsaWVudC5leGFtcGxlLmNvbS5zZXJ2ZXIuZXhhbXBsZS5jb20uIGlzDQogIGxpc3Rl ZCBpbiBpdHMgKGtleV9uYW1lLCBjb250ZXh0X2hhbmRsZSkgbWFwcGluZyB0YWJsZS4NCg0KDQog IElYLiBTZXJ2ZXIgY2FsbHMgR1NTX0FjY2VwdF9zZWNfY29udGV4dA0KICBUbyBjb250aW51ZSBz ZWN1cml0eSBjb250ZXh0IG5lZ290aWF0aW9uIHNlcnZlciBjYWxscw0KICBHU1NfQWNjZXB0X3Nl Y19jb250ZXh0IHdpdGggdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzIChOb3RlIHRoYXQgc29tZQ0K ICBJTlBVVCBhbmQgT1VUUFVUIHBhcmFtZXRlcnMgbm90IGNyaXRpY2FsIGZvciB0aGlzIGFsZ29y aXRobSBhcmUgbm90DQogIGRlc2NyaWJlZCBpbiB0aGlzIGV4YW1wbGUpDQogICBJTlBVVFMNCiAg ICAgQ09OVEVYVCBIQU5ETEUgaW5wdXRfY29udGV4dF9oYW5kbGUgID0gY29udGV4dF9oYW5kbGUg ZnJvbSB0aGUNCiAgICAgICAgICAgKDc4OS5jbGllbnQuZXhhbXBsZS5jb20uc2VydmVyLmV4YW1w bGUuY29tLiwgY29udGV4dF9oYW5kbGUpDQogICAgICAgICAgIGVudHJ5IGluIHRoZSBzZXJ2ZXIn cyBtYXBwaW5nIHRhYmxlDQogICAgIE9DVEVUIFNUUklORyAgIGlucHV0X3Rva2VuICAgICAgICAg ICA9IHRva2VuIHNwZWNpZmllZCBpbiB0aGUgS2V5DQogICAgICAgICAgIGZpZWxkIG9mIFRLRVkg UlIgKGZyb20gQWRkaXRpb25hbCByZWNvcmRzIFNlY3Rpb24gb2YNCiAgICAgICAgICAgdGhlIGNs aWVudCdzIHF1ZXJ5KQ0KDQogIFRoZSBPVVRQVVRTIHBhcmFtZXRlcnMgcmV0dXJuZWQgYnkgR1NT X0FjY2VwdF9zZWNfY29udGV4dCBpbmNsdWRlDQogICAgIElOVEVHRVIgICAgICAgIG1ham9yX3N0 YXR1cyA9IEdTU19TX0NPTVBMRVRFDQogICAgIENPTlRFWFRfSEFORExFIG91dHB1dF9jb250ZXh0 X2hhbmRsZSA9IGNvbnRleHRfaGFuZGxlDQogICAgIE9DVEVUIFNUUklORyAgIG91dHB1dF90b2tl biA9IE5VTEwNCg0KICBTaW5jZSBtYWpvcl9zdGF0dXMgPSBHU1NfU19DT01QTEVURSwgdGhlIHNl Y3VyaXR5IGNvbnRleHQgb24gdGhlDQogIHNlcnZlciBzaWRlIGlzIGVzdGFibGlzaGVkLCBidXQg dGhlIHNlcnZlciBzdGlsbCBuZWVkcyB0byByZXNwb25kIHRvDQogIHRoZSBjbGllbnQncyBUS0VZ IHF1ZXJ5LCBhcyBkZXNjcmliZWQgYmVsb3cuIFRoZSBzZWN1cml0eSBjb250ZXh0DQogIHN0YXRl IGlzIGFkdmFuY2VkIHRvIENvbnRleHQgRXN0YWJsaXNoZWQuDQoNCg0KICBYLiBTZXJ2ZXIgcmVz cG9uZHMgdG8gdGhlIFRLRVkgcXVlcnkNCiAgU2luY2UgdGhlIG1ham9yX3N0YXR1cyA9IEdTU19T X0NPTVBMRVRFIGluIHRoZSBsYXN0IHNlcnZlcidzIGNhbGwgdG8NCiAgR1NTX0FjY2VwdF9zZWNf Y29udGV4dCBhbmQgdGhlIG91dHB1dF90b2tlbiBpcyBOVUxMLCB0aGUgc2VydmVyDQogIHJlc3Bv bmRzIHRvIHRoZSBUS0VZIHF1ZXJ5IHBsYWNpbmcgaW4gdGhlIGFuc3dlciBzZWN0aW9uIGEgVEtF WSByZWNvcmQNCiAgdGhhdCB3YXMgc2VudCBieSB0aGUgY2xpZW50IGluIHRoZSBBZGRpdGlvbmFs IHJlY29yZHMgc2VjdGlvbiBvZiB0aGUNCiAgY2xpZW50J3MgbGF0ZXN0IFRLRVkgcXVlcnkuIElu IGFkZGl0aW9uIHRvIHRoaXMgc2VydmVyIHBsYWNlcyBhDQogIFRTSUcgcmVjb3JkIGluIGFkZGl0 aW9uYWwgcmVjb3JkcyBzZWN0aW9uIG9mIGl0cyByZXNwb25zZS4gU2VydmVyDQogIGNhbGxzIEdT U19HZXRNSUMgdG8gZ2VuZXJhdGUgYSBzaWduYXR1cmUgdG8gaW5jbHVkZSBpdCBpbiB0aGUgVFNJ Rw0KICByZWNvcmQuIFRoZSBzZXJ2ZXIgc3BlY2lmaWVzIHRoZSBmb2xsb3dpbmcgR1NTX0dldE1J QyBJTlBVVA0KICBwYXJhbWV0ZXJzOg0KICAgICBDT05URVhUIEhBTkRMRSBjb250ZXh0X2hhbmRs ZSA9IGNvbnRleHRfaGFuZGxlIGZyb20gdGhlDQogICAgICAgICAgICg3ODkuY2xpZW50LmV4YW1w bGUuY29tLnNlcnZlci5leGFtcGxlLmNvbS4sIGNvbnRleHRfaGFuZGxlKQ0KICAgICAgICAgICBl bnRyeSBpbiB0aGUgc2VydmVyJ3MgbWFwcGluZyB0YWJsZQ0KICAgICBPQ1RFVCBTVFJJTkcgICBt ZXNzYWdlICAgICAgICA9IG91dGdvaW5nIG1lc3NhZ2UgcGx1cyBUU0lHDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHZhcmlhYmxlcyAoYXMgZGVzY3JpYmVkIGluIFtSRkMyODQ1 XSkNCg0KICBUaGUgT1VUUFVUUyBwYXJhbWV0ZXJzIHJldHVybmVkIGJ5IEdTU19HZXRNSUMgaW5j bHVkZQ0KICAgICBJTlRFR0VSICAgICAgICBtYWpvcl9zdGF0dXMgPSBHU1NfU19DT01QTEVURQ0K ICAgICBPQ1RFVCBTVFJJTkcgICBwZXJfbXNnX3Rva2VuDQoNCiAgU2lnbmF0dXJlIGZpZWxkIGlu IHRoZSBUU0lHIHJlY29yZCBpcyBzZXQgdG8gcGVyX21zZ190b2tlbi4NCg0KRXhwaXJlcyBKdWx5 IDMwLCAyMDAyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAx OF0NCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgR1NTLVRTSUcgICAgICAgICAg ICAgIEphbnVhcnkgMzAsIDIwMDINCg0KDQogIFhJLiBDbGllbnQgcHJvY2Vzc2VzIHRva2VuIHJl dHVybmVkIGJ5IHNlcnZlcg0KICBDbGllbnQgcmVjZWl2ZXMgdGhlIFRLRVkgcXVlcnkgcmVzcG9u c2UgZnJvbSB0aGUgc2VydmVyLiBTaW5jZSB0aGUNCiAgbWFqb3Jfc3RhdHVzIHdhcyBHU1NfU19D T01QTEVURSBpbiB0aGUgbGFzdCBjbGllbnQncyBjYWxsIHRvDQogIEdTU19Jbml0X3NlY19jb250 ZXh0LCB0aGUgY2xpZW50IHZlcmlmaWVzIHRoYXQgdGhlIHNlcnZlcidzIHJlc3BvbnNlDQogIGlz IHNpZ25lZC4gVG8gdmFsaWRhdGUgdGhlIHNpZ25hdHVyZSBjbGllbnQgY2FsbHMgR1NTX1Zlcmlm eU1JQyB3aXRoDQogIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVyczoNCg0KICAgSU5QVVRTDQogICAg IENPTlRFWFQgSEFORExFIGNvbnRleHRfaGFuZGxlID0gY29udGV4dF9oYW5kbGUgZm9yDQogICAg ICAgICAgICAgICAgICA3ODkuY2xpZW50LmV4YW1wbGUuY29tLnNlcnZlci5leGFtcGxlLmNvbS4g a2V5X25hbWUNCiAgICAgT0NURVQgU1RSSU5HICAgbWVzc2FnZSAgICAgICAgPSBpbmNvbWluZyBt ZXNzYWdlIHBsdXMgVFNJRw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZhcmlh YmxlcyAoYXMgZGVzY3JpYmVkIGluIFtSRkMyODQ1XSkNCiAgICAgT0NURVQgU1RSSU5HICAgcGVy X21zZ190b2tlbiAgPSBTaWduYXR1cmUgZmllbGQgZnJvbSBUU0lHIFJSDQogICAgICAgICAgICAg ICAgICBpbmNsdWRlZCBpbiB0aGUgc2VydmVyJ3MgcXVlcnkgcmVzcG9uc2UNCg0KICBTaW5jZSB0 aGUgT1VUUFVUUyBwYXJhbWV0ZXIgbWFqb3Jfc3RhdHVzID0gR1NTX1NfQ09NUExFVEUsIHRoZQ0K ICBzaWduYXR1cmUgaXMgdmFsaWRhdGVkLCBzZWN1cml0eSBuZWdvdGlhdGlvbiBpcyBjb21wbGV0 ZSBhbmQgdGhlDQogIHNlY3VyaXR5IGNvbnRleHQgc3RhdGUgaXMgYWR2YW5jZWQgdG8gQ29udGV4 dCBFc3RhYmxpc2hlZC4gVGhlc2UNCiAgY2xpZW50IGFuZCBzZXJ2ZXIgd2lsbCB1c2UgdGhlIGVz dGFibGlzaGVkIHNlY3VyaXR5IGNvbnRleHQgdG8gc2lnbg0KICBhbmQgdmFsaWRhdGUgdGhlIHNp Z25hdHVyZXMgd2hlbiB0aGV5IGV4Y2hhbmdlIHBhY2tldHMgd2l0aCBlYWNoDQogIG90aGVyIHVu dGlsIHRoZSBjb250ZXh0IGV4cGlyZXMuDQoNCg0KNy4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMN Cg0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBwcm90b2NvbCBmb3IgRE5TIHNlY3VyaXR5IHVz aW5nIEdTUy1BUEkuDQpUaGUgc2VjdXJpdHkgcHJvdmlkZWQgYnkgdGhpcyBwcm90b2NvbCBpcyBv bmx5IGFzIGVmZmVjdGl2ZSBhcyB0aGUNCnNlY3VyaXR5IHByb3ZpZGVkIGJ5IHRoZSB1bmRlcmx5 aW5nIEdTUyBtZWNoYW5pc21zLg0KDQpBbGwgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZy b20gUkZDMjg0NSwgUkZDMjkzMCBhbmQgUkZDIDI3NDMNCmFwcGx5IHRvIHRoZSBwcm90b2NvbCBk ZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0KDQo4LiBJQU5BIENvbnNpZGVyYXRpb25zDQoN ClRoZSBhdXRob3JzIHJlcXVlc3QgdGhhdCB0aGUgSUFOQSByZXNlcnZlIHRoZSBUU0lHIEFsZ29y aXRobSBuYW1lDQpnc3MtdHNpZyBmb3IgdGhlIHVzZSBpbiB0aGUgQWxnb3JpdGhtIGZpZWxkcyBv ZiBUS0VZIGFuZCBUU0lHIHJlc291cmNlDQpyZWNvcmRzLiBUaGlzIEFsZ29yaXRobSBuYW1lIHJl ZmVycyB0byB0aGUgYWxnb3JpdGhtIGRlc2NyaWJlZCBpbiB0aGlzDQpkb2N1bWVudC4gVGhlIHJl cXVpcmVtZW50IHRvIGhhdmUgdGhpcyBuYW1lIHJlZ2lzdGVyZWQgd2l0aCBJQU5BIGlzDQpzcGVj aWZpZWQgaW4gUkZDIDI4NDUuDQoNCg0KOS4gQ29uZm9ybWFuY2UNCg0KVGhlIEdTUyBBUEkgdXNp bmcgU1BORUdPIFtSRkMyNDc4XSBwcm92aWRlcyBtYXhpbXVtIGZsZXhpYmlsaXR5IHRvDQpjaG9v c2UgdGhlIHVuZGVybHlpbmcgc2VjdXJpdHkgbWVjaGFuaXNtcyB0aGF0IGVuYWJsZXMgc2VjdXJp dHkgY29udGV4dA0KbmVnb3RpYXRpb24uIEdTUyBBUEkgdXNpbmcgU1BORUdPIFtSRkMyNDc4XSBl bmFibGVzIGNsaWVudCBhbmQgc2VydmVyIHRvDQpuZWdvdGlhdGUgYW5kIGNob29zZSBzdWNoIHVu ZGVybHlpbmcgc2VjdXJpdHkgbWVjaGFuaXNtcyBvbiB0aGUgZmx5LiBUbw0Kc3VwcG9ydCBzdWNo IGZsZXhpYmlsaXR5LCBETlMgY2xpZW50cyBhbmQgc2VydmVycyBTSE9VTEQgc3BlY2lmeSBTUE5F R08NCm1lY2hfdHlwZSBpbiB0aGVpciBHU1MgQVBJIGNhbGxzLiBBdCB0aGUgc2FtZSB0aW1lLCBp biBvcmRlciB0bw0KZ3VhcmFudGVlIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBETlMgY2xpZW50 cyBhbmQgc2VydmVycyB0aGF0IHN1cHBvcnQNCkdTUy1UU0lHIGl0IGlzIHJlcXVpcmVkIHRoYXQN Cg0KRXhwaXJlcyBKdWx5IDMwLCAyMDAyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSAxOV0NCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgR1NT LVRTSUcgICAgICAgICAgICAgIEphbnVhcnkgMzAsIDIwMDINCg0KLSBETlMgc2VydmVycyBzcGVj aWZ5IFNQTkVHTyBtZWNoX3R5cGUNCi0gR1NTIEFQSXMgY2FsbGVkIGJ5IEROUyBjbGllbnQgc3Vw cG9ydCBLZXJiZXJvcyB2NQ0KLSBHU1MgQVBJcyBjYWxsZWQgYnkgRE5TIHNlcnZlciBzdXBwb3J0 IFNQTkVHTyBbUkZDMjQ3OF0gYW5kDQogIEtlcmJlcm9zIHY1Lg0KDQpJbiBhZGRpdGlvbiB0byB0 aGVzZSwgR1NTIEFQSXMgdXNlZCBieSBETlMgY2xpZW50IGFuZCBzZXJ2ZXIgTUFZIGFsc28NCnN1 cHBvcnQgb3RoZXIgdW5kZXJseWluZyBzZWN1cml0eSBtZWNoYW5pc21zLg0KDQoNCjEwLiBBY2tu b3dsZWRnZW1lbnRzDQoNClRoZSBhdXRob3JzIG9mIHRoaXMgZG9jdW1lbnQgd291bGQgbGlrZSB0 byB0aGFuayB0aGUgZm9sbG93aW5nIHBlb3BsZQ0KZm9yIHRoZWlyIGNvbnRyaWJ1dGlvbiB0byB0 aGlzIHNwZWNpZmljYXRpb246ICBDaHVjayBDaGFuLCBNaWtlIFN3aWZ0LA0KUmFtIFZpc3dhbmF0 aGFuLCBPbGFmdXIgR3VkbXVuZHNzb24sIERvbmFsZCBFLiBFYXN0bGFrZSAzcmQgYW5kIEVyaWsN Ck5vcmRtYXJrLg0KDQoNCjExLiBSZWZlcmVuY2VzDQoNCltSRkMyNzQzXSBKLiBMaW5uLCAiR2Vu ZXJpYyBTZWN1cml0eSBTZXJ2aWNlIEFwcGxpY2F0aW9uIFByb2dyYW0NCiAgICAgICAgICBJbnRl cmZhY2UsIFZlcnNpb24gMiAsIFVwZGF0ZSAxIiwgUkZDIDI3NDMsIFJTQSBMYWJvcmF0b3JpZXMs DQogICAgICAgICAgSmFudWFyeSAyMDAwLg0KDQpbUkZDMjg0NV0gUC4gVml4aWUsIE8uIEd1ZG11 bmRzc29uLCBELiBFYXN0bGFrZSwgQi4gV2VsbGluZ3RvbiwNCiAgICAgICAgICAiU2VjcmV0IEtl eSBUcmFuc2FjdGlvbiBBdXRoZW50aWNhdGlvbiBmb3IgRE5TIChUU0lHKSIsDQogICAgICAgICAg UkZDIDI4NDUsIElTQywgTkFJIExhYnMsIE1vdG9yb2xhLCBOb21pbnVtLCBNYXksIDIwMDAsDQoN CltSRkMyOTMwXSBELiBFYXN0bGFrZSAzcmQsICJTZWNyZXQgS2V5IEVzdGFibGlzaG1lbnQgZm9y IEROUyAoVEtFWSBSUikiLA0KICAgICAgICAgIFJGQyAyOTMwLCBNb3Rvcm9sYSwgU2VwdGVtYmVy IDIwMDAuDQoNCltSRkMyNTM1XSBELiBFYXN0bGFrZSAzcmQsICJEb21haW4gTmFtZSBTeXN0ZW0g U2VjdXJpdHkgRXh0ZW5zaW9ucywiDQogICAgICAgICAgUkZDIDI1MzUsIElCTSwgTWFyY2ggMTk5 OS4NCg0KW1JGQzIxMzddIEQuIEVhc3RsYWtlIDNyZCwgIlNlY3VyZSBEb21haW4gTmFtZSBTeXN0 ZW0gRHluYW1pYyBVcGRhdGUsIg0KICAgICAgICAgIFJGQyAyMTM3LCBDeWJlckNhc2gsIEFwcmls IDE5OTcuDQoNCltSRkMyMTE5XSBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJG Q3MgdG8gSW5kaWNhdGUNCiAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJG QyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQpbUkZDMTAzNF0gTW9ja2FwZXRyaXMsIFAuLCAiRG9tYWlu IE5hbWVzIC0gQ29uY2VwdHMgYW5kIEZhY2lsaXRpZXMiLA0KICAgICAgICAgIFNURCAxMywgUkZD IDEwMzQsIE5vdmVtYmVyIDE5ODcuDQoNCltSRkMxMDM1XSBNb2NrYXBldHJpcywgUC4sICJEb21h aW4gTmFtZXMgLSBJbXBsZW1lbnRhdGlvbiBhbmQNCiAgICAgICAgICBTcGVjaWZpY2F0aW9uIiwg U1REIDEzLCBSRkMgMTAzNCwgTm92ZW1iZXIgMTk4Ny4NCg0KW1JGQzE5NjRdIExpbm4sIEouLCAi VGhlIEtlcmJlcm9zIFZlcnNpb24gNSBHU1MtQVBJIE1lY2hhbmlzbSIsDQogICAgICAgICAgUkZD IDE5NjQsIE9wZW5WaXNpb24gVGVjaG5vbG9naWVzLCBKdW5lIDE5OTYuDQoNCltSRkMyMDI1XSBB ZGFtcywgQy4sICJUaGUgU2ltcGxlIFB1YmxpYy1LZXkgR1NTLUFQSSBNZWNoYW5pc20gKFNQS00p IiwNCiAgICAgICAgICBSRkMgMjAyNSwgQmVsbC1Ob3J0aGVybiBSZXNlYXJjaCwgT2N0b2JlciAx OTk2Lg0KDQpbUkZDMjQ3OF0gQmFpemUsIEUuLCBQaW5rYXMsIEQuLCAiVGhlIFNpbXBsZSBhbmQg UHJvdGVjdGVkIEdTUy1BUEkNCiAgICAgICAgICBOZWdvdGlhdGlvbiBNZWNoYW5pc20iLCBSRkMg MjQ3OCwgQnVsbCwgRGVjZW1iZXIgMTk5OC4NCg0KRXhwaXJlcyBKdWx5IDMwLCAyMDAyICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyMF0NCg0KSU5URVJORVQt RFJBRlQgICAgICAgICAgICAgICAgICAgR1NTLVRTSUcgICAgICAgICAgICAgIEphbnVhcnkgMzAs IDIwMDINCg0KDQpbSVNPMTE1NzhdIkluZm9ybWF0aW9uIHRlY2hub2xvZ3kiLCAiT3BlbiBTeXN0 ZW1zDQogICAgICAgICAgSW50ZXJjb25uZWN0aW9uIiwgIlJlbW90ZSBQcm9jZWR1cmUgQ2FsbCIs DQogICAgICAgICAgSVNPL0lFQyAxMTU3ODoxOTk2LCBodHRwOi8vd3d3Lmlzby5jaC9jYXRlL2Qy MjI5Lmh0bWwuDQoNCg0KDQoNCjEyLiBBdXRob3IncyBBZGRyZXNzZXMNCg0KU3R1YXJ0IEt3YW4g ICAgICAgICAgICAgICAgICAgICAgICAgUHJhZXJpdCBHYXJnDQpNaWNyb3NvZnQgQ29ycG9yYXRp b24gICAgICAgICAgICAgICBNaWNyb3NvZnQgQ29ycG9yYXRpb24NCk9uZSBNaWNyb3NvZnQgV2F5 ICAgICAgICAgICAgICAgICAgIE9uZSBNaWNyb3NvZnQgV2F5DQpSZWRtb25kLCBXQSAgOTgwNTIg ICAgICAgICAgICAgICAgICBSZWRtb25kLCBXQSAgOTgwNTINClVTQSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFVTQQ0Kc2t3YW5AbWljcm9zb2Z0LmNvbSAgICAgICAgICAgICAgICAg cHJhZXJpdGdAbWljcm9zb2Z0LmNvbQ0KDQpKYW1lcyBHaWxyb3kgICAgICAgICAgICAgICAgICAg ICAgICBMZXZvbiBFc2lib3YNCk1pY3Jvc29mdCBDb3Jwb3JhdGlvbiAgICAgICAgICAgICAgIE1p Y3Jvc29mdCBDb3Jwb3JhdGlvbg0KT25lIE1pY3Jvc29mdCBXYXkgICAgICAgICAgICAgICAgICAg T25lIE1pY3Jvc29mdCBXYXkNClJlZG1vbmQsIFdBICA5ODA1MiAgICAgICAgICAgICAgICAgIFJl ZG1vbmQsIFdBICA5ODA1Mg0KVVNBICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVVNB DQpqYW1lc2dAbWljcm9zb2Z0LmNvbSAgICAgICAgICAgICAgICBsZXZvbmVAbWljcm9zb2Z0LmNv bQ0KDQoNClJhbmR5IEhhbGwgICAgICAgICAgICAgICAgICAgICAgICAgIEplZmYgV2VzdGhlYWQN Ckx1Y2VudCBUZWNobm9sb2dpZXMgICAgICAgICAgICAgICAgIE1pY3Jvc29mdCBDb3Jwb3JhdGlv bg0KNDAwIExhcHAgUm9hZCAgICAgICAgICAgICAgICAgICAgICAgT25lIE1pY3Jvc29mdCBXYXkN Ck1hbHZlcm4gUEEgMTkzNTUgICAgICAgICAgICAgICAgICAgIFJlZG1vbmQsIFdBICA5ODA1Mg0K VVNBICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVVNBDQpyYW5keWhhbGxAbHVjZW50 LmNvbSAgICAgICAgICAgICAgICBqd2VzdGhAbWljcm9zb2Z0LmNvbQ0KDQoNCg0KRXhwaXJlcyBK dWx5IDMwLCAyMDAyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFn ZSAyMV0NCg== ------_=_NextPart_001_01C1AA95.53972F74-- 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: