From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed Jun 4 02:47:52 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05691 for ; Wed, 4 Jun 2003 02:47:51 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h546hPH15337 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 4 Jun 2003 02:43:27 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h546iJw14691 for ipseckey-outgoing; Wed, 4 Jun 2003 02:44:19 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h546iIl14686 for ; Wed, 4 Jun 2003 02:44:18 -0400 (EDT) Received: from bsdi.dv.isc.org (c17249.carlnfd1.nsw.optusnet.com.au [210.49.138.109]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h546giH15329 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Wed, 4 Jun 2003 02:42:52 -0400 (EDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h546eBl3028636 for ; Wed, 4 Jun 2003 16:40:11 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h546eAK2041628 for ; Wed, 4 Jun 2003 16:40:10 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200306040640.h546eAK2041628@drugs.dv.isc.org> To: ipseckey@sandelman.ca From: Mark.Andrews@isc.org Subject: Re: [IPSECKEY] I-D ACTION:draft-ietf-ipseckey-rr-02.txt In-reply-to: Your message of "Fri, 23 May 2003 16:03:50 -0400." <200305232003.QAA23426@ietf.org> Date: Wed, 04 Jun 2003 16:40:10 +1000 Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca A bit of a delay here:-) Return-Path: owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Delivery-Date: Wed Jun 4 03:46:23 2003 Return-Path: Received: from localhost (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h53HkGK7038051 for ; Wed, 4 Jun 2003 03:46:22 +1000 (EST) (envelope-from owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca) X-Original-To: marka@farside.isc.org Delivered-To: marka@farside.isc.org Received: from farside.isc.org [204.152.187.5] by localhost with IMAP (fetchmail-6.2.0) for marka@localhost (single-drop); Wed, 04 Jun 2003 03:46:22 +1000 (EST) Received: from skid.isc.org (skid.isc.org [2001:4f8:4:d:290:27ff:fef7:1ad8]) by farside.isc.org (Postfix) with ESMTP id 63334A83A for ; Tue, 3 Jun 2003 17:45:13 +0000 (UTC) (envelope-from owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by skid.isc.org (Postfix) with ESMTP id 4A0598D629 for ; Tue, 3 Jun 2003 17:41:06 +0000 (UTC) (envelope-from owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4NKAJs09003 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Fri, 23 May 2003 16:10:21 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4NKB6v24379 for ipseckey-outgoing; Fri, 23 May 2003 16:11:06 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4NKB4q24373 for ; Fri, 23 May 2003 16:11:05 -0400 (EDT) Received: from mail2.flora.ca (madras3.flora.ca [192.139.46.245]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4NK9ls08990 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Fri, 23 May 2003 16:09:49 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail2.flora.ca (8.12.8/8.12.8) with ESMTP id h4NK9dKs022134 for ; Fri, 23 May 2003 16:09:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23426; Fri, 23 May 2003 16:03:51 -0400 (EDT) Message-Id: <200305232003.QAA23426@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipseckey@sandelman.ca From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [IPSECKEY] I-D ACTION:draft-ietf-ipseckey-rr-02.txt Date: Fri, 23 May 2003 16:03:50 -0400 Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed Jun 4 20:34:26 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19546 for ; Wed, 4 Jun 2003 20:34:25 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h550VAH22324 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 4 Jun 2003 20:31:12 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h550W3F23011 for ipseckey-outgoing; Wed, 4 Jun 2003 20:32:03 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h550W1m23004 for ; Wed, 4 Jun 2003 20:32:01 -0400 (EDT) Received: from sandelman.ottawa.on.ca ([2002:c08b:2e42::1]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h550UQd22292 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 4 Jun 2003 20:30:36 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h540iZQo022944 for ; Tue, 3 Jun 2003 20:44:35 -0400 Message-Id: <200306040044.h540iZQo022944@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations (pass 2) In-reply-to: Your message of "Fri, 23 May 2003 12:38:27 +0200." <20030523103827.GB2037@ivan.int-evry.fr> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 03 Jun 2003 20:44:34 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- {I think that this is a dead horse, but I didn't get all the emails in this thread sorted right...} >>>>> "JJ" == Jean-Jacques Puig writes: JJ> Question: what do you mean by: "In cases where the end-to-end integrity JJ> of the IPSECKEY RR is suspect" ? JJ> Do you mean: JJ> a) Implementation detected (how ?) or expects with a JJ> reasonnable probability that an active attack is JJ> under way. Then I JJ> agree the end client MUST restrict the use of the JJ> record. JJ> or: JJ> b) When there is no end-to-end integrity, (or when a JJ> gateway cannot JJ> know surely about that), the end client MUST restrict JJ> the use of JJ> the record. I mean (b). I don't know when one can determine (a) without DNSSEC, and if you have DNSSEC, well... So, if my gateway knows that it is loading good data for some zone, because, for instance, it *is* the DNS server for that zone, then it might be more lax. JJ> I'm really sorry to mess around with these problems of MAY/SHOULD/MUST, JJ> but I fear current statements let opened too many questions or may lead JJ> to restrict too much. Your text is reasonable. Am I to figure out how to integrate your text, or would you like to provide a straight diff where you feel it fits in? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPt1A8IqHRg3pndX9AQF2LgQAzdh2a4pzgt2blhUOjOR2RXHXyrdacIux tD+DUntD+kTwHznT4V4eCrz0bITE8y7/AWnuqjlXssnf8HtIA0aXs9bBA7Syjdpj RcX2yIUGY7GybbmSXAr+J7aQdr1SXz9CyF+z2KTKjti/MSGfwVypTg6Vmyl/Ji6r tU3NQigsMwA= =GEjk -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed Jun 4 23:10:14 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23923 for ; Wed, 4 Jun 2003 23:10:13 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5536EH23376 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 4 Jun 2003 23:06:16 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h5537Y403261 for ipseckey-outgoing; Wed, 4 Jun 2003 23:07:34 -0400 (EDT) Received: from fledge.watson.org (ak82hjs7hex92j@fledge.watson.org [204.156.12.50]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h5537Wm03241 for ; Wed, 4 Jun 2003 23:07:32 -0400 (EDT) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h5534uOn010697; Wed, 4 Jun 2003 23:04:56 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.12.9/8.12.9/Submit) with SMTP id h5534t8l010694; Wed, 4 Jun 2003 23:04:55 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 4 Jun 2003 23:04:55 -0400 (EDT) From: Sam Weiler Reply-To: Sam Weiler To: Michael Richardson cc: ipseckey Subject: [IPSECKEY] Generic algorithm test In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Fri, 30 May 2003, Sam Weiler wrote: > > Sam> Section 2.4: Needs to have generic text for any value, then the > > Sam> expansion for RSA and maybe mention the DSA doc, but not in it's own > > Sam> subsection. > > This is now 2.6/2.7. The new section 2.3 isn't clear on how (or if) > IPSECKEY automatically incorporates newly defined public key formats. > This needs to be clarified. > > 2.6 Should have generic text specifying how any key format is included, > with RSA and DSA given as examples, assuming that we want this to be > extensible. If we want to limit it to RSA/DSA, that should be made more > explicit. I've been having second thoughts about the wisdom of inheriting from the DNS Algorithm registry. Are all of the defined alogirthm types appropriate for IPSECKEY use? Is it likely that future ones will be? Remember that DNSSEC algorithms specify a hash, too, which is why RSA/MD5 and RSA/SHA1 have different algorithm values even though the data format is exactly the same. Do we want to prohibit use of type 1 (RSA/MD5)? What about the private formats? Assuming that inheritance is desired, here's some proposed text: RFC2535 established an IANA registry for DNS Security Algorithm Numbers, and subsequent documents have specified algorithms and associated KEY RR formats for use with DNSSEC. Rather than respecify those formats, this document reuses that registry and the associated KEY RR formats. The algorithm type field identifies the public key's cryptographic algorithm and determines the format of the public key field. The public key field contains the algorithm-specific portion of the KEY RR RDATA, omitting the first four octets of the KEY RR RDATA. This is the same portion of the KEY RR that must be specified by documents that define a DNSSEC algorithm. Those documents also specify a message digest to be used for generation of SIG RRs; that specification is not relevant to the IPSECKEY usage of the public key format. Example: RSA public keys Per the DNS Security Algorithm registry, an algorithm type of 5 identifies an RSA public key, encoded as described in section 2 of RFC3110. [The encoding of RSA/MD5 KEYs (type 1) specified in RFC2537 is the same as that defined in RFC3110. For simplicity and in keeping with RSA/MD5 being NOT RECOMMENDED for DNSSEC, type 1 SHOULD NOT be used in the IPSECKEY algorithm type.] The earlier definition of RSA/MD5 (algorithm type 1) in RFC2065 limited the exponent and modulus to 2552 bits in length. RFC3110 extended that limit to 4096 bits for RSA/SHA1 keys (type 5). The IPSECKEY RR imposes no length limit on type 5 public keys, other than the 65535 octet limit imposed by the two-octet length encoding. This length extension is applicable only to IPSECKEY and not to KEY RRs. And in the IANA considerations: This document updates the IANA Registry for DNS Resource Record Types by assigning type X to the IPSECKEY record. The values for the algorithm type field in the IPSECKEY record are inherited from the DNS Security Algorithm Numbers registry, and this document makes no changes to that registry. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed Jun 4 23:44:30 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24503 for ; Wed, 4 Jun 2003 23:44:30 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h553fTH24333 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 4 Jun 2003 23:41:31 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h553gqh05339 for ipseckey-outgoing; Wed, 4 Jun 2003 23:42:52 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h553gpm05334 for ; Wed, 4 Jun 2003 23:42:51 -0400 (EDT) Received: from fledge.watson.org (ak82hjs7hex92j@fledge.watson.org [204.156.12.50]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h553fNH24330 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Wed, 4 Jun 2003 23:41:25 -0400 (EDT) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h553e7On018132 for ; Wed, 4 Jun 2003 23:40:07 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.12.9/8.12.9/Submit) with SMTP id h553e7fd018129 for ; Wed, 4 Jun 2003 23:40:07 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 4 Jun 2003 23:40:07 -0400 (EDT) From: Sam Weiler To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Unknown format handling In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Fri, 30 May 2003, Sam Weiler wrote: > Does the document need to specify the handling of unknown gateway > types/formats (section 2.4)? We've heard no feedback on this. Anyone care? -- Sam - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Thu Jun 5 05:24:58 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12398 for ; Thu, 5 Jun 2003 05:24:57 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h559NsH26641 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 5 Jun 2003 05:23:57 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h559OvN16865 for ipseckey-outgoing; Thu, 5 Jun 2003 05:24:57 -0400 (EDT) Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h559OtE16853 for ; Thu, 5 Jun 2003 05:24:56 -0400 (EDT) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 67AD53426B; Thu, 5 Jun 2003 11:19:50 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 155563F405; Thu, 5 Jun 2003 11:24:30 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003060511194910421 ; Thu, 05 Jun 2003 11:19:50 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 426C93F405; Thu, 5 Jun 2003 11:24:29 +0200 (CEST) Received: from jjp by localhost with local id 19NquQ-0002mB-00; Thu, 05 Jun 2003 11:19:46 +0200 Date: Thu, 5 Jun 2003 11:19:46 +0200 From: Jean-Jacques Puig To: Sam Weiler Cc: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Unknown format handling Message-ID: <20030605091946.GA10387@ivan.int-evry.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Wed, Jun 04, 2003 at 11:40:07PM -0400, Sam Weiler wrote: > On Fri, 30 May 2003, Sam Weiler wrote: > > > Does the document need to specify the handling of unknown gateway > > types/formats (section 2.4)? > > We've heard no feedback on this. Anyone care? I care, but I lack knowledge of practices for RRs design. Is this point closely tied to DNS / Resolvers operations or is it up to a user scenario of the RR to tackle it ? Do RR proposals usually specify handling of unknown values for fields of this kind ? Isn't it implicit that in case of the occurence of such an event, the RR should be ignored ? Is it implicit in cases where other fields (algo type, etc) have unknow values ? Is there a need to define RESERVED or VENDOR SPECIFIC ranges for this field ? -- Jean-Jacques Puig - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Thu Jun 5 15:23:22 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13161 for ; Thu, 5 Jun 2003 15:23:21 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h55JMQH29071 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 5 Jun 2003 15:22:28 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h55JNPd01033 for ipseckey-outgoing; Thu, 5 Jun 2003 15:23:25 -0400 (EDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h55JNOi01028 for ; Thu, 5 Jun 2003 15:23:24 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 75DD218EC for ; Thu, 5 Jun 2003 15:20:50 -0400 (EDT) Date: Thu, 05 Jun 2003 15:20:50 -0400 From: Rob Austein To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Unknown format handling In-Reply-To: <20030605091946.GA10387@ivan.int-evry.fr> References: <20030605091946.GA10387@ivan.int-evry.fr> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030605192050.75DD218EC@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca At Thu, 5 Jun 2003 11:19:46 +0200, Jean-Jacques Puig wrote: > > > On Fri, 30 May 2003, Sam Weiler wrote: > > > Does the document need to specify the handling of unknown gateway > > > types/formats (section 2.4)? > > Is this point closely tied to DNS / Resolvers operations or is it up to > a user scenario of the RR to tackle it ? It's just payload as far as DNS is concerned. > Do RR proposals usually specify handling of unknown values for fields of > this kind ? Since this RR is just DNS payload, the main thing here is the set of constraints documented in draft-ietf-dnsext-unknown-rrs. > Isn't it implicit that in case of the occurence of such an event, the RR > should be ignored ? Is it implicit in cases where other fields (algo > type, etc) have unknow values ? Some people think that a spec should constrain as little as possible (but no less). Others think that a spec should specify how to handle unknown values ("ignore any such RR" would appear to be the only sane candidate in this case, since the gateway type determines the length of the gateway field (and no, I don't think we want to change that)). In either case, this is a general question of what a protocol spec ought to say about unassigned values in an enumerated field, and is not particularly specific to DNS. > Is there a need to define RESERVED or VENDOR SPECIFIC ranges for this > field ? Unless there's consensus right now to do this, I'd suggest just leaving it alone. It's easy to allocate a portion of the space at some later date, much more painful to take it back. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon Jun 9 11:02:39 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07931 for ; Mon, 9 Jun 2003 11:02:38 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h59Ewwq07295 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 9 Jun 2003 10:59:00 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h59F07S09490 for ipseckey-outgoing; Mon, 9 Jun 2003 11:00:07 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h59F06X09485 for ; Mon, 9 Jun 2003 11:00:06 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h59EwZq07290 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 9 Jun 2003 10:58:36 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h59EwYiP029351 for ; Mon, 9 Jun 2003 10:58:35 -0400 Message-Id: <200306091458.h59EwYiP029351@sandelman.ottawa.on.ca> To: ipseckey Subject: Re: [IPSECKEY] Generic algorithm test In-reply-to: Your message of "Wed, 04 Jun 2003 23:04:55 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 09 Jun 2003 10:58:34 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca >>>>> "Sam" == Sam Weiler writes: Sam> I've been having second thoughts about the wisdom of inheriting from Sam> the DNS Algorithm registry. Are all of the defined alogirthm types Sam> appropriate for IPSECKEY use? Is it likely that future ones will be? If there are future public key algorithms defined, they would be appropriate. Sam> Remember that DNSSEC algorithms specify a hash, too, which is why Sam> RSA/MD5 and RSA/SHA1 have different algorithm values even though the Yes, as does IKE, for the same reason. If we do not want to use DNSSEC values, then we can use IKE values: http://www.iana.org/assignments/ipsec-registry It doesn't matter to me. Or we can create a new space. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon Jun 9 11:03:54 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07961 for ; Mon, 9 Jun 2003 11:03:54 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h59Exkq07306 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 9 Jun 2003 10:59:49 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h59F1Fj09568 for ipseckey-outgoing; Mon, 9 Jun 2003 11:01:15 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h59F1EX09562 for ; Mon, 9 Jun 2003 11:01:14 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h59Exhq07303 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 9 Jun 2003 10:59:44 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h59ExhkX029407 for ; Mon, 9 Jun 2003 10:59:43 -0400 Message-Id: <200306091459.h59ExhkX029407@sandelman.ottawa.on.ca> To: ipseckey Subject: Re: [IPSECKEY] Generic algorithm test In-reply-to: Your message of "Wed, 04 Jun 2003 23:04:55 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 09 Jun 2003 10:59:42 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Well, I take that back. IKE values do not specify the format of the public key. That's really what we care about - that the bits-on-the-wire format is "well known" ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue Jun 10 14:15:38 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11408 for ; Tue, 10 Jun 2003 14:15:38 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5AIEeq13531 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 10 Jun 2003 14:14:42 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h5AIFnn08496 for ipseckey-outgoing; Tue, 10 Jun 2003 14:15:49 -0400 (EDT) Received: from one.elistx.com (one.elistx.com [209.116.252.130]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h5AIFlM08475 for ; Tue, 10 Jun 2003 14:15:48 -0400 (EDT) Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HGA004LZ2P2WE@eListX.com> for ipseckey@lox.sandelman.ottawa.on.ca; Tue, 10 Jun 2003 14:15:03 -0400 (EDT) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3p2/8.12.3) with ESMTP id h5AIAHNO012590; Tue, 10 Jun 2003 14:10:18 -0400 (EDT envelope-from ogud@ogud.com) Date: Tue, 10 Jun 2003 14:13:59 -0400 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: [IPSECKEY] Generic algorithm test In-reply-to: <200306091459.h59ExhkX029407@sandelman.ottawa.on.ca> X-Sender: post@localhost To: Michael Richardson , ipseckey Message-id: <5.1.1.6.2.20030610141027.0200e538@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii References: Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca At 10:59 2003-06-09, Michael Richardson wrote: >Well, I take that back. IKE values do not specify the format of the public >key. That's really what we care about - that the bits-on-the-wire format >is "well known" I think that separate registry is in order, the requirements for registration are reference to IKE algorithm, reference to DNS key wire format or specification of wire format. Adding new algorithm requires IETF [consensus, standards action] ? Value 1 is IKE authentication method 3 and format is RSA/MD5 specified in RFC2536. etc. Olafur - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From mcr@lox.sandelman.ottawa.on.ca Sun Jun 15 11:47:15 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04785 for ; Sun, 15 Jun 2003 11:47:14 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5FFkpQ06041 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Sun, 15 Jun 2003 11:47:15 -0400 (EDT) Received: (from mcr@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h5FFkav15803; Sun, 15 Jun 2003 11:46:36 -0400 (EDT) Date: Sun, 15 Jun 2003 11:46:36 -0400 (EDT) Message-Id: <200306151546.h5FFkav15803@lox.sandelman.ottawa.on.ca> From: mcr@sandelman.ottawa.on.ca Subject: [ipseckey] Monthly information file for ipseckey@sandelman.ottawa.on.ca To: ipseckey-archive@ietf.org BOF description IPSEC KEYing information resource record WG (ipseckey) Please see http://www.ietf.org/html.charters/ipseckey-charter.html for the official page. To unsubscribe, email to majordomo@sandelman.ca, body is: "unsubscribe ipseckey" You can always ask majordomo@sandelman.ottawa.on.ca to remove you from any list hosted by Sandelman Software This message sent to ipseckey-archive@lists.ietf.org From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue Jun 17 19:03:39 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15643 for ; Tue, 17 Jun 2003 19:03:38 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5HN2kq18509 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 17 Jun 2003 19:02:48 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h5HN3lg17047 for ipseckey-outgoing; Tue, 17 Jun 2003 19:03:47 -0400 (EDT) Received: from sentry.rv.nailabs.com (firewall-user@sentry.rv.nailabs.com [204.254.155.100]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h5HN3km17036 for ; Tue, 17 Jun 2003 19:03:46 -0400 (EDT) Received: by sentry.rv.nailabs.com; id TAA17394; Tue, 17 Jun 2003 19:03:33 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma017388; Tue, 17 Jun 03 19:03:12 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6p2/8.11.6) with ESMTP id h5HN0Dc23896; Tue, 17 Jun 2003 19:00:13 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Tue, 17 Jun 2003 19:00:13 -0400 (EDT) From: Sam Weiler X-X-Sender: To: cc: ipseckey Subject: [IPSECKEY] IPSECKEY inheritance of DNSSEC algorithm registry In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca The IPSECKEY RR definition draft is nearing WG last call -- this would be a good time to review the document. The chairs would particularly like feedback on whether or not the IPSECKEY record should inherit format definitions from the DNS Security Algorithm registry -- if someone defines a (DNS)KEY RR format for Sam's Public Key Algorithm, does it automagically show up as an IPSECKEY format? The text in draft-ietf-ipseckey-rr-04.txt is internally inconsistent, but the intent with this version was that, yes, the formats are inherited. Please send all comments to the IPSECKEY list. General Discussion: ipseckey@sandelman.ca To Subscribe: ipseckey-request@sandelman.ca Archive: http://www.sandelman.ca/lists/html/ipseckey/ http://www.ietf.org/html.charters/ipseckey-charter.html http://www.ietf.org/internet-drafts/draft-ietf-ipseckey-rr-04.txt -- Sam - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed Jun 18 05:54:29 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25458 for ; Wed, 18 Jun 2003 05:54:28 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5I9rWq21266 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 18 Jun 2003 05:53:34 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h5I9sfI14224 for ipseckey-outgoing; Wed, 18 Jun 2003 05:54:41 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h5I9saV14207 for ; Wed, 18 Jun 2003 05:54:36 -0400 (EDT) Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 9C5101C; Wed, 18 Jun 2003 13:02:38 +0300 (EEST) Message-ID: <3EF036B2.5000508@nomadiclab.com> Date: Wed, 18 Jun 2003 12:53:54 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Weiler Cc: namedroppers@ops.ietf.org, ipseckey Subject: Re: [IPSECKEY] IPSECKEY inheritance of DNSSEC algorithm registry References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Content-Transfer-Encoding: 7bit Sam Weiler wrote: > The chairs would particularly like feedback on whether or not the > IPSECKEY record should inherit format definitions from the DNS > Security Algorithm registry -- if someone defines a (DNS)KEY RR format > for Sam's Public Key Algorithm, does it automagically show up as an > IPSECKEY format? I am in favour of inheriting the definitions. The same definitions are currently being reused in HIP, and I am proposing that we use those also in SEND. (SEND currently specifies ASN.1 OIDs, but I personally see little value in that.) In particular, what comes to the following: > 2.3 RDATA format - algorithm type > .... > The public key field contains the algorithm-specific portion of the > KEY RR RDATA, omitting the first four octets of the KEY RR RDATA. > This is the same portion of the KEY RR that must be specified by > documents that define a DNSSEC algorithm. Those documents also > specify a message digest to be used for generation of SIG RRs; that > specification is not relevant to the IPSECKEY usage of the public key > format. I think the intention of the text is excellent. It aligns very well with the current HIP usage of RFC2535 key formats. However, it might be good to explicitly mention that the first four octets would contain the flags, protocol, and algorithm fields, which are now left away. A couple of comments: Should there be a reserved octed before the gateway field, thereby aligning the gateway field to 32-bit boundary? AAAA RDATA format is defined in Section 2.2 (not 3.2) of RFC1886. --Pekka Nikander - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed Jun 18 07:54:21 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28423 for ; Wed, 18 Jun 2003 07:54:20 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5IBrXq21495 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 18 Jun 2003 07:53:35 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h5IBt0A05142 for ipseckey-outgoing; Wed, 18 Jun 2003 07:55:00 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h5IBsvV05137 for ; Wed, 18 Jun 2003 07:54:57 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5IBrJq21492 for ; Wed, 18 Jun 2003 07:53:20 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28185; Wed, 18 Jun 2003 07:53:18 -0400 (EDT) Message-Id: <200306181153.HAA28185@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipseckey@sandelman.ca From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [IPSECKEY] I-D ACTION:draft-ietf-ipseckey-rr-04.txt Date: Wed, 18 Jun 2003 07:53:17 -0400 Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPSEC KEYing information resource record Working Group of the IETF. Title : A method for storing IPsec keying material in DNS Author(s) : M. Richardson Filename : draft-ietf-ipseckey-rr-04.txt Pages : 15 Date : 2003-6-17 This document describes a new resource record for DNS. This record may be used to store public keys for use in IPsec systems. This record replaces the functionality of the sub-type #1 of the KEY Resource Record, which has been obsoleted by RFC3445. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipseckey-rr-04.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-ipseckey-rr-04.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-ipseckey-rr-04.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: <2003-6-17144533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipseckey-rr-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipseckey-rr-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17144533.I-D@ietf.org> --OtherAccess-- --NextPart-- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Thu Jun 19 14:09:39 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06232 for ; Thu, 19 Jun 2003 14:09:34 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5JI7aq28419 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 19 Jun 2003 14:07:38 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h5JI8cQ20226 for ipseckey-outgoing; Thu, 19 Jun 2003 14:08:38 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h5JI8br20221 for ; Thu, 19 Jun 2003 14:08:37 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5JI6qq28416 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Thu, 19 Jun 2003 14:06:58 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h5JI6pdZ021392 for ; Thu, 19 Jun 2003 14:06:51 -0400 Message-Id: <200306191806.h5JI6pdZ021392@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: [IPSECKEY] Re: IPSECKEY inheritance of DNSSEC algorithm registry Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 19 Jun 2003 14:06:50 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca {email from non-subscriber. Now added to exception list} From: "Scott Rose" To: "Sam Weiler" Cc: References: Subject: Re: IPSECKEY inheritance of DNSSEC algorithm registry Date: Wed, 18 Jun 2003 10:08:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Since it is an IANA registry and not just IETF consensus, it seems easier. I don't know of a IPSEC specific registry of algorithm codes/encodings that fit better. One thing that might cause trouble is that the RSA/MD5 is listed as "not recommended" in DNSSEC, which means it may not be supported by poorly implemented resolvers (or worse, generate some error). A note could be added that the status of the algorithm (NOT RECOMMENDED, MANDATORY, etc) does not apply to the IPSECKEY unless stated in a IPSECKEY draft. Future encoding RFC authors should take IPSECKEY and other (possible future) RR types into consideration. Is there any reason NOT to allow this? Scott PS - not a memeber of ipseckey mailing list - so flame me directly. ----- Original Message ----- From: "Sam Weiler" To: Cc: "ipseckey" Sent: Tuesday, June 17, 2003 7:00 PM Subject: IPSECKEY inheritance of DNSSEC algorithm registry > The IPSECKEY RR definition draft is nearing WG last call -- this would > be a good time to review the document. > > The chairs would particularly like feedback on whether or not the > IPSECKEY record should inherit format definitions from the DNS > Security Algorithm registry -- if someone defines a (DNS)KEY RR format > for Sam's Public Key Algorithm, does it automagically show up as an > IPSECKEY format? > > The text in draft-ietf-ipseckey-rr-04.txt is internally inconsistent, > but the intent with this version was that, yes, the formats are > inherited. > > Please send all comments to the IPSECKEY list. > General Discussion: ipseckey@sandelman.ca > To Subscribe: ipseckey-request@sandelman.ca > Archive: http://www.sandelman.ca/lists/html/ipseckey/ > > http://www.ietf.org/html.charters/ipseckey-charter.html > http://www.ietf.org/internet-drafts/draft-ietf-ipseckey-rr-04.txt > > -- Sam > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed.