From owner-dns-security Fri Aug 7 09:59:45 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA14012 for dns-security-outgoing; Fri, 7 Aug 1998 09:54:32 -0400 (EDT)
Message-Id: <199808071331.JAA12164@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;;;;;;;@tis.com@tis.com;;;@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-secfail-00.txt
Date: Fri, 07 Aug 1998 09:31:02 -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 : Intermediate Security Failures in DNSSEC
Author(s) : O. Gudmundsson, B. Wellington
Filename : draft-ietf-dnssec-secfail-00.txt
Pages : 5
Date : 06-Aug-98
This document identifies the situations where a signature
verification fails in a recursive security aware DNS server, and
how DNS servers should handle these cases, and the errors that
should be reported to DNS resolvers. This document proposes a new
error to be returned by DNSSEC capable servers.
A DNSSEC server acting as a recursive server MUST validate the
signatures on RRsets in a response it passes on; this draft
addresses the case when the data it receives fails signature
verification. The end resolver must be notified of this occurence
in such a way that it will not confuse it with another error.
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-secfail-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-secfail-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-ietf-dnssec-secfail-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: <19980806183523.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-secfail-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnssec-secfail-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19980806183523.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-dns-security Fri Aug 7 09:59:46 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA13996 for dns-security-outgoing; Fri, 7 Aug 1998 09:53:32 -0400 (EDT)
Message-Id: <199808071316.JAA11158@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;;;;;;;@tis.com@tis.com;;;@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-update2-00.txt
Date: Fri, 07 Aug 1998 09:16:53 -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 : Secure Domain Name System (DNS) Dynamic Update
Author(s) : D. Eastlake
Filename : draft-ietf-dnssec-update2-00.txt
Pages : 15
Date : 06-Aug-98
Revised Domain Name System (DNS) protocol extensions to authenticate
the data in DNS and provide key distribution services have been
defined in draft-ietf-dnssec-secext2-*.txt, which obsoletes the
original DNS security protocol definition in RFC 2065. In addition,
symetric key DNS transaction signatures have been defined in draft-
ietf-dnsind-tsig-*.txt. Secure DNS Dynamic Update operations were
also been defined [RFC 2137] in connection RFC 2065. This document
updates secure dynamic update in light of draft-ietf-dnssec-secext2-
*.txt and draft-ietf-dnsind-tsig-*.txt. It describes how to use
digital signatures covering requests and data to secure updates and
restrict updates to those authorized to perform them as indicated by
the updater's possession of cryptographic keys.
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-update2-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-update2-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-ietf-dnssec-update2-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: <19980806153412.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-update2-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnssec-update2-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19980806153412.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-dns-security Fri Aug 28 14:31:55 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06813 for dns-security-outgoing; Fri, 28 Aug 1998 14:27:23 -0400 (EDT)
Message-Id: <199808281656.MAA05631@torque.pothole.com>
X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol
To: dns-security@tis.com
Subject: FWD: Re: Edupage, 27 August 1998
Date: Fri, 28 Aug 1998 12:56:10 -0400
From: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
X-Mts: smtp
Sender: owner-dns-security@ex.tis.com
Precedence: bulk
------- Forwarded Message
Message-Id: <v04011712b20c5989c94f@[139.167.130.248]>
In-Reply-To: <2.2.16.19980827140054.0dd7abc4@mailer.packet.net>
Date: Fri, 28 Aug 1998 08:57:32 -0400
From: Robert Hettinga <rah@shipwright.com>
Subject: Re: Edupage, 27 August 1998
At 1:57 PM -0400 on 8/27/98, Edupage Editors wrote:
> DARPA LEADS FIGHT AGAINST DOMAIN-NAME HACKERS
> The Defense Advanced Research Projects Agency (DARPA) has awarded a $1.4
> million contract to Network Associates to develop a cryptographic
> authentication system for the Internet's domain-address system. The new
> system will enable the Net's routing points to verify the origin of any
> given Web page, preventing hackers from corrupting Web page caches or
> rerouting domain traffic altogether. It will not, however, prevent hackers
> from breaking into individual Web servers and changing pages. "That's not
> part of this particular approach," says the director of Network Associates'
> TIS Labs. The company is working with the Internet Software Consortium,
> which will distribute the security system to Unix vendors when it becomes
> commercially available. Beta versions are expected to be ready in about six
> months, with a final product on the market in about 18 months. (TechWeb 26
> Aug 98)
-----------------
Robert A. Hettinga <mailto: rah@philodox.com>
Philodox Financial Technology Evangelism <http://www.philodox.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
------- End of Forwarded Message
From owner-dns-security Mon Aug 31 16:40:48 1998
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14642 for dns-security-outgoing; Mon, 31 Aug 1998 16:37:06 -0400 (EDT)
Message-Id: <199808311850.OAA02269@torque.pothole.com>
X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol
To: Brian Wellington <bwelling@tis.com>
cc: dns-security@tis.com
Subject: Re: General comments on last call DNSSEC drafts
In-reply-to: Your message of "Wed, 29 Jul 1998 11:32:30 EDT."
<Pine.LNX.3.96.980729110332.31736E-100000@askew.hq.tis.com>
Date: Mon, 31 Aug 1998 14:50:45 -0400
From: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
X-Mts: smtp
Sender: owner-dns-security@ex.tis.com
Precedence: bulk
Brian,
From: Brian Wellington <bwelling@tis.com>
Date: Wed, 29 Jul 1998 11:32:30 -0400 (EDT)
To: dns-security@tis.com
Message-ID: <Pine.LNX.3.96.980729110332.31736E-100000@askew.hq.tis.com>
>I read through all of the drafts last week, and have a few minor comments
>on several of them. None of these are critical (and definitely should not
>prevent recycling at Proposed Standard or movement to Informational), but
>I'd like to discuss them anyway. Without further ado:
>
>General question:
>- The "Current DNS implementations are optimized for small transfers"
> paragraph is present is all of the drafts. Yes, this is an important
> cpnsideration, but is such repitition necessary?
Yes, it is present in many of the drafts. This is partly becasue some
of the drafts were formed by splitting or closing and then modifying
earlier drafts. It seems to me that the remarks are short enough that
it would not be worth while abstracting them into a separate document.
Perhaps the material can be re-organized at some point in the future
when we go to Draft Standard or the like.
>draft-ietf-dnssec-certs-02.txt:
>- The CERT record contains a "key tag" field to allow the CERT to be more
> easily paired with a KEY record. Are multiple CERT with the same
> name and key tag allowed, and are there special considerations?
Yes, there is no problem with multiple CERTs for the same subject and
the key tag could be the same because they are different types of
CERTs with the same public key in them or just because of random key
tag collisions. Perhaps this should be explicitly mentioned in the
draft.
>- Is the matching key required to have the same name as the certificate?
> There could be cases where this is undesirable.
No, although it seems to me it should be common for them to.
>draft-ietf-dnssec-ddi-05.txt
>- Except for the fact that the example scenario uses KEY records, this
> draft has nothing to do with DNSSEC. Why is it associated with DNSSEC?
Why not? TSIG seems like it should be in DNSSEC but its in DNSIND.
The IETF is not too doctrinaire about such things. And I think a
major use of detached DNS info would be to construte certificate like
chunks that include a KEY RRset and authenticating SIG(s). What uses
do you think would be common?
>draft-ietf-dnssec-dhk-02.txt
>- In section 2:
> > If "prime length" field is 1 or 2, then the "prime" field is actually
> > an unsigned index into a table of up to 65,536 predefined
> > prime/generator pairs to be defined in which case the generator length
> > should be zero.
> I believe this has been brought up before, but this is unimplementable
> until this table is specified, and any attempt to implement would lead
> to incompatibility between vendors.
That's why it says "to be defined". The meaning of a prime length of
1 or 2 is reserved to point into a table to be defined by a future
document. And I suspect this future document will be revised as more
standard pairs are thought up. Is IP "unimplementable" because the
meaning of all values of the protocol byte are not yet defined?
>draft-ietf-dnssec-dss-02.txt
>- The DSS KEY record contains a 'T' field, from which the key length can
> be determined. Since the key length can be determined from the RR size,
> this is not necessary. Also, the meaning is reserved if T > 8. If the
> reserved values are designed to allow longer keys, T is still not
> necessary; if it some other reason, then a new algorithm identifier
> should be specified for those cases. As mentioned in the draft, T is
> irrelevant for SIG records.
The idea is that the DSS KEY record corresponds to the DSA Standard.
This has already been changed once to allow for longer keys. It is
not clear to me what changes could occur later. I basicly do not
agree that if later changes were for other than key length, a
different algorithm byte should be used. I put T in the SIG, as it
says, so such future changes could be indicated within the DSA
algorithm.
>draft-ietf-dnssec-rsa-00.txt
>- The European equivalent of RSAREF is called RSAEURO, not EuroRef.
Thanks, I'll fix that.
>draft-ietf-dnssec-secops-01.txt
>- A small addition to Section 4.2, DSS Key Sizes. DSS signatures are not
> only smaller than RSA sigs, they are a fixed size regardless of key
> size (41 octets currently, 40 if T is removed).
OK.
>draft-ietf-dnssec-secext2-05.txt
>- Transaction signatures have a flaw. There is no way for a resolver to
> specify that the response to a query MUST be signed. A resolver is not
> required to drop a response with no transaction signature when it
> expects the response to have one. Thus, the signature is useful when
> present, but if not present, it could be the result of an attacker
> stripping off the signature and modifying the payload.
Since in DNSSEC, these are public key signatures, they are quite
expensive computationally. It is unreasonable in general to require
that servers sign responses or check signatures on requests. Perhaps,
instead of just saying that they are "optional", the draft should say
they are only added or checked by mutual agreement...
>Comments?
>
>Brian
Thanks for the comments,
Donald