From owner-dns-security Wed May 6 11:12:57 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA26317 for dns-security-outgoing; Wed, 6 May 1998 11:08:07 -0400 (EDT)
Message-Id: <199805061506.LAA10851@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;;;;@tis.com@tis.com;;;
Cc: dns-security@tis.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dnssec-secext2-05.txt
Date: Wed, 06 May 1998 11:06:35 -0400
Sender: owner-dns-security@ex.tis.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Security Working Group
of the IETF.
Title : Domain Name System Security Extensions
Author(s) : D. Eastlake
Filename : draft-ietf-dnssec-secext2-05.txt
Pages : 51
Date : 05-May-98
Extensions to the Domain Name System (DNS) are described that provide
data integrity and authentication to security aware resolvers and
applications through the use of cryptographic digital signatures.
These digital signatures are included in secured zones as resource
records. Security can also be provided through non-security aware
DNS servers in some cases.
The extensions provide for the storage of authenticated public keys
in the DNS. This storage of keys can support general public key
distribution services as well as DNS security. The stored keys
enable security aware resolvers to learn the authenticating key of
zones in addition to those for which they are initially configured.
Keys associated with DNS names can be retrieved to support other
protocols. Provision is made for a variety of key types and
algorithms.
In addition, the security extensions provide for the optional
authentication of DNS protocol transactions and requests.
This document incorporates feedback on RFC 2065 from early
implementers and potential users.
Internet-Drafts are 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-dnssec-secext2-05.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-secext2-05.txt
Internet-Drafts directories are located at:
Africa: ftp.is.co.za
Europe: ftp.nordu.net
ftp.nis.garr.it
Pacific Rim: munnari.oz.au
US East Coast: ftp.ietf.org
US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv@ietf.org. In the body type:
"FILE /internet-drafts/draft-ietf-dnssec-secext2-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: <19980506102154.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-secext2-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnssec-secext2-05.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19980506102154.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-dns-security Mon May 18 15:07:37 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13580 for dns-security-outgoing; Mon, 18 May 1998 15:02:15 -0400 (EDT)
Reply-To: James M Galvin <galvin@commerce.net>
From: James M Galvin <galvin@commerce.net>
To: Jeff Schiller <jis@mit.edu>, Marcus Leech <Marcus.Leech.mleech@nt.com>
cc: iesg-secretary@ietf.org, dns-security@ex.tis.com
Subject: DNS Security to the IESG
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1943.895518628.1@elistx.com>
Date: Mon, 18 May 1998 15:10:28 -0400
Message-ID: <9805181510.aa01947@one.eListX.com>
Sender: owner-dns-security@ex.tis.com
Precedence: bulk
As Chair of the DNS Security Working Group with this message the working
group is submitting the following documents to be considered for
publication as Proposed Standards:
draft-ietf-dnssec-secext2-05.txt
draft-ietf-dnssec-dss-02.txt
draft-ietf-dnssec-rsa-00.txt
draft-ietf-dnssec-certs-02.txt
draft-ietf-dnssec-indirect-key-01.txt
draft-ietf-dnssec-dhk-02.txt
These documents represent consensus although not unanimity. Concerns
fall in to the categories of specification clarity and lack of
operational experience to be absolutely certain of a few technical
choices. There are also some subjective concerns regarding the utility
of a few functions and features.
Nonetheless, it is my opinion these documents represent "as far as we
are going to get" with respect to resolution. Further, it is my opinion
that operational experience will present the necessary "clarity of
opinion" to permit resolution of the concerns when the documents are
eligible to be advanced to Draft Standard. Operational experience is
problematic unless these documents are advanced to at least the Proposed
Standard level. Experimental is not an option.
During your review please note that the first three documents are a
logical set replacing RFC 2065. RFC 2065 is the current Proposed
Standard for DNS Security. The technical changes between this version
and that version require recycling at the Proposed Standard level.
Note further that the first two documents are required to advance
together according to IETF rules regarding encumbered technologies; the
third is text split from RFC 2065 so as to permit the DNS Security
extensions themselves to be algorithm independent.
Enjoy,
Jim
--
James M. Galvin Director, Electronic Commerce Technologies
CommerceNet Consortium +1 410.549.5545
http://www.commerce.net +1 410.549.5546 FAX
From owner-dns-security Thu May 21 08:59:58 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA25621 for dns-security-outgoing; Thu, 21 May 1998 08:57:07 -0400 (EDT)
Date: Thu, 21 May 1998 08:13:54 +0200
Message-Id: <199805210613.IAA01745@mir3.ida.liu.se>
To: dns-security@tis.com
From: Yahya Al-Salqan <Yahya.Abual-Salqan@eng.sun.com>
Subject: Enterprise Security Workshop: Call for participation
Sender: owner-dns-security@ex.tis.com
Precedence: bulk
=============================================================
Call for Participation:
IEEE WET ICE '98
Third International Workshop
on
Enterprise Security
Stanford University, Palo Alto, USA
June 17-19 1998
=============================================================
On behalf of the Workshop Program and Organizing Committees, I
would like to invite you to participate in The 3rd IEEE
International Enterprise Security Workshop to be held on June
17-19, Stanford University, Palo Alto, California. The Workshop
includes paper presentations, panel discussions, keynote speeches
and invited talks covering all aspects of enterprise security.
Topics to be covered include: Public key infrastructure,
intrusion detection, Web security, application security
(e.g. digital library and health care), and access control.
Highlights of the program:
o Keynote speech by Dr. Li Gong, Java Security Architect,
Sun Microsystems;
o Industrial security expertise from: Microsoft NT security
group, Sun Microsystems, Entrust, Certicom, Verisign,
SSH Communication security and many others. It is an
unprecedented opportunity to put all these companies in one
room. Don't miss it.
o Participation of IETF security group leaders;
o Participation of NSA (National Security Agency);
o Two panel discussions:
- "State-of-the-art Enterprise Security: Practice and Future"
- "Intrusion Detection: Present and Future"
o Workshop is held in conjunction with other WETICE workshops:
- "Web-based infrastructure for collaborative Enterprises,"
- "Collaboration in Presence of Mobility,"
o Two social events.
The Workshop Preliminary program can be found at:
http://www.ida.liu.se/labs/iislab/SECWK/agenda.html
The Registration form can be found at:
http://www.cerc.wvu.edu/WETICE/WETICE98/registration.html
(Please mark the Enterprise Security Workshop on the
registration form)
The Workshop main page can be found at:
http://www.ida.liu.se/labs/iislab/SECWK/
I look forward to meeting you at the Workshop.
Sincerely,
Yahya Al-Salqan, Ph.D.
Workshop General Chair
Sun Microsystems
From owner-dns-security Wed May 27 08:41:45 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20502 for dns-security-outgoing; Wed, 27 May 1998 08:38:13 -0400 (EDT)
Message-Id: <199805271244.IAA11159@clipper.hq.tis.com>
X-Sender: balenson@pop.hq.tis.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 27 May 1998 08:52:07 -0400
To: ids@uow.edu.au, firewalls@greatcircle.com, cat-ietf@mit.edu,
ietf@ns.ietf.org, ipsec@tis.com, dns-security@tis.com,
www-security@ns2.rutgers.edu, www-buyinfo@allegra.att.com,
ietf-otp@bellcore.com, pem-dev@tis.com, virus-l@lehigh.edu,
ietf-pkix@tandem.com, spki@c2.net, ietf-tls@consensus.com,
ietf-open-pgp@imc.org, ietf-smime@imc.org, aft@socks.nec.com,
ietf-radius@livingston.com, ietf-ssh@clinet.fi,
OGsecurity@opengroup.org, cryptography@c2.net, risks@csl.sri.com
From: "David M. Balenson" <balenson@tis.com>
Subject: CFP: 1999 Network & Distributed System Security Symposium
(NDSS '99)
Cc: balenson@tis.com
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_896287927==_"
Sender: owner-dns-security@ex.tis.com
Precedence: bulk
--=====================_896287927==_
Content-Type: text/plain; charset="us-ascii"
--=====================_896287927==_
Content-Type: text/plain; charset="us-ascii"
C A L L F O R P A P E R S
The Internet Society
1999 Network and Distributed System Security Symposium
(NDSS'99)
Where: Catamaran Resort, San Diego, California
When: February 3-5, 1999
GOAL: The symposium will foster information exchange among hardware and
software developers of network and distributed system security
services. The intended audience includes those who are interested in
the practical aspects of network and distributed system security,
focusing on actual system design and implementation, rather than
theory. A major goal of the symposium is to encourage and enable the
Internet community to apply, deploy, and advance the state of
available security technology. The proceedings of the symposium will
be published by the Internet Society.
Topics for the symposium include, but are not limited to, the
following:
* Security in malleable systems: mobile code, mobile agents, active
networks, dynamic policy updates, etc.
* Special problems: e.g. interplay between security goals and other
goals such as efficiency, usability, reliability, interoperability,
resource sharing, and cost.
* Integrating security services with system and application security
facilities and with application protocols, including message handling,
file transport, remote file access, directories, time synchronization,
data base management, routing, voice and video multicast, network
management, boot services, and mobile computing.
* Fundamental services: authentication, integrity, confidentiality,
authorization, non-repudiation, and availability.
* Supporting mechanisms and APIs: key management and certification
infrastructures, audit, and intrusion detection.
* Telecommunications security, especially for emerging technologies --
very large systems, e.g., the Internet, high-speed systems, e.g., the
gigabit testbeds, wireless systems, personal communication systems,
and large-scale, heterogeneous distributed systems.
* Controls: firewalls, packet filters, application gateways
* Object security and security objects
* Network information resources and tools such as World Wide Web (WWW),
Gopher, archie, and WAIS.
* Electronic commerce: payment services, fee-for-access, EDI, notary
services; endorsement, licensing, bonding, and other forms of
assurance; rights management and other forms of intellectual property
protection
* Implementation and management of network security policy
* Security for voice over IP
* Security for routing
GENERAL CHAIR:
Stephen Welke, Trusted Computer Solutions
PROGRAM CHAIRS:
Stephen Kent, BBN Technologies
Gene Tsudik, USC/Information Sciences Institute
TUTORIAL CHAIR:
Doug Maughan, National Security Agency
PROGRAM COMMITTEE:
David Balenson, TIS Labs at Network Associates
Steve Bellovin, AT&T Labs -- Research
Matt Bishop, University of California at Davis
Bob Blakley, IBM
Doug Engert, Argonne National Laboratories
Warwick Ford, VeriSign
Li Gong, Sun Microsystems
Rich Graveman, Bellcore
Ari Juels, RSA Laboratories
Tom Longstaff, CERT
Doug Maughan, National Security Agency
Dan Nessett, 3Com Corporation
Michael Roe, Cambridge University
Jeffrey Schiller, MIT
Wolfgang Schneider, GMD Darmstadt
Christoph Schuba, Purdue University
Win Treese, Open Market
Jonathan Trostle, Cisco
LOCAL ARRANGEMENTS CHAIR:
Thomas Hutton, San Diego Supercomputer Center
PUBLICATIONS CHAIR:
John Kochmar, SEI
PUBLICITY CHAIR:
David Balenson, TIS Labs at Network Associates
LOGISTICS CHAIR:
Carla Rosenfeld, Internet Society
REGISTRATIONS CHAIR
Beth Strait, Internet Society
SUBMISSIONS: The committee invites technical papers and panel proposals,
for topics of technical and general interest. Technical papers should
be 10-20 pages in length. Panel proposals should be two pages and
should describe the topic, identify the panel chair, explain the
format of the panel, and list three to four potential panelists.
Technical papers will appear in the proceedings. A description of
each panel will appear in the proceedings, and may at the discretion
of the panel chair, include written position statements from each
panelist.
Each submission must contain a separate title page with the type of
submission (paper or panel), the title or topic, the names of the
author(s), organizational affiliation(s), telephone and FAX numbers,
postal addresses, Internet electronic mail addresses, and must list a
single point of contact if more than one author. The names of authors,
affiliations, and other identifying information should appear only on
the separate title page.
Submissions must be received by 31 July 1998, and must be made via
electronic mail in either PostScript or ASCII format. If the
committee is unable to print a PostScript submission, it will be
returned and hardcopy requested. Therefore, PostScript submissions
must arrive well before 31 July.
All submissions and program related correspondence (only) should be
directed to the program chair:
Stephen Kent
c/o BBN Technologies
70 Fawcett Street
Cambridge, Mass. 02138
Email:sndss99-submissions@bbn.com
Phone: +1 (617) 873-1996
FAX: +1 (617) 873-4086
Dates, final call for papers, advance program, and registration
information will be available at the URL: http://www.isoc.org/ndss99.
Each submission will be acknowledged by e-mail. If acknowledgment is
not received within seven days, please contact the program chair as
indicated above. Authors and panelists will be notified of acceptance
by 18 September 1998. Instructions for preparing camera-ready copy
for the proceedings will be sent at that time. The camera-ready copy
must be received by 16 October 1998.
--=====================_896287927==_
Content-Type: text/plain; charset="us-ascii"
----------------------------------------------------------------------------
David M. Balenson, Publicity Chair, NDSS '99
TIS Labs at Network Associates, Inc.
3060 Washington Road, Glenwood, MD 21738 USA
balenson@tis.com; 301-854-5358; fax 301-854-5363
--=====================_896287927==_--
From owner-dns-security Wed May 27 15:00:27 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22759 for dns-security-outgoing; Wed, 27 May 1998 14:59:09 -0400 (EDT)
Message-ID: <356C63A5.61CC@ccnet.com>
Date: Wed, 27 May 1998 12:04:05 -0700
From: Kurt Stammberger <stam@ccnet.com>
X-Mailer: Mozilla 3.01 (Macintosh; I; PPC)
MIME-Version: 1.0
To: ids@uow.edu.au, firewalls@greatcircle.com, cat-ietf@mit.edu, ietf@ietf.org,
ipsec@tis.com, dns-security@tis.com, www-security@ns2.rutgers.edu,
www-buyinfo@allegra.att.com, ietf-otp@bellcore.com, pem-dev@tis.com,
virus-l@lehigh.edu, ietf-pkix@tandem.com, spki@c2.net,
ietf-tls@consensus.com, ietf-open-pgp@imc.org, ietf-smime@imc.org,
aft@socks.nec.com, ietf-radius@livingston.com, ietf-ssh@clinet.fi,
OGsecurity@opengroup.org, cryptography@c2.net, risks@csl.sri.com
Subject: RSA'99 Deadline
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-dns-security@ex.tis.com
Precedence: bulk
Dave's NDSS note reminded me to remind y'all:
D E A D L I N E ! D E A D L I N E !
The Deadline for talk proposals for RSA'99 is SIX DAYS AWAY (June 1st).
For more information, or to propose a talk or submit a paper for
presentation, visit www.rsa.com/conf99
Questions? E-mailez-moi.
Kurt Stammberger
Conference Director
RSADSI
From owner-dns-security Wed May 27 15:27:25 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA22994 for dns-security-outgoing; Wed, 27 May 1998 15:27:11 -0400 (EDT)
Message-Id: <199805271925.MAA21067@basilisk.Eng.Sun.COM>
Date: Wed, 27 May 1998 12:25:35 -0700 (PDT)
From: Yahya Al-Salqan <Yahya.Abual-Salqan@eng.sun.com>
Reply-To: Yahya Al-Salqan <Yahya.Abual-Salqan@eng.sun.com>
Subject: Call for participation (FYI)
To: firewalls@greatcircle.com, cat-ietf@mit.edu, ietf@ietf.org, ipsec@tis.com,
dns-security@tis.com, www-security@ns2.rutgers.edu,
www-buyinfo@allegra.att.com, ietf-otp@bellcore.com, pem-dev@tis.com,
virus-l@lehigh.edu, ietf-pkix@tandem.com, spki@c2.net,
ietf-tls@consensus.com, ietf-open-pgp@imc.org, ietf-smime@imc.org,
aft@socks.nec.com, ietf-radius@livingston.com, ietf-ssh@clinet.fi,
OGsecurity@opengroup.org, cryptography@c2.net, risks@csl.sri.com
Cc: ssl-talk@netscape.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: SCk4v9pjCPXd6BFIFnKHgg==
X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc
Sender: owner-dns-security@ex.tis.com
Precedence: bulk
Today is the deadline for the early registration ... take advantage of it.
My appology if you receive this e-mail more than once!
=================================================
Call for Participation:
IEEE WET ICE '98
Third International Workshop
on
Enterprise Security
Stanford University, Palo Alto, USA
June 17-19 1998
=================================================
On behalf of the Workshop Program and Organizing Committees, I would like to
invite you to participate in The 3rd IEEE International Enterprise Security
Workshop will be held June 17-19, Stanford University, Palo Alto, California.
The Workshop includes paper presentations, panel discussions, keynote speeches
and invited talks covering all aspects of enterprise security. Topics to be
covered include: Public key infrastructure, intrusion detection, Web security,
application security (e.g. digital library and healthcare), and access control.
Highlights of the program:
o Keynote speech by Dr. Li Gong, Java Security Architect, Sun
Microsystems;
o Industrial security expertise from: Microsoft NT security
group, Sun Microsystems, Entrust, Certicom, Verisign, SSH
Communication security and many others. It is an unprecedented
opportunity to put all these companies in one room. Don't miss it.
o Participation of IETF security group leaders;
o Participation of NSA (National Security Agency);
o Two panel discussions:
- "State-of-the-art Enterprise Security: Practice and Future"
- "Intrusion Detection: Present and Future"
o Workshop held in conjunction with other WETICE workshops:
"Web-based infrastructure for collaborative
Enterprises,"
"Collaboration in Presence of Mobility,"
o Two social events.
The Workshop Preliminary program can be found at:
http://www.ida.liu.se/labs/iislab/SECWK/agenda.html
The Registration form can be found at:
http://www.cerc.wvu.edu/WETICE/WETICE98/registration.html
(Please mark the Enterprise Security on the registration form)
The Workshop main page can be found at:
http://www.ida.liu.se/labs/iislab/SECWK/
I look forward to meeting you at the Workshop.
Sincerely,
Yahya Al-Salqan, Ph.D.
Workshop General Chair
Sun Microsystems
------------- End Forwarded Message -------------
------------- End Forwarded Message -------------
From owner-dns-security Fri May 29 10:58:15 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA03440 for dns-security-outgoing; Fri, 29 May 1998 10:52:51 -0400 (EDT)
Message-Id: <199805291445.KAA03800@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
From: Internet-Drafts@ietf.org
cc: dns-security@tis.com
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-lewis-dnskey-referral-00.txt
Date: Fri, 29 May 1998 10:45:31 -0400
Sender: owner-dns-security@ex.tis.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : The Zone Referral Key
Author(s) : E. Lewis, J. Scharff, J. Gilmore
Filename : draft-lewis-dnskey-referral-00.txt
Pages : 7
Date : 28-May-98
A new type of key is defined to address the problems of
performance in large delegeted zones and issues of liability of
registrars with regards to the storing of public keys belonging
to zone cuts. This new key type also brings DNSSEC more in line
with the DNS treatment of zone cuts and speeds recovery in
handling key exposure.
The new type of key is a referral record that is stored, signed,
at the parent zone's place for the delegation point. A resolver
receiving this record is being informed that there are genuine
public keys at the child's authoritative name servers. The
parent no longer needs to store the child's public keys locally.
Internet-Drafts are 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-lewis-dnskey-referral-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-lewis-dnskey-referral-00.txt
Internet-Drafts directories are located at:
Africa: ftp.is.co.za
Europe: ftp.nordu.net
ftp.nis.garr.it
Pacific Rim: munnari.oz.au
US East Coast: ftp.ietf.org
US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv@ietf.org. In the body type:
"FILE /internet-drafts/draft-lewis-dnskey-referral-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: <19980528164613.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-lewis-dnskey-referral-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-lewis-dnskey-referral-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19980528164613.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-dns-security Fri May 29 15:35:25 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA04621 for dns-security-outgoing; Fri, 29 May 1998 15:33:54 -0400 (EDT)
X-Authentication-Warning: defenestration.hq.tis.com: bwelling owned process doing -bs
Date: Fri, 29 May 1998 15:49:04 -0400 (EDT)
From: Brian Wellington <bwelling@tis.com>
X-Sender: bwelling@defenestration.hq.tis.com
To: namedroppers@internic.net, dns-security@tis.com
Subject: AXFR & NS records at delegation points
Message-ID: <Pine.LNX.3.96.980529154736.6231D-100000@defenestration.hq.tis.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-dns-security@ex.tis.com
Precedence: bulk
In prototyping DNSSEC functions in BIND, we've come across a problem
concerning zone transfers. This problem is not specific to DNSSEC,
however.
The problem is determining what is returned (specifically regarding the NS
record) at delegation points in a zone when the source of the transfer is
authoritative for both the zone being transfered and the zone below the
delegation point.
Example 1:
zone.bar.com:
...
foo NS a.foo.bar.com
...
zone.foo.bar.com:
...
@ NS b.foo.bar.com
As an example, say our nameserver is serving bar.com and foo.bar.com. When
the name server receives an AXFR request for bar.com, which NS record does it
include for foo.bar.com? The one from the bar.com zone or the (more credible)
one from the foo.bar.com zone? In BIND, only the more credible record is
stored (the other is expunged from memory).
The data from the lower zone is more credible, but including it leads to a
problem where two servers can both be serving bar.com and contain the same
serial number in the SOA, but if only one is serving foo.bar.com, the AXFR
will contain different data. In other words, for a secondary claiming serial
number = 1998052913, the NS record would be a.foo.bar from a server
authoritative only for the bar.com zone, and it would be b.foo.bar.com from a
server authoritative for both zones.
Example 2:
zone.bar.com:
...
foo NS a.foo.bar.com
...
zone.foo.bar.com.signed:
...
@ NS a.foo.bar.com
SIG NS ...
...
This also related to DNSSEC. If the upper zone is unsigned and the lower zone
is signed, the upper zone will overwrite (in BIND, at least) its unsigned NS
record for foo.bar.com with the signed one from the lower zone. Should the
AXFR contain the SIG NS record or not?
Additionally, there may be a similar problem with KEY records, as the parent
and child zones both contain KEY records at delegation points. In this case,
though, the parent should not contain the key record in the first place.
Any suggestions?
Brian
From owner-dns-security Fri May 29 16:16:05 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA04770 for dns-security-outgoing; Fri, 29 May 1998 16:15:53 -0400 (EDT)
To: Brian Wellington <bwelling@tis.com>
Cc: namedroppers@internic.net, dns-security@tis.com
Subject: Re: AXFR & NS records at delegation points
In-Reply-To: Brian Wellington's message of "Fri, 29 May 1998 15:49:04 -0400."
References: <Pine.LNX.3.96.980529154736.6231D-100000@defenestration.hq.tis.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 30 May 1998 06:31:16 +1000
Message-Id: <3673.896473876@munnari.OZ.AU>
From: Robert Elz <kre@munnari.oz.au>
Sender: owner-dns-security@ex.tis.com
Precedence: bulk
Date: Fri, 29 May 1998 15:49:04 -0400 (EDT)
From: Brian Wellington <bwelling@tis.com>
Message-ID: <Pine.LNX.3.96.980529154736.6231D-100000@defenestration.hq.tis.com>
| The problem is determining what is returned (specifically regarding the NS
| record) at delegation points in a zone when the source of the transfer is
| authoritative for both the zone being transfered and the zone below the
| delegation point.
This has always been a point of irritation, and there are arguments for
both possible answers.
In general however, I believe that the authoritative data is the data that
matters, that should be believed, and that any copies of inconsistent
unauthoritative data are errors, and should be expunged by any means possible.
That is, the delegation information in the parent zone should be identical
to the NS record set in the child zone, always (allowing for the permitted
inconsistencies around times of updates as always in the DNS). If it is
different, the parent is wrong, and should be connected.
Whether or not it is good for it to be corrected (or partly corrected)
"by accident" by virtue of the server also being authoritative for the
child is a complex issue, and not really worth debating. But it ought
be corrected one way or another.
| As an example, say our nameserver is serving bar.com and foo.bar.com. When
| the name server receives an AXFR request for bar.com, which NS record does
| it include for foo.bar.com?
I would suggest that including the RRset from the child zone is perfectly
reasonable - but I would hesitate to make that mandatory.
| The data from the lower zone is more credible, but including it leads to a
| problem where two servers can both be serving bar.com and contain the same
| serial number in the SOA, but if only one is serving foo.bar.com, the AXFR
| will contain different data.
There are plenty of other ways for DNS configuration errors (which is what
the above scenario represents) to cause that effect. It is not worth worrying
specially about this one particular case.
| Example 2:
| If the upper zone is unsigned and the lower zone
| is signed, [...] Should the
| AXFR contain the SIG NS record or not?
No, the SIG records belong to the child zone, and should remain there. Glue
should only ever be included when necessary for correct functioning of
the DNS - anything below the zone cut is glue. That includes the NS
records themselves, however they are (obviously) required in the parent zone.
kre
From owner-dns-security Fri May 29 19:10:56 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05323 for dns-security-outgoing; Fri, 29 May 1998 19:10:21 -0400 (EDT)
Message-Id: <199805292325.QAA17875@bb.rc.vix.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Brian Wellington <bwelling@tis.com>
cc: namedroppers@internic.net, dns-security@tis.com
Subject: Re: AXFR & NS records at delegation points
In-reply-to: Your message of "Fri, 29 May 1998 15:49:04 EDT."
<Pine.LNX.3.96.980529154736.6231D-100000@defenestration.hq.tis.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 29 May 1998 16:25:31 -0700
From: Jerry Scharf <scharf@vix.com>
Sender: owner-dns-security@ex.tis.com
Precedence: bulk
Brian,
(I am probably about to put my foot in my mount, so it's much better to do it
in public.)
My understanding is exactly the opposite of what kre said.
When I read about the "mount-like semantics" discussed in 2181 zone cuts, I
assume that it is just like the unix file mount: When you mount a new
filesystem on some point, all the files below the old mount point are
unavailable but do not disappear. If you unmount the other filesystem, they
reappear instantly. Also, if you dump the disk by walking the inode tree, you
will get all the files including the hidden ones. So when I do dump ->
restore, the hidden files are there, which is the analog of axfr. In the case
of DNS, since the NS records are still there on the copy, the data is still
hidden. I thought that this was one of the exact things that 2181 was supposed
to clarify!
I can imagine a case where you could use this, but I do agree that this can be
done better in other ways. I am also not exactly sure why being authoritative
for the child or not should change the contents of the zone transfer (though
it would certainly make the interal data storage for BIND different.)
jerry
From owner-dns-security Fri May 29 19:27:39 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05356 for dns-security-outgoing; Fri, 29 May 1998 19:27:21 -0400 (EDT)
To: Jerry Scharf <scharf@vix.com>
Cc: Brian Wellington <bwelling@tis.com>, namedroppers@internic.net,
dns-security@tis.com
Subject: Re: AXFR & NS records at delegation points
In-Reply-To: Jerry Scharf's message of "Fri, 29 May 1998 16:25:31 -0700."
References: <199805292325.QAA17875@bb.rc.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 30 May 1998 09:41:48 +1000
Message-Id: <7650.896485308@munnari.OZ.AU>
From: Robert Elz <kre@munnari.oz.au>
Sender: owner-dns-security@ex.tis.com
Precedence: bulk
Date: Fri, 29 May 1998 16:25:31 -0700
From: Jerry Scharf <scharf@vix.com>
Message-ID: <199805292325.QAA17875@bb.rc.vix.com>
| My understanding is exactly the opposite of what kre said.
I don't think so. I don't disagree at all with any of what you have said,
except possibly whether axfr is quite the analog of dump/restore.
In any case, having different NS records in the parent and child is a
config error, and I'm not sure that anything that could be specified here
can really cope with all such errors.
kre
From owner-dns-security Fri May 29 23:30:57 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA05700 for dns-security-outgoing; Fri, 29 May 1998 23:29:42 -0400 (EDT)
Date: Fri, 29 May 1998 23:45:15 -0400 (EDT)
From: "Donald E. Eastlake 3rd" <dee@cybercash.com>
To: dns-security@tis.com
cc: namedroppers@internic.net
Subject: Re: AXFR & NS records at delegation points
In-Reply-To: <199805292325.QAA17875@bb.rc.vix.com>
Message-ID: <Pine.SOL.3.96.980529232712.17411F-100000@mis01.reston.cybercash.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-dns-security@ex.tis.com
Precedence: bulk
I agree entirely with Robert Elz.
On Fri, 29 May 1998, Jerry Scharf wrote:
> Date: Fri, 29 May 1998 16:25:31 -0700
> From: Jerry Scharf <scharf@VIX.COM>
> To: Brian Wellington <bwelling@TIS.COM>
> Cc: namedroppers@internic.net, dns-security@TIS.COM
> Subject: Re: AXFR & NS records at delegation points
>
> Brian,
>
> (I am probably about to put my foot in my mouth, so it's much better to do
> it in public.)
>
> My understanding is exactly the opposite of what kre said.
>
> When I read about the "mount-like semantics" discussed in 2181 zone cuts, I
> assume that it is just like the unix file mount: When you mount a new
> filesystem on some point, all the files below the old mount point are
> unavailable but do not disappear. If you unmount the other filesystem, they
> reappear instantly. Also, if you dump the disk by walking the inode tree, you
No, the non-authoritative NS and A (or maybe AAAA) RRs can get completely
overwritten by the better data from the subzone.
If you are doing an AXFR, you could send either. It won't effect
validation of the zone based on SIGs and NXTs. If you happen to have a
child SIG on an NS or glue A RRs, I guess there is some ambiguity on
whether you could send those in an AXFR. But since such SIGs are
explicitly prohibited in the parent zone, I think they should NOT be send
in an AXFR. (Of course you should not send the child NXTs but I guess a
security un-aware server migh send those along with child glue SIGs so I
guess a secure server has to be able to handle receiving these in an
AXFR.)
> will get all the files including the hidden ones. So when I do dump ->
> restore, the hidden files are there, which is the analog of axfr. In the case
> of DNS, since the NS records are still there on the copy, the data is still
> hidden. I thought that this was one of the exact things that 2181 was supposed
> to clarify!
>
> I can imagine a case where you could use this, but I do agree that this can be
> done better in other ways. I am also not exactly sure why being authoritative
> for the child or not should change the contents of the zone transfer (though
> it would certainly make the interal data storage for BIND different.)
To quote from the current secext2 draft:
DNS security would like to view each zone as a unit of data
completely under the control of the zone owner with each entry
(RRset) signed by a special private key held by the zone manager.
But the DNS protocol views the leaf nodes in a zone, which are also
the apex nodes of a subzone (i.e., delegation points), as "really"
belonging to the subzone.
For backward compatility (think of a zone transfer from a secondary that
hasonly "Basic" server conformance, i.e., understands KEY, SIG, and NXT
but does not crypto), DNSSEC needs to yield to the DNS way. Besides, I
really don't see any harm in some versions of a zone being "better" as
long as it doesn't break any SIGs, etc.
> jerry
Thanks,
Donald
=====================================================================
Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com
318 Acton Street +1 978-371-7148(fax) dee@world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.privacy.org/ipc