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" X-Mts: smtp Sender: owner-dns-security@ex.tis.com Precedence: bulk ------- Forwarded Message Message-Id: In-Reply-To: <2.2.16.19980827140054.0dd7abc4@mailer.packet.net> Date: Fri, 28 Aug 1998 08:57:32 -0400 From: Robert Hettinga 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 Philodox Financial Technology Evangelism 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 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." Date: Mon, 31 Aug 1998 14:50:45 -0400 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-dns-security@ex.tis.com Precedence: bulk Brian, From: Brian Wellington Date: Wed, 29 Jul 1998 11:32:30 -0400 (EDT) To: dns-security@tis.com Message-ID: >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