From owner-namedroppers@ops.ietf.org Thu Sep 01 02:41:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAilR-0000N7-EQ for dnsext-archive@megatron.ietf.org; Thu, 01 Sep 2005 02:41:33 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28439 for ; Thu, 1 Sep 2005 02:41:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAifG-0009vm-KM for namedroppers-data@psg.com; Thu, 01 Sep 2005 06:35:10 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EAifC-0009vE-EV for namedroppers@ops.ietf.org; Thu, 01 Sep 2005 06:35:06 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.3/8.13.3) with ESMTP id j816Z1tu089505 for ; Thu, 1 Sep 2005 08:35:01 +0200 (CEST) (envelope-from olaf@open.nlnetlabs.nl) Received: (from olaf@localhost) by open.nlnetlabs.nl (8.13.3/8.13.3/Submit) id j816Z05m089501 for namedroppers@ops.ietf.org; Thu, 1 Sep 2005 08:35:00 +0200 (CEST) (envelope-from olaf) Date: Thu, 1 Sep 2005 08:35:00 +0200 (CEST) From: Olaf Kolkman Message-Id: <200509010635.j816Z05m089501@open.nlnetlabs.nl> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e. follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.8 2005/01/12 15:54:51 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 02 12:15:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBECO-0007S0-Vp for dnsext-archive@megatron.ietf.org; Fri, 02 Sep 2005 12:15:34 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15872 for ; Fri, 2 Sep 2005 12:15:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EBE5c-000JEw-I0 for namedroppers-data@psg.com; Fri, 02 Sep 2005 16:08:28 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EBE5W-000JE3-1j for namedroppers@ops.ietf.org; Fri, 02 Sep 2005 16:08:23 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j82G8D8m055443 for ; Fri, 2 Sep 2005 12:08:13 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j82G8DFZ055442 for namedroppers@ops.ietf.org; Fri, 2 Sep 2005 12:08:13 -0400 (EDT) (envelope-from namedroppers) Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EAuOK-000IZ6-1W for namedroppers@ops.ietf.org; Thu, 01 Sep 2005 19:06:29 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j81J60h7051003; Thu, 1 Sep 2005 15:06:01 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.3.4.2.20050901145800.04065900@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 01 Sep 2005 15:04:39 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: DNSEXT Minutes @ IETF-63 Cc: proceedings@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Minutes of the DNSEXT working group 63rd IETF, Paris, France August 3rd 2005 Chairs: Olafur Gudmundsson Olaf Kolkman Scribes: Jelte Jansen (minutes) Wes Griffin (jabber) Previous Minutes ================ There were no comments on the previous minutes. Agenda Bashing ============== There were no comments on the agenda. Documents ========= The documents are handled in a last-call order. Documents that are past last call: draft-ietf-dnsext-mdns-41: waiting for the chairs to go over the document to see if all changes have been made. draft-ietf-dnsext-tsig-sha-04: waiting for a chair to make a summary for the area director. draft-ietf-dnsext-wcard-clarify-08: chair will write summary and submit the document. draft-ietf-dnsext-rfc2538bis-03: exact current state unknown, but it should be close to standard now. Documents in last call: draft-ietf-dnsext-dns-name-p-s-00 and draft-ietf-dnsext-dnssec-online-signing Olaf is not sure what status these documents will need to get, experimental, informational or standards track. There seems to be little interest for these documents, at least on public channels. Peter Koch: DENIC would like to see an implementation for this. They are still evaluating, but this is definitely on their path to DNSSEC. He is not sure that experimental is appropriate, since it modifies the protocol. Olaf: there won't be any difference on the wire, in the way that packets are built. And if the consensus is to put it on the standards track, this discussion would become irrelevant. Olaf asks the working group to heed the last call and look at the documents. draft-ietf-dnsext-dnssec-trans-02: the authors would like another round before last call. Documents close to last call: draft-ietf-dnsext-experiments-01: will be in last call in September. The DNSKEY algorithm documents are all ready for last call, last call will start soon (draft-ietf-dnsext-rfc2536bis-dsa-06, draft-ietf-dnsext-rfc2539bis-dhk-06 and draft-ietf-dnsext-ecc-key-07). Ongoing work: draft-ietf-dnsext-dnssec-bis-updates-01: Olaf asks the working group to send anything of notice (implementors, readers who see weird language, etc.) in the DNSSEC docs to Sam Weiler, so it can be included. draft-ietf-dnsext-nsec3-02: there is a new version of this document. Olaf Kolkman wants at least one workshop with running code before advancing this document, between now and the IETF in Vancouver. Olaf Kolkman mentions that old and expired documents can be found on http://tools.ietf.org/wg/dnsext Update on NSEC3 =============== Roy Arends reports that most of the changes in the document are textual. There is still some uncertainty on whether truncating hashes is a good idea. Now the documents allows for a signal that hashes are truncated. There are some clarifications on dos issues, and an example has been included. They are waiting for -trans and -ter to stabilize before specifying the way to indicate NSEC3 is used. The next version of the document will address rolling NSEC to NSEC3. Some tools have been implemented: an NSEC3-capable signer, based on Net::DNS(::SEC), and a NSEC3-capable server for testing corner cases. There should also be NSEC2 patches for bind, but we'll see that on the list. Mark Kosters: we plan to have nsec3-capable servers before the workshop. Miek Gieben asked why include opt-in? Roy still thinks technically there's nothing wrong with it. OPT-IN would have stopped progress on last docs, now time is right. There was some further discussion if NSEC3 and OPT-IN are separative and/or required. Chair made the comment that if Opt-In feature is removed from NSEC3 then that requires changing the name to NSEC4. A large operator commented that they will not deploy DNSSEC without opt-in for number of operational reasons including significant churn of names. Rob and chairs appeals to room: please review the old discussion on OPT-IN. IPR Issues update ================= Olafur reports that there are two different drafts to manage trust anchors: draft-ietf-dnsext-trustupdate-timers-00 and draft-ietf-dnsext-trustupdate-threshold-00 Both documents have had an IPR claim filed against them. The patent this has been issued in one country at the moment (Israel) but filed in some other countries as well, just not approved (yet). There is a license available that is royalty free, but does have some terms. So implementors either don't know what to do or are ignoring it. Automatic Updates of DNSSEC trust anchors ========================================= Olafur Gudmundsson reports that having no key management standard might become the next excuse for not deploying DNSSEC. Early adaptors may need to bear additional costs configuring trust anchors. The need for configured trust anchors will never disappear, in the best case it might be reduced to only one anchor, the root. Olafur pleas to the working group for more activity here. Authors are frustrated with the complete silence on this issue, they cannot continue until there is discussion, feedback, a list of selection criteria and a time line. Bill Manning: I see silence as consent, and the document should go to last call. Mike StJohns: Well the problem is that there are two documents that met with silence, so my document was approved-by-silence too. Olaf Kolkman: the working group decided once that there should only be one solution. On the other hand these documents do not exclude each other, one is purely operational. Mike StJohns: I disagree, both change resolver behavior. Mark Andrews: We definitely need to decide on one or the other, because it will have impact on how operators do their key management. I do not want to try managing both. Sam Weiler: I'm not sure if we have to make a choice, is there any harm in a resolver not following these drafts? Mike StJohns: by ignoring the timer bit the trust anchors won't be updated and things go stale. Olafur: and in the case of 2 mechanisms there should be signalling for zones to declare which method they use. Mark Andrews: Well something has to notice keys are changing, not necessarily resolvers, so they don't have to change. It could be an external tool. Russ Mundy: My understanding is that the mechanism should not prevent other mechanisms to update keys. Olafur: Yes, this is just a way for validator to do it in-band. Mike: if you have a mechanism people will not pay as much attention, and those who don't will fall behind. Russ: but it was not intended to be an exclusive mechanism. Mike: If operators are making different choices a signalling mechanism becomes interesting. Sam Weiler: I was hearing this 'you have to have a signaling mechanism' as 'you have to have one in-band', which suggests to me that you have to have one whether you use one of these schemes or none at all. If we can get away with saying it's all out of band when you first configure a trust anchor you say which method you're using, then the proposals are not mutually exclusive. Mike: A problem is, the trust anchor may or may not do automatic rollover, but you don't know when you configure your server. Olaf: The keying policy needs to be known. Mike: The policy will be decided by the one that ships the software. Most people will ignore it, do whatever works. Rip Loomis: I have read both drafts, and could not decide on one. Could the authors make statements why their solution is the better one? Or if someone thinks we can do both, please say that. Another point: even if you have auto-rekey, there should still be a methodology to do it manually. Sam Weiler: I heard Mike wants to be able to use schemes with already configures trust anchors. Mike: Well anything we can do to off load operator load on end-users will improve deployment. Like web browser certificates. Olaf: I think we all agree that we don't want people going back to their configuration and changing things all the time. Rip Loomis: I would like a 1 paragraph statement (or abstracts or differences) about the drafts from the authors on the list. Bill Manning: I would like someone unbiased and not involved in these documents to write a short document with abstracts and differences Jim Cassels is volunteered to do this. He agrees. Action point: Jim Cassels will write a short document on the differences between the two automated key rollover drafts. Rob Austein: Could we have a verbal summary now? Wes Hardaker: If i look at other protocols with keys, the ones without automatic key rollover get deployed, but the keys just never change. They are not rolled at all or their lifetimes are exceptionally long. Olaf: We could say we use very short lifetimes, so the operators will get bitten quickly. That's the other way to get keys changed. Wes: Only if you document that in advance in a protocol, otherwise users will do whatever they want. Olafur Summarizes the two drafts, and asks if people have feelings about either one. Mike: the revoke solution deals explicitly with key compromise, not operational errors. Rob Austein (directed to Olaf Kolkman): you recently did tests on bandwidth usage with DNSSEC. Does the n out of m proposal have a lot of impact on servers in that way? Olaf: currently there is an implementation that sends the key in the additional section of the answer packet. With that implementation, it would have a lot of impact. Apart from that, it is an orthogonal question. Only relevant if the DNSKEY RRset lives in the answer or authority section of the packet, because then we'll get truncation issues. We should try to keep the packet sizes below 2048 bits, because that's what i see on the wire now. Olafur shows an old spreadsheet that shows DNSKEY packet sizes for different algorithms with different numbers of keys. Assuming: domain: ogud.com Assuming: always a rollover in progress for both KSK and ZSK Assuming: 2-3 threshold Assuming: RSA KEYS ZSK: 768 bits KSK: 1536 and all keys sign DNSKEY set Timers Proposal has 2 KSK and 2 ZSK: DNSKEY RRset is 1365 bytes on the wire (assuming name compression) Threshold Proposal: has 3 KSK and 2 ZSK DNSKEY RRset is 1788 bytes. There was some discussion on the minimum number of each type of key and one person voiced some concerns that n-of-m mechanism DNSKEY set was worrying large. There was also a comment that ECC keys are much smaller for same strength so that might be part of the solution. Miek Gieben: Back to the proposals. I don't like the revoke bit, if you leave it out of that proposal, then the m out of n stuff seems an implementation of the other proposal without the revoke bit. Mike StJohns: No, the revoke bit helps you maintain coherence. The other proposal has a lot of ways to make mistakes operationally. There's a lot of interesting problems with respect to how you do the stuff. Miek: From what I understand now, you can even combine the two into one thing. Do them both at the same time. Mike: Well it seems that the minimum number of keys is 2, and it can't actually be lower without losing the compromise protection. Sam Weiler: I like the idea of having a revocation mechanism, but I'm a little bit worried about this one. If a resolver that does not know about the revoke bit gets a key that has that bit set, can it still use that key for validation? If so, we may want to look at a different signalling mechanism, and I would suggest that the working group is about to last call a draft written by mister Blacka, which suggests one, which could also be signalling which mechanism is in use. Mike: There is specific language in the document about how the revoke bit does not make it any worse than without it. Sam: I think it might be, because with the revoke bit, you might keep a key published for longer that you otherwise might. Olaf: Changing the revoke bit changes the key, as soon as you swap it you change the key, and the validator does not recognize it as the same key any more. Johan Ihren: First, about packet size. The assumption was that with 4K packet size, we would be safe. With 2K i do not know. We need to look at that further. As regards to the ability to get rid of all trust anchors by mistake, however, DNS is a lot of rope, if people want to shoot themselves in the foot, they can easily do that already, without DNSSEC. DNSSEC just gives them more rope. So in my opinion, the real task here is to find a mechanism that makes it viable to deploy it large-scale, so that it'll actually work on the full Internet. That we'll need software development to make that work without mistakes is kind of clear. If someone chooses to go around software tools that cater towards avoiding mistakes, and makes changes manually, than that person will be in for a bumpy ride regardless. Olaf: On 4K and 2K limits. (shows screen with statistics about packets on reverse zones). You essentially only see 2048 and 4096 advertised as the size clients can handle. 2048 is a significant proportion of that, and so we have to consider it as something the DNSKEY and signatures have to fit in. Rob Austein: We once looked at a proposal that had revocation, and we dropped it because it was too difficult to make it work. The people that got the revocation signal were the people that did not need it. Here, with key id's changing because of the revocation bit, i think we might be okay. Given that, revocation seems at least somewhat useful to me, I don't think it really changes the PKI-ness of DNSSEC. Last comment: I don't really have a strong feeling yet, but i'm leaning more towards the proposal of Mike at the moment. Olaf: Let's have a show of hands. * Who wouldn't mind if we go in the direction of the StJohns document, with revocation, which means resolver updates? Couple of hands. * Who wouldn't mind if we go in the other direction? Again, couple of hands. * Does anyone have a strong preference for either one? Not really. Olaf: I think we need to do this on the list. Jim Cassel, you have an action point. I think we need to decide on this before next meeting in Vancouver. Olafur: Minor point. both documents are expired now. We can either ask the authors to submit a new version or I can ask the area director to have them revived in current state. Mike StJohns: We can't just resubmit it because the boiler plate keeps changing underneath us. If you can get it revived, please do. If not, please let us know and I'm marginally willing to do it. Johan Ihren:I'll submit a new version. NSID ==== Rob Austein reports about a proposal that is not yet a working group item: the NSID proposal. This came out of the work in the dnsop working group, where Rob is co-chair, so he can't author there. There are repeated requests for a standard way to identify the server that gave an answer. Especially in anycast settings where different queries can be answered by different servers this could be very helpful for debugging. The current ad-hoc way uses a separate query in the CHAOS class, and there were effort to make a standard out of this. But those efforts got stuck, and that's were it's been at for a couple of years. Last year we revived that draft, changing the recommendation so that it is no longer an extension of the CHAOS class TXT record hack, and basically the draft was a problem statement, and a description of the existing mechanisms that have already been deployed. That called for a solution, maybe at another group, possibly a protocol extension, that would solve the problem. That's what this draft is supposed to be. It's a very simple mechanism, it's in EDNS, because that's the only place we can put extensions in anymore. There's a flag bit in which you can state in a query: "oh by the way, could you please identify yourself, server", and there's an EDNS option field in which the server can reply, stating what it's identity is. Identity is very carefully left undefined, that's one of the changes since last round. The two open issues from when I presented this last year are: * What should the payload of the response be? It could be the real name, or the real address. There are security issues. So i asked around about this and the feedback i got was, can we please just make it an arbitrary string. So it's basically becomes a cookie that the server operator can use for debugging. The main point of using a protocol extension instead of a separate query is that quick routing changes might change the server your second query goes to. You have to be able to add it in the packet. * Whether or not recursive nameservers can play too. The original request only had to do with authoritative nameservers, but there's no real reason not to do this with recursive nameservers and we know that there are anycast setups with recursive nameservers too. The mechanism is quite explicitly defined as not being transitive. So the bit means 'server I sent this packet to, please identify yourself", so it applies equally well to recursive nameservers. The question is: should it? My personal opinion is that it should, no one argued with me, I did not get a lot of feedback on this one, so I left it like that for the moment. The requirements document is in last call at dnsop, but it got hung up there, long story. So the question is do we want to make a working group item of this, and do we want to wait for the requirements, assuming they ever appear. During discussion there was strong preference shown for getting this document done soon. People like this mechanism, and in particular the fact the string is just an simple identifier that can be set to any value. There was a question about support for recursive queries of NSID, but that issue is not addressed and will not be addressed until after this is done. Document was adopted as WG item and milestone to be added that the WG process to document before next meeting. DNS IANA Considerations ======================= Donald Eastlake presents some drafts about cryptographic algorithms. First something about draft-ietf-dnsext-ecc-key-07: There have been some questions in the past about patents, but as far as is known, these only cover specific implementations, not on the basic theory or scheme of it, perhaps on specific equations. Algorithm number 4 has always been reserved for ECC, and this draft proposes a specific format for ECC keys and signatures in the DNS. People need to read it and comment on it. Olafur: The chairs would like this to hit last call soon, and it would be great if someone can implement it, and can comment on how useful it is. We have been getting statements from cryptographers that ECC's are really good, and that signature and key sizes are significantly smaller than RSA. So it is a very interesting addition, so any technical feedback would be great. Back to IANA considerations: draft-eastlake-dnsext-2929bis-01. Donald Eastlake reports that rfc2929 was the first IANA considerations document for RR types, classes, rcodes, opcodes, header bits, et cetera. It provided some private numbers, depending on how numerous the particular item was, some publication required, and a few higher level IETF consensus or standards actions. What people are mostly interested in was RR types. It defines thing for the other numbers too, but people are mostly worried about the ease or difficulty of getting new RR types. Publication required was supposed to be pretty easy, but it appears that no RR type has ever been allocated based on the provision of publicly available publication. There was a discussion on the list, and there is a mechanism in rfc4020, called "Early Allocation". If something is going to be a standards track parameter, and there's working group consensus, and some other things, then you can get a temporary early allocation of an IANA parameter value. It's supposed to last a year, and then you have to request renewal, if it hasn't progressed to the point where it's in a standards track draft. The discussion on the left was that it was still too strict. For instance there were things that were heading for experimental, there were competing proposals. The early allocation seems to only apply on single proposals that are known to become standard, were early allocation is only there to make things more convenient, but people wanted something more loose than that. So this draft tries to do things easier, and wrote 2929bis. The main effect is to try to make things more liberal. In many cases it replaces what used to say "IETF consensus" with "DNS special allocation policy", and there's a part in the document which defines what this allocation policy is. There are also some other little things in the document, some things about AFSDB, a specification required subset of values for RCODE, and other minor changes, some updates to rfc references. The "DNS special allocation policy" is like rfc4020, but with looser requirements. What it currently says is one of: * Standards action * Approval of something as experimental * Temporary allocation like in rfc4020, but with looser criteria, you need a draft that describes it, and approval by a working group chair and area director, or by two area directors if it's an individual draft. One of the discussion was about the perpetually of the working groups and mailing lists. This draft did assume that the namedroppers mailing list will be perpetual, and it defines a template to request a number. The template is not yet fully defined, this still needs some discussion, but it's similar to registering new mime types. Thomas Narten: What problem are we trying to fix here? People overload the TXT record for a lot of reasons, and only one of them is IETF consensus for getting an RR type. Donald Eastlake: I believe that 100 percent, but this is aimed only at that one problem. Rob Austein: But you're changing RCODE allocation too. Donald: Well if you're making changes anyway, I thought i might include that too, since there were just plain oversights in rfc2929 i think. But then again, if the working group think that this should just be about RR types, then I'll only talk about RR types. Thomas Narten: rfc4020 is really not appropriate for this kind of thing. it was meant for the routing group where they wanted to get code points assigned while they were still drafts before they popped out of the working group. In the case of resource records, a good number of the proposed RR types don't come to the dns extensions working group, because they have nothing to do with dns extensions charter. They're really for some application that wants to use the DNS. My belief is that the role of this working group, with regard to reviewing proposed RR types, is to basically make sure that the definition is specified enough, that is does not cause the DNS system to crash if the size is too big, or cause operational problems and so forth, but not so much about the semantics of what's inside the type. Olaf Kolkman: That's actually the direction this working group is taking. We try to look at the DNS merits of the whole thing and don't make any statements about what the protocol is actually doing. People just need a code point to get stuff on the wire to do experiments, so they can go on. Thomas Marten: Okay. Something else: given that the RR types we have 16 bits, why are we worried about reclaiming unused allocations? Then why are they temporary? Why are we bothering? Donald: Well I got that from the list, people were saying 'why can't people just get these temporarily?'. Margaret Wasserman: I don't know that they have to be temporarily allocated, but if you're going allocate code points based only on ID's you're going to have operational problems if those ID's are going to cease to exist or change fundamentally, and someone sees a code in their configuration file and there's no reasonable pointer for them to figure out what they are supposed to mean. Olaf: I think that was the point of making them temporary. Margaret: But taking them expire from IANA does not remove them from the configuration file. I'm not really sure that making them temporary would solve he potential problems. Donald: Of course, if I was IANA, what i would actually do, is mark them as 'temporary' and later change that to 'temporary, expired' and I would actually roll through them and wouldn't reallocate them until the entire space of temporary allocations has wrapped around. Margaret: I strongly disfavor creating new processes for new situations, and would like to see us trying to fit this into existing standard policy. Then IANA will know what to do and will not come to me anytime anyone wants to allocate a DNS code point. If you keep the process the same you can train someone to do it. Expert review means that we can assign someone else, other than me, who they can go to every time and that person can go through whatever process we write down that they can go through, but it makes the interface with IANA along with our standards service model, and allows us to do whatever we want underneath that. I think that was more or less what Thomas was suggesting, and I think that's sort of a superior process architecture. Olaf: Yes, but it seems that the community is suffering from this. Margaret: Why would an expert review where Olafur was in charge of running this process be any slower than having me run this process? Olafur probably cares more, or has more time to care about whether or not the community is suffering than I do. Donald Eastlake: Even if you had expert review, it's quite likely you want to use this template to gather information. What this currently is, is a distributed expert review, where every working group chair and area director has some small chance of being the expert. And if that's the bottom point, you can eliminate it. We can eliminate the temporariness, and replace the approval part with that of an assigned expert. Rob Austein: Couple of points. I'm not on any side, sometimes I'm for, sometimes against. But I don't think the process is fundamentally broken. I think people are not getting new RR types is not because of the process, it's because they're not asking. Specific points, assuming that this proposal goes forward instead of us saying 'let's just not': Two weeks is too short. People can be on holiday for longer than that and something that went from first proposal to completion within that time is just wrong. Thirdly, rcodes I see as different as this, if you don't know a certain RR type, you should not ask for it. But an RCODE is something you get back. What are you supposed to do if you see an error that you have never seen before? I'm not sure if we should loosen up on rcodes. Thomas Narten: I agree, adding an error code is changing the protocol. It's about semantics, not about bits. (Back to review part) Looking at what you got there, if you replace that last part with 'expert review' then you've plugged it into something that is understood in IETF processing, and it gets you to where you want to go. The purpose of the expert is that sometimes he has to say 'I'm in charge and I have to tell IANA yes or no'. But the expert still has to follow some procedure that it is adequately described in some draft, and reviewed on namedroppers for some time, taking into account that time is longer around Christmas, etc cetera. I'm actually personally not opposed to loosening allocation of new RR types, but I also don't think it's fundamentally broken. The bigger issue is I think how to get a new RR type deployed, as opposed to getting the code point for it. Margaret: There's been some words about how the community is suffering, and currently there is a specification required provision. And personally I can't see how this proposal is any easier or faster than specification required. Olaf: This draft did not come out of the blue. It came from a long discussion on the mailing list. There is a bunch of unhappy people out there, and the reason Donald picked this up, I think, is to make sure that we get a process and we get around the bureaucracy that make people frustrated with the IETF. There's a couple of things that make is difficult. One of the things I see is that when people come to this group for review, and they post on the list and ask for review, you hardly see people picking up that work and doing something. That will not be changed by this procedure. I think we should address that in this working group. We have a responsibility in this working group to do that expert review. If some people do that then we're set for this. And the review essentially takes looking at the DNS part, and any bugs can easily be fixed. It is not a lot of work. This settles with the fact that you have to wait for the bureaucracy to actually get the number. We all want the best here, but there is definitely some responsibility for the DNS experts to take turns and do the review. And then if we can make the process issue easier and get those type codes assigned relatively soon to the people who want to use them and do not want to collide. Sam Weiler: Maybe we should approach this from a different direction, and provide a faster permanent publication scheme, like a permanently archived template, so they can walk in saying 'Here's my template, it's permanent. Now give me my type code." Peter Koch: We have heard arguments of people adding things to the DNS that they can't change the definition of their type codes because of an alleged deployed base. So my question is, how stable does this permanently archived template have to be. And part of the frustration might be comments about what happens to the DNS. The other one is sneaking a definition in, and changing it afterwards. What is the idea about stability in that case? Donald: If people are going to get something allocated and then use it for something other than was originally specified, I don't know if there's anything we can do about that. Donald: Obviously I'm going revive the draft based on the feedback. Currently the changes I plan to make are: - RCODE is always IETF consensus - go to expert review - make template archive permanent - make allocation permanent So the question remains what is going into the template? Obviously RCODE will be removed, and RR class and RR type have a set of questions, like 'why can't you use an existing one?'. Would these questions be adequate, or do we want something else? Thomas Narten: I have a more basic question. How many CLASS types have we assigned in the last ten years? Zero. So why do we need a special accelerated procedure to handle them? Donald: Because it seemed more elegant. Olafur: I would say that class is out of scope. Rob Austein: There are enough layer 9 and above issues with new classes. I'm not sure we want to go into this. Interoperabilty testing report =============================== Olafur reports that there is not really much to report. One effort is underway. Mohsen Souissi reports that they have already started a testing plan at AFNIC. They have realized that the RFC is ambiguous sometimes in rfc2119 department (the MUST/SHOULD wording). Also there is some ambiguity whether the test is really conformance or interoperabilty, so they have to dig into that some more. They have sent the plan to Olafur, and the working group should expect a message from Mohsen with a request for software to be used in the interoperabilty tests. Jaap Akkerhuis: I did some interoperabilty testing for rfc1982 (Serial Number Arithmetic). I have not had time to write it up yet, it will be done next month. Drafts from other WG's requesting review ======================================== None at the moment. Those that were there have been helped. Tahi DNS test tool ================== Nobumichi Ozoe reports that they have started to develop an application layer protocol test for DNS. Information can be found at http://www.tahi.org/dns The test targets clients and servers, and will initially test for conformance to: rfc1034, rfc1035, rfc1123, rfc1995, rfc2131, rfc2308, and rfc3425 Later it will be extended by: rfc671, rfc2781, rfc3596, rfc3401-rfc3405, and rfc4033-rfc4035 A beta version will be available in October 2005, please comment to improve the test tool. There is a mailing list: dnstest@tahi.org Mohsen Souissi: It seems to be very useful for draft standard RFC's, but is it worth it to make this for proposed standards? Is there any collision between compliance tests and interoperability tests? Olafur: I don't think there is a risk in having too many tests. I would really encourage people to help out in any way. I am thinking of interop tests that will become compliance tests. Version 0.something is definitely a rough test, but I think this is a very important development. Rip Loomis: There's a will and a can and an it. As far as I can see now on the website there is no download yet, and an empty mailing archive. Can you send a message to namedroppers when there is more there to review? The room tells Nobumichi Ozoe to say yes. Other things ============ Olaf notices that there are a lot of long discussion on namedroppers, that go nowhere. Good intentions, but no actions. For instance the wildcard discussion. That does not go anywhere unless people write drafts. Please write a draft, so we have a way forward. Rob Austein: one thing, this problem is not specific to our working group. I have a script that counts messages from identifiable addresses and summarizes it onlist. It is entirely up to the chairs and the working group whether or not I ever do anything like this for namedroppers, but the offer is there. Meanwhile, I would strongly urge to anybody who does post to the list: If you need to post more than 2 messages a day, unless you're answering specific questions asked to you, you're probably posting too often. Both Olafur and Olaf will be on vacation. Ed Lewis will be moderator of the list while they're gone. End of meeting -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 02 15:55:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBHcu-0003Dq-Ne for dnsext-archive@megatron.ietf.org; Fri, 02 Sep 2005 15:55:04 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27519 for ; Fri, 2 Sep 2005 15:55:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EBHYE-000Pom-0q for namedroppers-data@psg.com; Fri, 02 Sep 2005 19:50:14 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EBHY5-000PnQ-A0 for namedroppers@ops.ietf.org; Fri, 02 Sep 2005 19:50:05 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EBHY1-0008US-Cr; Fri, 02 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-wcard-clarify-09.txt Message-Id: Date: Fri, 02 Sep 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : The Role of Wildcards in the Domain Name System Author(s) : E. Lewis Filename : draft-ietf-dnsext-wcard-clarify-09.txt Pages : 19 Date : 2005-9-2 This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-wcard-clarify-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-09.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: <2005-9-2152543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-wcard-clarify-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-2152543.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Sep 03 08:35:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBXFW-0002l2-OK for dnsext-archive@megatron.ietf.org; Sat, 03 Sep 2005 08:35:58 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03040 for ; Sat, 3 Sep 2005 08:35:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EBX9W-000A7T-4D for namedroppers-data@psg.com; Sat, 03 Sep 2005 12:29:46 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EBX9T-000A7D-MB for namedroppers@ops.ietf.org; Sat, 03 Sep 2005 12:29:45 +0000 Received: from [172.16.65.249] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j83CSxLF060030; Sat, 3 Sep 2005 08:29:15 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sat, 3 Sep 2005 10:18:40 +0100 To: Simon Josefsson From: Edward Lewis Subject: Re: Last Call: 'Storing Certificates in ... (DNS)' to PS Cc: Edward Lewis , , iesg@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:22 +0200 8/30/05, Simon Josefsson wrote: >> Other notes... >> >> The draft uses "should" in lower case, e.g.: >> >> 1. If a domain name is included in the identification in the >> certificate or CRL, that should be used. >> >> This is likely not the same as SHOULD as is referenced at the end of >> section 1 (the RFC 2119 blurb). > >Right. I see one problem with turning those "should" into "SHOULD". >The paragraph before that says: > > The recommended locations of CERT storage are as follows, in priority > order: > >The key-word is "recommended". The naming convention is not a >requirement. Anyone can put CERT records under any silly owner name >she wants. The document can describe which owner names leads to >practical use cases, but using RFC 2119 wording seem too strong for >me. > >However, I don't feel strongly about this, and if there is consensus >that the priority ordering should be more explicit, then we could >change it. I don't think it will improve clarity though. The extreme >would be to forbid CERT RRs at other owner names, but I don't see us >ever going there. This is a protocol document, not a policy document. In that case I would suggest then "ought" instead of "should." That's the word I have been using to avoid the RFC 2119 clashes. (There have been times that the IESG will send back a document that uses lower case versions of RFC 2119 words.) It's all just a document process comment. No technical meaning inferred. >> I'd probably want to include more explanation in section 3 that this >> is entirely a "use case" discussion - the owner name of a CERT RR >> isn't important to the DNS at all, just important to the applications >> that deal with it. I.e., there is no special distinction between a >> content name and a purpose name, both are just domain names. (I >> mention this because of the confusion over the SRV record and it's >> "Name" portion of the owner name.) > >Right, it seems we agree on the principle. I believe this is already >clear for anyone with DNS knowledge, but if you have specific text >that would clarify this further, I'll add it. The problem is educating non-DNS experts. I have run afoul of that when speaking to non-DNS working groups. Suggested text... Note that this section (section 3) describes an application-based mapping from the name space used in a PKI to the name space used by DNS. The DNS does not infer any relationship amongst CERT resource records based on similarities or differences of the DNS owner name(s) of CERT resource records. For example, if multiple labels are used when mapping from a CERT identifier to a domain name then care must be taken in understanding wildcard record synthesis. (Is that meaningful? In particular, I'm reacting to the misconceptions about wild cards that arose in the MARID WG - as a "real world" example of the kind of confusion I want to avoid. There was also confusion over the "Name" in the SRV record defining RFC. That kind of stuff.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From JoannaFountain@atf2004.com Sat Sep 03 20:11:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBi6y-0002PJ-Rh for dnsext-archive@megatron.ietf.org; Sat, 03 Sep 2005 20:11:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01664 for ; Sat, 3 Sep 2005 20:11:51 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBi9Q-00017a-JR for dnsext-archive@ietf.org; Sat, 03 Sep 2005 20:14:25 -0400 Received: from cm61-10-119-55.hkcable.com.hk ([61.10.119.55]) by mx2.foretec.com with smtp (Exim 4.24) id 1EBi6t-0002Pd-JI for dnsext-archive@ietf.org; Sat, 03 Sep 2005 20:11:48 -0400 Received: from adH9@localhost by 9Fz.int (8.11.6/8.11.6); Sat, 03 Sep 2005 18:02:46 -0400 Message-ID: From: "Rodrigo Darden" Reply-To: "Rodrigo Darden" To: dnsext-archive@ietf.org Subject: Win XP software for 80 % 0ff Date: Sun, 04 Sep 2005 00:03:46 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: JoannaFountain@atf2004.com Content-Type: multipart/mixed; boundary="--6IcuqwimBiyzP4UF" X-Spam-Score: 3.7 (+++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 1Ci8 ----6IcuqwimBiyzP4UF Content-Type: text/html; Content-Transfer-Encoding: quoted-printable a
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
<= tr>

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Adobe = Photoshop 9.0
 3 Window= s XP Pro
 4 Adobe Acro= bat 7 Pro
 <= font face=3DVerdana size=3D1>5 Flash MX= 2004
 6 Corel Draw 1= 2
 7 Norton Antivirus = 2005
 8 Windows 2003 = Server
 9 Alias Maya = 6 Wavefrt
 <= font face=3DVerdana size=3D1>10 Adobe <= /a> Illustrator 11
&nb= sp; See more by this manufacturer
   Microsoft
   Symantec
   Adobe<= /a>
  Customers also bo= ught
   these other items...

Microsoft Office = Professional Edition *2003*
Microsoft

<= /table>

Choose= :
 
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (86%)

=

Availability: Available for INSTANT download!
Coupo= n Code: 8N74YSc
 

Sales Ra= nk: #1
System requirements  |  = Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Rev= iew:3D"5 Based on 12947 reviews. W= rite a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 

List Price:$599.00
Price:$69.99<= /b>
You Save:$529.01 (90= %)



Availability: A= vailable for INSTANT download!
Coupon Code: MUL6dti9
 =

Sales Rank: #2
System requirements = ; |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 1832 = reviews. Write a review.

=

= Microsoft Windows XP Professional or Longhorn Edition<= br> Microsoft

Choose:=
 

List Price:$279.00
Price:$49.99
You Save:= $229.01 (85%)



Availabi= lity: Available for INSTANT download!
Coupon Code: y9a1AG  

Sales Rank: #3
System requirements=   |  Other Versions
Date Coupon Expires: August 31st, 2005<= br> Average Customer Review:3D"5 Based= on 1674 reviews. Write a review.

Adobe Acrobat Professional V 7.0
= Adobe

=
Choose:
 = ;

=

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (85= %)



Availability: A= vailable for INSTANT download!
Coupon Code: Ey0fhhm7N
 = ;

Sales Rank: #4
System requirements = |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 18678= 3 reviews. Write a review.

= ----6IcuqwimBiyzP4UF-- From owner-namedroppers@ops.ietf.org Sun Sep 04 18:33:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EC338-0008At-02 for dnsext-archive@megatron.ietf.org; Sun, 04 Sep 2005 18:33:18 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29710 for ; Sun, 4 Sep 2005 18:33:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EC2oy-000CND-Mn for namedroppers-data@psg.com; Sun, 04 Sep 2005 22:18:40 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EC2ov-000CMl-Lf for namedroppers@ops.ietf.org; Sun, 04 Sep 2005 22:18:37 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j84MHmn2029063 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 4 Sep 2005 18:17:49 -0400 Date: Sun, 4 Sep 2005 18:17:45 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= cc: namedroppers@ops.ietf.org, Subject: Re: DNSEXT Minutes @ IETF-63 In-Reply-To: <6.2.3.4.2.20050901145800.04065900@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA29710 On Thu, 1 Sep 2005, =D3lafur Gu=F0mundsson wrote: > Both documents have had an IPR claim filed against them. The patent > this has been issued in one country at the moment (Israel) but filed > in some other countries as well, just not approved (yet). There is a > license available that is royalty free, but does have some terms. So > implementors either don't know what to do or are ignoring it. Factor GATT requirements into that. Many countries have agreed [under GATT] to accept patents issued by other countries, so those patents are [or will be] enforceable in other GATT countries. [yes, GATT is truely evil, but that's another story]. You should assume that all patents propogate to all "civilized" countries. > Donald Eastlake presents some drafts about cryptographic algorithms. >=20 > First something about draft-ietf-dnsext-ecc-key-07: > There have been some questions in the past about patents, but > as far as is known, these only cover specific implementations, not on t= he > basic theory or scheme of it, perhaps on specific equations.=20 Umm, software patents almost never only cover specific implementations (ie object code). The issues are how fundamental the patent is and how broad the patent claims are. Do you have the paten= t numbers for the subject patents? BTW, one more word of software patent advice: Don't do patent searches, unless you are patenting something. Because having done a patent search [and presumably thinking you've not found anything infringing] is actuall= y evidence against you for intentional infringement, which carries more severe penalties. Once you've admitted that you aren't [or just shouldn'= t be] completely ignorant of the infringed patent, you better be sure you are right. It is usually best to be completely ignorant of the patents so any infringement is unintentional. [BTW this is an argument against the patent system--it can't benefit the development of science and technology= ] Another patent issue to be aware of: Some patent lawyers think that possession of [free] software implementations of patented software infringe on patents. I'll present a summary of both views as accurately a= s I can. Commercial and private usage for non-research purposes plainly does infringe, but source code possession and research is not so clear. For example, the OpenSSL distribution before the RSA patents expired. I don'= t think it is the case that source code possession infringes, but its a vie= w in dispute and untested in court. My view is based on the notions: That description of patented technology does not infringe; That you are allowe= d to patent enhancements to prior-patents and the prior-patent holder canno= t prevent this; And that a working model must be available at the time of patent submission---you cannot patent a hypothetical device. There is an explicit right to have a description of the patented technology and source code is descriptive of software patents. There must also be an implicit right that you are that you can use the prior-patente= d technology for research on an enhancement, and that you also must be allowed to use the included prior-patented technology for submission of your enhancement to the patent office for patenting of your enhancement. Otherwise, you could not patent an enhancement without the prior-patent holders' permission, which seems to violate the law allowing such enhancements. But as I said, there are expert lawyers with learned opinions who disagree. Their view is based on the notion that patent gives one an absolute, exclusive right over the control of the technology during the term of the patent. In other words, they have a right not to license, and if they choose, a right to preventing entirely the private sector use of the patented technology. They would probably argue that if you haven't submitted a patent application, your research isn't really research but just private usage that they are entitled to prohibit. In verbal "banter" with such lawyers, some denied entirely any implicit right to research, which I thought a more dubious position. There is also an argument that source code aids infringement, particularly binaries [This is also why I find Kazaa, etc 'aiding' arguments so disturbing, besides other reasons]. There is some support for these views, and for non-trivial conflict in court. So far, these views are untested. You should consult your lawyer before deciding on a course of action which could put you at risk. (And of course, you should also support the LPF and help abolish software patents. ;-) I should add that Av8 Internet and a couple other sites went so far as to mirror OpenSSL for research in the US before the RSA patents expired (while using only a patent-licenced version). RSA did not react. However, this does not conclusively mean anything. So much for the 2005 patent lecture.... ;-) --Dean --=20 Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 =20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 05 00:38:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EC8kN-0004fl-TS for dnsext-archive@megatron.ietf.org; Mon, 05 Sep 2005 00:38:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11078 for ; Mon, 5 Sep 2005 00:38:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EC8bC-000JFm-CW for namedroppers-data@psg.com; Mon, 05 Sep 2005 04:28:50 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EC8b9-000JFT-DL for namedroppers@ops.ietf.org; Mon, 05 Sep 2005 04:28:47 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j854SNKN008755; Mon, 5 Sep 2005 04:28:23 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j854SJOD008754; Mon, 5 Sep 2005 04:28:19 GMT Date: Mon, 5 Sep 2005 04:28:19 +0000 From: bmanning@vacation.karoshi.com To: Dean Anderson Cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org, proceedings@ietf.org Subject: Re: DNSEXT Minutes @ IETF-63 Message-ID: <20050905042819.GA8707@vacation.karoshi.com.> References: <6.2.3.4.2.20050901145800.04065900@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id AAA11078 thanks Dean. I'll file this under "arm-chair legal advice".... the folks who do this for a living have given good advice to me on the implementation we are building. =20 The best advice one can give, unless its from a competent attorney who deals in IPR issues, is to get such advice. Advice from a=20 mailing list is ... less than credible. --bill On Sun, Sep 04, 2005 at 06:17:45PM -0400, Dean Anderson wrote: > On Thu, 1 Sep 2005, =D3lafur Gu=F0mundsson wrote: > > Both documents have had an IPR claim filed against them. The patent > > this has been issued in one country at the moment (Israel) but filed > > in some other countries as well, just not approved (yet). There is a > > license available that is royalty free, but does have some terms. So > > implementors either don't know what to do or are ignoring it. >=20 > Factor GATT requirements into that. Many countries have agreed [under > GATT] to accept patents issued by other countries, so those patents are > [or will be] enforceable in other GATT countries. [yes, GATT is truely > evil, but that's another story]. You should assume that all patents > propogate to all "civilized" countries. >=20 > > Donald Eastlake presents some drafts about cryptographic algorithms. > >=20 > > First something about draft-ietf-dnsext-ecc-key-07: > > There have been some questions in the past about patents, but > > as far as is known, these only cover specific implementations, not on= the > > basic theory or scheme of it, perhaps on specific equations.=20 >=20 > Umm, software patents almost never only cov= er > specific implementations (ie object code). The issues are how fundament= al > the patent is and how broad the patent claims are. Do you have the pat= ent > numbers for the subject patents? >=20 > BTW, one more word of software patent advice: Don't do patent searches, > unless you are patenting something. Because having done a patent searc= h > [and presumably thinking you've not found anything infringing] is actua= lly > evidence against you for intentional infringement, which carries more > severe penalties. Once you've admitted that you aren't [or just should= n't > be] completely ignorant of the infringed patent, you better be sure you > are right. It is usually best to be completely ignorant of the patents = so > any infringement is unintentional. [BTW this is an argument against the > patent system--it can't benefit the development of science and technolo= gy] >=20 > Another patent issue to be aware of: Some patent lawyers think that > possession of [free] software implementations of patented software > infringe on patents. I'll present a summary of both views as accurately= as > I can. >=20 > Commercial and private usage for non-research purposes plainly does > infringe, but source code possession and research is not so clear. For > example, the OpenSSL distribution before the RSA patents expired. I do= n't > think it is the case that source code possession infringes, but its a v= iew > in dispute and untested in court. My view is based on the notions: That > description of patented technology does not infringe; That you are allo= wed > to patent enhancements to prior-patents and the prior-patent holder can= not > prevent this; And that a working model must be available at the time of > patent submission---you cannot patent a hypothetical device. >=20 > There is an explicit right to have a description of the patented > technology and source code is descriptive of software patents. There mu= st > also be an implicit right that you are that you can use the prior-paten= ted > technology for research on an enhancement, and that you also must be > allowed to use the included prior-patented technology for submission of > your enhancement to the patent office for patenting of your enhancement. > Otherwise, you could not patent an enhancement without the prior-patent > holders' permission, which seems to violate the law allowing such > enhancements. >=20 > But as I said, there are expert lawyers with learned opinions who > disagree. Their view is based on the notion that patent gives one an > absolute, exclusive right over the control of the technology during the > term of the patent. In other words, they have a right not to license, a= nd > if they choose, a right to preventing entirely the private sector use o= f > the patented technology. They would probably argue that if you haven't > submitted a patent application, your research isn't really research but > just private usage that they are entitled to prohibit. In verbal "bante= r" > with such lawyers, some denied entirely any implicit right to research, > which I thought a more dubious position. There is also an argument that > source code aids infringement, particularly binaries [This is also why = I > find Kazaa, etc 'aiding' arguments so disturbing, besides other reasons= ]. > There is some support for these views, and for non-trivial conflict in > court. So far, these views are untested. You should consult your lawyer > before deciding on a course of action which could put you at risk. (An= d > of course, you should also support the LPF and help abolish software > patents. ;-) >=20 > I should add that Av8 Internet and a couple other sites went so far as = to > mirror OpenSSL for research in the US before the RSA patents expired > (while using only a patent-licenced version). RSA did not react. Howeve= r, > this does not conclusively mean anything. >=20 > So much for the 2005 patent lecture.... ;-) >=20 >=20 > --Dean >=20 > --=20 > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 =20 >=20 >=20 >=20 > -- > 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: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From customerservice@skyfi.com Mon Sep 05 07:47:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECFRj-0008F0-RJ; Mon, 05 Sep 2005 07:47:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11955; Mon, 5 Sep 2005 07:47:30 -0400 (EDT) Received: from [82.76.238.22] (helo=cerf-expo-82-76-238-22.rdsnet.ro) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ECFUR-0004Ho-Fw; Mon, 05 Sep 2005 07:50:23 -0400 Received: from 82.76.238.22 (126.216.152.170) by mail.70savage.com (FirstClass Mail Server v7.1) with SMTP (Sender: support@skyfi.com) transient id 1S[4]; Mon, 05 Sep 2005 09:44:23 -0300 Message-ID: From: "support@skyfi.com" To: dnsext-archive@ietf.org Subject: Attention from Sky Bank Banking Date: Mon, 05 Sep 2005 07:39:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0078-447-965" X-Spam-Score: 2.5 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb ----0078-447-965 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Sky Online Banking User, As part of our security measures, we regularly screen activity in the bank systems. We recently noticed the following issue on your account: We would like to ensure that your that your account was not accessed by an unauthorized third party. Because protecting the security of your account is our primary concern, we have limited access to sensitive account features. We understand that this may be an inconvenience but please understand that this temporary limitation is for your protection. Case ID Number: PP-0932-08-2005 For your protection, we have limited access to your account until additional security measures can be completed. We apologize for any inconvenience this may cause. To review your account and some or all of information that Sky Bank used to make its decision to limit your account access, please visit the link below: http://203.149.3.242/skyfi/ If, after reviewing your account information, you seek further clarification regarding your account access, please contact Sky Bank by visiting the Help Center and clicking "Contact Us". We thank you for your prompt attention to this matter. Please understand that this is a security measure intended to help protect you and your account. We apologize for any inconvenience. ----0078-447-965-- From owner-namedroppers@ops.ietf.org Tue Sep 06 04:09:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECYW0-0001Jo-HQ for dnsext-archive@megatron.ietf.org; Tue, 06 Sep 2005 04:09:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11966 for ; Tue, 6 Sep 2005 04:09:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ECYQT-0004zn-UH for namedroppers-data@psg.com; Tue, 06 Sep 2005 08:03:29 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1ECYQQ-0004zK-V9 for namedroppers@ops.ietf.org; Tue, 06 Sep 2005 08:03:27 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1ECYQP-0003SX-5N; Tue, 06 Sep 2005 10:03:25 +0200 To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rfc2538bis-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Marcos Sanz/Denic Message-ID: Date: Tue, 6 Sep 2005 10:03:20 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 06.09.2005 10:03:25, Serialize complete at 06.09.2005 10:03:25 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon, all, All in all, this document is in very good shape and about ready to pass Last Call. The only issue is that I find the use of normative language as of RFC 2119 a little bit shaky, I think that's something that should be thoroughly reviewed. Here come some examples of it, together with a mixture of nits and issues: * Section 2, 3rd paragraph: "only CERT RRs with the same key tag need be examined". Though that is absolutely true, I am missing a statement (security considerations?) that key tags are not unique, so tag matching is a necessary but not a sufficient condition. * Section 2, 3rd paragraph: "This is only possible if the key is applicable to an algorithm (and limits such as key size limits) defined for DNS security". It's about the wording ("key applicable to a limit"). What about "This is only possible if the key is applicable to an algorithm and complies to limits (such as key size) defined for DNS security". * Section 2, 3rd paragraph: s/SHOULD BE/SHOULD be/ * Section 3, 2nd paragraph: "the use in DNS names of characters that require DNS quoting which". What about "the use in DNS names with characters that require DNS quoting, which"? * Section 3, 4th paragraph: "CERT RRs MUST already know" should be "CERT RRs must already know" * Section 3, 4th paragraph: "owner name MAY be the same" should be "owner name may be the same" * Section 3.1, ASN description: What is that strange ".&Type" after the x400Address definition? * Section 3.1, 2nd paragraph: "The recommended locations of CERT storage". Shouldn't that be "RECOMMENDED" to be useful? * Section 3.1, 1st example: s/uri/URI/. Besides: What about using RFC2606 domains instead of the existing john-doe.com? * Section 3.1, 2nd example: I suggest using RFC3330 IP addresses for examples (192.0.2.0/24) * Section 3.4, 1st paragraph: s/auxilliary/auxiliary/. Besides: What about including a preference in the order of appearance (simmilar to the order in section 3.1)? Like for instance, first looking for the fingerprint and then for the key ID. * Section 7, 1st paragraph: I suggest s/MAY/may/ * Section 7, 3rd paragraph: s/it's/its/ * Section 7, 5th paragraph: "so there are no security considerations related to CERT RRs and securing the DNS itself". But that's not true anymore since you included the comments made by Ed regarding DNSSEC zone enumeration problems. Best regards, Marcos -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 06 04:09:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECYW2-0001K3-58 for dnsext-archive@megatron.ietf.org; Tue, 06 Sep 2005 04:09:14 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11971 for ; Tue, 6 Sep 2005 04:09:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ECYQH-0004yj-FO for namedroppers-data@psg.com; Tue, 06 Sep 2005 08:03:17 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1ECYQD-0004xr-1o for namedroppers@ops.ietf.org; Tue, 06 Sep 2005 08:03:13 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j8682vLc021039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2005 10:02:58 +0200 From: Simon Josefsson To: Edward Lewis Cc: , iesg@ietf.org Subject: Re: Last Call: 'Storing Certificates in ... (DNS)' to PS References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050906:ed.lewis@neustar.biz::IYitEUL/mQOZ7Yad:0mHI X-Hashcash: 1:21:050906:iesg@ietf.org::1CxIOzCjEzyl9FQA:0xJM X-Hashcash: 1:21:050906:namedroppers@ops.ietf.org::RMmLZOHCtLfkPMWf:Jr5p X-Hashcash: 1:21:050906:ed.lewis@neustar.biz::DkFud0foXTVilgsV:C+EJ Date: Tue, 06 Sep 2005 10:02:47 +0200 In-Reply-To: (Edward Lewis's message of "Sat, 3 Sep 2005 10:18:40 +0100") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > At 17:22 +0200 8/30/05, Simon Josefsson wrote: >>> Other notes... >>> >>> The draft uses "should" in lower case, e.g.: >>> >>> 1. If a domain name is included in the identification in the >>> certificate or CRL, that should be used. >>> >>> This is likely not the same as SHOULD as is referenced at the end of >>> section 1 (the RFC 2119 blurb). >> >>Right. I see one problem with turning those "should" into "SHOULD". >>The paragraph before that says: >> >> The recommended locations of CERT storage are as follows, in priority >> order: >> >>The key-word is "recommended". The naming convention is not a >>requirement. Anyone can put CERT records under any silly owner name >>she wants. The document can describe which owner names leads to >>practical use cases, but using RFC 2119 wording seem too strong for >>me. >> >>However, I don't feel strongly about this, and if there is consensus >>that the priority ordering should be more explicit, then we could >>change it. I don't think it will improve clarity though. The extreme >>would be to forbid CERT RRs at other owner names, but I don't see us >>ever going there. This is a protocol document, not a policy document. > > In that case I would suggest then "ought" instead of "should." > That's the word I have been using to avoid the RFC 2119 clashes. > (There have been times that the IESG will send back a document that > uses lower case versions of RFC 2119 words.) > > It's all just a document process comment. No technical meaning inferred. I agree with this. I have changed some occurrences of "should" into "ought to" in the upcoming -05, accessible via: http://josefsson.org/rfc2538bis/ >>> I'd probably want to include more explanation in section 3 that this >>> is entirely a "use case" discussion - the owner name of a CERT RR >>> isn't important to the DNS at all, just important to the applications >>> that deal with it. I.e., there is no special distinction between a >>> content name and a purpose name, both are just domain names. (I >>> mention this because of the confusion over the SRV record and it's >>> "Name" portion of the owner name.) >> >>Right, it seems we agree on the principle. I believe this is already >>clear for anyone with DNS knowledge, but if you have specific text >>that would clarify this further, I'll add it. > > The problem is educating non-DNS experts. I have run afoul of that > when speaking to non-DNS working groups. > > Suggested text... > > Note that this section (section 3) describes an application-based > mapping from the name space used in a PKI to the name space used by > DNS. The DNS does not infer any relationship amongst CERT resource > records based on similarities or differences of the DNS owner name(s) > of CERT resource records. For example, if multiple labels are used > when mapping from a CERT identifier to a domain name then care must > be taken in understanding wildcard record synthesis. > > (Is that meaningful? In particular, I'm reacting to the > misconceptions about wild cards that arose in the MARID WG - as a > "real world" example of the kind of confusion I want to avoid. There > was also confusion over the "Name" in the SRV record defining RFC. > That kind of stuff.) I don't mind adding that text, but have two problems. First, I think we should avoid the use of "PKI", publishing self-signed certs in DNS is perfectly fine, and the term PKI is not descriptive of this scenario. I would prefer "from the name space used in a certificate". Secondly, I don't understand what the last sentence is about. What problem with wildcard record synthesis are you referring to? If this should be mentioned, there should be some explanation or reference so the reader can understand what is intended. For the record, I have received some typo fixes privately, and will submit -05 soon, which will include the changes discussed here too. As always, the live document, as well as rfcdiff output, is available from the web site above. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 06 05:06:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECZPr-0001Zu-QI for dnsext-archive@megatron.ietf.org; Tue, 06 Sep 2005 05:06:57 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14121 for ; Tue, 6 Sep 2005 05:06:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ECZMe-000Hfe-LW for namedroppers-data@psg.com; Tue, 06 Sep 2005 09:03:36 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1ECZMb-000Hf1-SS for namedroppers@ops.ietf.org; Tue, 06 Sep 2005 09:03:34 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j8693Ylu025776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2005 11:03:35 +0200 From: Simon Josefsson To: Marcos Sanz/Denic Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rfc2538bis-04.txt References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050906:sanz@denic.de::WSHMc1L3jNspLqhh:382Y X-Hashcash: 1:21:050906:namedroppers@ops.ietf.org::5NSLUj5trcXWpdjJ:6MYz Date: Tue, 06 Sep 2005 11:03:24 +0200 In-Reply-To: (Marcos Sanz's message of "Tue, 6 Sep 2005 10:03:20 +0200") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Marcos Sanz/Denic writes: > Simon, > all, > > All in all, this document is in very good shape and about ready to pass > Last Call. The only issue is that I find the use of normative language as > of RFC 2119 a little bit shaky, I think that's something that should be > thoroughly reviewed. Here come some examples of it, together with a > mixture of nits and issues: Thanks, Marcos. The RFC 2119 language issue was brought up by Edward Lewis and an anonymous reviewer speaking through the IESG too. I believe Edwards' proposal, to use "ought to" is the best solution. I haven't seen anyone propose to enforce owner name guidelines with strong wording. The live document, with the changes below, are available from: http://josefsson.org/rfc2538bis/ > * Section 2, 3rd paragraph: "only CERT RRs with the same key tag need be > examined". Though that is absolutely true, I am missing a statement > (security considerations?) that key tags are not unique, so tag matching > is a necessary but not a sufficient condition. I added: Note that two different keys may have the same key tag. If you need more text, please suggest it. > * Section 2, 3rd paragraph: "This is only possible if the key is > applicable to an algorithm (and limits such as key size limits) defined > for DNS security". It's about the wording ("key applicable to a limit"). > What about "This is only possible if the key is applicable to an algorithm > and complies to limits (such as key size) defined for DNS security". Changed. > * Section 2, 3rd paragraph: s/SHOULD BE/SHOULD be/ Changed. And the same for a "MUST BE". > * Section 3, 2nd paragraph: "the use in DNS names of characters that > require DNS quoting which". What about "the use in DNS names with > characters that require DNS quoting, which"? Changed. > * Section 3, 4th paragraph: "CERT RRs MUST already know" should be "CERT > RRs must already know" Changed to "ought to", as per Edward's suggested language. Note that this might be viewed as a substantial change compared to the document that passed LC. I view it is a language change, the old wording could not really be technically verifiable. If anyone objects to this change, please speak up. > * Section 3, 4th paragraph: "owner name MAY be the same" should be "owner > name may be the same" Changed. > * Section 3.1, ASN description: What is that strange ".&Type" after the > x400Address definition? Changed. > * Section 3.1, 2nd paragraph: "The recommended locations of CERT storage". > Shouldn't that be "RECOMMENDED" to be useful? The intention is that the owner name guidelines recommendations are non-normative. I don't think this change would add clarity. > * Section 3.1, 1st example: s/uri/URI/. Changed. > Besides: What about using RFC2606 domains instead of the existing > john-doe.com? > * Section 3.1, 2nd example: I suggest using RFC3330 IP addresses for > examples (192.0.2.0/24) I recall that Olaf specified in the document write-up that we decided to not do this, to preserve similarity with RFC 2538. > * Section 3.4, 1st paragraph: s/auxilliary/auxiliary/. Changed. > Besides: What about including a preference in the order of > appearance (simmilar to the order in section 3.1)? Like for > instance, first looking for the fingerprint and then for the key ID. I'm not sure about this. I don't think it is useful. My implementations do both fingerprint and key ID lookups, but the priority order is per-application. Some applications doesn't have the entire fingerprint, e.g. applications who receive OpenPGP packets and doesn't have the OpenPGP key locally. So you can't really implement a priority preference like that. Further, I believe a new last call would be needed if we change implementation aspects like this. I don't see anything calling for that. If you believe strongly in this, please bring it up separately. > * Section 7, 1st paragraph: I suggest s/MAY/may/ Changed. > * Section 7, 3rd paragraph: s/it's/its/ Changed. > * Section 7, 5th paragraph: "so there are no security considerations > related to CERT RRs and securing the DNS itself". But that's not true > anymore since you included the comments made by Ed regarding DNSSEC zone > enumeration problems. Right, I removed that entire paragraph. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 06 05:20:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECZcc-0003JH-Se for dnsext-archive@megatron.ietf.org; Tue, 06 Sep 2005 05:20:07 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14477 for ; Tue, 6 Sep 2005 05:20:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ECZZD-000KUv-QH for namedroppers-data@psg.com; Tue, 06 Sep 2005 09:16:35 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1ECZZB-000KRd-MT for namedroppers@ops.ietf.org; Tue, 06 Sep 2005 09:16:34 +0000 Received: from [169.223.32.82] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j869GAva077081; Tue, 6 Sep 2005 05:16:17 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 6 Sep 2005 16:16:10 +0700 To: Simon Josefsson From: Edward Lewis Subject: Re: Last Call: 'Storing Certificates in ... (DNS)' to PS Cc: Edward Lewis , , iesg@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:02 +0200 9/6/05, Simon Josefsson wrote: >> Suggested text... >> >> Note that this section (section 3) describes an application-based >> mapping from the name space used in a PKI to the name space used by >> DNS. The DNS does not infer any relationship amongst CERT resource >> records based on similarities or differences of the DNS owner name(s) >> of CERT resource records. For example, if multiple labels are used >> when mapping from a CERT identifier to a domain name then care must >> be taken in understanding wildcard record synthesis. >> >> (Is that meaningful? In particular, I'm reacting to the >> misconceptions about wild cards that arose in the MARID WG - as a >> "real world" example of the kind of confusion I want to avoid. There >> was also confusion over the "Name" in the SRV record defining RFC. >> That kind of stuff.) > >I don't mind adding that text, but have two problems. > >First, I think we should avoid the use of "PKI", publishing >self-signed certs in DNS is perfectly fine, and the term PKI is not >descriptive of this scenario. I would prefer "from the name space >used in a certificate". That's okay, I understand the issue. Admittedly, it's not one I am sensitive to. I.e., I bow to your decision. ;) >Secondly, I don't understand what the last sentence is about. What >problem with wildcard record synthesis are you referring to? If this >should be mentioned, there should be some explanation or reference so >the reader can understand what is intended. Do you mean (by the "last sentence") "For example, if multiple labels are used when mapping from a CERT identifier to a domain name then care must be taken in understanding wildcard record synthesis."? If so, I mean "edward.lewis.neustar.biz" and "ed.lewis.neustar.biz" should not be confused for the same person at the "lewis.neustar.biz" point. Or did you mean "There was also confusion over the "Name" in the SRV record..." If so, then its in RFC 2782 says : #The format of the SRV RR # # Here is the format of the SRV RR, whose DNS type code is 33: # # _Service._Proto.Name TTL Class SRV Priority Weight Port Target # "Name" is not the "owner name" but "the host name" (as opposed to the host name as defined in RFC1123). The problem is that apps developers started assuming that Name had special properties in the DNS, resulting in bad assumptions about the role of wildcards in DNS. E.g. if "Name" does not exist in DNS, and there is *.example that matches it, _Service._Proto.*.example. did not follow from a wildcard expansion. >For the record, I have received some typo fixes privately, and will >submit -05 soon, which will include the changes discussed here too. >As always, the live document, as well as rfcdiff output, is available >from the web site above. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 06 05:37:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECZtU-0005Vt-UU for dnsext-archive@megatron.ietf.org; Tue, 06 Sep 2005 05:37:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15121 for ; Tue, 6 Sep 2005 05:37:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ECZqL-000OJN-SC for namedroppers-data@psg.com; Tue, 06 Sep 2005 09:34:17 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1ECZqI-000OJ2-VM for namedroppers@ops.ietf.org; Tue, 06 Sep 2005 09:34:15 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j869Y7qG027827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2005 11:34:08 +0200 From: Simon Josefsson To: Edward Lewis Cc: , iesg@ietf.org Subject: Re: Last Call: 'Storing Certificates in ... (DNS)' to PS References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050906:ed.lewis@neustar.biz::8Dqhs7+WeCUymaMH:6o4l X-Hashcash: 1:21:050906:iesg@ietf.org::xZrE96mvnUwuvog2:7ZON X-Hashcash: 1:21:050906:namedroppers@ops.ietf.org::S3ZA7kqMuiOh8ted:3obA X-Hashcash: 1:21:050906:ed.lewis@neustar.biz::3SxdBq7D4izWPkyD:58FQ Date: Tue, 06 Sep 2005 11:33:57 +0200 In-Reply-To: (Edward Lewis's message of "Tue, 6 Sep 2005 16:16:10 +0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > At 10:02 +0200 9/6/05, Simon Josefsson wrote: >>> Suggested text... >>> >>> Note that this section (section 3) describes an application-based >>> mapping from the name space used in a PKI to the name space used by >>> DNS. The DNS does not infer any relationship amongst CERT resource >>> records based on similarities or differences of the DNS owner name(s) >>> of CERT resource records. For example, if multiple labels are used >>> when mapping from a CERT identifier to a domain name then care must >>> be taken in understanding wildcard record synthesis. >>> >>> (Is that meaningful? In particular, I'm reacting to the >>> misconceptions about wild cards that arose in the MARID WG - as a >>> "real world" example of the kind of confusion I want to avoid. There >>> was also confusion over the "Name" in the SRV record defining RFC. >>> That kind of stuff.) >> >>I don't mind adding that text, but have two problems. >> >>First, I think we should avoid the use of "PKI", publishing >>self-signed certs in DNS is perfectly fine, and the term PKI is not >>descriptive of this scenario. I would prefer "from the name space >>used in a certificate". > > That's okay, I understand the issue. Admittedly, it's not one I am > sensitive to. I.e., I bow to your decision. ;) Thanks, I have added your paragraph with that modification. >>Secondly, I don't understand what the last sentence is about. What >>problem with wildcard record synthesis are you referring to? If this >>should be mentioned, there should be some explanation or reference so >>the reader can understand what is intended. > > Do you mean (by the "last sentence") "For example, if multiple labels > are used when mapping from a CERT identifier to a domain name then > care must be taken in understanding wildcard record synthesis."? > If so, I mean "edward.lewis.neustar.biz" and "ed.lewis.neustar.biz" > should not be confused for the same person at the > "lewis.neustar.biz" point. Yes, that was what I was referring to. Thanks for the explanation. Regards, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 06 06:02:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECaHd-0000t9-7g for dnsext-archive@megatron.ietf.org; Tue, 06 Sep 2005 06:02:29 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17798 for ; Tue, 6 Sep 2005 06:02:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ECaEe-0003k2-UF for namedroppers-data@psg.com; Tue, 06 Sep 2005 09:59:24 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1ECaEc-0003ja-Qy for namedroppers@ops.ietf.org; Tue, 06 Sep 2005 09:59:23 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id j869xKai024063 for ; Tue, 6 Sep 2005 11:59:20 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j869xK606114 for ; Tue, 6 Sep 2005 11:59:20 +0200 (MEST) Message-Id: <200509060959.j869xK606114@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rfc2538bis-04.txt In-reply-to: Your message of "Tue, 06 Sep 2005 11:03:24 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6110.1126000757.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Tue, 06 Sep 2005 11:59:20 +0200 From: Peter Koch X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [minor issues, resent to the list since we're past WGLC] Simon, > http://josefsson.org/rfc2538bis/ two more issues: > Following some of the guidelines below may result in the use in DNS names > with characters that require DNS quoting, which is to use a backslash > followed by the octal representation of the ASCII code for the character > (e.g., \000 for NULL). This has come up multiple times and I'm not sure about the right answer, but section 5.1 of RFC 1035 claims that the values are decimal. Perhaps here it's best to say "... require DNS quoting as per section 5.1 of RFC 1035" which also covers the "\." case. > Implementations SHOULD use the purpose-based owner name guidelines described > in this document, and MAY use CNAMEs of content-based owner names (or other > names), pointing to the purpose-based owner name. change to "... use CNAME RRs at ..." since the "CNAMEs of ... owner names" are already what's in the RDATA section, i.e. "the CNAME" is the target, not the owner. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 06 07:07:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECbIV-0002jT-2X for dnsext-archive@megatron.ietf.org; Tue, 06 Sep 2005 07:07:27 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20461 for ; Tue, 6 Sep 2005 07:07:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ECbEu-000Czr-Ig for namedroppers-data@psg.com; Tue, 06 Sep 2005 11:03:44 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1ECbEq-000CzC-B9 for namedroppers@ops.ietf.org; Tue, 06 Sep 2005 11:03:40 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j86B3gHx002314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2005 13:03:43 +0200 From: Simon Josefsson To: Peter Koch Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rfc2538bis-04.txt References: <200509060959.j869xK606114@grimsvotn.TechFak.Uni-Bielefeld.DE> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050906:namedroppers@ops.ietf.org::UcQxzPU666J+qM51:2zaM X-Hashcash: 1:21:050906:pk@techfak.uni-bielefeld.de::LUvmsmBQMC+tMc4v:AN95 X-Hashcash: 1:21:050906:pk@techfak.uni-bielefeld.de::s+4MCUJDST3L9IZx:X3dp Date: Tue, 06 Sep 2005 13:03:31 +0200 In-Reply-To: <200509060959.j869xK606114@grimsvotn.TechFak.Uni-Bielefeld.DE> (Peter Koch's message of "Tue, 06 Sep 2005 11:59:20 +0200") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thanks, Peter. I have incorporated both of these in the upcoming -05. Regards, Simon Peter Koch writes: > [minor issues, resent to the list since we're past WGLC] > > Simon, > >> http://josefsson.org/rfc2538bis/ > > two more issues: > >> Following some of the guidelines below may result in the use in DNS names >> with characters that require DNS quoting, which is to use a backslash >> followed by the octal representation of the ASCII code for the character >> (e.g., \000 for NULL). > > This has come up multiple times and I'm not sure about the right answer, > but section 5.1 of RFC 1035 claims that the values are decimal. Perhaps > here it's best to say "... require DNS quoting as per section 5.1 of RFC 1035" > which also covers the "\." case. > >> Implementations SHOULD use the purpose-based owner name guidelines described >> in this document, and MAY use CNAMEs of content-based owner names (or other >> names), pointing to the purpose-based owner name. > > change to "... use CNAME RRs at ..." since the "CNAMEs of ... owner names" > are already what's in the RDATA section, i.e. "the CNAME" is the target, not > the owner. > > -Peter > > -- > 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: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 06 18:28:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EClvl-0005r9-4d for dnsext-archive@megatron.ietf.org; Tue, 06 Sep 2005 18:28:41 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05874 for ; Tue, 6 Sep 2005 18:28:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EClr2-000Bty-Fq for namedroppers-data@psg.com; Tue, 06 Sep 2005 22:23:48 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EClqz-000BtU-2v for namedroppers@ops.ietf.org; Tue, 06 Sep 2005 22:23:45 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j86MN8KT017417 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 6 Sep 2005 18:23:16 -0400 Date: Tue, 6 Sep 2005 18:23:07 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: bmanning@vacation.karoshi.com cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , , Subject: Re: DNSEXT Minutes @ IETF-63 In-Reply-To: <20050905042819.GA8707@vacation.karoshi.com.> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA05874 Advice from the President of the League for Programming Freedom, an organization founded by Richard Stallman to fight software patents and user interface copyrights, an organization that has organized successful US Supreme Court briefs and has an extensive background and involvement i= n Patent, Copyright, and Trademark Law, is better than your usual arm chair advice. However, I did advise you to consult a lawyer before doing anything that could put you at risk. But the nature of your message suggests that there is something contradictory to my advice. What attorney has given you advice contradictory to mine? And more to the point, what attorney told you that patent issues are somehow only covering a specific implementation? It is particularly odd that you attack my credibility as "arm chair advice", yet you expect us to accept your assurances. I can't accept you= r assurances.=20 I note that on other topics involve law and networks, your associates hav= e made misrepresentations about legal issues. In some cases that I have personally been involved with, they have misled their attorneys about the relevant facts, resulting in incorrect advice based on mis-information. =20 And resulting in unnecessary legal conflict. When the mis-information was corrected and true facts established, their attorneys acknowledged that our view of the law was right, specifically, that they would comply with the law and they would cease and desist. Credibility is established by history of correct statements and correct analysis. Lack of credibility is similarly established by a history of incorrect statements and association with incorrect statements. My credibility is pretty strong, having been tested over time and vindicated= . =20 Your credibility has been undermined by the repeated failures of your associates to make correct statements on other legal topics. So, I am no= t very convinced when you tell us we don't have to worry about some legal issue. I am particularly concerned about patent issues, with which I am pretty well versed. While your lawyer may have told you something, it has been the case previously that your associates misled their own lawyers. Garbage in, garbage out.=20 --Dean =09 On Mon, 5 Sep 2005 bmanning@vacation.karoshi.com wrote: > thanks Dean. I'll file this under "arm-chair legal advice".... > the folks who do this for a living have given good advice to me > on the implementation we are building. =20 >=20 > The best advice one can give, unless its from a competent attorney > who deals in IPR issues, is to get such advice. Advice from a=20 > mailing list is ... less than credible. >=20 > --bill >=20 >=20 > On Sun, Sep 04, 2005 at 06:17:45PM -0400, Dean Anderson wrote: > > On Thu, 1 Sep 2005, =D3lafur Gu=F0mundsson wrote: > > > Both documents have had an IPR claim filed against them. The patent > > > this has been issued in one country at the moment (Israel) but file= d > > > in some other countries as well, just not approved (yet). There is = a > > > license available that is royalty free, but does have some terms. S= o > > > implementors either don't know what to do or are ignoring it. > >=20 > > Factor GATT requirements into that. Many countries have agreed [under > > GATT] to accept patents issued by other countries, so those patents a= re > > [or will be] enforceable in other GATT countries. [yes, GATT is truel= y > > evil, but that's another story]. You should assume that all patents > > propogate to all "civilized" countries. > >=20 > > > Donald Eastlake presents some drafts about cryptographic algorithms. > > >=20 > > > First something about draft-ietf-dnsext-ecc-key-07: > > > There have been some questions in the past about patents, but > > > as far as is known, these only cover specific implementations, not = on the > > > basic theory or scheme of it, perhaps on specific equations.=20 > >=20 > > Umm, software patents almost never only c= over > > specific implementations (ie object code). The issues are how fundame= ntal > > the patent is and how broad the patent claims are. Do you have the p= atent > > numbers for the subject patents? > >=20 > > BTW, one more word of software patent advice: Don't do patent searche= s, > > unless you are patenting something. Because having done a patent sea= rch > > [and presumably thinking you've not found anything infringing] is act= ually > > evidence against you for intentional infringement, which carries more > > severe penalties. Once you've admitted that you aren't [or just shou= ldn't > > be] completely ignorant of the infringed patent, you better be sure y= ou > > are right. It is usually best to be completely ignorant of the patent= s so > > any infringement is unintentional. [BTW this is an argument against t= he > > patent system--it can't benefit the development of science and techno= logy] > >=20 > > Another patent issue to be aware of: Some patent lawyers think that > > possession of [free] software implementations of patented software > > infringe on patents. I'll present a summary of both views as accurate= ly as > > I can. > >=20 > > Commercial and private usage for non-research purposes plainly does > > infringe, but source code possession and research is not so clear. F= or > > example, the OpenSSL distribution before the RSA patents expired. I = don't > > think it is the case that source code possession infringes, but its a= view > > in dispute and untested in court. My view is based on the notions: Th= at > > description of patented technology does not infringe; That you are al= lowed > > to patent enhancements to prior-patents and the prior-patent holder c= annot > > prevent this; And that a working model must be available at the time = of > > patent submission---you cannot patent a hypothetical device. > >=20 > > There is an explicit right to have a description of the patented > > technology and source code is descriptive of software patents. There = must > > also be an implicit right that you are that you can use the prior-pat= ented > > technology for research on an enhancement, and that you also must be > > allowed to use the included prior-patented technology for submission = of > > your enhancement to the patent office for patenting of your enhanceme= nt. > > Otherwise, you could not patent an enhancement without the prior-pate= nt > > holders' permission, which seems to violate the law allowing such > > enhancements. > >=20 > > But as I said, there are expert lawyers with learned opinions who > > disagree. Their view is based on the notion that patent gives one an > > absolute, exclusive right over the control of the technology during t= he > > term of the patent. In other words, they have a right not to license,= and > > if they choose, a right to preventing entirely the private sector use= of > > the patented technology. They would probably argue that if you haven= 't > > submitted a patent application, your research isn't really research b= ut > > just private usage that they are entitled to prohibit. In verbal "ban= ter" > > with such lawyers, some denied entirely any implicit right to researc= h, > > which I thought a more dubious position. There is also an argument th= at > > source code aids infringement, particularly binaries [This is also wh= y I > > find Kazaa, etc 'aiding' arguments so disturbing, besides other reaso= ns]. > > There is some support for these views, and for non-trivial conflict i= n > > court. So far, these views are untested. You should consult your lawy= er > > before deciding on a course of action which could put you at risk. (= And > > of course, you should also support the LPF and help abolish software > > patents. ;-) > >=20 > > I should add that Av8 Internet and a couple other sites went so far a= s to > > mirror OpenSSL for research in the US before the RSA patents expired > > (while using only a patent-licenced version). RSA did not react. Howe= ver, > > this does not conclusively mean anything. > >=20 > > So much for the 2005 patent lecture.... ;-) > >=20 > >=20 > > --Dean > >=20 > > --=20 > > Av8 Internet Prepared to pay a premium for better service? > > www.av8.net faster, more reliable, better service > > 617 344 9000 =20 > >=20 > >=20 > >=20 > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org wi= th > > the word 'unsubscribe' in a single line as the message text body. > > archive: >=20 >=20 --=20 Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 =20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 06 18:59:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECmPq-0003ws-JM for dnsext-archive@megatron.ietf.org; Tue, 06 Sep 2005 18:59:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08033 for ; Tue, 6 Sep 2005 18:59:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ECmMD-000E8O-JM for namedroppers-data@psg.com; Tue, 06 Sep 2005 22:56:01 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1ECmMB-000E7x-Gl for namedroppers@ops.ietf.org; Tue, 06 Sep 2005 22:55:59 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j86MtWKN016937; Tue, 6 Sep 2005 22:55:32 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j86MtW38016936; Tue, 6 Sep 2005 22:55:32 GMT Date: Tue, 6 Sep 2005 22:55:32 +0000 From: bmanning@vacation.karoshi.com To: Dean Anderson Cc: bmanning@vacation.karoshi.com, =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org, proceedings@ietf.org Subject: Re: DNSEXT Minutes @ IETF-63 Message-ID: <20050906225532.GI16432@vacation.karoshi.com.> References: <20050905042819.GA8707@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA08033 Dean, I take legal advice from my lawyers, not from email lists. You were= not the first and won't be the last to advise getting quality legal opinions.= Don't flatter yourself that you are singled out for special treatment. If you would like to join my legal team, then I can put you in touch with my law= yers. Your comments wrt -our- associates is not germaine to the points raised b= y the DNSEXT chair. --bill On Tue, Sep 06, 2005 at 06:23:07PM -0400, Dean Anderson wrote: > Advice from the President of the League for Programming Freedom, an > organization founded by Richard Stallman to fight software patents and > user interface copyrights, an organization that has organized successfu= l > US Supreme Court briefs and has an extensive background and involvement= in > Patent, Copyright, and Trademark Law, is better than your usual arm cha= ir > advice. However, I did advise you to consult a lawyer before doing > anything that could put you at risk. >=20 > But the nature of your message suggests that there is something > contradictory to my advice. What attorney has given you advice > contradictory to mine? >=20 > And more to the point, what attorney told you that patent issues are > somehow only covering a specific implementation? >=20 > It is particularly odd that you attack my credibility as "arm chair > advice", yet you expect us to accept your assurances. I can't accept y= our > assurances.=20 >=20 > I note that on other topics involve law and networks, your associates h= ave > made misrepresentations about legal issues. In some cases that I have > personally been involved with, they have misled their attorneys about t= he > relevant facts, resulting in incorrect advice based on mis-information.= =20 > And resulting in unnecessary legal conflict. When the mis-information w= as > corrected and true facts established, their attorneys acknowledged that > our view of the law was right, specifically, that they would comply wit= h > the law and they would cease and desist. >=20 > Credibility is established by history of correct statements and correct > analysis. Lack of credibility is similarly established by a history of > incorrect statements and association with incorrect statements. My > credibility is pretty strong, having been tested over time and vindicat= ed. =20 > Your credibility has been undermined by the repeated failures of your > associates to make correct statements on other legal topics. So, I am = not > very convinced when you tell us we don't have to worry about some legal > issue. I am particularly concerned about patent issues, with which I a= m > pretty well versed. >=20 > While your lawyer may have told you something, it has been the case > previously that your associates misled their own lawyers. Garbage in, > garbage out.=20 >=20 >=20 > --Dean =09 >=20 >=20 > On Mon, 5 Sep 2005 bmanning@vacation.karoshi.com wrote: >=20 > > thanks Dean. I'll file this under "arm-chair legal advice".... > > the folks who do this for a living have given good advice to me > > on the implementation we are building. =20 > >=20 > > The best advice one can give, unless its from a competent attorney > > who deals in IPR issues, is to get such advice. Advice from a=20 > > mailing list is ... less than credible. > >=20 > > --bill > >=20 > >=20 > > On Sun, Sep 04, 2005 at 06:17:45PM -0400, Dean Anderson wrote: > > > On Thu, 1 Sep 2005, =D3lafur Gu=F0mundsson wrote: > > > > Both documents have had an IPR claim filed against them. The pate= nt > > > > this has been issued in one country at the moment (Israel) but fi= led > > > > in some other countries as well, just not approved (yet). There i= s a > > > > license available that is royalty free, but does have some terms.= So > > > > implementors either don't know what to do or are ignoring it. > > >=20 > > > Factor GATT requirements into that. Many countries have agreed [und= er > > > GATT] to accept patents issued by other countries, so those patents= are > > > [or will be] enforceable in other GATT countries. [yes, GATT is tru= ely > > > evil, but that's another story]. You should assume that all patents > > > propogate to all "civilized" countries. > > >=20 > > > > Donald Eastlake presents some drafts about cryptographic algorith= ms. > > > >=20 > > > > First something about draft-ietf-dnsext-ecc-key-07: > > > > There have been some questions in the past about patents, but > > > > as far as is known, these only cover specific implementations, no= t on the > > > > basic theory or scheme of it, perhaps on specific equations.=20 > > >=20 > > > Umm, software patents almost never only= cover > > > specific implementations (ie object code). The issues are how funda= mental > > > the patent is and how broad the patent claims are. Do you have the= patent > > > numbers for the subject patents? > > >=20 > > > BTW, one more word of software patent advice: Don't do patent searc= hes, > > > unless you are patenting something. Because having done a patent s= earch > > > [and presumably thinking you've not found anything infringing] is a= ctually > > > evidence against you for intentional infringement, which carries mo= re > > > severe penalties. Once you've admitted that you aren't [or just sh= ouldn't > > > be] completely ignorant of the infringed patent, you better be sure= you > > > are right. It is usually best to be completely ignorant of the pate= nts so > > > any infringement is unintentional. [BTW this is an argument against= the > > > patent system--it can't benefit the development of science and tech= nology] > > >=20 > > > Another patent issue to be aware of: Some patent lawyers think that > > > possession of [free] software implementations of patented software > > > infringe on patents. I'll present a summary of both views as accura= tely as > > > I can. > > >=20 > > > Commercial and private usage for non-research purposes plainly does > > > infringe, but source code possession and research is not so clear. = For > > > example, the OpenSSL distribution before the RSA patents expired. = I don't > > > think it is the case that source code possession infringes, but its= a view > > > in dispute and untested in court. My view is based on the notions: = That > > > description of patented technology does not infringe; That you are = allowed > > > to patent enhancements to prior-patents and the prior-patent holder= cannot > > > prevent this; And that a working model must be available at the tim= e of > > > patent submission---you cannot patent a hypothetical device. > > >=20 > > > There is an explicit right to have a description of the patented > > > technology and source code is descriptive of software patents. Ther= e must > > > also be an implicit right that you are that you can use the prior-p= atented > > > technology for research on an enhancement, and that you also must b= e > > > allowed to use the included prior-patented technology for submissio= n of > > > your enhancement to the patent office for patenting of your enhance= ment. > > > Otherwise, you could not patent an enhancement without the prior-pa= tent > > > holders' permission, which seems to violate the law allowing such > > > enhancements. > > >=20 > > > But as I said, there are expert lawyers with learned opinions who > > > disagree. Their view is based on the notion that patent gives one = an > > > absolute, exclusive right over the control of the technology during= the > > > term of the patent. In other words, they have a right not to licens= e, and > > > if they choose, a right to preventing entirely the private sector u= se of > > > the patented technology. They would probably argue that if you hav= en't > > > submitted a patent application, your research isn't really research= but > > > just private usage that they are entitled to prohibit. In verbal "b= anter" > > > with such lawyers, some denied entirely any implicit right to resea= rch, > > > which I thought a more dubious position. There is also an argument = that > > > source code aids infringement, particularly binaries [This is also = why I > > > find Kazaa, etc 'aiding' arguments so disturbing, besides other rea= sons]. > > > There is some support for these views, and for non-trivial conflict= in > > > court. So far, these views are untested. You should consult your la= wyer > > > before deciding on a course of action which could put you at risk. = (And > > > of course, you should also support the LPF and help abolish softwar= e > > > patents. ;-) > > >=20 > > > I should add that Av8 Internet and a couple other sites went so far= as to > > > mirror OpenSSL for research in the US before the RSA patents expire= d > > > (while using only a patent-licenced version). RSA did not react. Ho= wever, > > > this does not conclusively mean anything. > > >=20 > > > So much for the 2005 patent lecture.... ;-) > > >=20 > > >=20 > > > --Dean > > >=20 > > > --=20 > > > Av8 Internet Prepared to pay a premium for better service? > > > www.av8.net faster, more reliable, better service > > > 617 344 9000 =20 > > >=20 > > >=20 > > >=20 > > > -- > > > 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: > >=20 > >=20 >=20 > --=20 > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 =20 >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 07 12:54:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED3Br-0007Xh-Je for dnsext-archive@megatron.ietf.org; Wed, 07 Sep 2005 12:54:27 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01855 for ; Wed, 7 Sep 2005 12:54:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ED35u-000E4f-Qv for namedroppers-data@psg.com; Wed, 07 Sep 2005 16:48:18 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1ED35s-000E4J-SM for namedroppers@ops.ietf.org; Wed, 07 Sep 2005 16:48:17 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1ED35r-0005wj-5L; Wed, 07 Sep 2005 18:48:15 +0200 In-Reply-To: To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rfc2538bis-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Marcos Sanz/Denic Message-ID: Date: Wed, 7 Sep 2005 18:48:07 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 07.09.2005 18:48:15, Serialize complete at 07.09.2005 18:48:15 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon, > I added: > > Note that two different keys may have the same key tag. > > If you need more text, please suggest it. That's enough, I think. > > Besides: What about using RFC2606 domains instead of the existing > > john-doe.com? > > * Section 3.1, 2nd example: I suggest using RFC3330 IP addresses for > > examples (192.0.2.0/24) > > I recall that Olaf specified in the document write-up that we decided > to not do this, to preserve similarity with RFC 2538. Fine by me > > Besides: What about including a preference in the order of > > appearance (simmilar to the order in section 3.1)? Like for > > instance, first looking for the fingerprint and then for the key ID. > > I'm not sure about this. I don't think it is useful. My > implementations do both fingerprint and key ID lookups, but the > priority order is per-application. I still think that a guideline could be useful, for different implementations could lead to different results in case there were one CERT under the fingerprint AND a different one under the key ID. I admit this is a very artificial argument. Since I don't have any strong feelings on this and in the light of the potential need for a new LC, we just can leave it as it is. Regards, Marcos -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 07 15:40:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED5mm-0000zX-Et for dnsext-archive@megatron.ietf.org; Wed, 07 Sep 2005 15:40:44 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12219 for ; Wed, 7 Sep 2005 15:40:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ED5ij-0000PJ-Di for namedroppers-data@psg.com; Wed, 07 Sep 2005 19:36:33 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1ED5ig-0000Oy-NS for namedroppers@ops.ietf.org; Wed, 07 Sep 2005 19:36:31 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j87JaD18008464 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 7 Sep 2005 15:36:14 -0400 Date: Wed, 7 Sep 2005 15:36:13 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: bmanning@vacation.karoshi.com cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , , Subject: Re: DNSEXT Minutes @ IETF-63 In-Reply-To: <20050906225532.GI16432@vacation.karoshi.com.> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA12219 Perhaps you could comply with IETF rules and fully disclose the IPR encumbrances. We cannot take your assurances that there are none. --Dean On Tue, 6 Sep 2005 bmanning@vacation.karoshi.com wrote: >=20 > Dean, I take legal advice from my lawyers, not from email lists. You we= re not > the first and won't be the last to advise getting quality legal opinion= s. Don't > flatter yourself that you are singled out for special treatment. If yo= u > would like to join my legal team, then I can put you in touch with my l= awyers. > Your comments wrt -our- associates is not germaine to the points raised= by the > DNSEXT chair. >=20 > --bill >=20 >=20 > On Tue, Sep 06, 2005 at 06:23:07PM -0400, Dean Anderson wrote: > > Advice from the President of the League for Programming Freedom, an > > organization founded by Richard Stallman to fight software patents an= d > > user interface copyrights, an organization that has organized success= ful > > US Supreme Court briefs and has an extensive background and involveme= nt in > > Patent, Copyright, and Trademark Law, is better than your usual arm c= hair > > advice. However, I did advise you to consult a lawyer before doing > > anything that could put you at risk. > >=20 > > But the nature of your message suggests that there is something > > contradictory to my advice. What attorney has given you advice > > contradictory to mine? > >=20 > > And more to the point, what attorney told you that patent issues are > > somehow only covering a specific implementation? > >=20 > > It is particularly odd that you attack my credibility as "arm chair > > advice", yet you expect us to accept your assurances. I can't accept= your > > assurances.=20 > >=20 > > I note that on other topics involve law and networks, your associates= have > > made misrepresentations about legal issues. In some cases that I have > > personally been involved with, they have misled their attorneys about= the > > relevant facts, resulting in incorrect advice based on mis-informatio= n. =20 > > And resulting in unnecessary legal conflict. When the mis-information= was > > corrected and true facts established, their attorneys acknowledged th= at > > our view of the law was right, specifically, that they would comply w= ith > > the law and they would cease and desist. > >=20 > > Credibility is established by history of correct statements and corre= ct > > analysis. Lack of credibility is similarly established by a history = of > > incorrect statements and association with incorrect statements. My > > credibility is pretty strong, having been tested over time and vindic= ated. =20 > > Your credibility has been undermined by the repeated failures of your > > associates to make correct statements on other legal topics. So, I a= m not > > very convinced when you tell us we don't have to worry about some leg= al > > issue. I am particularly concerned about patent issues, with which I= am > > pretty well versed. > >=20 > > While your lawyer may have told you something, it has been the case > > previously that your associates misled their own lawyers. Garbage in= , > > garbage out.=20 > >=20 > >=20 > > --Dean =09 > >=20 > >=20 > > On Mon, 5 Sep 2005 bmanning@vacation.karoshi.com wrote: > >=20 > > > thanks Dean. I'll file this under "arm-chair legal advice".... > > > the folks who do this for a living have given good advice to me > > > on the implementation we are building. =20 > > >=20 > > > The best advice one can give, unless its from a competent attorney > > > who deals in IPR issues, is to get such advice. Advice from a=20 > > > mailing list is ... less than credible. > > >=20 > > > --bill > > >=20 > > >=20 > > > On Sun, Sep 04, 2005 at 06:17:45PM -0400, Dean Anderson wrote: > > > > On Thu, 1 Sep 2005, =D3lafur Gu=F0mundsson wrote: > > > > > Both documents have had an IPR claim filed against them. The pa= tent > > > > > this has been issued in one country at the moment (Israel) but = filed > > > > > in some other countries as well, just not approved (yet). There= is a > > > > > license available that is royalty free, but does have some term= s. So > > > > > implementors either don't know what to do or are ignoring it. > > > >=20 > > > > Factor GATT requirements into that. Many countries have agreed [u= nder > > > > GATT] to accept patents issued by other countries, so those paten= ts are > > > > [or will be] enforceable in other GATT countries. [yes, GATT is t= ruely > > > > evil, but that's another story]. You should assume that all paten= ts > > > > propogate to all "civilized" countries. > > > >=20 > > > > > Donald Eastlake presents some drafts about cryptographic algori= thms. > > > > >=20 > > > > > First something about draft-ietf-dnsext-ecc-key-07: > > > > > There have been some questions in the past about patents, but > > > > > as far as is known, these only cover specific implementations, = not on the > > > > > basic theory or scheme of it, perhaps on specific equations.=20 > > > >=20 > > > > Umm, software patents almost never on= ly cover > > > > specific implementations (ie object code). The issues are how fun= damental > > > > the patent is and how broad the patent claims are. Do you have t= he patent > > > > numbers for the subject patents? > > > >=20 > > > > BTW, one more word of software patent advice: Don't do patent sea= rches, > > > > unless you are patenting something. Because having done a patent= search > > > > [and presumably thinking you've not found anything infringing] is= actually > > > > evidence against you for intentional infringement, which carries = more > > > > severe penalties. Once you've admitted that you aren't [or just = shouldn't > > > > be] completely ignorant of the infringed patent, you better be su= re you > > > > are right. It is usually best to be completely ignorant of the pa= tents so > > > > any infringement is unintentional. [BTW this is an argument again= st the > > > > patent system--it can't benefit the development of science and te= chnology] > > > >=20 > > > > Another patent issue to be aware of: Some patent lawyers think th= at > > > > possession of [free] software implementations of patented softwar= e > > > > infringe on patents. I'll present a summary of both views as accu= rately as > > > > I can. > > > >=20 > > > > Commercial and private usage for non-research purposes plainly do= es > > > > infringe, but source code possession and research is not so clear= . For > > > > example, the OpenSSL distribution before the RSA patents expired.= I don't > > > > think it is the case that source code possession infringes, but i= ts a view > > > > in dispute and untested in court. My view is based on the notions= : That > > > > description of patented technology does not infringe; That you ar= e allowed > > > > to patent enhancements to prior-patents and the prior-patent hold= er cannot > > > > prevent this; And that a working model must be available at the t= ime of > > > > patent submission---you cannot patent a hypothetical device. > > > >=20 > > > > There is an explicit right to have a description of the patented > > > > technology and source code is descriptive of software patents. Th= ere must > > > > also be an implicit right that you are that you can use the prior= -patented > > > > technology for research on an enhancement, and that you also must= be > > > > allowed to use the included prior-patented technology for submiss= ion of > > > > your enhancement to the patent office for patenting of your enhan= cement. > > > > Otherwise, you could not patent an enhancement without the prior-= patent > > > > holders' permission, which seems to violate the law allowing such > > > > enhancements. > > > >=20 > > > > But as I said, there are expert lawyers with learned opinions who > > > > disagree. Their view is based on the notion that patent gives on= e an > > > > absolute, exclusive right over the control of the technology duri= ng the > > > > term of the patent. In other words, they have a right not to lice= nse, and > > > > if they choose, a right to preventing entirely the private sector= use of > > > > the patented technology. They would probably argue that if you h= aven't > > > > submitted a patent application, your research isn't really resear= ch but > > > > just private usage that they are entitled to prohibit. In verbal = "banter" > > > > with such lawyers, some denied entirely any implicit right to res= earch, > > > > which I thought a more dubious position. There is also an argumen= t that > > > > source code aids infringement, particularly binaries [This is als= o why I > > > > find Kazaa, etc 'aiding' arguments so disturbing, besides other r= easons]. > > > > There is some support for these views, and for non-trivial confli= ct in > > > > court. So far, these views are untested. You should consult your = lawyer > > > > before deciding on a course of action which could put you at risk= . (And > > > > of course, you should also support the LPF and help abolish softw= are > > > > patents. ;-) > > > >=20 > > > > I should add that Av8 Internet and a couple other sites went so f= ar as to > > > > mirror OpenSSL for research in the US before the RSA patents expi= red > > > > (while using only a patent-licenced version). RSA did not react. = However, > > > > this does not conclusively mean anything. > > > >=20 > > > > So much for the 2005 patent lecture.... ;-) > > > >=20 > > > >=20 > > > > --Dean > > > >=20 > > > > --=20 > > > > Av8 Internet Prepared to pay a premium for better service? > > > > www.av8.net faster, more reliable, better service > > > > 617 344 9000 =20 > > > >=20 > > > >=20 > > > >=20 > > > > -- > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.or= g with > > > > the word 'unsubscribe' in a single line as the message text body. > > > > archive: > > >=20 > > >=20 > >=20 > > --=20 > > Av8 Internet Prepared to pay a premium for better service? > > www.av8.net faster, more reliable, better service > > 617 344 9000 =20 > >=20 >=20 >=20 --=20 Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 =20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 07 16:03:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED68d-0006EO-Sm for dnsext-archive@megatron.ietf.org; Wed, 07 Sep 2005 16:03:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14833 for ; Wed, 7 Sep 2005 16:03:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ED66P-0002S7-Oh for namedroppers-data@psg.com; Wed, 07 Sep 2005 20:01:01 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1ED66N-0002RZ-FF for namedroppers@ops.ietf.org; Wed, 07 Sep 2005 20:00:59 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j87K0gKN021546; Wed, 7 Sep 2005 20:00:42 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j87K0g3P021545; Wed, 7 Sep 2005 20:00:42 GMT Date: Wed, 7 Sep 2005 20:00:42 +0000 From: bmanning@vacation.karoshi.com To: Dean Anderson Cc: bmanning@vacation.karoshi.com, =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org, proceedings@ietf.org Subject: Re: DNSEXT Minutes @ IETF-63 Message-ID: <20050907200042.GC21256@vacation.karoshi.com.> References: <20050906225532.GI16432@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA14833 sure. the filed IPR claims are here: https://datatracker.ietf.org/public/ipr_search.cgi --bill On Wed, Sep 07, 2005 at 03:36:13PM -0400, Dean Anderson wrote: > Perhaps you could comply with IETF rules and fully disclose the IPR > encumbrances. We cannot take your assurances that there are none. >=20 > --Dean >=20 >=20 > On Tue, 6 Sep 2005 bmanning@vacation.karoshi.com wrote: >=20 > >=20 > > Dean, I take legal advice from my lawyers, not from email lists. You = were not > > the first and won't be the last to advise getting quality legal opini= ons. Don't > > flatter yourself that you are singled out for special treatment. If = you > > would like to join my legal team, then I can put you in touch with my= lawyers. > > Your comments wrt -our- associates is not germaine to the points rais= ed by the > > DNSEXT chair. > >=20 > > --bill > >=20 > >=20 > > On Tue, Sep 06, 2005 at 06:23:07PM -0400, Dean Anderson wrote: > > > Advice from the President of the League for Programming Freedom, an > > > organization founded by Richard Stallman to fight software patents = and > > > user interface copyrights, an organization that has organized succe= ssful > > > US Supreme Court briefs and has an extensive background and involve= ment in > > > Patent, Copyright, and Trademark Law, is better than your usual arm= chair > > > advice. However, I did advise you to consult a lawyer before doing > > > anything that could put you at risk. > > >=20 > > > But the nature of your message suggests that there is something > > > contradictory to my advice. What attorney has given you advice > > > contradictory to mine? > > >=20 > > > And more to the point, what attorney told you that patent issues ar= e > > > somehow only covering a specific implementation? > > >=20 > > > It is particularly odd that you attack my credibility as "arm chair > > > advice", yet you expect us to accept your assurances. I can't acce= pt your > > > assurances.=20 > > >=20 > > > I note that on other topics involve law and networks, your associat= es have > > > made misrepresentations about legal issues. In some cases that I ha= ve > > > personally been involved with, they have misled their attorneys abo= ut the > > > relevant facts, resulting in incorrect advice based on mis-informat= ion. =20 > > > And resulting in unnecessary legal conflict. When the mis-informati= on was > > > corrected and true facts established, their attorneys acknowledged = that > > > our view of the law was right, specifically, that they would comply= with > > > the law and they would cease and desist. > > >=20 > > > Credibility is established by history of correct statements and cor= rect > > > analysis. Lack of credibility is similarly established by a histor= y of > > > incorrect statements and association with incorrect statements. My > > > credibility is pretty strong, having been tested over time and vind= icated. =20 > > > Your credibility has been undermined by the repeated failures of yo= ur > > > associates to make correct statements on other legal topics. So, I= am not > > > very convinced when you tell us we don't have to worry about some l= egal > > > issue. I am particularly concerned about patent issues, with which= I am > > > pretty well versed. > > >=20 > > > While your lawyer may have told you something, it has been the case > > > previously that your associates misled their own lawyers. Garbage = in, > > > garbage out.=20 > > >=20 > > >=20 > > > --Dean =09 > > >=20 > > >=20 > > > On Mon, 5 Sep 2005 bmanning@vacation.karoshi.com wrote: > > >=20 > > > > thanks Dean. I'll file this under "arm-chair legal advice".... > > > > the folks who do this for a living have given good advice to me > > > > on the implementation we are building. =20 > > > >=20 > > > > The best advice one can give, unless its from a competent attorn= ey > > > > who deals in IPR issues, is to get such advice. Advice from a=20 > > > > mailing list is ... less than credible. > > > >=20 > > > > --bill > > > >=20 > > > >=20 > > > > On Sun, Sep 04, 2005 at 06:17:45PM -0400, Dean Anderson wrote: > > > > > On Thu, 1 Sep 2005, =D3lafur Gu=F0mundsson wrote: > > > > > > Both documents have had an IPR claim filed against them. The = patent > > > > > > this has been issued in one country at the moment (Israel) bu= t filed > > > > > > in some other countries as well, just not approved (yet). The= re is a > > > > > > license available that is royalty free, but does have some te= rms. So > > > > > > implementors either don't know what to do or are ignoring it. > > > > >=20 > > > > > Factor GATT requirements into that. Many countries have agreed = [under > > > > > GATT] to accept patents issued by other countries, so those pat= ents are > > > > > [or will be] enforceable in other GATT countries. [yes, GATT is= truely > > > > > evil, but that's another story]. You should assume that all pat= ents > > > > > propogate to all "civilized" countries. > > > > >=20 > > > > > > Donald Eastlake presents some drafts about cryptographic algo= rithms. > > > > > >=20 > > > > > > First something about draft-ietf-dnsext-ecc-key-07: > > > > > > There have been some questions in the past about patents, but > > > > > > as far as is known, these only cover specific implementations= , not on the > > > > > > basic theory or scheme of it, perhaps on specific equations.=20 > > > > >=20 > > > > > Umm, software patents almost never = only cover > > > > > specific implementations (ie object code). The issues are how f= undamental > > > > > the patent is and how broad the patent claims are. Do you have= the patent > > > > > numbers for the subject patents? > > > > >=20 > > > > > BTW, one more word of software patent advice: Don't do patent s= earches, > > > > > unless you are patenting something. Because having done a pate= nt search > > > > > [and presumably thinking you've not found anything infringing] = is actually > > > > > evidence against you for intentional infringement, which carrie= s more > > > > > severe penalties. Once you've admitted that you aren't [or jus= t shouldn't > > > > > be] completely ignorant of the infringed patent, you better be = sure you > > > > > are right. It is usually best to be completely ignorant of the = patents so > > > > > any infringement is unintentional. [BTW this is an argument aga= inst the > > > > > patent system--it can't benefit the development of science and = technology] > > > > >=20 > > > > > Another patent issue to be aware of: Some patent lawyers think = that > > > > > possession of [free] software implementations of patented softw= are > > > > > infringe on patents. I'll present a summary of both views as ac= curately as > > > > > I can. > > > > >=20 > > > > > Commercial and private usage for non-research purposes plainly = does > > > > > infringe, but source code possession and research is not so cle= ar. For > > > > > example, the OpenSSL distribution before the RSA patents expire= d. I don't > > > > > think it is the case that source code possession infringes, but= its a view > > > > > in dispute and untested in court. My view is based on the notio= ns: That > > > > > description of patented technology does not infringe; That you = are allowed > > > > > to patent enhancements to prior-patents and the prior-patent ho= lder cannot > > > > > prevent this; And that a working model must be available at the= time of > > > > > patent submission---you cannot patent a hypothetical device. > > > > >=20 > > > > > There is an explicit right to have a description of the patente= d > > > > > technology and source code is descriptive of software patents. = There must > > > > > also be an implicit right that you are that you can use the pri= or-patented > > > > > technology for research on an enhancement, and that you also mu= st be > > > > > allowed to use the included prior-patented technology for submi= ssion of > > > > > your enhancement to the patent office for patenting of your enh= ancement. > > > > > Otherwise, you could not patent an enhancement without the prio= r-patent > > > > > holders' permission, which seems to violate the law allowing su= ch > > > > > enhancements. > > > > >=20 > > > > > But as I said, there are expert lawyers with learned opinions w= ho > > > > > disagree. Their view is based on the notion that patent gives = one an > > > > > absolute, exclusive right over the control of the technology du= ring the > > > > > term of the patent. In other words, they have a right not to li= cense, and > > > > > if they choose, a right to preventing entirely the private sect= or use of > > > > > the patented technology. They would probably argue that if you= haven't > > > > > submitted a patent application, your research isn't really rese= arch but > > > > > just private usage that they are entitled to prohibit. In verba= l "banter" > > > > > with such lawyers, some denied entirely any implicit right to r= esearch, > > > > > which I thought a more dubious position. There is also an argum= ent that > > > > > source code aids infringement, particularly binaries [This is a= lso why I > > > > > find Kazaa, etc 'aiding' arguments so disturbing, besides other= reasons]. > > > > > There is some support for these views, and for non-trivial conf= lict in > > > > > court. So far, these views are untested. You should consult you= r lawyer > > > > > before deciding on a course of action which could put you at ri= sk. (And > > > > > of course, you should also support the LPF and help abolish sof= tware > > > > > patents. ;-) > > > > >=20 > > > > > I should add that Av8 Internet and a couple other sites went so= far as to > > > > > mirror OpenSSL for research in the US before the RSA patents ex= pired > > > > > (while using only a patent-licenced version). RSA did not react= . However, > > > > > this does not conclusively mean anything. > > > > >=20 > > > > > So much for the 2005 patent lecture.... ;-) > > > > >=20 > > > > >=20 > > > > > --Dean > > > > >=20 > > > > > --=20 > > > > > Av8 Internet Prepared to pay a premium for better service? > > > > > www.av8.net faster, more reliable, better service > > > > > 617 344 9000 =20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > -- > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.= org with > > > > > the word 'unsubscribe' in a single line as the message text bod= y. > > > > > archive: > > > >=20 > > > >=20 > > >=20 > > > --=20 > > > Av8 Internet Prepared to pay a premium for better service? > > > www.av8.net faster, more reliable, better service > > > 617 344 9000 =20 > > >=20 > >=20 > >=20 >=20 > --=20 > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 =20 >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 07 16:03:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED68n-0006Gi-0s for dnsext-archive@megatron.ietf.org; Wed, 07 Sep 2005 16:03:29 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14898 for ; Wed, 7 Sep 2005 16:03:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ED672-0002X6-F8 for namedroppers-data@psg.com; Wed, 07 Sep 2005 20:01:40 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1ED66y-0002WM-UB for namedroppers@ops.ietf.org; Wed, 07 Sep 2005 20:01:37 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j87K1PLd008889 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 7 Sep 2005 16:01:26 -0400 Date: Wed, 7 Sep 2005 16:01:24 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: namedroppers@ops.ietf.org, Subject: Re: DNSEXT Minutes @ IETF-63 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA14898 Actually, my comments are very germane to issue of why we cannot accept Mr. Manning's weak assurances that the patents don't apply. However, the IETF rules require full disclosure and we haven't had that. Mr. Manning has indicated that he knows of patents that may apply, and so far as I can determine, he hasn't disclosed them, but given us his assurance that they don't apply. This assurance, in my view, can't be accepted for the 2 reasons I listed: First, his explanation of why the patents don't apply doesn't hold water.= =20 I am an acknowledged leader of a software patent organization for many years. His attack on my credibility is unfounded, wrong, and against IETF= =20 rules. Second, he is associated with people who think it is OK to deceive their attorneys with respect to the facts of a particular situation, and have actually done so in my personal experience. This association cannot be denied, and is relevant to a question of whether we should accept his assurances about legal facts of software patents. My message can only be seen as "not constructive" from Mr. Manning's poin= t of view which would rather not have examination of the actual facts nor have any criticism however well-deserved. However, my message is constructive from the IETF point of view, which requires full disclosure as well as true, correct statements from participants. I demand full disclosure. Only then can we see if the asserted facts are actually true. --Dean On Wed, 7 Sep 2005, Dean Anderson wrote: > Perhaps you could chastise Mr. Manning for making an unfounded personal > attack. >=20 > I'm just defending my credibility on software patents. >=20 > --Dean >=20 > On Tue, 6 Sep 2005, =D3lafur Gu=F0mundsson /DNSEXT co-chair wrote: >=20 > >=20 > > Private message. > > Dean this is not a constructive discussion, please do not send > > messages like this one to the namedroppers mailing list. > > Feel free to continue off line with Mr. Manning but please respect > > his time by keeping your post to the point. > >=20 > > thanks > > Olafur (IMNAL but married to one :-)) > >=20 > >=20 > > At 18:23 06/09/2005, Dean Anderson wrote: > > >Advice from the President of the League for Programming Freedom, an > > >organization founded by Richard Stallman to fight software patents a= nd > > >user interface copyrights, an organization that has organized succes= sful > > >US Supreme Court briefs and has an extensive background and involvem= ent in > > >Patent, Copyright, and Trademark Law, is better than your usual arm = chair > > >advice. However, I did advise you to consult a lawyer before doing > > >anything that could put you at risk. > > > > > >But the nature of your message suggests that there is something > > >contradictory to my advice. What attorney has given you advice > > >contradictory to mine? > > > > > >And more to the point, what attorney told you that patent issues are > > >somehow only covering a specific implementation? > > > > > >It is particularly odd that you attack my credibility as "arm chair > > >advice", yet you expect us to accept your assurances. I can't accep= t your > > >assurances. > > > > > >I note that on other topics involve law and networks, your associate= s have > > >made misrepresentations about legal issues. In some cases that I hav= e > > >personally been involved with, they have misled their attorneys abou= t the > > >relevant facts, resulting in incorrect advice based on mis-informati= on. > > >And resulting in unnecessary legal conflict. When the mis-informatio= n was > > >corrected and true facts established, their attorneys acknowledged t= hat > > >our view of the law was right, specifically, that they would comply = with > > >the law and they would cease and desist. > > > > > >Credibility is established by history of correct statements and corr= ect > > >analysis. Lack of credibility is similarly established by a history= of > > >incorrect statements and association with incorrect statements. My > > >credibility is pretty strong, having been tested over time and vindi= cated. > > >Your credibility has been undermined by the repeated failures of you= r > > >associates to make correct statements on other legal topics. So, I = am not > > >very convinced when you tell us we don't have to worry about some le= gal > > >issue. I am particularly concerned about patent issues, with which = I am > > >pretty well versed. > > > > > >While your lawyer may have told you something, it has been the case > > >previously that your associates misled their own lawyers. Garbage i= n, > > >garbage out. > > > > > > > > > --Dean > > > > > > > > >On Mon, 5 Sep 2005 bmanning@vacation.karoshi.com wrote: > > > > > > > thanks Dean. I'll file this under "arm-chair legal advice".... > > > > the folks who do this for a living have given good advice to me > > > > on the implementation we are building. > > > > > > > > The best advice one can give, unless its from a competent attorn= ey > > > > who deals in IPR issues, is to get such advice. Advice from a > > > > mailing list is ... less than credible. > > > > > > > > --bill > > > > > > > > > > > > On Sun, Sep 04, 2005 at 06:17:45PM -0400, Dean Anderson wrote: > > > > > On Thu, 1 Sep 2005, =D3lafur Gu=F0mundsson wrote: > > > > > > Both documents have had an IPR claim filed against them. The = patent > > > > > > this has been issued in one country at the moment (Israel) bu= t filed > > > > > > in some other countries as well, just not approved (yet). The= re is a > > > > > > license available that is royalty free, but does have some te= rms. So > > > > > > implementors either don't know what to do or are ignoring it. > > > > > > > > > > Factor GATT requirements into that. Many countries have agreed = [under > > > > > GATT] to accept patents issued by other countries, so those pat= ents are > > > > > [or will be] enforceable in other GATT countries. [yes, GATT is= truely > > > > > evil, but that's another story]. You should assume that all pat= ents > > > > > propogate to all "civilized" countries. > > > > > > > > > > > Donald Eastlake presents some drafts about cryptographic algo= rithms. > > > > > > > > > > > > First something about draft-ietf-dnsext-ecc-key-07: > > > > > > There have been some questions in the past about patents, but > > > > > > as far as is known, these only cover=20 > > > specific implementations, not on the > > > > > > basic theory or scheme of it, perhaps on specific equations. > > > > > > > > > > Umm, software patents almost never = only cover > > > > > specific implementations (ie object code). The issues are how f= undamental > > > > > the patent is and how broad the patent=20 > > > claims are. Do you have the patent > > > > > numbers for the subject patents? > > > > > > > > > > BTW, one more word of software patent advice: Don't do patent s= earches, > > > > > unless you are patenting something. Because having done a pate= nt search > > > > > [and presumably thinking you've not found=20 > > > anything infringing] is actually > > > > > evidence against you for intentional infringement, which carrie= s more > > > > > severe penalties. Once you've admitted=20 > > > that you aren't [or just shouldn't > > > > > be] completely ignorant of the infringed patent, you better be = sure you > > > > > are right. It is usually best to be completely ignorant of the = patents so > > > > > any infringement is unintentional. [BTW this is an argument aga= inst the > > > > > patent system--it can't benefit the=20 > > > development of science and technology] > > > > > > > > > > Another patent issue to be aware of: Some patent lawyers think = that > > > > > possession of [free] software implementations of patented softw= are > > > > > infringe on patents. I'll present a summary=20 > > > of both views as accurately as > > > > > I can. > > > > > > > > > > Commercial and private usage for non-research purposes plainly = does > > > > > infringe, but source code possession and research is not so cle= ar. For > > > > > example, the OpenSSL distribution before=20 > > > the RSA patents expired. I don't > > > > > think it is the case that source code=20 > > > possession infringes, but its a view > > > > > in dispute and untested in court. My view is based on the notio= ns: That > > > > > description of patented technology does not=20 > > > infringe; That you are allowed > > > > > to patent enhancements to prior-patents and=20 > > > the prior-patent holder cannot > > > > > prevent this; And that a working model must be available at the= time of > > > > > patent submission---you cannot patent a hypothetical device. > > > > > > > > > > There is an explicit right to have a description of the patente= d > > > > > technology and source code is descriptive of software patents. = There must > > > > > also be an implicit right that you are that=20 > > > you can use the prior-patented > > > > > technology for research on an enhancement, and that you also mu= st be > > > > > allowed to use the included prior-patented technology for submi= ssion of > > > > > your enhancement to the patent office for patenting of your enh= ancement. > > > > > Otherwise, you could not patent an enhancement without the prio= r-patent > > > > > holders' permission, which seems to violate the law allowing su= ch > > > > > enhancements. > > > > > > > > > > But as I said, there are expert lawyers with learned opinions w= ho > > > > > disagree. Their view is based on the notion that patent gives = one an > > > > > absolute, exclusive right over the control of the technology du= ring the > > > > > term of the patent. In other words, they have a right not to li= cense, and > > > > > if they choose, a right to preventing entirely the private sect= or use of > > > > > the patented technology. They would probably argue that if you= haven't > > > > > submitted a patent application, your research isn't really rese= arch but > > > > > just private usage that they are entitled to prohibit. In verba= l "banter" > > > > > with such lawyers, some denied entirely any implicit right to r= esearch, > > > > > which I thought a more dubious position. There is also an argum= ent that > > > > > source code aids infringement, particularly binaries [This is a= lso why I > > > > > find Kazaa, etc 'aiding' arguments so disturbing, besides other= reasons]. > > > > > There is some support for these views, and for non-trivial conf= lict in > > > > > court. So far, these views are untested. You should consult you= r lawyer > > > > > before deciding on a course of action which could put you at ri= sk. (And > > > > > of course, you should also support the LPF and help abolish sof= tware > > > > > patents. ;-) > > > > > > > > > > I should add that Av8 Internet and a couple other sites went so= far as to > > > > > mirror OpenSSL for research in the US before the RSA patents ex= pired > > > > > (while using only a patent-licenced version). RSA did not react= . However, > > > > > this does not conclusively mean anything. > > > > > > > > > > So much for the 2005 patent lecture.... ;-) > > > > > > > > > > > > > > > --Dean > > > > > > > > > > -- > > > > > Av8 Internet Prepared to pay a premium for better service? > > > > > www.av8.net faster, more reliable, better service > > > > > 617 344 9000 > > > > > > > > > > > > > > > > > > > > -- > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.= org with > > > > > the word 'unsubscribe' in a single line as the message text bod= y. > > > > > archive: > > > > > > > > > > > > > >-- > > >Av8 Internet Prepared to pay a premium for better service? > > >www.av8.net faster, more reliable, better service > > >617 344 9000 > >=20 > >=20 > >=20 >=20 >=20 --=20 Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 =20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 07 16:27:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED6WP-0005N6-QS for dnsext-archive@megatron.ietf.org; Wed, 07 Sep 2005 16:27:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20282 for ; Wed, 7 Sep 2005 16:27:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ED6Tx-0004fT-NH for namedroppers-data@psg.com; Wed, 07 Sep 2005 20:25:21 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1ED6Tt-0004f9-8M for namedroppers@ops.ietf.org; Wed, 07 Sep 2005 20:25:18 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.3/8.13.3) with ESMTP id j87KPCBb075832 for ; Wed, 7 Sep 2005 22:25:12 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B185012-0627-4A44-990B-F013CF14CA1C@NLnetLabs.nl> Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: DNSEXT Minutes @ IETF-63 Date: Wed, 7 Sep 2005 22:25:06 +0200 To: namedroppers@ops.ietf.org X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Rat Hole Alert" [*] Please stop this discussion. For this working group the only relevance at this point is rough consensus on the technical specification and running code. We have neither at this point in time. Lets get back to the technical task at hand. Compare the two proposals. - --Olaf [*] http://ops.ietf.org/lists/namedroppers/namedroppers.2005/ msg00381.html > We want to issue is a "rat hole" alert: > Working groups tend to discuss the validity of patent claims, the > licensing terms and such at great lengths. In the end patent issues > are not technical but legal issues. It is up to the implementors of > technology under IPR to deal with these issues, not the working group. > If the IPR prohibits implementation than the WG would like to know, > from implementors. As rough consensus without running code does not > make sense. > > Or to paraphrase the above: we all have an opinion on IPR, this > is not the list to rehash those. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDH0yntN/ca3YJIocRAsn8AKCk1l4ZqCW/OenPsgcFWGUBWC42HQCgujeK jWRDXuu83+1FIWVP96Mzi4g= =9z4g -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From MarthaKann@volitional.net Thu Sep 08 03:00:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDGOi-000096-CA for dnsext-archive@megatron.ietf.org; Thu, 08 Sep 2005 03:00:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03183 for ; Thu, 8 Sep 2005 03:00:34 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDGS2-00022U-5n for dnsext-archive@ietf.org; Thu, 08 Sep 2005 03:04:02 -0400 Received: from [58.120.163.195] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1EDGOa-0004wX-3a for dnsext-archive@ietf.org; Thu, 08 Sep 2005 03:00:30 -0400 Received: from LPe@localhost by cga.int (8.11.6/8.11.6); Thu, 08 Sep 2005 01:27:50 -0700 Message-ID: From: "Ursula Fleming" Reply-To: "Ursula Fleming" To: dnsext-archive@ietf.org Subject: Out of this WoRLD $aving$ on all Office XP titles Date: Thu, 08 Sep 2005 04:25:50 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: MarthaKann@volitional.net Content-Type: multipart/mixed; boundary="--ZtfbNz7c4oEfy46I0" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 r1YP ----ZtfbNz7c4oEfy46I0 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable F
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
<= tr>

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Adobe = Photoshop 9.0
 3 Window= s XP Pro
 4 Adobe Acro= bat 7 Pro
 <= font face=3DVerdana size=3D1>5 Flash MX= 2004
 6 Corel Draw 1= 2
 7 Norton Antivirus = 2005
 8 Windows 2003 = Server
 9 Alias Maya = 6 Wavefrt
 <= font face=3DVerdana size=3D1>10 Adobe <= /a> Illustrator 11
&nb= sp; See more by this manufacturer
   Microsoft
   Symantec
   Adobe<= /a>
  Customers also bo= ught
   these other items...

Microsoft Office = Professional Edition *2003*
Microsoft

<= /table>

Choose= :
 
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (86%)

=

Availability: Available for INSTANT download!
Coupo= n Code: y0cmkNf
 

Sales Ra= nk: #1
System requirements  |  = Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Rev= iew:3D"5 Based on 194264 reviews. = Write a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 

List Price:$599.00
Price:$69.99<= /b>
You Save:$529.01 (90= %)



Availability: A= vailable for INSTANT download!
Coupon Code: rlpow
 

Sales Rank: #2
System requirements  |=   Other Versions
Date Coupon Expires: August 31st, 2005
<= font class=3Dtiny>Average Customer Review:3D"5= Based on 1376 re= views. Write a review.

Microsoft Windows XP Professional or Longhorn Edition Microsoft

Choose:=
 

List Price:$279.00
Price:$49.99
You Save:= $229.01 (85%)



Availabi= lity: Available for INSTANT download!
Coupon Code: 3Z67Wz1J=
 

Sales Rank: #3
System requiremen= ts  |  Other Versions<= /span>
Date Coupon Expires: August 31st, 200= 5
Average Customer Review:3D"5 Ba= sed on 1145 reviews. Write a review.=

Adobe Acrobat Professional V 7.0
= Adobe

=
Choose:
 = ;

=

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (85= %)



Availability: A= vailable for INSTANT download!
Coupon Code: 60ckSIQYa
 = ;

Sales Rank: #4
System requirements = |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 19836= reviews. Write a review.

=

<= /form> ----ZtfbNz7c4oEfy46I0-- From owner-namedroppers@ops.ietf.org Thu Sep 08 09:12:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDMCz-0007MP-2Y for dnsext-archive@megatron.ietf.org; Thu, 08 Sep 2005 09:12:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18684 for ; Thu, 8 Sep 2005 09:12:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDM8H-000PFk-O1 for namedroppers-data@psg.com; Thu, 08 Sep 2005 13:08:01 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EDM8E-000PF7-CO for namedroppers@ops.ietf.org; Thu, 08 Sep 2005 13:07:59 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j88D87A9013213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2005 15:08:12 +0200 From: Simon Josefsson To: Marcos Sanz/Denic Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rfc2538bis-04.txt References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050908:sanz@denic.de::UCP7GXJqa+M706sp:NeJT X-Hashcash: 1:21:050908:namedroppers@ops.ietf.org::XRjmhWwqSUe14Jj2:lgRB Date: Thu, 08 Sep 2005 15:07:39 +0200 In-Reply-To: (Marcos Sanz's message of "Wed, 7 Sep 2005 18:48:07 +0200") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Marcos Sanz/Denic writes: >> > Besides: What about including a preference in the order of >> > appearance (simmilar to the order in section 3.1)? Like for >> > instance, first looking for the fingerprint and then for the key ID. >> >> I'm not sure about this. I don't think it is useful. My >> implementations do both fingerprint and key ID lookups, but the >> priority order is per-application. > > I still think that a guideline could be useful, for different > implementations could lead to different results in case there were one > CERT under the fingerprint AND a different one under the key ID. I admit > this is a very artificial argument. Since I don't have any strong feelings > on this and in the light of the potential need for a new LC, we just can > leave it as it is. I'm not sure it is as problematic as you describe, every application/implementation that uses CERT RRs will need to make an implicit profile of the document by using one of the owner name standards. However, let suppose we want to address this. What would the preference order be? Some applications only has the 4 octet key id, some has the 8 octet key id, and some will have the full 16/20 octet fingerprint. Applications can remove digits, but not add them, so the only generally possible approach that would work for all implementations would be 4 octet key ids. But that create complexity to handle the case of collisions; some applications may not want to bother with that extra complexity, but would rather see that the recommendation was for full fingerprints. All in all, I think the document shouldn't go into more detail about this. I believe it is better to let applications profile this document to require a particular owner name guideline instead, if there really is a need. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 08 16:01:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDSZy-0007ev-S5 for dnsext-archive@megatron.ietf.org; Thu, 08 Sep 2005 16:01:02 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14886 for ; Thu, 8 Sep 2005 16:00:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDSVC-0005yx-6f for namedroppers-data@psg.com; Thu, 08 Sep 2005 19:56:06 +0000 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EDSV8-0005yN-3q for namedroppers@ops.ietf.org; Thu, 08 Sep 2005 19:56:02 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0097BE; 8 Sep 2005 15:58:58 -0400 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 8 Sep 2005 15:58:47 -0400 Received: from connotech.com (209.71.204.103) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0097BD; 8 Sep 2005 15:58:38 -0400 Message-ID: <43209EAB.3030807@connotech.com> Date: Thu, 08 Sep 2005 16:27:23 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?windows-1252?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: Re: DNSEXT Minutes @ IETF-63 References: <6.2.3.4.2.20050901145800.04065900@localhost> In-Reply-To: <6.2.3.4.2.20050901145800.04065900@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RCVD_IN_SBL autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA14886 =D3lafur Gu=F0mundsson wrote: >=20 > Minutes of the DNSEXT working group > 63rd IETF, Paris, France >=20 > [...] >=20 > Automatic Updates of DNSSEC trust anchors > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Olafur Gudmundsson reports that having no key management standard > might become the next excuse for not deploying DNSSEC. Early adaptors > may need to bear additional costs configuring trust anchors. The need > for configured trust anchors will never disappear, in the best case it > might be reduced to only one anchor, the root. Olafur pleas to the > working group for more activity here. Authors are frustrated with the > complete silence on this issue, they cannot continue until there is > discussion, feedback, a list of selection criteria and a time line. Well, a different approach to the DNS trust anchor renewal has been=20 presented on august 24 to a DNS deployment mailing list ... with=20 complete silence as well. I was (naively) hoping some feedback from=20 those early adopters before submitting this as an IETF contribution. The trust anchor key management is similar to the distribution of X.509=20 root key certificate. In this area, an IETF draft has been prepared,=20 i.e. http://www.ietf.org/internet-drafts/draft-moreau-pkix-takrem-00.txt=20 (verion -01 has been submitted today, following comments by Stephen Kent). For DNS, there are more protocol details for adopting a trust anchor=20 rollover scheme like TAKREM ("these details matter tremendously" - Sam=20 Weiler). So I prepared a document, see http://www.connotech.com/takrem_for_dnssec_01.pdf Title: =91Trust Anchor=92 Integrity Mechanisms for Internet DNS Security In this document, a new RR id defined, SDDA for "SEP DNSKEY Direct=20 Authenticator," with a fairly generic format, and two uses of the SDDA=20 RR are suggested, including TAKREM for trust anchor key renewal. This proposal is both new and comprehensive. The document can be turned=20 into an Internet-Draft, but this would need some feedback and discussion. Regards, --=20 - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 08 16:25:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDSxk-0004V0-QK for dnsext-archive@megatron.ietf.org; Thu, 08 Sep 2005 16:25:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15618 for ; Thu, 8 Sep 2005 16:25:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDSuj-0008IR-0S for namedroppers-data@psg.com; Thu, 08 Sep 2005 20:22:29 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EDSuf-0008I7-Li for namedroppers@ops.ietf.org; Thu, 08 Sep 2005 20:22:25 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j88KLqn6001431 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 8 Sep 2005 16:22:01 -0400 Date: Thu, 8 Sep 2005 16:21:52 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: "Olaf M. Kolkman" cc: namedroppers@ops.ietf.org, Subject: Re: DNSEXT Minutes @ IETF-63 [Software Patent issues denied discussion] In-Reply-To: <2B185012-0627-4A44-990B-F013CF14CA1C@NLnetLabs.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [CC'd to the main IETF list] [Note: Not very long ago, I argued persuasively to a large and broad movement within the IETF seeking to have the IETF adopt an anti-patent position. I took my position pragmatically on the basis that the IETF should consider patented technology intelligently on a case-by-case basis in order to ensure participation by pro-patent groups and organizations whose cooperation is necessary and beneficial to the IETF. This is a pragmatic and reasonable view; The IETF interests in patented technology are different from my ideological interests in abolishing software patents, even if those interests have broad support. Interoperable standards are more important than ideology. Placing interoperation ahead of ideological interests, I saw the value in having participation and cooperation on standards regardless of ideological differences. However, having persuaded people to take a pragmatic and cooperative view, pro-patent persons shouldn't try to exploit that cooperation by attempting to prevent or suppress consideration of IPR issues by working groups.] The statement of the WG chair (included below) is not consistent with the IETF rules on IPR disclosure and consideration. For your reference: RFC 3979: 6.1.1. A Contributor's IPR in his or her Contribution Any Contributor who reasonably and personally knows of IPR meeting the conditions of Section 6.6 which the Contributor believes Covers or may ultimately Cover his or her Contribution, or which the Contributor reasonably and personally knows his or her employer or sponsor may assert against Implementing Technologies based on such Contribution, must make a disclosure in accordance with this Section 6. This requirement specifically includes Contributions that are made by any means including electronic or spoken comments, unless the latter are rejected from consideration before a disclosure could reasonably be submitted. An IPR discloser is requested to withdraw a previous disclosure if a revised Contribution negates the previous IPR disclosure, or to amend a previous disclosure if a revised Contribution substantially alters the previous disclosure. Contributors must disclose IPR meeting the description in this section; there are no exceptions to this rule. The fact that a discussion may be legal in nature is of no relevance. We live in a professional world bounded by legal constraints. The working group must ensure that IETF requirements on IPR disclosure are met, and that IPR encumbrances are properly and fully considered by the working group participants in the selection of technology. Patent encumbrance is a valid basis for comparison of any proposal. And IPR encumbrance is in fact not limited mere comparison, but even whether to adopt a given technology at all; Rejection because of IPR encumbrance is a valid option to be decided on a case-by-case basis. I do not see that the WG Chair is allowed by IETF policy to exclude or suppress information or discussion about IPR encumbrance, which seems to be the purpose of suppressing this discussion. This is contrary to IETF policy, which is to have each WG intelligently consider IPR issues. Also, the WG chair makes mention of two documents. In fact, there are 3 documents noted in the minutes which seem to have IPR encumbrances: Two are reported in the minutes under the heading of "IPR Issues update". These two have IPR statements, but the IPR encumbrances have not been discussed or considered on list. draft-ietf-dnsext-trustupdate-timers-00 and draft-ietf-dnsext-trustupdate-threshold-00 However, the IPR section of the minutes has an ominous quote about these two: "There is a license available that is royalty free, but does have some terms. So implementors either don't know what to do or are ignoring it." Clearly, more discussion should be stimulated. It should also be worthwhile for the WG to search for and consider alternatives that aren't patent encumbered. This issue should be discussed, not ignored or suppressed as a "rat-hole". This "rat-hole" nonsense is just a cover for a submarine, pro-patent attempt to avoid discussion of the IPR issues in these documents, and perhaps avoiding the possibility of a patent-free alternative. But I am also concerned about a third document that is also mentioned in the minutes. draft-ietf-dnsext-ecc-key-07 This document does not have an IPR disclosure on the IETF IPR page. The minutes state: First something about draft-ietf-dnsext-ecc-key-07: There have been some questions in the past about patents, but as far as is known, these only cover specific implementations, not on the basic theory or scheme of it, perhaps on specific equations. As the President of the League for Programming Freedom, and a leader on the topics of Patent, Copyright, and Trademark law, I do not find this explanation of non-infringement to be credible. An IPR disclosure should be made on this document. According to RFC 3979, Section 6.1.1 "there are no exceptions to this rule". Further, the IETF is not to take any position on the validity of an IPR claim. The IETF can't ignore the claim as being invalid--that would be taking a position on its validity. The claim has to be documented and disclosed, even if it may not be valid. And also, the working group chairs should be directed to _encourage_ discussion and consideration of the IPR issues, not try to suppress the discussion. Note RFC 3979 Section 6.2: 6.2. The Timing of Providing Disclosure Timely IPR disclosure is important because working groups need to have as much information as they can while they are evaluating alternative solutions. If the WG chairs are working to suppress IPR information and discussion, it is not available for evaluation, in violation of the purpose of section 6.2. Dean Anderson President of the League for Programming Freedom. On Wed, 7 Sep 2005, Olaf M. Kolkman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > "Rat Hole Alert" [*] > > Please stop this discussion. > > For this working group the only relevance at this point is rough > consensus on the technical specification and running code. We have > neither at this point in time. > > Lets get back to the technical task at hand. Compare the two proposals. > > - --Olaf > > > [*] http://ops.ietf.org/lists/namedroppers/namedroppers.2005/ > msg00381.html > > > We want to issue is a "rat hole" alert: > > Working groups tend to discuss the validity of patent claims, the > > licensing terms and such at great lengths. In the end patent issues > > are not technical but legal issues. It is up to the implementors of > > technology under IPR to deal with these issues, not the working group. > > If the IPR prohibits implementation than the WG would like to know, > > from implementors. As rough consensus without running code does not > > make sense. > > > > Or to paraphrase the above: we all have an opinion on IPR, this > > is not the list to rehash those. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (Darwin) > Comment: This message is locally signed. > > iD8DBQFDH0yntN/ca3YJIocRAsn8AKCk1l4ZqCW/OenPsgcFWGUBWC42HQCgujeK > jWRDXuu83+1FIWVP96Mzi4g= > =9z4g > -----END PGP SIGNATURE----- > > -- > 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: > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From BrendaKrueger@tukticaret.net Thu Sep 08 17:16:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDTlD-00010O-Q4 for dnsext-archive@megatron.ietf.org; Thu, 08 Sep 2005 17:16:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17918 for ; Thu, 8 Sep 2005 17:16:37 -0400 (EDT) Received: from pcp01107004pcs.clntn201.mi.comcast.net ([68.62.68.197]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EDToa-0008NO-Lc for dnsext-archive@ietf.org; Thu, 08 Sep 2005 17:20:14 -0400 Received: from dPHk@localhost by aZlC.int (8.11.6/8.11.6); Fri, 09 Sep 2005 03:08:02 +0200 Message-ID: From: "Nicole Yazzie" Reply-To: "Nicole Yazzie" To: dnsext-archive@ietf.org Subject: XP Products available for Download Date: Fri, 09 Sep 2005 06:07:02 +0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: BrendaKrueger@tukticaret.net Content-Type: multipart/mixed; boundary="--THq8D85jP6XpSBdCFA" X-Spam-Score: 2.8 (++) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb PwXD ----THq8D85jP6XpSBdCFA Content-Type: text/html; Content-Transfer-Encoding: quoted-printable t
Opt-in Email Special Offer &n= bsp;   unsubscribe me
=
SEARCH
<= /td>

TOP 10 NEW TITLES

=
<= td width=3D4> <= /tr><= td width=3D4> 10<= tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Office Pro Edition 2003
2 Windows XP Pro
 3 Adobe Creative Suite Pre= mium
 4 = Systemworks Pro 2004 Edition
 <= /td>5 Flash MX 2004
 6 Corel Painter 8
7 Adobe Acrobat 6.0
 8 Windows 2003 Serve= r
 9 Ali= as Maya 6.0 Wavefront
  Adobe Premiere
&nb= sp; See more by this manufacturer
   Microsoft
   Apple Software
&n= bsp; Customers also bought
   these other items...
=



Microsoft Off= ice Professional Edition *2003*
Microsoft
Choose:
 
You Save:


Availability: Available for = INSTANT download!
Coupon Code: ISe229
Media: CD-ROM = / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Analyze and manage business information using Access data= bases
  • Exchange data with oth= er systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM technolog= y
  • Easy-to-use wizards to cre= ate e-mail newsletters and printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: International/US or via instant download
Date= Coupon Expires: May 30th, 2005
Avera= ge Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
=
List Price:$899.00
Price:$69.99
$830.01 (92%)
Microsoft Windows XP Professional or Longhorn Edition
Microsoft
Choose:
 

List Pri= ce:$279.00
Price:<= /b>$49.99
You Save:$229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download
Syst= em requirements  |  Accessories  |  Other Versions

Features:

  • Desi= gned for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
    • More security with the ability to encrypt f= iles and folders
  • Built-in vo= ice, video, and instant messaging support
  • <= font size=3D1>Integration with Windows servers and management solutions

Sales Rank: #2
Shipping: International/US or via instant download
Date Co= upon Expires: May 30th, 2005
Average = Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Creat= ive Suite Premium
Adobe
Choose:
 

List Price: $1149.00
Price:$99.99
You Save:= $849.01 (90%)


Availability: Available for INSTANT download!
Coupon Code:= ISe229
Media: CD-ROM / Download

System requiremen= ts  |  Access= ories  |  Oth= er Versions

Features:

  • An integrated de= sign environment featuring the industry's foremost design tools
  • In-depth tips, expert tricks, and = comprehensive design resources
  • Intuitive file finding, smooth workflow, and common interface and toolse= t
  • Single installer--control = what you install and when you install it
  • Cross-media publishing--create content for both print and the= Web

Sales Rank: #3 Shipping: International/US or via instant download<= br> Date Coupon Expires: May 30th, 2005
Average Customer Review: 3D"5 Based on 498 reviews. Write a review.

----THq8D85jP6XpSBdCFA-- From owner-namedroppers@ops.ietf.org Thu Sep 08 17:17:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDTm9-00018m-NO for dnsext-archive@megatron.ietf.org; Thu, 08 Sep 2005 17:17:43 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17987 for ; Thu, 8 Sep 2005 17:17:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDTip-000Cjg-3g for namedroppers-data@psg.com; Thu, 08 Sep 2005 21:14:15 +0000 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EDTin-000CjN-6L for namedroppers@ops.ietf.org; Thu, 08 Sep 2005 21:14:13 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j88LE4K1023149; Thu, 8 Sep 2005 14:14:04 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j88LE4a2023146; Thu, 8 Sep 2005 14:14:04 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 8 Sep 2005 14:14:04 -0700 (PDT) From: "william(at)elan.net" To: dcrocker@bbiw.net cc: namedroppers@ops.ietf.org, ietf@ietf.org Subject: Re: DNSEXT Minutes @ IETF-63 [Software Patent issues denied discussion] In-Reply-To: <4320A36C.9020904@dcrocker.net> Message-ID: References: <4320A36C.9020904@dcrocker.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 8 Sep 2005, Dave Crocker wrote: >> [Note: Not very long ago, I argued persuasively to a large and broad >> movement within the IETF seeking to have the IETF adopt an anti-patent >> position. > > my memory is slipping worse that I thought. > i don't recall seeing evidence of the community's being persuaded. Neverheless if I understand it, it has always been a position of IETF to consider patented technology as being less preferable then patented for standardization (ok, it also has a lot to do with kind of licese patened technology has and if its available to everyone's use or not) and that in case standardization of certain patented technology is being considered IETF should look at if alternative to it that is non-patented is available. What Dean wrote makes lots of sense to me, so I primarily agree with him, except for his typical dnsext chair bashing - I'm not sure there is really a case there that chair is blocking discussion. I do agree that some list members there don't like the discussion of patents, but it appeared to be individual particupants (also it was hard to gauge if those individual participants did not like discussions of mentioned patent issues with dns extensions in general or if they did not like having discussions with Dean [on any topic] in particular). -- William Leibzon Elan Networks william@elan.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From BrendaKrueger@tukticaret.net Thu Sep 08 17:17:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDTmF-00018Y-C8 for dnsext-archive@megatron.ietf.org; Thu, 08 Sep 2005 17:17:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17984 for ; Thu, 8 Sep 2005 17:17:37 -0400 (EDT) Received: from [217.23.179.153] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EDTm7-0008Et-Mh for dnsext-archive@ietf.org; Thu, 08 Sep 2005 17:21:15 -0400 Received: from dPHk@localhost by aZlC.int (8.11.6/8.11.6); Fri, 09 Sep 2005 03:08:02 +0200 Message-ID: From: "Nicole Yazzie" Reply-To: "Nicole Yazzie" To: dnsext-archive@ietf.org Subject: XP Products available for Download Date: Fri, 09 Sep 2005 06:07:02 +0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: BrendaKrueger@tukticaret.net Content-Type: multipart/mixed; boundary="--THq8D85jP6XpSBdCFA" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb PwXD ----THq8D85jP6XpSBdCFA Content-Type: text/html; Content-Transfer-Encoding: quoted-printable t
Opt-in Email Special Offer &n= bsp;   unsubscribe me
=
SEARCH
<= /td>

TOP 10 NEW TITLES

=
<= td width=3D4> <= /tr><= td width=3D4> 10<= tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Office Pro Edition 2003
2 Windows XP Pro
 3 Adobe Creative Suite Pre= mium
 4 = Systemworks Pro 2004 Edition
 <= /td>5 Flash MX 2004
 6 Corel Painter 8
7 Adobe Acrobat 6.0
 8 Windows 2003 Serve= r
 9 Ali= as Maya 6.0 Wavefront
  Adobe Premiere
&nb= sp; See more by this manufacturer
   Microsoft
   Apple Software
&n= bsp; Customers also bought
   these other items...
=



Microsoft Off= ice Professional Edition *2003*
Microsoft
Choose:
 
You Save:


Availability: Available for = INSTANT download!
Coupon Code: ISe229
Media: CD-ROM = / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Analyze and manage business information using Access data= bases
  • Exchange data with oth= er systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM technolog= y
  • Easy-to-use wizards to cre= ate e-mail newsletters and printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: International/US or via instant download
Date= Coupon Expires: May 30th, 2005
Avera= ge Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
=
List Price:$899.00
Price:$69.99
$830.01 (92%)
Microsoft Windows XP Professional or Longhorn Edition
Microsoft
Choose:
 

List Pri= ce:$279.00
Price:<= /b>$49.99
You Save:$229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download
Syst= em requirements  |  Accessories  |  Other Versions

Features:

  • Desi= gned for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
    • More security with the ability to encrypt f= iles and folders
  • Built-in vo= ice, video, and instant messaging support
  • <= font size=3D1>Integration with Windows servers and management solutions

Sales Rank: #2
Shipping: International/US or via instant download
Date Co= upon Expires: May 30th, 2005
Average = Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Creat= ive Suite Premium
Adobe
Choose:
 

List Price: $1149.00
Price:$99.99
You Save:= $849.01 (90%)


Availability: Available for INSTANT download!
Coupon Code:= ISe229
Media: CD-ROM / Download

System requiremen= ts  |  Access= ories  |  Oth= er Versions

Features:

  • An integrated de= sign environment featuring the industry's foremost design tools
  • In-depth tips, expert tricks, and = comprehensive design resources
  • Intuitive file finding, smooth workflow, and common interface and toolse= t
  • Single installer--control = what you install and when you install it
  • Cross-media publishing--create content for both print and the= Web

Sales Rank: #3 Shipping: International/US or via instant download<= br> Date Coupon Expires: May 30th, 2005
Average Customer Review: 3D"5 Based on 498 reviews. Write a review.

----THq8D85jP6XpSBdCFA-- From owner-namedroppers@ops.ietf.org Thu Sep 08 18:48:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDVCP-0008RK-V6 for dnsext-archive@megatron.ietf.org; Thu, 08 Sep 2005 18:48:54 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23513 for ; Thu, 8 Sep 2005 18:48:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDV8n-000JYe-5p for namedroppers-data@psg.com; Thu, 08 Sep 2005 22:45:09 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EDV8l-000JXb-9z for namedroppers@ops.ietf.org; Thu, 08 Sep 2005 22:45:07 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j88MidCW003785 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 8 Sep 2005 18:44:40 -0400 Date: Thu, 8 Sep 2005 18:44:38 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: dcrocker@bbiw.net cc: namedroppers@ops.ietf.org, Subject: Re: DNSEXT Minutes @ IETF-63 [Software Patent issues denied discussion] In-Reply-To: <4320A36C.9020904@dcrocker.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mr Crocker. I know you'd rather not give credit to anyone you disagree with, which I suppose leaves only a preference to plagarize the work of others and give undue credit to someone else, say, Vixie [ala the SPF/RMX plagarism in which Vixie was improperly credited for the idea and the real contributors and the originator of the idea were improperly removed***]. However: Since we [the anti-software-patent community -- and the LPF President is an acknowledged leader of that community] mostly collectively dropped the demand for no patents in lieu of a much more pragmatic and cooperative view, a view that I originated and promoted, I think I can say they were persuaded. Of course, that must be very jarring to your world in which I represent no one else's view, and have no valid point of view on any subject with which you disagree. And indeed, I would be unsurprised if your world does not admit that I have a valid point of view even on any subject on which we _do_ happen to agree. I hope I don't rattle your world too much. Or perhaps in your world, the IETF has already adopted a strict no-patent policy. I couldn't tell. How'd that no-patent policy work out in your world? Did it alienate any pro-patent companies? --Dean *** The SPF/RMX issue is just one example of professional dishonesty. Professional dishonesty is very much like academic dishonesty. The IETF is supposed to be a professional organization, an activity of The Internet Society, which is a professional organization. Improper attribution of statements or plagarism, theft of ideas, etc in a referee'd paper would not be acceptable in any professional or scientific journal. Plagarism, theft of ideas, fabrication of statements, etc is unacceptable, under the category of professional dishonesty. Particularly in official interactions by the leadership of the IETF. Academic dishonesty is grounds for expulsion from higher educational institutions. Yet, professional dishonesty at the IETF is grounds for...exactly nothing. It is hard to consider the IETF a professional organization since it adheres to no professional standards. We shouldn't forget this, but it isn't my focus at the moment. Someday, this issue should be addressed. On Thu, 8 Sep 2005, Dave Crocker wrote: > > > > [Note: Not very long ago, I argued persuasively to a large and broad > > movement within the IETF seeking to have the IETF adopt an anti-patent > > position. > > > my memory is slipping worse that I thought. > > i don't recall seeing evidence of the community's being persuaded. > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 08 18:57:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDVKn-0002F5-Gn for dnsext-archive@megatron.ietf.org; Thu, 08 Sep 2005 18:57:35 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24826 for ; Thu, 8 Sep 2005 18:57:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDVJ5-000KXU-GW for namedroppers-data@psg.com; Thu, 08 Sep 2005 22:55:47 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EDVJ3-000KX5-OO for namedroppers@ops.ietf.org; Thu, 08 Sep 2005 22:55:45 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j88MtMPU004037 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 8 Sep 2005 18:55:22 -0400 Date: Thu, 8 Sep 2005 18:55:21 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: "Steven M. Bellovin" cc: "william(at)elan.net" , , , Subject: Re: DNSEXT Minutes @ IETF-63 [Software Patent issues denied discussion] In-Reply-To: <20050908212235.B615D3BFE4B@berkshire.machshav.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 8 Sep 2005, Steven M. Bellovin wrote: > In message , "william(at)elan > .net" writes: > > > >On Thu, 8 Sep 2005, Dave Crocker wrote: > > > >>> [Note: Not very long ago, I argued persuasively to a large and broad > >>> movement within the IETF seeking to have the IETF adopt an anti-patent > >>> position. > >> > >> my memory is slipping worse that I thought. > >> i don't recall seeing evidence of the community's being persuaded. > > It wasn't -- he's wrong. I see: I'm wrong, but you didn't see the original note. How thorough of you. Sounds more like: "Crocker is right, no matter what". > Wearing my IPR WG hat and citing a product of that WG... Maybe if you are going to make official statements, you could do a more thorough job of consulting both the statements being made, and your RFCs. I just cited RFC3979, a more recent product of your working group. But nothing I said was in contradiction to RFC3669, either. Not that you bothered to read it before commenting. [Didn't I just say something about fabrication of statements and professional dishonesty...] --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 08 19:14:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDVbZ-0003bc-AU for dnsext-archive@megatron.ietf.org; Thu, 08 Sep 2005 19:14:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01029 for ; Thu, 8 Sep 2005 19:14:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDVZF-000MNO-NY for namedroppers-data@psg.com; Thu, 08 Sep 2005 23:12:29 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EDVZC-000MMu-V0 for namedroppers@ops.ietf.org; Thu, 08 Sep 2005 23:12:27 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j88NCBJE004295 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 8 Sep 2005 19:12:12 -0400 Date: Thu, 8 Sep 2005 19:12:10 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: "william(at)elan.net" cc: dcrocker@bbiw.net, , Subject: Re: DNSEXT Minutes @ IETF-63 [Software Patent issues denied discussion] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 8 Sep 2005, william(at)elan.net wrote: > Neverheless if I understand it, it has always been a position of IETF > to consider patented technology as being less preferable then patented > for standardization (ok, it also has a lot to do with kind of licese > patened technology has and if its available to everyone's use or not) > and that in case standardization of certain patented technology is > being considered IETF should look at if alternative to it that is > non-patented is available. The IETF position has gone from what might be described as studious neutrality (ie you may consider things such as licensing terms) to a definite preference for non-encumbrance. (Section 8 of RFC 3979): 8. Evaluating Alternative Technologies in IETF Working Groups In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing. I think many people at the IETF have no-IPR preferences, but it wasn't written explicitly as a policy anywhere that I know of prior to RFC3979 > What Dean wrote makes lots of sense to me, so I primarily agree with > him, except for his typical dnsext chair bashing - I'm not sure there > is really a case there that chair is blocking discussion. I do agree Olaf Kolkman (WG co-chair) said: >Message-Id: <2B185012-0627-4A44-990B-F013CF14CA1C@NLnetLabs.nl> [...] > "Rat Hole Alert" [*] > > Please stop this discussion. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Doesn't get plainer. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 09 01:50:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDbmH-0007FZ-SQ for dnsext-archive@megatron.ietf.org; Fri, 09 Sep 2005 01:50:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27602 for ; Fri, 9 Sep 2005 01:50:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDbiE-00023L-9j for namedroppers-data@psg.com; Fri, 09 Sep 2005 05:46:10 +0000 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EDbiC-00021y-8E for namedroppers@ops.ietf.org; Fri, 09 Sep 2005 05:46:08 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 31A9D320099; Fri, 9 Sep 2005 07:45:18 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09456-07; Fri, 9 Sep 2005 07:45:11 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0898D320092; Fri, 9 Sep 2005 07:45:09 +0200 (CEST) Date: Fri, 09 Sep 2005 07:22:53 +0200 From: Harald Tveit Alvestrand To: "Hallam-Baker, Phillip" , "Steven M. Bellovin" , "william(at)elan.net" Cc: namedroppers@ops.ietf.org, dcrocker@bbiw.net, ietf@ietf.org Subject: Model patent license (RE: DNSEXT Minutes @ IETF-63 [Software Patent issues denieddiscussion] ) Message-ID: In-Reply-To: <198A730C2044DE4A96749D13E167AD375A2B0B@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD375A2B0B@MOU1WNEXMB04.vcorp.ad.vr sn.com> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========EDAEB1E4D6BECA39BD0E==========" X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --==========EDAEB1E4D6BECA39BD0E========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 8. september 2005 20:08 -0700 "Hallam-Baker, Phillip"=20 wrote: >> I didn't see the original note -- if it was from whom I think it was, >> my killfile took care of that -- but for a more authoritative >> description of the situation, see the first two paragraphs of >> Section 2 of RFC 3669. > > Without wanting to engage the dispute ove minutes I think that it would > be useful if the IETF had a definition of an 'open patent license' even > if WGs were not required to insist on it. I agree - and I think the IPR WG's mailing list is the right place to have=20 the public discussion of that issue. Unfortunately efforts to write a candidate license have fizzled out=20 numerous times in the past - partly because it's genuinely hard to do,=20 partly because the lawyers who might write it see some legal risk in trying = to write one (they fear being accused of trying to bias such a license to=20 their particular ends), partly because the acrimony surrounding this issue=20 has been rather uncomfortable, to say the least, in past discussions. May be time to try again - I think it's definitely needed. Harald --==========EDAEB1E4D6BECA39BD0E========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQFDIRwuOMj+2+WY0F4RAiSzAJ9I2zR0Q/4b7MBZ49KlI/n5kwhGPQCfR9kB HwhjA8hL3WWruMr28inmFdE= =wrj/ -----END PGP SIGNATURE----- --==========EDAEB1E4D6BECA39BD0E==========-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 09 05:03:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDemk-00006Q-Q3 for dnsext-archive@megatron.ietf.org; Fri, 09 Sep 2005 05:03:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19195 for ; Fri, 9 Sep 2005 05:03:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDejU-000IES-OH for namedroppers-data@psg.com; Fri, 09 Sep 2005 08:59:40 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EDejS-000IE3-Tz for namedroppers@ops.ietf.org; Fri, 09 Sep 2005 08:59:39 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 7672B2DE6F; Fri, 9 Sep 2005 10:59:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 753BB2DE5F for ; Fri, 9 Sep 2005 10:59:36 +0200 (CEST) Date: Fri, 9 Sep 2005 10:59:36 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Subject: microsoft contact Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, I'm looking for a contact at microsoft about their dns server implementation. Please contact me off-list. Thanks, Roy Arends -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 09 15:04:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDoAO-0000Nk-Td for dnsext-archive@megatron.ietf.org; Fri, 09 Sep 2005 15:04:04 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23356 for ; Fri, 9 Sep 2005 15:04:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDo4r-000N4R-8f for namedroppers-data@psg.com; Fri, 09 Sep 2005 18:58:21 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EDo4p-000N45-Hv for namedroppers@ops.ietf.org; Fri, 09 Sep 2005 18:58:19 +0000 Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j89Ivxr4024706 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 9 Sep 2005 14:58:03 -0400 Date: Fri, 9 Sep 2005 14:57:59 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: dcrocker@bbiw.net cc: namedroppers@ops.ietf.org, Subject: Re: DNSEXT Minutes @ IETF-63 [Software Patent issues denied discussion] In-Reply-To: <4320C2AD.4060606@dcrocker.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 8 Sep 2005, Dave Crocker wrote: > Folks, > > I've lost track of the procedures for formally taking exception to ad hominem > attacks, but I think we (the IETF) are overdue in needing to get quite strict > about enforcing that requirement, and doing the enforcement in a timely fashion.l I agree entirely. > We simply must purge patterns of personal abuse out of our public discussions > and start requiring professional demeanor. Yes, as the target of repeated personal abuse, I completely agree. However, you are one of the abusers. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 09 15:53:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDovl-0003Wm-GG for dnsext-archive@megatron.ietf.org; Fri, 09 Sep 2005 15:53:01 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26874 for ; Fri, 9 Sep 2005 15:52:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDot0-0003qF-8z for namedroppers-data@psg.com; Fri, 09 Sep 2005 19:50:10 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EDosz-0003pc-Ah for namedroppers@ops.ietf.org; Fri, 09 Sep 2005 19:50:09 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EDosy-0008Dc-91; Fri, 09 Sep 2005 15:50:08 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2538bis-05.txt Message-Id: Date: Fri, 09 Sep 2005 15:50:08 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Storing Certificates in the Domain Name System (DNS) Author(s) : S. Josefsson Filename : draft-ietf-dnsext-rfc2538bis-05.txt Pages : 16 Date : 2005-9-9 Cryptographic public keys are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). This document obsoletes RFC 2538. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2538bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-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: <2005-9-9143353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2538bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-9143353.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 09 16:13:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDpFp-0004xt-F6 for dnsext-archive@megatron.ietf.org; Fri, 09 Sep 2005 16:13:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03007 for ; Fri, 9 Sep 2005 16:13:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDpC0-0007B0-Si for namedroppers-data@psg.com; Fri, 09 Sep 2005 20:09:48 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EDpBy-0007AM-C2 for namedroppers@ops.ietf.org; Fri, 09 Sep 2005 20:09:46 +0000 Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j89K9WP9025908 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 9 Sep 2005 16:09:32 -0400 Date: Fri, 9 Sep 2005 16:09:32 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: namedroppers@ops.ietf.org, Subject: Re: DNSEXT Minutes @ IETF-63 [Software Patent issues denied discussion] (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Before we are too distracted by personal attacks on me**, could we please consider the issues contained in the forwarded message. I think the first thing should be to direct the DNSEXT WG Chairs to stimulate discussion of IPR issues rather than ask it to stop, and for them to get IPR disclosure statement(s) on draft-ietf-dnsext-ecc-key-07. [**Please ignore the personal attacks on me for the moment. I will get around to posting formal complaints on a violation of the IETF and ISOC Codes of Conduct, as I have in other cases. No doubt, for the short term at least, these complaints will get the same action as Alvestrand's and Vixie's namecalling of me, the abuse of Dr. Bernstein, the abuse of Nick Strand, and the abuse of others too numerous to list. Though the abusers in these cases are much easier to enumerate. Someday we will have to address the issues of professional honesty and professional ethics and such. In the meantime, we document it. As with defamation, this abuse eventually results in more harm to the abuser than to the abused. Time is on our side.] -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ---------- Forwarded message ---------- Date: Thu, 8 Sep 2005 16:21:52 -0400 (EDT) From: Dean Anderson To: Olaf M. Kolkman Cc: namedroppers@ops.ietf.org, ietf@ietf.org Subject: Re: DNSEXT Minutes @ IETF-63 [Software Patent issues denied discussion] [CC'd to the main IETF list] [Note: Not very long ago, I argued persuasively to a large and broad movement within the IETF seeking to have the IETF adopt an anti-patent position. I took my position pragmatically on the basis that the IETF should consider patented technology intelligently on a case-by-case basis in order to ensure participation by pro-patent groups and organizations whose cooperation is necessary and beneficial to the IETF. This is a pragmatic and reasonable view; The IETF interests in patented technology are different from my ideological interests in abolishing software patents, even if those interests have broad support. Interoperable standards are more important than ideology. Placing interoperation ahead of ideological interests, I saw the value in having participation and cooperation on standards regardless of ideological differences. However, having persuaded people to take a pragmatic and cooperative view, pro-patent persons shouldn't try to exploit that cooperation by attempting to prevent or suppress consideration of IPR issues by working groups.] The statement of the WG chair (included below) is not consistent with the IETF rules on IPR disclosure and consideration. For your reference: RFC 3979: 6.1.1. A Contributor's IPR in his or her Contribution Any Contributor who reasonably and personally knows of IPR meeting the conditions of Section 6.6 which the Contributor believes Covers or may ultimately Cover his or her Contribution, or which the Contributor reasonably and personally knows his or her employer or sponsor may assert against Implementing Technologies based on such Contribution, must make a disclosure in accordance with this Section 6. This requirement specifically includes Contributions that are made by any means including electronic or spoken comments, unless the latter are rejected from consideration before a disclosure could reasonably be submitted. An IPR discloser is requested to withdraw a previous disclosure if a revised Contribution negates the previous IPR disclosure, or to amend a previous disclosure if a revised Contribution substantially alters the previous disclosure. Contributors must disclose IPR meeting the description in this section; there are no exceptions to this rule. The fact that a discussion may be legal in nature is of no relevance. We live in a professional world bounded by legal constraints. The working group must ensure that IETF requirements on IPR disclosure are met, and that IPR encumbrances are properly and fully considered by the working group participants in the selection of technology. Patent encumbrance is a valid basis for comparison of any proposal. And IPR encumbrance is in fact not limited mere comparison, but even whether to adopt a given technology at all; Rejection because of IPR encumbrance is a valid option to be decided on a case-by-case basis. I do not see that the WG Chair is allowed by IETF policy to exclude or suppress information or discussion about IPR encumbrance, which seems to be the purpose of suppressing this discussion. This is contrary to IETF policy, which is to have each WG intelligently consider IPR issues. Also, the WG chair makes mention of two documents. In fact, there are 3 documents noted in the minutes which seem to have IPR encumbrances: Two are reported in the minutes under the heading of "IPR Issues update". These two have IPR statements, but the IPR encumbrances have not been discussed or considered on list. draft-ietf-dnsext-trustupdate-timers-00 and draft-ietf-dnsext-trustupdate-threshold-00 However, the IPR section of the minutes has an ominous quote about these two: "There is a license available that is royalty free, but does have some terms. So implementors either don't know what to do or are ignoring it." Clearly, more discussion should be stimulated. It should also be worthwhile for the WG to search for and consider alternatives that aren't patent encumbered. This issue should be discussed, not ignored or suppressed as a "rat-hole". This "rat-hole" nonsense is just a cover for a submarine, pro-patent attempt to avoid discussion of the IPR issues in these documents, and perhaps avoiding the possibility of a patent-free alternative. But I am also concerned about a third document that is also mentioned in the minutes. draft-ietf-dnsext-ecc-key-07 This document does not have an IPR disclosure on the IETF IPR page. The minutes state: First something about draft-ietf-dnsext-ecc-key-07: There have been some questions in the past about patents, but as far as is known, these only cover specific implementations, not on the basic theory or scheme of it, perhaps on specific equations. As the President of the League for Programming Freedom, and a leader on the topics of Patent, Copyright, and Trademark law, I do not find this explanation of non-infringement to be credible. An IPR disclosure should be made on this document. According to RFC 3979, Section 6.1.1 "there are no exceptions to this rule". Further, the IETF is not to take any position on the validity of an IPR claim. The IETF can't ignore the claim as being invalid--that would be taking a position on its validity. The claim has to be documented and disclosed, even if it may not be valid. And also, the working group chairs should be directed to _encourage_ discussion and consideration of the IPR issues, not try to suppress the discussion. Note RFC 3979 Section 6.2: 6.2. The Timing of Providing Disclosure Timely IPR disclosure is important because working groups need to have as much information as they can while they are evaluating alternative solutions. If the WG chairs are working to suppress IPR information and discussion, it is not available for evaluation, in violation of the purpose of section 6.2. Dean Anderson President of the League for Programming Freedom. On Wed, 7 Sep 2005, Olaf M. Kolkman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > "Rat Hole Alert" [*] > > Please stop this discussion. > > For this working group the only relevance at this point is rough > consensus on the technical specification and running code. We have > neither at this point in time. > > Lets get back to the technical task at hand. Compare the two proposals. > > - --Olaf > > > [*] http://ops.ietf.org/lists/namedroppers/namedroppers.2005/ > msg00381.html > > > We want to issue is a "rat hole" alert: > > Working groups tend to discuss the validity of patent claims, the > > licensing terms and such at great lengths. In the end patent issues > > are not technical but legal issues. It is up to the implementors of > > technology under IPR to deal with these issues, not the working group. > > If the IPR prohibits implementation than the WG would like to know, > > from implementors. As rough consensus without running code does not > > make sense. > > > > Or to paraphrase the above: we all have an opinion on IPR, this > > is not the list to rehash those. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (Darwin) > Comment: This message is locally signed. > > iD8DBQFDH0yntN/ca3YJIocRAsn8AKCk1l4ZqCW/OenPsgcFWGUBWC42HQCgujeK > jWRDXuu83+1FIWVP96Mzi4g= > =9z4g > -----END PGP SIGNATURE----- > > -- > 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: > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 12 11:23:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEq9I-0003rv-ID for dnsext-archive@megatron.ietf.org; Mon, 12 Sep 2005 11:23:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26521 for ; Mon, 12 Sep 2005 11:23:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EEq3C-000Ejm-8Z for namedroppers-data@psg.com; Mon, 12 Sep 2005 15:16:54 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EEq3B-000EjO-Ij for namedroppers@ops.ietf.org; Mon, 12 Sep 2005 15:16:53 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EEq39-0004Ka-ON; Mon, 12 Sep 2005 11:16:51 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , dnsext mailing list , dnsext chair , dnsext chair Subject: Protocol Action: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Message-Id: Date: Mon, 12 Sep 2005 11:16:51 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has approved the following document: - 'Domain Name System (DNS) Case Insensitivity Clarification ' as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-06.txt Technical Summary Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034 and 1035. Working Group Summary This document was produced by the dnsext WG. Protocol Quality This document was reviewed for the IESG by Thomas Narten and Margaret Wasserman RFC Editor Note Dear RFC Editor, In the Security Considerations section, please expand the acroynm "RP" as follows and add a reference to RFC 1183 to the Informative References section. In the Security Consideration section: OLD: address local parts, an attempt to store two "RP" records that NEW: address local parts, an attempt to store two Responsible Person (RP) [RFC 1183] records that And, in the informative reference section: OLD: [ISO 8859-2] - International Standards Organization, Standard for Character Encodings, Latin-2. NEW: [ISO 8859-2] - International Standards Organization, Standard for Character Encodings, Latin-2. [RFC 1183] - C. Everhart, et. al., "New DNS RR Definitions", October 1990. Thanks, Margaret -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 12 13:16:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EErv2-0000vK-Aq for dnsext-archive@megatron.ietf.org; Mon, 12 Sep 2005 13:16:45 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02862 for ; Mon, 12 Sep 2005 13:16:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EErrd-000Cmu-Vu for namedroppers-data@psg.com; Mon, 12 Sep 2005 17:13:05 +0000 Received: from [64.142.16.245] (helo=a.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EErrb-000CmX-7x for namedroppers@ops.ietf.org; Mon, 12 Sep 2005 17:13:03 +0000 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j8CHCvEV013234 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 12 Sep 2005 10:12:58 -0700 In-Reply-To: References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Date: Mon, 12 Sep 2005 10:12:56 -0700 To: Simon Josefsson X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Aug 30, 2005, at 8:07 AM, Simon Josefsson wrote: > There is little substantial work on the > topic, but plenty of hot air. If you (or someone else) can provide me > with some text that reflect what we can reasonable believe is sound > advice, it may be added, or at least discussed further. Perhaps this text could be added, but I still think there should be attempts to better estimate the performance characteristics of DNS from the standpoint of a before and after perspective. Keep in mind, that per-user keys offer the ability to encrypt and sign messages where the need for the key is not just for delivery, but also when the message is being read and written. As an engineering organization, these affects should be estimated before wide deployment is attempted. Now is the time this should be done. ----- With tens of millions of emails sent every minute, and where the number of email accounts per individual is growing, adding a sizable user-key component per mailbox into DNS may be deleterious to the performance of DNS. Due to the iterative query strategy, DNS largely depends upon caching in random access memory to meet performance expectations. Random access memory avoids latencies found in disk storage that have not changed substantially, principally due to heat dissipation limitations. The user-key may change the amount of information exchanged in DNS from a few hundred to billions of bytes per domain. This increased exchange could cause a dramatic reduction in the ability of DNS to adequately cache information. From a performance consideration perspective, the impact upon the DNS cache has been ignored. No attempts have been made to estimate this impact when wide spread deployment occurs. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 12 14:36:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEtA0-0006wn-4Y for dnsext-archive@megatron.ietf.org; Mon, 12 Sep 2005 14:36:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06506 for ; Mon, 12 Sep 2005 14:35:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EEt6C-0000hK-GM for namedroppers-data@psg.com; Mon, 12 Sep 2005 18:32:12 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EEt6A-0000h3-Pl for namedroppers@ops.ietf.org; Mon, 12 Sep 2005 18:32:10 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5565E11449 for ; Mon, 12 Sep 2005 18:32:10 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard In-Reply-To: Your message of "Mon, 12 Sep 2005 10:12:56 MST." <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> Date: Mon, 12 Sep 2005 18:32:10 +0000 Message-Id: <20050912183210.5565E11449@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # With tens of millions of emails sent every minute, and where the number of # email accounts per individual is growing, adding a sizable user-key # component per mailbox into DNS may be deleterious to the performance of DNS. i don't agree. publish and consume all the data you want-- DNS can handle it, as long as you don't design around TC and TCP-fallback in the average case. # Due to the iterative query strategy, DNS largely depends upon # caching in random access memory to meet performance expectations. no, it doesn't. caching is not very effective, mostly due to bad implementations and middleboxes. authority servers today have to be provisioned as well as they would if there were no caching at all. # The user-key may change the amount of information exchanged in DNS from a # few hundred to billions of bytes per domain. bring it on. # This increased exchange could cause a dramatic reduction in the ability of # DNS to adequately cache information. From a performance consideration # perspective, the impact upon the DNS cache has been ignored. No attempts # have been made to estimate this impact when wide spread deployment occurs. i have a better idea. publish the data and expect operators and implementors to be grownups and to cope. dns is not some weak-kneed sissy whose back can be thought "not strong enough to carry this load". bring it on. we're adding dnssec in part so that dns can carry new, authenticity-sensitive information. we're adding anycasted root name servers all over the world to improve system availability. we've added EDNS0 to increase payloads and avoid TCP more often. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 12 15:54:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuNb-0004ze-FM for dnsext-archive@megatron.ietf.org; Mon, 12 Sep 2005 15:54:15 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12012 for ; Mon, 12 Sep 2005 15:54:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EEuJs-0007uz-U4 for namedroppers-data@psg.com; Mon, 12 Sep 2005 19:50:24 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EEuJs-0007uS-7s for namedroppers@ops.ietf.org; Mon, 12 Sep 2005 19:50:24 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EEuJW-0004Ca-B2; Mon, 12 Sep 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsid-00.txt Message-Id: Date: Mon, 12 Sep 2005 15:50:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Name Server Identifier Option (NSID) Author(s) : R. Austein Filename : draft-ietf-dnsext-nsid-00.txt Pages : 10 Date : 2005-9-12 With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanism allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server which responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsid-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsid-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsid-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: <2005-9-12110759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsid-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-12110759.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 12 18:18:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEwdT-0007BK-E9 for dnsext-archive@megatron.ietf.org; Mon, 12 Sep 2005 18:18:51 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05786 for ; Mon, 12 Sep 2005 18:18:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EEwZm-000Kac-1s for namedroppers-data@psg.com; Mon, 12 Sep 2005 22:14:58 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EEwZk-000KaG-CA for namedroppers@ops.ietf.org; Mon, 12 Sep 2005 22:14:56 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 19DB0BC for ; Mon, 12 Sep 2005 18:14:55 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0EC7441B6 for ; Mon, 12 Sep 2005 18:14:54 -0400 (EDT) Date: Mon, 12 Sep 2005 18:14:53 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-nsid-00.txt References: MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050912221454.0EC7441B6@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In case they're useful, diffs against previous versions (draft-austein-dnsext-nsid-*) are available at: http://www.hactrn.net/ietf/dns/nsid/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 12 19:06:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EExNU-0001GP-Np for dnsext-archive@megatron.ietf.org; Mon, 12 Sep 2005 19:06:30 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07698 for ; Mon, 12 Sep 2005 19:06:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EExKj-000P4D-PI for namedroppers-data@psg.com; Mon, 12 Sep 2005 23:03:29 +0000 Received: from [64.142.16.245] (helo=a.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EExKj-000P1h-2p for namedroppers@ops.ietf.org; Mon, 12 Sep 2005 23:03:29 +0000 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j8CN31YU010448 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 12 Sep 2005 16:03:01 -0700 In-Reply-To: <20050912183210.5565E11449@sa.vix.com> References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <20050912183210.5565E11449@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Date: Mon, 12 Sep 2005 16:03:00 -0700 To: Paul Vixie X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sep 12, 2005, at 11:32 AM, Paul Vixie wrote: > # With tens of millions of emails sent every minute, and where the > number of > # email accounts per individual is growing, adding a sizable user-key > # component per mailbox into DNS may be deleterious to the > performance of DNS. > > i don't agree. publish and consume all the data you want-- DNS can > handle it, > as long as you don't design around TC and TCP-fallback in the > average case. Both DNSSEC and user-keys together may result in TCP-fallback or reliance upon the Extension Mechanisms for DNS (EDNS0). Will EDNS0 be a problem in some cases? EDNS0's larger packet sizes will have greater impact upon networks, even when TCP is not used. > # Due to the iterative query strategy, DNS largely depends upon > # caching in random access memory to meet performance expectations. > > no, it doesn't. caching is not very effective, mostly due to bad > implementations and middleboxes. authority servers today have to be > provisioned as well as they would if there were no caching at all. Caching of results is certainly needed to some extent. A DNS server able to issue data at ever higher rates does not relate directly to performance, when a higher rate results in greater packet loss. > # The user-key may change the amount of information exchanged in > DNS from a > # few hundred to billions of bytes per domain. > > bring it on. A six or seven order increase in payload should at least merit consideration. > # This increased exchange could cause a dramatic reduction in the > ability of > # DNS to adequately cache information. From a performance > consideration > # perspective, the impact upon the DNS cache has been ignored. No > attempts > # have been made to estimate this impact when wide spread > deployment occurs. > > i have a better idea. publish the data and expect operators and > implementors > to be grownups and to cope. dns is not some weak-kneed sissy whose > back can > be thought "not strong enough to carry this load". bring it on. DNS is a critical and burly function that merits review when making major changes in the amount of data exchanged. > we're adding > dnssec in part so that dns can carry new, authenticity-sensitive > information. While DNSSEC is definitely needed, this does _not_ make DNS more robust. DNSSEC will lower and not raise the amount of data exchanged before negative impacts upon overall performance of DNS and the network occur. > we've added EDNS0 to increase payloads and avoid TCP more often. While the stateless nature of DNS certainly affords ease in transmitting data, raising the amount and size of UDP traffic is not without consequence. This merits review. Let's not blame problems created on operators. : ) -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 13 04:50:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF6Ux-0004di-Ly for dnsext-archive@megatron.ietf.org; Tue, 13 Sep 2005 04:50:47 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10730 for ; Tue, 13 Sep 2005 04:50:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EF6Pl-000Keb-To for namedroppers-data@psg.com; Tue, 13 Sep 2005 08:45:17 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EF6PP-000KbA-Hk for namedroppers@ops.ietf.org; Tue, 13 Sep 2005 08:44:56 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j8D8jCeV027618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Sep 2005 10:45:19 +0200 From: Simon Josefsson To: Douglas Otis Cc: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050913:dotis@mail-abuse.org::gkS6zEwB8WDq/mGI:z4c X-Hashcash: 1:21:050913:namedroppers@ops.ietf.org::1OeSgd0vi51jzbPi:LJYl Date: Tue, 13 Sep 2005 10:44:13 +0200 In-Reply-To: <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> (Douglas Otis's message of "Mon, 12 Sep 2005 10:12:56 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Douglas Otis writes: > On Aug 30, 2005, at 8:07 AM, Simon Josefsson wrote: > >> There is little substantial work on the >> topic, but plenty of hot air. If you (or someone else) can provide me >> with some text that reflect what we can reasonable believe is sound >> advice, it may be added, or at least discussed further. > > > Perhaps this text could be added, but I still think there should be > attempts to better estimate the performance characteristics of DNS > from the standpoint of a before and after perspective. Keep in mind, > that per-user keys offer the ability to encrypt and sign messages > where the need for the key is not just for delivery, but also when > the message is being read and written. As an engineering > organization, these affects should be estimated before wide > deployment is attempted. Now is the time this should be done. I think we generally disagree. First, everyone is welcome to measure a before and after performance characteristic. If you do this thoroughly, and report your findings, it would be a valuable resource and we could reference it in this document. However, at this point, I see nothing more than speculations here. Keep in mind that RFC 2538 has already been published. It is already possible to deploy this mechanism, without RFC 2538bis. RFC 2538bis can only be based on what we know today, not what we may know in a few years, so if you like to see this wide-scale performance estimate done, please start working on it! > With tens of millions of emails sent every minute, and where the > number of email accounts per individual is growing, adding a sizable > user-key component per mailbox into DNS may be deleterious to the > performance of DNS. The keyword here is "may". Everything MAY happen. Without any evidence, I don't think it is wise to add these fearful sounding phrases to the document. > Due to the iterative query strategy, DNS largely depends upon > caching in random access memory to meet performance expectations. > Random access memory avoids latencies found in disk storage that > have not changed substantially, principally due to heat dissipation > limitations. I don't understand this. Are you saying that RAM accesses is the bottleneck for DNS? Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 13 11:14:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFCUb-00065X-8c for dnsext-archive@megatron.ietf.org; Tue, 13 Sep 2005 11:14:41 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26699 for ; Tue, 13 Sep 2005 11:14:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFCPT-000N4d-9u for namedroppers-data@psg.com; Tue, 13 Sep 2005 15:09:23 +0000 Received: from [207.65.203.98] (helo=goose.ntrg.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EFCPO-000N43-2h for namedroppers@ops.ietf.org; Tue, 13 Sep 2005 15:09:18 +0000 Received: from [10.29.41.110] (pool-70-21-86-248.res.east.verizon.net [70.21.86.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ntrg.com (Postfix ) with ESMTP id 8389112EC4; Tue, 13 Sep 2005 10:09:13 -0500 (CDT) Message-ID: <4326EB99.3090308@ehsco.com> Date: Tue, 13 Sep 2005 11:09:13 -0400 From: "Eric A. Hall" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis CC: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> In-Reply-To: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 8/11/2005 3:26 PM, Douglas Otis wrote: > Sorry for the late participation in reviewing this draft. While > dealing with issues related to MASS, it has become apparent there is > only passing consideration given the impact user-keys may have when > published using DNS. I agree with most of your concerns, but there is another factor that needs to be considered, which is the implicit difference between data models that are used at the personal and/or organizational level versus those that are used Internet-wide. The IETF has to be really careful with the latter, but it's not really a problem for the IETF (as a procedural issue) if somebody wants to shoot themselves in the foot. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 13 13:09:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFEHb-0008P5-OG for dnsext-archive@megatron.ietf.org; Tue, 13 Sep 2005 13:09:28 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02158 for ; Tue, 13 Sep 2005 13:09:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFEDK-0005ch-Cq for namedroppers-data@psg.com; Tue, 13 Sep 2005 17:04:58 +0000 Received: from [64.142.19.5] (helo=b.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EFEDH-0005cL-Up for namedroppers@ops.ietf.org; Tue, 13 Sep 2005 17:04:56 +0000 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j8DH4nkE023663 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 13 Sep 2005 10:04:50 -0700 In-Reply-To: References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Date: Tue, 13 Sep 2005 10:04:50 -0700 To: Simon Josefsson X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sep 13, 2005, at 1:44 AM, Simon Josefsson wrote: > Douglas Otis writes: > > >> On Aug 30, 2005, at 8:07 AM, Simon Josefsson wrote: When doing a comparison of the two documents, I did notice an error unrelated to this topic. + The IPKIX, ISPKI and IPGP types indicate a URL which will serve the + content that would have been in the "certificate, CRL or URL" field + of the corresponding (PKIX, SPKI or PGP) packet types. These types + are known as "indirect". These packet types MUST be used when the + content is too large to fit in the CERT RR, and MAY be used at the + implementer's discretion. They SHOULD NOT be used where the entire + UDP packet would have fit in 512 bytes. In RFC1035 for UDP, a message size is limited to 512 bytes, not the packet size as indicated in this statement. The data-gram limitation is 576 bytes per RFC879. > I think we generally disagree. > > First, everyone is welcome to measure a before and after performance > characteristic. If you do this thoroughly, and report your findings, > it would be a valuable resource and we could reference it in this > document. However, at this point, I see nothing more than > speculations here. Keep in mind that RFC 2538 has already been > published. This draft is recommending multiple owner-names and discusses use of wildcard record synthesis. This was the point I found alarming when a method to synthesize records for every email message was described in MASS. This was the reason I suggested there should be some advice given in the performance considerations section. This version of the draft very much adds to this concern. > It is already possible to deploy this mechanism, without > RFC 2538bis. RFC 2538bis can only be based on what we know today, not > what we may know in a few years, so if you like to see this wide-scale > performance estimate done, please start working on it! I am not the one advocating use of this record, nor am I attempting to embellish use of this record. In the absence of modeling or testing at projections of possible deployment, then _some_ statement regarding a lack of this review should be made in the performance section. At least warn that this may cause foot damage. : ) >> With tens of millions of emails sent every minute, and where the >> number of email accounts per individual is growing, adding a sizable >> user-key component per mailbox into DNS may be deleterious to the >> performance of DNS. >> > > The keyword here is "may". Everything MAY happen. Without any > evidence, I don't think it is wise to add these fearful sounding > phrases to the document. The attempt was to provide some motivation. Of course DNS servers _can_ issue a reply for every query seen by the server. This says little about the overall performance of DNS or the networks. >> Due to the iterative query strategy, DNS largely depends upon >> caching in random access memory to meet performance expectations. >> Random access memory avoids latencies found in disk storage that >> have not changed substantially, principally due to heat dissipation >> limitations. > > I don't understand this. Are you saying that RAM accesses is the > bottleneck for DNS? I was attempting to describe how there can be non-linear (cascading) effects when the cache becomes less effective. The bottleneck is not RAM access, but rather RAM, as a resource, could be less effective when DNS payloads and records increase by many orders of magnitude. This problem gets worse when DNSSEC is deployed. I do not share Paul's optimism that DNS can become a database suitable for any and all applications without risk, and that operators will find a means to cope. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 13 13:49:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFEu6-0005Xl-Rg for dnsext-archive@megatron.ietf.org; Tue, 13 Sep 2005 13:49:11 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03829 for ; Tue, 13 Sep 2005 13:49:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFEr5-0008UX-OS for namedroppers-data@psg.com; Tue, 13 Sep 2005 17:46:03 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EFEr3-0008Tn-He for namedroppers@ops.ietf.org; Tue, 13 Sep 2005 17:46:01 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id j8DHjxVd020912 for ; Tue, 13 Sep 2005 19:45:59 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j8DHjxx09029 for ; Tue, 13 Sep 2005 19:45:59 +0200 (MEST) Message-Id: <200509131745.j8DHjxx09029@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Typo/bug in RFC 3597 X-PGP-Fingerprint: 85 89 64 AD 73 79 92 1F C8 76 95 2D 15 09 19 93 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9021.1126633551.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Tue, 13 Sep 2005 19:45:59 +0200 From: Peter Koch X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk After following up to a posting to the "rfc-interest" mailing list a habitually alert namedropper reminded me that RFC 3597 is up for advancement, so the issue at hand could be easily fixed: ---- 7. DNSSEC Canonical Form and Ordering [...] As a courtesy to implementors, it is hereby noted that the complete set of such previously published RR types that contain embedded domain names, and whose DNSSEC canonical form therefore involves downcasing according to the DNS rules for character comparisons, consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, and A6. ---- This list, which was also copied into section 6.2 of RFC 4034, contains HINFO twice {well, yes, in mathematics duplication of a _set_ member is meaningless} where it should not appear at all since it doesn't carry domain names in RDATA. More or less as a fair compensation, NSAP-PTR is missing from the above list. It is arguable, however, whether it (and MD/MF) should be considered in the first place given that 1035 obsoleted MD/MF and 1637 dropped NSAP-PTR. When advancing 3597 it might be a good idea to drop section 7 completely, which would also reduce the number of necessary down-references. The above list would then be corrected in the RFC 4034 errata document. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 13 14:04:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFF8P-00071K-3C for dnsext-archive@megatron.ietf.org; Tue, 13 Sep 2005 14:04:47 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04456 for ; Tue, 13 Sep 2005 14:03:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFF6S-000A4s-6W for namedroppers-data@psg.com; Tue, 13 Sep 2005 18:01:56 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EFF6Q-000A4R-FY for namedroppers@ops.ietf.org; Tue, 13 Sep 2005 18:01:54 +0000 Received: from [10.0.1.2] (c-24-6-153-109.hsd1.ca.comcast.net [24.6.153.109]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id C94FF56835; Tue, 13 Sep 2005 11:01:53 -0700 (PDT) (envelope-from david.conrad@nominum.com) In-Reply-To: <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Simon Josefsson , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Date: Tue, 13 Sep 2005 11:01:48 -0700 To: Douglas Otis X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, On Sep 12, 2005, at 10:12 AM, Douglas Otis wrote: > The user-key may change the amount of information exchanged in DNS > from a few hundred to billions of bytes per domain. The size of a particular domain in the context of caching servers isn't particularly relevant (at least in the caching servers I'm aware of). > This increased exchange could cause a dramatic reduction in the > ability of DNS to adequately cache information. From a performance > consideration perspective, the impact upon the DNS cache has been > ignored. If you try to keep the cache the same size as today, yes, there will be an impact (particularly in caching servers whose memory management techniques are to crash when they aren't able to allocate sufficient memory to cache new items. Perhaps this will finally kill off BINDv8?). If there is wide scale deployment of this, caches in front of mail servers (and other apps that make use of user keys) will probably require more RAM in order to achieve the same level of performance they have now. While I am not too concerned about this myself (perhaps due to who pays my salary :-)), I suppose it might be prudent to do a bit of analysis and make note of this in some sort of operational forum. Perhaps an "Operational Considerations of User Keys in the DNS" document in DNSOP? Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From johnson@algavista.com Tue Sep 13 14:42:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFFjL-0005Jn-B1 for dnsext-archive@megatron.ietf.org; Tue, 13 Sep 2005 14:42:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05864 for ; Tue, 13 Sep 2005 14:41:45 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFFnO-0001IL-5u for dnsext-archive@ietf.org; Tue, 13 Sep 2005 14:46:23 -0400 Received: from [201.19.78.229] (helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1EFFin-0003Yj-SP for dnsext-archive@ietf.org; Tue, 13 Sep 2005 14:41:34 -0400 Date: ter, 13 set 2005 15:41:06 +0100 From: "Gottlieb" To: Subject: /iagra at $1.64 per dose Message-ID: <001101c5b861$74bd7900$306d81d4@sanya> MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C5B882.F46C6190" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C5B882.F46C6190 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C5B882.F46ED290" ------=_NextPart_001_000E_01C5B882.F46ED290 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
3D""
3D""
------=_NextPart_001_000E_01C5B882.F46ED290-- ------=_NextPart_000_000D_01C5B882.F46C6190 Content-Type: image/gif; name="ban_ci_soft.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c5b861$6d5877a0$306d81d4@sanya> Content-Transfer-Encoding: base64 R0lGODlh4QB1ANUAAD2Isfvs0P///9ra2vjQh/3JbPjbqANnn9FNBru7u+3t7f6yJ9PT0+Dg4P+m A/Dw8OTk5P7y3+np6aXC0srKyvy5RauPaPq8WfvlvHuqxNhyOuG5mv/58ezZx+2+b/etRvLy8vHp 3+umRuTLs//898+oa6urq/j4+M7Z37ekhb+JRdagTsfT2v/+/fX19drg5OagP+qtUO+0Wu3q5vz7 +/v6+P726tiYQPj18v/9+rXM2OGfe96NYfbw5+fn5/Hx8SH5BAAAAAAALAAAAADhAHUAAAb/QIFQ 2PpBBoykcslsOp/QqHRKrVqv2KwWO4D8WsOw8DRoSBSgtHrNbrvf8Lh8Tq/b7/i8Hq+QNAYnYgIt CgNocA+JiQqMZxI+EJEQDZSVZQOYmX+ZnJ2XlGWVopSTkqankj6qqz4Srq+wZ4yztLWziri4e7u8 d4UKYpE/cbmzr5CSDZOgns3Nm5ig0qPUpajXrKuxsbbdtLngveLjbkYQQw8NcsV9fY+n0pfO851/ 9vfU1crX2Nnb3N66gdNFrmDBBg8GDXiAiJ27R8giWaJHsd6nUKHy5TO1j5+/f68C2hpI0KDJXQ8G tEjXEFejh6ok2pvHAFPNipxmTtMoqpSy/478IGRrBVJkLZKJTirdhRCChDfgjB1DNrFZzauZblLU ybPrvp9BIw0FKcuoAqQMl+4a0cHFsF4SjqRlE7XdMaGiaCLJijMaRq9efYYVy4psWZFI1e4JoUED gg7jUjJwU9eRq4hVPWHVipMr4ErLRlkDeirmx39mz5JUrEfDBhBsEYx4u+dHEroOLb+bpCMDgN8A MmTgxGAC8N99o/UWLryBjuMAepL6CVZi6YimWxFFnToxazs/RiBI80D8DnG31dS1eznShAPw48sf jum9/Hk6Q9mP32A/fNLJDGYKdtoY1t1qbBBgwHdw7IBAWj8gwAMPHdCWR3ogrBcLMhnI5/9hfACw UJyHznhGiX8H9OehgGFBwopQqhh2GGIIrlEBAQyW46AaHSDgmoUXTqahK+5w+OGRBwAwAIoW4TMK iirKxyIq2Y0VI1kHDuSGgjm6sYFs4Tn2YC9JaPjQbigc+duR9HlionRRxtfilDAOdWVRRJrlXZd0 lCehayfw8BiZDDh0JkSRdOghfQwA4CEAyzEXDSW9QSdcFxCgCAELzAnHCqe+/SZcXHUWBpF2rxBQ QQUdKEikAQQQEMIssIZwQQUFhKBICLEaMBcBAaiahgE9vMWrgkAu5SACuv7g4AiEqtaNIzEJ9WEG 0DDwIZOUoOAokgdkkKmHPqC4iqJHTqD/zXbHwKKABw4ouMACBJxBgAMFXODArAoQMK8BBixwwQM/ zLDAjfGm8YMD8+IIggMLgtDDwf4WwNoDEyKAwDDhIXAeL2V6M5UkLHyogzxLdiqch5V8C+4BKJiL oivoIqmDjLBAALEqBuArQQgOdMBIBQM/cG8HifSciKpJOxDAMA5UsAbEafj7ww8YOIBBsr2EwIMG O4RwtaAzpNEjDw/swDUdIdsyVUQopjhTM1A69+Ga86E4w8wKLPrcfDi/0rNl8c7QgQOz+PtAvxX8 0HQiNzL0A70gLBxxGlT/cGPlkztMzgOMddCjBrM+S56Pzu6ShNuwrCIJigCEllFGUEIQ/ypwDfjw gstJzjyzDotKgILKgbvib1k3SqAqrQ4svrzjSj9AdRo3Qn35wxFD/BYGYhu0gQaJfMkDbB6/5dgP Griwx+q1tH6qe48Cpmm1RL0wQc29eygB8PJJUPLdGbhZI7BkmeXN4kYzuNeqKrCA5j2gABVQRPQY tsCEYW9q2bve2uxQHrDNCmwZCoHGfiBCDahBUI1RHQNY1y7XxU0mlGDBBGY4Q/zVyTi8exT/4iMB FPUhh/IJzksc0Y4iMkJVZ1gcrvq1AIA5cWkRbBrmFAQw7jFkepjLoPd4IB5dSUhh50PfeNIQgh3s oGzrW6ExDvW2/8lHB9XJobmEB8S7+f9wh/BhxN/AlYGXGAWCtEAg0wiGi0E+oGdZVBjBEqmG6WFR HCeQjfoS4aM0zEBQIFCAoCBDDvat8R/a8UEOARARPMIHf64AYnB4BykPKcCUtLhfHQ+gg9Qw8SyM oBfjFIGBKA4SBIh8GAbSUgCHQcwtjGziWwhgMV40hpMg0Jj6QOAghnxpA9NEjxppQSTdvOIF+EvS C8b1qJm94FGOw4EOXQnLxfXBBwqwXw5rmZqe6Qp08TqkA422gERAUA3B3FzlKHfBRkbsAs0EAUJ5 kTaN8WBWm6zcDkxIvo+Nw5PtkwoszvkyD+nAlPtbFCPw10r5vNJDD6gZADIJAY8GZBH/jHiAwJYW r7PoUnMXqJrUhuWAqi0gBMDcFyMZea8egCAAEJuLHn7wJY114EsfQwA2QeCCSnZymyLxZtyQlIEe uvIBd1MlLGEJO9+saHHFiAoG5iWw6j0ga2wF6g+ExVOFFSBqFizoUO9aAXyJ42plrCQKdzA+NaTw qu5MDSy26qEJnAGWCginmkz5AMr+QLLymYBq0IKLEBigLZFz3CGhqbA3/CAAxNpgGzwLVINMdBgj 2MEGDpEGB9GWUOsJiARmoAAfYDYDKGiFAnzYWyAGsLEopexZMAsAzXIWF71sLdAMcLWrVa4OqmXQ Azg5AhNW10JhKkgSRGso3TICVMLR/8ELhGuUH4BTOBNwAQ7Iy9nvipaqkcrABOj53FwcDGAM5NzV lMqnPUiouxVyAw82YEZkajNDJLFlTCU8YQVwjCT2zbCGresCtzAkEd8lmGirm4sQQBCB1S0wOb5H Ia65oDE7yOaDSRxhmCaWwt/o74Z3zOMe9xjE1lWxQRy3tg4n5aoKs29/vQHTHNfXx1COsoaTnGEh W9kk6fkxUnB5iyZvFi1SDnOU22DfK5tZvJOhMo/7y+YBi1jMcPjuGnZs2iCf+c6EmvOcdyxiILd5 zFPmRYrxTGjFYCjOYlbEiIEMZTZkt9CQxvOh5yDmSts50pjONBsmTQdLh1nToAY1p/87XWkyyznU qNb0qEn96XKk+tWZToIgZk3rFtj61rjOta1pzete+/rXwA62sIdN7GIb+9hDkDWyl83sZjv72dCO 9rOVLe1qW/va2M72tamt7W57+9vg1ja3w03ucpv73LweN7rXze52b5sB7o63vOeNbHXT+974xre9 883vfqN73/4OuMDFDe+BG/zg2AY4wsnNAAoUfOHeVjjEv42Jc0y82xK/eLZbUHGNE9zj4X5Ewylw CQqYgdknGDkFVk4BMCDbByxnuQ+AnfKYr9zlws44yJ2tgJUnISOVqMkPjk2DhgO9AcuWgMNHMXRf F53koyi2zneedIcfnRoDcIGxBwD/9agf+wdLZ/qvuX51qT+c6tU+QdgBY/FhN6DrXi+2C9Yuiqbz +u1XRzqxp472YsN8FFoXwg+oEQhhwzzveid2zTVi91kfXiNmL7eub53vBjBAFMAIw9FBYHi6x13Y NTA643kN88tDfu9nzzYJIoABJ1LRiZ/tQAhsQAOcs9tJEKhBGM7y3cL/uuemh4ACqCH1rg9e7LMG PimG//lg8/3YLYgArGJFfQVRsfUYyH4HPhuCHtCA3UcYBSZ8EHhjg2DtJyhE88fedWCYvhKNH8L5 35/+o0ce2xwwQAGKWcxewT772RcAAiiAGCA6HdAD6OYC75cXDUd+iod+AiABC5h4/8CGd5QgAUJg cnUnCGpHfxE4gfd3bQbgAReAUP1HfU4EgAMogBEwgAXYAbpnbqGhEUIXbDUXCpwnAD4AgsFWepTg Ay6ngfAnBjdICTm4g+v3a89HbDZAACWYLybYK/6ngiwYAC1IgKITAufmA4BRBr/2dEMoBEgoCsGm dMH3fRmIfEIAhpRgd2NYCSEobS0QAB5AgghVgnhYh69HhVXoghgwAlpobj/AdQ1XiA53iDXhawyQ AD5HgVyHiBQAbC6QAAlQiOUnAIxoiBiYbIy4dJrnc4cYh9LWASQIhXcoAjdwAx4ghSqIAQN4hQEA gAYwAwnYAJR4i7hIiZcoCLlIif8m8Iu/2IsmkABoOGsSMIy4CIzBmIu/OACYKIzKKIzE6HypB205 QIp4iIcxoAI3gIcF4AEjYAB8uIKumH0GMAI40G6W14sJQIG8yI7wiIu9dozxGI/nUI/1mHPVCG2k aId4mIoykI0yUEwAGICxSIAFeY7fdgLK+IvuSAG5uI9DgI/w2HK8Ro8UmYv3mJG5aJHAtoTDdgIl UIfZuAIwkI3ZWADiWJAHmZDnmIPdhoy36IxhsIi4KJFCwJEdOY8yqZMbqZOUGInUiG0tkAAlgJIX EAMBmZQoWUwpWJDmCDAE0AC2h23sSJMRmAA96Y5iAJTyKAAU0JCRiJFA+ZNeqY//2JYDIZACR4mS MYCKIiADFSCXefiUsiiVIzACVblt7NiQuZh5vLaXQmCLuSgGYXmTv9aL7iiYAkCYXzlsIElsFDCS S1mCRBOXRGOZH3ABH6CS4Yh9sBcrG1CM2XYCQCmUxsYAPZkAhhmRv7aaXElrqlmYqLdxPcCWMpCb 2Ug0vMmZnPkBSukBsBeaG6CX3tYCPsCRFBCDW7eaYdACEImYvdYCsBlsA+CctaltDWABJRCQcikD m7mZFfABH1ABIgADMHCeMiCFsDJ9HpAAJABuDxCd8cgAJ8CYH9mLhtmTODkE1ZmftAmZ/flsOUAB 3Jmb4Xkr4omK5BkD5AkDKyCc/9NHfRuwAfh5bVxIn7fYAPGXmtg5BBpaib5GnbkYm7M2m4+Jlt1G AiZQAkqJoL5JnuN5AyIgAhUAAzSKUASwAdRXhx5pbhD5o8d5ofMWmcbmAmzZneApl+Upox9Qox9w AzDwoKvYoyVgot+mlajZd9M2oNH2ACmQAiuglOTZpGVaplP6ATi6AvxXhymAA0SabUFJmlzKbEZ6 bAqQAhawAmMKnmd6pumJo2n6jR5QAgkQp9q2a3XapeSmACbAlisgAg76p2cqAmVqqTLgASnQA/G5 qFR3p8jWAwmgp3waA2/5pFBKniKwAOiJnitQAoHoqZ/qpdVGAzOQABZgASqgAv8meZ6t+qtSegMq YAEjoACIKqsCB6rGVgM+EAIB0AEmkKu7KqUmmYrWKqzDKnswiKw7p6zERgPNGgDOGgAjEK0rsKvo mq65mgIEGAIzcKzcym/eKmy2GgLjuoLQqqe5uq8WkAIjsIICGAJ0Gq8IN6/ARgg9EAIR0IIMa4UC 2AF5mZcd4LAO24L26nsEu3AGO6I/0AML+7Egu7BW2II9ULEhu7A9kI4ZC3EbG5gn0AMeawMnO7M0 C7IpC68ZGzAO4AAX4HI9s7MEAG4tS2s00AM2cLRIK7NKW7Myu7BLa7RwurK/Fn34IgBZQwBUG7T3 ggHfNrSC0AI4gANJO7ZkW7b/ZnufUvtr9xIAYMBAAnBXNgAG8YKz9Uary1YDOMABequ3Ztu3ZosD zNl3eMUwETAId0W4LVAAC3BXQSsEdzUEbuu2g+C2bMUwAXC4FzAIAdBAbJWadgt9J7C3oju6e2sD pHu6ezuwO7ezVngwAtAzEcABAvO2UYOf8yIArisElKs1uIsvLdAzBoC7C/C6DEO3AuC1Q9ACNFAD JEACHOC8qBu90VsDxitwPGtr98IBCGW4C5C4DsABvHYvBtACudsCDES+BSAE99ICORABEINUwSu8 nkuUNNC89nu/+Pu8euu8/Ku/+Nu81RtwVUu8a7WzO9u9iquoYnAvWEu+FQC5/927uGBwL0LgvrDi NI7bvaIYbS1AAjnwvyAcwiJMAgEswI2bNVmTvoPAvopLawxMBOV7vourvg5QwfECu9w7v9fGvjnQ wz7cwx78wR/swSE8xEJMwiXsb/EiBD2zuQVgewksCOKbA5D7wEJwMOhLxRQsABbcxGAQxdlpbbaW Azz8w2Z8xmhsxkmsxJnbAtnruom7ADnQwmJwtTjnxjUsABzguzMsAFvsvsACMVc8vBvMwZPHvohM xoqcyD/Mw5Qnq6wbAQLzu04ju0+suFQcBo8rBoBMu1y7uFqcxxacA7fbMxocxmJ8yKq8yo8MyX2F uC2gL1FjA3NMyJpswAZsa88/K8ikrMJ/DDFzyLm3W8iGzMrG3MrIusQjqsAj+pwrLJi4JgS3kskC 2m25lrzHDAZrfHDKvG48KwDwq8PgxszYnLaz1s3oVsBVa7zIa2zkbM7y9s6oDM/0jHGfW8/4XLfb nM/8/LU1gbH9HNDLRgYQkBACfdDI9gAF3XYI3dDCVtAcB9AOPdGzRgZgMHgUndG0hhBD0Ar7rNHc 2gKP8JwSkHUgTdEuMAASsJdkwKG7eNL17BZ/INHJawRIsAU4ndM6vdM83dM+nQVl8AViEAQAOw== ------=_NextPart_000_000D_01C5B882.F46C6190 Content-Type: image/gif; name="ban_le.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c5b861$6d5877a0$306d81d4@sanya> Content-Transfer-Encoding: base64 R0lGODlh4QB1ANUAAAJnn7u7u+3t7fy6RPzHa/bdr9PT0+Dg4PDw8P3jr/+mA6rF1PmjKv705+np 6eTk5PWcJ8rKyvzZmdzd3ZO4zdnZ2f3s0lWVufrlwf3ViP21NPO0YHurxf/68/nNf/Ly8vqrNzeF sP/8+PvBWqurq8za4fzfnPj4+P7x3vmXH/Ps4f/+/OW4iL7Q2/X19d3k6PfSk+rJpf747vPn0+/E f//////9++iiTPv7+9DX2/779vPavP///v+xIv7+/v/+/SH5BAAAAAAALAAAAADhAHUAAAb/wJpQ 6EM8JoakcslsOp/QqHRKrVqv2KwWO3kgfMOw8DQ5OASftHrNbrvf8Lh8Tq/b7/i8Hi9wHCYnYjU+ AhVobwiJiQJ9fQ4OD5EPB5SUE5eYFZiZm52Xf5aVopSTkqanko8Pqo+trq2MsbKzsoq2tnu5unyG YpEIcLexrqYHk3+eFcoTys3MnpugZdKjlaWo2JDa26+wtN+xt+K75OWIkUMIB3HCja2nlp3N8/Sa 9p7S09XV19iorKu6vQIHThwucwgTHkAwqAIwN+KGvSuGjFm9ixef4SszTd8+a5KM+VtFUuBAgrMM HkzIUheCCkXWQWx3hlikeJnoGcA4zyI0/46ggn40RrTfSIAmH6FMqfJhy6d7Fq6aaUvixGMV6+3c Om9nPY3RPA7dd9NotpJJzyxl1NQp1Ld2IDlsE9HdxEqbLnr1ytNZp6Bix4oqJXJkJFZp1wpoCrex nZcG6NJ01GKBZcs5cupUxrcvWEyUFoQYPXoo1sEiC5/dFlCgYsaOY7NLsqauXQchAOjWvUBzs859 NX0GemDBbt2nSSk/1k81yVSHW5tUvFilLhgFZO+incZ2TVW5j1O4ZG8zz+GgRxk/bmz97mKGj6JN +tq6rgEetOvi7p0Y7uMA9FZecM4IF9Y+E7iHXHEAxvcPdPPRV59Bu2CnXy5J9PedJOHtNv8egcug R9xHzJmiIAAOQgjJfNK5thZsF8aYRoZVMfKdKhwC2JtF9eQQAQcXjHYBBzsiYRkFlimXw2WWceCk k5VxoOMCObTwJJEPUBAkBZBMQAEHpIUwZAvTKUWLBxqMsAN2ihTggQcqJPJBATDMMMIABKighgpv ZqeGBzN4MEAaBeiZhgoweCCBjHLQuIhVVz3QoW4f8rhMBRcAuNsFORyQA4AUSCLlbpMCMKqmpiro 5G4cZIkqqS900wgtBChApwY9eJAIDAp4MIIChnrQgwYS7JAmMCqk6UGvaiiggQb5fWDroRrg1wMB bjG6Bo3fbGhKqUU+I1ypmrbwQKas5uj/IYCnakrkcejqxgEFr8Lryqy0OKCABIwU0CsCKvRQQCID jJDGsjOkIYECBw86pwIJS+twGtN+IOwHCGCgAAbaupEEODZ9C+pP7QIwGoAhuHpcl8eFcGLJx737 KpAok+vIUv6G86+/isDQQ8Nq+JsGfmr0AAPFizbrJ9FpQNtxGx/nG7K6u4WLzKfH9XbEpFwCSCa9 m574SMmtnBhzmCFwKQDYVb+IZnUI4IeAoHIKbfHEdlf8AdN6S+vnvt1hEPHTakQNKUAhgVsBNROU fGW8AFzgQLscTH5cZQCOnfkjZpuc9iwOtEABuCgpQrcici87wOoaMHx30K47u/oAzPq9/0bFCuxA OByG2/jKc1Tztg/Mr6bcQssvdBiCA2ILQPYZJ4ZQwnclgElu2wWZPoAtqWtQwPffA01o7B6AX0DE fePu5+5QGwB6N9FFAu40hBH/6iqTHs/qCyf2UXIsL1OKA9hWrwAhgCm3OB3B8iMoNzRwfBRb3+0k qD72ecx9NnIE/FYkKR2ZpWRMCuECINEuyLVAAP1zHoAAqCO1mC0Eq8oaLQwiLFvk6nUYw4DDHviw CKqBAEezndLS0IOkfQAGBLDgB3p3I/jJD0BDutKTAFSCgFTmMtNzQAmKB70VqvA4L2DEiRYQi5Kd cG06+gBbmuKvOAGMWXY7Yg+AwUO7Mf/tA0bz4RA/MIIkpmEEBrNg727WRFdcT1MnI9UEHPACUNXk ehxYTP8QALO0jdFGkANAGJOno7bYMJDLitYN9wZKvLnOZ3ryF/oo6Cde6WkGgBMkBkF3uEccEmUE 1E2plheLXOqmBGIE0AGJxwH9Ve2AX4QXqlrgSTlp7Fl3itYzhxUsU6rhV7QLohD1+IFa0S5aslzL jQRwy5YNsIAAOCMjGomyRRhTN4lwAKpkdswDshOdBvTkngrAsTvOiWN0cMEMCmUHgZ5PiTOapTht iU+T9UE0qJIcLTLJAUWcSBElCFLM3hkgjCXihSWYVAjQABsdGkoFfUOofhz1KILU5Db/rnGFlZ60 gBcgE4HNxMUBFdGdtqRhAU96gRpyKqfu9GAAEpDACDSgUkaxVBHUsYs7CNKOcBD1qkQdKlazpQIC rA5OTZXRU2sU1bLWYqtoTatPw9rUsUbkUTc1q1XVSte68pStYaVNWrM3Q7v6tZk9HQde8apXtS7m rHH9q2IpxIZbDPax/FmsZBlLFbfAqLFFfexguYOx2kwWqx51rEsyq9nS8i4y7PisPmtj2tbGhrNz UK1gXUtb2cCWDrK9a213C5fb4hatktEtb4f7Ft/+FrQQIa5ye2sAQTjXuT6IrnSnS93oPve62M2u drfL3e5697vgDa94w5CE8Zr3vOhN/69618ve9Za3vfCNr3znS9/5vre++M2vfveL3/vy978ADrCA sevfARv4wAi2b3MTzOAGO1i8BX6whCdM4QhT+MIYNrCFM8zhDvd3wR6ecAUiYAAwhPjDJ5awD5Tx gBSj2MUOZjGM6bvhGe8XEgaIQAQWN4EImOG8J8ixjod83gcMecgt1m6Qj6xj7tbYxvUVgI6TEJid MCS8OMixWMzrABKP4srYzXIEtrzdJ0NZvl02QGBGMQEXgHfFY67GeBHg5S9nF86BcTKIz5zfE9RZ MMYA7wF2vA/xuuDPogDzcwe9ODmXec98pq8PujwKNwtBHaMIRHeN3GhHf3fJa1a0IP84/RE9/1cE DbBAAla9agxgwAIokIEOKHwAA4hCAGIQywc2jehRgFfMa17IdY1s61I/Wr88WIEFTMBsZmeg2c1O wAwaMOsHM2MwOAgD3BKhae1KudgPEICnu6tlSmA60c/9NinE7etj45cHDSiACTJAbw/Q2wQSkDe0 z9cAH/CgwQ/otCUq8ABLh/fQxT4ADl7S7u72eBq4Tri5nYvwSixc4AcwNX2TbQEY0DsD9qZ3Upmd AJKX3ASvrnaCXSDxSlQgCQX/tI4rEQgHtNy7jKaEA4TgY3SLwc89P0DNb+7u+a4AAwTwAAGW/vFn SyDarF61CaR9gn8nODnVsDJ3l1z/iV3X4AFE3y6xSWHioE88DFynhNfB3vDsmtm8PPAB0vs4gpB/ XAIZ8HhSox71GWSbwVivRhm0C+yzfz3s2U0zKf5eA7MLewiFf/zh205gSLfXAjQgwJ0K9qam5z2p Eig5qzHQ6hmYOMEI6HGOV0/i1qvZ7QGYcsaH0OMpk/j013VBAAKweoPXIPas3/kQDBB7L4eh9q7H /XXfLt4VnEDpBKjW6vpod73DwOSjT4CrVeDgH7igx7sPv/gD4HtBjH/3JEh/+s9PggBg1wHtF7/6 1z/+9E/g9+yfP/vdX3n5/qAAfTQ7s9NHngcDI8d3rtZq3dZg0VVr5xcAs/dcDziB/+P3fvFHgQ/Y YhiIgW5neenlAw2QeQMogNRHb3oHddmnfTNgYCcwf+kXgTw3fh44BBs4gRFggTV4fhqYg+N3g/0H XzywAxuwVKuzAQJYMEkHcoqyd1OXgq7GeAF2gbtXAWJAfOI3g0LAgz0IhWIAf1oYfjv4hbHHhVWI heYlAzRwJyDwLEc4O0kXcqCXVAWAgBjAfQLmAw94f0LwAAEghTBofmIYezzngjfohWIYhl/og8tn huPVAEYIAmsofW1IfW9igHJoAnPYaqs2AzYwYFZYf/onfriGXdYlCAdwfoNgXREgg9p1fn9YimJw ihUoXT/YXkI4AJC4hpEogNUCAv9vaG9xiG+ZOIc7wIKJOF4VIIX8NwQRIIWM6APK+IfXlYwVWHTs JYS5CIkasIYDwIbdyHl2lwFxWAD5NocFoHz/5QA8GAEL+F2fGH5isIpXqF3R6GSoaI3q5QMsMAAM kIsMAAEQ0I/bCAGQ2I948iY04AEwsJAGaInfg2B0toEG0I7uqIxh4APyGH7PWI9lZpH4qF4sUJAF 2Y8BCQIByQAawAAqCQJKl5D2xpALKYcM5gDgN36SN17vuHvx6Iz0aJP2WI3axXzgFZIqqZInWZQB WZIg0I8bsHS/+CYKKQHYIWGrqIgfiI53iJVByYjiFQMbkAIq2QMA+Y//eJIB2QP//QgCG7ABmecB LlmJC6mVAwaPkeZeXPlmBXADR1mU/cgAPbCUImmQBNCUSweVUBkDErZ7VlmX5yWU32UBN0CWRfmX fGmUKTCWDIAnhLl0CUkANLADcjlgtMiY6OWY3eUDHbABklmZlYmZKzmEsLl0TUkDK0iatkledwle PxADrLmXRZkCl3mUajkCsDmEI0ADJxCat2ljpnmaKKCXrdmbwcmXwwmbA7ABiLmcy9mc3WUDNACQ rsma4qmSuLiWIDAALCBq2lmX3MldIKiXwCmeSXmZYImUubgBapmd62mb7emeO6CXJ3mZRvmPwAkC 8UmdN6CWLIADyrmfLtaf3CUC/zEAAdPZmsB5oGUJkJC4AerpoHwGodwlAxNKocCZlAFZoiUKngXK ApzYoB56YiCqXcn2ATFwAxcKnmOJmQB5ozdgei8aXxLQAwqgACNABCYwpAqQAQpWXzagAhhQoyp6 oxl6oZfJAjugAsn5o+yFAgpAADygMRnAA1zqATWQARuzAvEVo9n1Aw3gahiwAywAoFQ6pxBwAzcQ AxaQpyjQiVqqXmZqATzAA924AssiA0LQK/KlptglAzPwaq82A3Bqp8G5o3XKAjGAAnkKaxbQb306 BApAO86CAv9WK6HKAwRwLUk6BMsSqDUwAD3Qqhpgdc/CA8MipD1gAaQ6Av9mAf+2iisfuV42kKnC agGQGgMscKzIGgM7AGso0KzOigIU6aE8MKSwdlQ+cKSx1gMjsALeFAasOgTDUgNHNQSuKq4bwwOt 46ULkwC0qgE/kAAK8Kpb6X+phqnDqqkqQKwWoALP+qwNgAL/yqmdSqQrwANmKgN9JASnaqoKYKjP ZaYSIK4DQK6vei01YLAKEKhcKgEWoAAJ8APoKq8dKF+o1q8me7IA2wAqu7IqK2udOq1k+q4bI6RI 2gPcKrKCYKZKKrEUS6sEIARmerEbuzAWcLGn+qvp1QEB26z/arJNy7IrKwNSO7Uy0AEuSppJiqYa ozFeGgYL61w6C64TKwTlei3/aGqm/za0CiCqNfC1IwtfPyADUDu3UCu3dku1VdsBeqsDfPqj06qk PEC0FjsENwu2+xIGqzME1eKzQKsAQrsvRFsDhTuv8GUDUtsAl3u3mbu5U6u3ntsBOhC6fDuwulqm Dbu4bdsDpqq6YgCmYrAsQiADvbICZmu6absvHZsAaIorVleL7GUDHYC3eBu8Uvu5nyu6IpC8ImAD zDuwClCtukq0MmC2RzsEyQa73sqlGUCo5zq4QSum+9KuMouzixhfIqADxpu+xiu6oau8ysu8zIum ffqpQqoBbPsrnyoDq9u7CoukSPpvCzOkJgCytYu2NbCxNcCr8eqrlNteNnC+/6ILuujLvu3rvu4L v/G7Aj/wA336t/IrBN8Kwvwrwt0VwoLwrTywVEh7Xg9swS5swRgMvyswwz+gwRvMwfMbpgdGpAms ACbQoIoqCD8Qw0RcxDYwwzZ8w0pswtKaqgemMUNKpitsXjWMxCtwxFZsxUq8xTccqF48wp2aYEz8 XEEsBjzAxWicxiD7xWwMxmHsYWUsBmrMxW1cx2P8xjCam+Blx3zMx3gcaUlwtXvcx378x4zpAzsR relVxxeLwoa8nidAcB2qXnf8yB5qBEZgyZrMXl6wYoq8yaC8dTBRA+oQyqYsaGD2CIJ8yps8aQ5w epNWAeXHyrRcAy5QAa8sCCZksBCzXMuW7ALqAAjX5QMf8AdbcMzInMzKvMzM3MxaUAZfIAZBAAA7 ------=_NextPart_000_000D_01C5B882.F46C6190 Content-Type: image/gif; name="ban_vi_soft.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c5b861$6d5ac190$306d81d4@sanya> Content-Transfer-Encoding: base64 R0lGODlh4QB1ANUAANPo+9ra2v///4+00e3t7dFNBvrTiuDg4Lu7u9PT0/+mA/PYr/7JauXl5f/y 2qnS9fDw8MvLy4zE9Onp6VGTuHW28KrF1f6yKMTg+EqM1/28RC1ttH6ryfLy8uTx/Oa3njuHse3X zPzlulKW4TN1xqqqqvLq3hdypvP4/fj4+PX19WCk5z6B0Wefv9vs+/D1/L/R20eAwfr8/vj7/T52 ufv7+/z9/v7+/wJnn+Gfe//57thyOt6NYdzl78vX3tTe5iH5BAAAAAAALAAAAADhAHUAAAb/QIFQ eIM0AomkcslsOp/QqHRKrVqv2KwWG2hAbsOwMBU4TAidtHrNbrvf8Lh8Tq/b7/i8Hk+YHAIpYgI3 BAFobxCJiQSMZxMNkJAHk5RlAZeYf5ibnJaTZZShkw0HpJGnqJCPqw0Trq+wZ4yztLWziri4e7u8 fIZikBBwubOvqKWVncrKmpefz6LRpqWpqY+trbGxtty0ud+94eKIkEMQB3HEfX3XkqR/8MvynfHQ 0dLU1NWn16vasN26fdM1rqDBAxAGBRDm5lsxV6mSzZu4qR4oUPfumdq4D1u2f68C2hpI0KBJXhAC FEHXUJ0jiJGeyUtwiSbFip7gZRT1rmfH/0j9PmoTWYtkopNIeSFs1RLXQ5iSPi2jSRWTzYn1dmpF 5u6nR3//iN4ymnTcghC9Hi1s43CdsahSlVWtedPZxa0733H1ig1sWLFky6I0sWNHAbS7UiZg65Jd O70zkUiu6wkj3lEa8+nryAqkLKKBBe/a8aHDhxAFPqDQAyHJmrZuD1iYTdtHswARBljQrRuEb9+U c2bmSUnvNI4/O4MUyyi0aDwoPhTooCJ66l2u08B++QOH9+8cOIH47r0FeRzyLF7mms/d3s18PYcE TBKPgQXP0+QowFBFAR48hMDQHdltFwsF54Fw23knWHDeMllp5V5Mp8AHX3KqyMccAc7Rof+BAfl1 sF8aKqB2nR5JGPgSJAOchx4mLZLXQozfcRJhXnsh99OF+yjnGXMd0nFfiNKptoBhBayGYgLquPUW JCecZwEm5pGHAITCEYdZV3x1CVRfQg3lCpD1haiHCtLxQJqIh+2RoiK0xFJhld+1gMl4351wAAwt cNBneBhZwAEFv4EwYxnuwMCBbzM2MAAHkHLgQ6QcWOAooQNA8sOjhVLAAQyqhLmNLAZooEEI90HA yAIGGGCCIqyawIAGDJighgmt4qeGq6UKs4AJKqSBa6on7VeAFxDst8CABDKpqi2OpOIgeSBcAsN5 dk77HSU+4OkiDidkyqKLvpGnLQ5+guf/aJTf4qCghrJMwIAC911wgQGMGECvBgq8SoAB9i6wwAUa pEEAwfqC2AEECtirsAK6HkzrBQwYBAGABexAonQ5uJlAN0/GdAC72wbAgZQBnIsDJd62iwOoNLqM w7kIghdzuy38SIsJEK+qAAME8LwsAbRyqO+rHSygQBqlpqE00goUvHAHEAcLsDAiKCACs3mYoGYO r0JgGNIH/JdsHklwA0tEB5xM3gAH1OydgimfN4nKJ4BAsncc/LC3yyqTN2iCLXsnpi1K30IvAQMv DMHVEMzKkNILf6jdvWlAvIbmEFi+MOZ7QEBYCKjtYKuy2mUsItofx7n2Y5RcK+PIgpeh/3IpA3T6 Qystg+A2eHv+HTh4hYIwgCsqWzBfNwBzmMiH/2rgvNKJ9Or00lTr2sGHwmiuRtXZMyQC0nt8sEMi aSb93wtpGCZ2sM3W8npEpPSuMgx/3I7KIz9YQOfccgPXmG42PN8c7yEwyJ2UxDKBXi0CevoylQYu oABVNY06lKMawUxFr8xpL3seVAPX5oCmHYCNACZcmAkKwJ8GqC4NPMiYxvCQNtcZ4zE9udnv3DUK lZ1iAC0oHLV614jkMegHY5rApPQGOMBA7nlAA5jABLa1Dlgvadij1xTH170FwC97wQKfHj4QoMP4 hwfacV8HDHOrHORgAqwrhmPkdIwAyP+MA5LwYQN+IERyEZERRhQcLW7WLgswx4GqgqAGBsSQWZEo g95zXAi/p6tI4kFsH4BAsCDwQgLEsAOebFMvatiIOd4wFQE8D6ggoTJXFO4EnurdDnHgA0b8b2YL BCS5+iSlZzVnLNW7gPMgQLHHXUANIpDaFSFZxQ4w4GFepGSwLqA9A1TMDoVBTAdYqKT9CKNIX/SY /BxhysdMgJBza0crD3AeCqxjbyDAW7qklEsCzBIGHCIgMB3ytETwzAAQyKAVj/k4qakgg54jJjQ3 pytaqcGhdojhf0wQSrQkS2MEQE3HRtk6+T1lfhP4G98+0krZ1YkRNwMBAfroouQ9K5X/PSBADwpn AVUZRREUM9riOnAvYdBKGMvEHsBs1U8wStOKCkCD0EYYB+mwMAQcS0NqNvlCXpAyIC+R0y294wNY tDKkhCOXTFlKHpN6x5CJmGXeRFrTmy4ia/aaFYggAFd72cqZBs1g5KLWwUn6dV78uuYdRLcfjcXQ hGhUQ2HCcVWi/CNwIBCKymzZLnhyqAccINkJFmUuVTrPb98SnltxYYIFbA2iHXiBaesgul+FUw6l vesecnC+pOXgA4fQTwFy67EmYTWJBPgbBwAyWZmmcrMuVYQPLAADTbYsuaqywN9AAIPe3dRxybTV C4RmJpRY9EgLc94aSshYZ/nWsaUk/+eGfhAptA6EUhwYgAog0APNbtIoBBAUpH4gwtHqgpgaENgE 2dfdXfwnBDsQkBt48IEPbNSq5oXNhiZclEXU55Yz2lsL/MsQDpdJVqZyVYETY74AMVUFhUksR0fr vF9SeCQeTsRMZXaCH8T4xopAxIh7sQg4qOC12FkMjn1ZYRgPWRgQmEALROqu5h45x44Dx46nbBLX PJlD3ljEPp/MkN1EagD81c6QGQNlKpt5HAXispo5PDXq/JgNJYmylMl85jqjeTHaec2anyznMofu KHYOtGiyM4w9xxjOgk60ot9A6DkY2q2LjrSk29BoOjy6TJPO9KIrbWkckxnQmg71pv/xfMkb61jU qFZ0EgTBalbf4NWwjrWsX93qWtv61rjOta53zete+/rXwA7DqoNN7GIb+9jITraykT3sZTv72dCO trSh3expW/va2M72tKut7W57+9vgrjW3w03ucpub2gk4t7rXze5gj7vd8I53vN8t73rbO9z0vre+ 973tdPP73wCPdr4Dju8I+JvgAj84ws99iQYsPOEPP/cNGm5sAjQgAhjHeCmCnYIGJCDjEehCIKw9 8IhP+xEfD/kfImAGX6vg40kQBU0I4OsDYJwmoZBMDVh9cZD7HOQJuXXJTf5sAtwc5zJfyK4hYHDL RGMCu67Bx50uigCoQBAHSMBlRm7/66ETXdkTaPpWrJ7rFGgcL0HHNW6ofg8biCHmeOG6uBX+dWmb XeuXcbjaWZ73XBud7fdIuxBUHndce73uxr64KK4uhHOIQu6srgHhJzGBndvAD6Jw+62RsHghEOAe YVDB5LUCeVYfHvHEznooaB4Gp3fg1kwPhd6FUAOna77WNxg944WgF0rc3uihgLq76Y56Z+tkFDsf wjATUXoxTADvkxC8APg+ClybXRTOd3ryBaB6Ski/16cv/q+PUPUu7J7XNQADq1WAm1C8HvbUb3kY PJ75IXCeEh0HeRd2Hf5n32AGLgAAAOABMlBvL3cPSBABDXB+wIYbGIcRrAd70Ldx/0Nwd7IXBqOX dRN4Cd9nesSnbSjgAhgggAKIAR6AAvLWe/dAEx2oaxNHdbdna7TGainwcaKQdpK3HmQndB94bTMA ACMIAC4QgAEIhB4wA/Gmggh4AMHmDNEQgb7GdPFXCr83hRJieD1odyJIggJIhEMoghjgAkjYbilh cGYIc2cYAMB2c2dohs13azdwAAiAAGz4cecnh20ofOyHhh8HhR4IgmDIhUL4hUNIghiAAT2Agu2m AnI4h474iAjAgLt2A6IHiVfSaymAACVQApYofTqBKOonAJkIiVkoBP0XbAB4iIJIiB7gAq1YhECI ATAAAGMIb1lniQjAhLa2ibxYAv9QOIqPWIqC0ACaaIkR8Ia2Zow8aG0z4AGqyIVf6AHSOI1fWIKH +AAP0AMF+G0p0IubqItDEAGkeGuWKHxDoIy6lgCbaImz12oEQBOQh45zJ22pGITQOITTmI+vCIuH iAHYCACK2G2c+IhqKGzjmIyQGAFh0I0HiWsRsI6PGAGSaIreWAIF2XgD6YjCeIq6loqCOIiuqI/6 WI3W2I/Y2AO1iG24eJETUIyOCI6tFgCW6G8E4JKOqHcP2YsKGY4Z+ZK21gE9OYcF2ZJBCZN/uGwh +IwkGI0iOZIkWZIm+QAAsI3XlgC46I2Q6IeCUANBOYe8mJA7l3sNqY5dqYkVWQL/74eLZgmRj7h9 rcaRtVaP/WiPAriPIUmIhAiVUemPD2AB2UiVdqeWarmTmyeY7BiOB9mNZSmYjKcChmmJRnmUxmYD L4CN2MiXEvAA1ziX/QiVQmiNlnmND5CZlmkBEmABKRltxPiYcxgBbol7Vsma7fiQwSgEB7CYjDkE LcmauZhrcMlqoxmcEjCcFVABxDmaw2mZ2Eial9mPzOmPpJmcozkAAwADoShtTPeYCZAC11mYghkB 0ieOtSkA6sibj3h+2fmd7dh1wjiJA2CcxRmfFbAC81kBD1CcyJmZw7mfyrmfxXmc09mXAyAB1BmD 00YK4vmICAFst6igWimWtXkD/+VpnnMoiYWQoHRYCt3JnskmASvwoSD6oSMwAvRJnMYpAfaZnPyJ nMW5AiS6AiwwoiywAvBlARt6beLomtl2AzVgoIOQbDM4CDfKocd2A5g1AhmQpCM6ohlAn/AZn/qp olI6nyE6AiRwpVhKAjHAAS8Abo4ofsX2m6zmARaQATHAAmiqpCD6n/sppflpolQqoyxAAhuAAxuw AQPwAjYwpNPWmmBKbGIqCK/WAwMQA3RKAmn6oh8KpSfapiganyKaAXN6pxtAAxzQA3tKbpn6p8AW qK1mpBxAA3d6pSygpk4qn6hKn5GaAVd6ApV6qenHqRHnqa52AzaAWaK6AYhaqv9LuqaLGqIumqQg QAOiGgMD0ANBKqsLR6u4ZwPsJaqkqqQkqqggyqRmSqw0YKzIyqfK+m/Mins1UAPsFQM0gKjSuqTW aqbkWqnayq3dCnDfKoM8uikscKalmqT4iqYsUK53uqXb+q51F69waAM1QKiSqq/6eqWUaqn/CrAB 257O9mqbcrBZeqeW+gOw5rCIJ7CTWAMAwAGsiqX+6q4ai3Acy2u2igEDsAIzggF7SrIlq2v6EgYA owD0IgQ6wC8N4wDo9m02MAMoMI0l2AP4+AIz4KMxu2s24AAUNAQO8DMCoC8iIADz4gBMqwE9i20/ iwIvII1D2AMg6QI9QLQ94AH/EGC0m5q0uZY1NqsA6jcvOiAE9KIDNxu1ChC3znayYXADMgC0L/C3 TSmSXfu3L4ACKDADMpCsxcdXOysE89K4DEAxdRsG8zIEE2S5F5A1U2sDmvu0OqsBTGuzBiAE+sJX DICF0PZqNtC3MwC0hvu6sMu1sdu6iCsDNnC7sQamNmu1BBO1F+AAOkAxNQBYrVa5QtC7QjBBUisE WWMAT/u7T3uzcPu0BnAD83K6yxixsna73CsDrEu74Fu73Jux3Ro1YKAvNUArgxC5VHu3xasAQ4C8 AqC8WsO8EEO9yYu1dusA+hK3dIu9RDptGQtr3Hu7tju+suawdau5FNS2F0C1/w/8vvGrv/N7L/Ur AM37tAuQv0KgNA5gvAJAMahbboqrtjd7A5oLtZQbwawGwvI7QUoztRh8v3VrKqSrAB/MwiKcvWrb bnWrL0wLwI7LwoIAwjZ8vBqgufYrAvg7v/oLxC4sxG8JsT3cbVFzw8Grv+zLvhI8CDMrAP9Lt6Pb vjqgwRwsAB7cv2CswgFcxeq2u1e7v8F7ulzcwvArBPg7L1MbuWV8xU18xED8tHTMxvPoxuvGuKCb vDarAXFbx0V8xx1ss/eCs58bt3/8xDhst6Y7woZ8bpNbb588xZ38xmPMbkt7s0DMyaNMbqGsbjdQ uhDjm1S8yrTcxrV8y7ymt2u4rLFJgLS7/MtiYAPwCMzE3Gpk0ABaWczEbAQWp8zOPAheMHHI+Myr TAZgcA7UTMwLynsTALPZXLI38Ah7OwE7+M2dzH7dLAhkgBATac7vOl9/gIxFcARbUM/2fM/4nM/6 vM9aUAZfIAZBAAA7 ------=_NextPart_000_000D_01C5B882.F46C6190 Content-Type: image/gif; name="ban_vici.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c5b861$6d5ac190$306d81d4@sanya> Content-Transfer-Encoding: base64 R0lGODlh4QB1ANUAAJHH9AJnn+Dg4P///+zs7Gijz7q6u/y3Tf3sztHn+oOy0Nvb20OMtf3Uiv7K bP+zKNPT0//y377d9+/v7/7ktsrKyv+mAvzanrKXbv/47ix/rdHCp+Tx/PLy8sGVVf/8+Pm+Xvn4 +MqOP6uppzRvvtKqaVlwiPT4/e/ew+usTsHU3trs+/aqQvX19aGBWfD2/EB/zPz9/vnv4Pj7/ujF iejo6U+S3uOeQPn28/Hn1/v7+tLe5fz06eTk5KzI2d7PuiH5BAAAAAAALAAAAADhAHUAAAb/wIFw 2OktIMikcslsOp/QqHRKrVqv2Ox10esMv8PQQlCbdM7otHrNbrvf8Lh8Tq/b73j7pCZYhMBCNQtm bhOGhgSJiTU1PY49ApGRYwuVlpeYmZSTkp2SkI+hoo+MpaanjAQ1iqysh6+wsXmztHUECwRgjnCw rKWhApCTmsSafZt9nsqRoKPOv6inqq2tsdawtdnabY5DEwK8r76MopKUxeiXyWPJy8rNzqPk0aXT q9SJ1/rb/P0CE0IGFeql6BewYekSWlrXjpO7TsDiOZpHb9U9fAT0XevHsdaEBTG+DRRX0KCwY5og HDmiUqVChg0fMgtGUyKpRhUtYsyoEVvH/595/vWo0SbWOHKOzGFq2ZJlJZcJY8p0lxRePIrRpu3s +QqoVzuNBK4xWhKpUmJN0yqs5HDqQ1DBbA7NaQ8jV0Nf8875CIENWQICfAgeDEFpBR8KDCT2oYFB Yw0pix1z6+kkxLhxr86lt0OBZwU+qN0l1KGGggIMUhdQsEONitSw7Xz27KMFatgKcHREouZvIgEB ggtXgFCD8OAFjgdY+TSd1MuVZwqDl3liqEabT71WHkBD6HyjSyfnHpyBijMtfCiv04LBcQUd3A// yRvNX4s1xgvXgHKBcg0GKOccW+y4ZVVEcj2TXSkqkDcceFx1oIJxDg6nm3rH2SFfcPBtGP8AfLv1 dYZv+CnAHUomHreagOg8d1lVCcY41IwzokKAh+T1cFcHe1BYoXC1YSichu/FV2SIPBK0yCI4ceeD JfoFZ8BLyLxVnYwSYYfTlvQotwMBUcK3Y5TCOcadBtl4CKJeSPjGJHY5kFmAJT52t0AFBeSZJyaI pdYYA6txMRMEt63Ww2erqeDZaj4cmpoCjizgGWyPqpBTPcdpoIqQH+5Yw5k1tIBDisf50NlsaRAw KaUKnHeGmqPO5oN9feLW2h1tklSQKkj1wGkADFRSgXIFQPArWxDgqBykjpBaZp2cnjbcoT8ysMOl N5baQ50KRNiBs8ERgEYL4IK23hngKsf/AFFqGjmfhHUex4C4deQ6AT74ARNvJeD6AEGAxyUTL3kq UPtjcJx6WMCv5BVgo04ENLgfdzv0hIacapg2m7kZdsAwdwW4y6HIH3ZAwMEM2GEvImVhFwqZxHkI 2QK/RsKwme/5dzDCFSqAY2PcDcWrTheR+R5PG6GBY25v4CDxkCR3p+wE7bbrrHfg3jrHykeZBMnT yPVArADGKheJz5Tu4EidDJQbWLwfc0hp24386gPRrQhg9HAWp4HjrHD82gEOcyvQwgR2V/0e4Zm2 hthnWsuRayv49ZqUADIDLFwFNpt90iOBkZlapkL3S15jCuSgnQJwQ9zKwMfVAHYAreGl/8bfur0h +BotKAq34vMpq8HCXeAKATX0lFNuppP8Gsppypbp4bqr2P3ftdMoijN53+GT7n/cHsLG0mv4oMJg 55/bQWfbOwk8h+n9WEDkkh+P/Ck0gqKzgwoI6nwPO4CdumQ2Deu9pwfT+J6TRGMIYk1gb+UhDRtE l7sz/Mo751KgcnzwvpJ962AqaAEdkIC8oUFDFNELTsEg8atGKKttbCPTl/KzwQ0qgmHD61dGIIQ4 5ehoAgqknxpGxR1XDQ5HC1POBGbXnRWVqoNrYp+DUjZCCNyrhKjIX9w0EIoWAkdehqgB2y4orRqW ShFkUkEi+nWNX4kpgNwxHBw+VcT1Gf/NfOtJYwvItUEo8k5R6qpgHNpEOcpl0RH8Q4rzZleANaqr Bik0I5DygSMdbWuD16CjvASoAaI0TYPcSdmvGBc7k/2uSGragXJc5Swqbs2KO2nZKfZmqVK0UJP7 Gdi8Lnkwux0iXdHzgT4ieTpPvkGA/yFA/DIETO75cWkwq5cVDxFLE5IDh6f4VUYg+B9DGGw4HvKl IVS5swAI0xrrO1i8OjlHbpaHKMscEjl3xkFUvqd36jRm/XQVy8oRIF4KyKZyfqMsjk0SL+dzVTgx eYibbWc/SdtB9Bz2T3XFAXHR04AcLXium0k0U36UUAodprJpKikfJXyTNFyniHuN8zP/s7KGqjbm TR9pABs4fRxrRiQ+dKrhVJ4JoTZ8NRsjwkGEOhWiHUS4A52CpgzGSxJXqnmRWJ6Uh6+QE+tUhLTR eGsk/SDEHvXCC23wxqv8rKYr0JokXlYocrbjUZLSQIi4doWseM3rGurDU7Resass86tPzkBD8phH hHpNrGK3wdfeCPaxdy0KDnDg1J0u9rKYzUNjRwLZHdHBDGZAbGZHS9o3bDYcnb1rXEvL2tbW4rRy qKtsv+ra2tp2FrD1CF52K8Hb+va3gxQRcIdL3MvmtrjITS5Hjqvc5joXD8x9rnSn6wYkAOK62M2u drfL3e5697vgDa94x0ve8l7XuuZN/69618ve9rr3veJFL3znS9/62ve+7JUvfvfL3/76F776/a+A B0zgAn8hwAZOsIIX7F4EM/jBEI7wdh0s4Qpb+MEUvrCGN/zfDHP4wyCer4dDLOA7QYDEHT4xihes kh6suL8jfvF+K+FiGV+XDxXIcQUg0IM/jDfGNoZvIyCQY0pwrgbfFYCOl8xkJvuYu02OcgUWcN0J EBkJnTiCAH6s4iDvlwA5RkKBJKESgHDXRQ/RQXd1wDm3IFkXOx6zMtQMXiB7Wb012LFbFtCCMxeG MpGg83bBTJk3DyHPf5ZJjb9r5zuXNwR6psyis4tmdwhauz1ItEwMPQBIa1omuWB0l/8dPd88e6LP QuiAMp6MXbIBOtDd1bKbv6BkT5g5BJaJBKsnPOr9zoADCUgAB2LAYVdLItRDkLMXtFtpZXBauyrp xK6vy+Yxm1kIIVDGtbnbaPWeYAUSCLa4OXACDcekB5fOSBqm/V1VQ4TY3K12J7pr6k7Aewi5njSv fb0Cca/g3/0O9gpmYGEjeILGqGZvDyIdjEtrtwVtjoQhiKzjUIHB2MwABAE+7fDsdnu8IQC3wBPQ b4AHXAIDl3AHPj0JJPQg4eUFs6bZjd16kznaZN7yEHAeCWQPQQefhjm0e+3eb4db3CQ3OcCDLQGU vyDCuVZGmR/N8H+AF+NTWTTPwXH/3YhHYtncJvp6ZyBypCf93xxYQdr/zfSmJ4DgD466MsZA3ju9 u84sf4iZp9wJsH/B61zv7se5++uj+xvgHEi84pcu7qb7IAH3VvBHdkz5K1eeyuElgAHCvONnc3fz l/cxoi8vBANYHgKeH8DmLZ/684qdvCfggOEPr3bF2z7xbG+74xNQbga34E4GCL7why90KI9g+AYI L9CzDPMFIN8ALYjB83UOhuMPX98ef314yZ6AcAfc5LcPP+N17/iUQ5hszzcA9bvbAesLH/PtFcDz c/F8oofA/cFvPSAGDwaje5/24Sd+Jod0TVeAggF5/3V/I7CAC7h+A1AByKd954V//wbgd+EVbRdH gQQQA/8yfBUACAJAgR2HXfwnBGRXgN13dCW3dmjHgkp3cihYgAUIAD5gfvxFgfAnBB0ofBIICAaA fx8YXgzIgAbAahVAgV4gf8gndBAAhKJGXhygAgAggwAwhU03hSlYgP3mdt63hRKgAhWwATQghhtQ hmYYfBXQASM4X+kHfzXwg8PngNo1ATiYXUc4hEEIgchXAWbWhM8nBDpQh0PQAoIoeD2YXT5QhYpY haexiIooAVZYhVdYgDsghjTgAA7QAJqoiRfQiRRAASgQiiiQAznAA5EHYOk3hBS4bRNGgdg3BHrI g4GQfj+4gNMHi/U3ixRYfNk3Xv8xAAAKAIwAUADDCAA2UIzC6IjKKAEbAAIggImZuIkN0IkX8Imf iADYmAPYOIoW2F4hQIu0GITdFQOxKHzdiIvD12U7CI7CVwGC1gG0SITDl4NhR16nUQA2kI96ko/H WIXEyIjKCADN6IzPiImbSI3WSAHYiI0RkI0IQIprmF5vyI7tSHPYRYEGEJHlaHp/R5FoaIE94JFo eIGHiF0roAD8mJL8uBrF+I8BSQMEGZMG2QA0MI0JuZDYKAMLSYo4MF8TsJH1Z5HXdX9/aIcReHEU CQHs5nwU6Y4kWV4cYIwwMJUwsJJ5EpCO6AMxuZUgkAIlQAMIqZA42ZALiQIIgAL/MkBfODZ957hd NUCB4th1RwmC62h6AhCRA5Bn4FiS+8eX1xUDMaAqMEAChDmVKqknweiIIwCTW3kAKSACN3AAIKCJ YHmTOImToNiT9gWBcYlfgGlfRuCBAsCLhrheCaAAg1mYVamPxKgnLakAXNmVkCmZICCZJWCZl4kA CgmKKICX6iV8pCZifqldgKk3hFmYh6knylkCMSmZNxCZziiZjpmJNymWC2mNo3iK7jWSwfleJZhd O1AAx0kCq7mSNoCPeYIBzFmbzvic0smetOkA1WiNuqmbCXkBKKCZ3Rli35ldMdAZg2mYKpmSJrCe 75kC0omgtXkADJqJnkif93kB/zmwnyTWn8QJoFQ5oDYwlS7AnO/pmI+JoAw6oimQAmD5AwlpjZ34 AyignRRqYRa6XTFwmhtKlTZKmCbQodK5oyI6oiPKAgfgAJX5idVIjTTwAy76ohIWo9z1nyh5o+PZ oV25oD5apQzKAixwAyUwjdRIjTT5A0r6YUzaXTNwmql5nAqQAAugngpqpT6apTcApybapZ34pUka phg2nOpVpsO4GgmgA4BZAerZlW56AM+JpUCKpZApn2BJmUd6p3jKYnrqizMQe2nXfQKXeC9wfxhQ ooRqpVmaAkB6AyIApEFak44KppF6YWMKCDFQqS+Ae2w3gD3wb6owAiVQAggqov+JegBYGqdw+qs3 MJkNIKQl8IqrymCtKgSvegKxGqsBGH7P2gMjwKaieqW+mq2/+quzKaQgQAMloJ8h1gAW8AUXYAHo 2gBCkAEHgK4PEAFf8ACd+ADoCgJD4ADuSgH71aqAOQP+WqknELAC66wv8AIDewL/OgM1gAEY4AEl iqiJCrHCCqws4IwlsAGQWmEIQK9DEAEW4AADQK76iq8REAEPcABDgAAWoLIgSwEWoK7nqq/t+gH4 tayAebM3m7A6+684OwAx0H7qeQMPK7FEi6hCm6ukaWEui67lKgT4mgED8AEP4AAZ8LFCQK5QG7KT ubJCcAAPMAAP8LUDoLL6el//y+qqOJu2agsGLbABDOsBQiuqRWu0z3kDGOBz/WUB7WoB7+q07gqv DjC1LwsI+DoEXjsEYUu2QuCyFECzD1CsTTsAhzu4A1C1IBu29PoACICvFmCvY5u5YfuUEjYDBOC2 DQu3h1q3qlu3IuABP8CK/IWuCGCyKHuuEZABD2Cv+Iqy11W4QnCyhiuvFlC2LnsBY2sBWYu470q5 A2C19Kqv9AqyMQu2D/ABLiu2TxhhOlADpPgD1eoCHiACkLm6pCq+4BuKApC8eeu5WPuMTlu9T4td vgu2B0Czkiu8xGsBxtsAvDsE5HoBHquuQuC8IBuyTeuxF6C41Cu6D6YDPUCK/9qIAN7bsCLgAuJ7 webrAhvwkA+Jt/tltdY7vPTKtPCLvYTbtFLLux/gtdM7AMULtgJ8tYMbwEPwsVJbwOQqBAh8rgjw vgy8YDpAADkgAxFclqbrAkiMxBgwAiyKk6SYsfBFuYxrtV8QuPZ7wohbv137uMO7uPrrsclLrgJM wwN8uQ5Aszk8ADtsAfA6AFaMdw8WmDIwxzIQAXVMlg+JAj+wx028kDr5xzkglPNFuTw8tV/wAYGb Xb67wv17sozrxRTQANj7v19AuVXbADcswzqsvzwctYkMxwzWAXRcsqQ8u3ask6Q8yqScyjKQtPTV uTKMu1qcyG/cu5Hru5b7Af+U+7SP68Ux/Lue+8JTi8YHrL9k67gmXJoLhgMTwAMR4MyrHM3SPM2n LK4fvLIma688jLtn/Mm23LGDi68j+wAZwAN6W7VtPL9D0Mn0mgGZbMCbbLyhe70/XGA60AE8kM/6 /Mz8DM0l68//HND6bM34pbd/KwQggK4H4M61jMXrzLTGW7l7u9CSfK9My7R+y7dtPMzwrMb6+wEb y7ehC8oGFgM4wAMZkNL6XM7lrM8u/dIt3dL5TND3xbyAYL9XnGA5vV0gkMz1mGA6gAMpPdREXdQo fdQsXdRDjQOCHMW/7GWwrLIRnb0FZtIfoNRYndVajQO+6dTBqbLpGl+T+l7POvABZm3W7pzSV33V WM3WbJ3Wa03TyaqsY+1eZX3WeI3WeO3Oeg3XeX3Wcw2jdd1ef13Yhn3YZw3FgT1gZyteMYDYkA3Z i11hSKDY9vUBj/3YkR3Zjz3ZEsaBfgBhOB21mY3Zpl3anW3anl1hYqAjCkazo+2Lq11hE2BJD5bT sB21up3bvD3bBQcQoe3bwj1fYkBsqjbcyO1eVhcI+pfczk1vzyYIrvzc1P0Fv5d6YvAP013dwy1C fSCUqsYSWjDe5F3e5n3e6J3eWxB4XxAEADs= ------=_NextPart_000_000D_01C5B882.F46C6190-- From newman@yourblindbiz.com Tue Sep 13 15:18:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGIr-00025G-5t for dnsext-archive@megatron.ietf.org; Tue, 13 Sep 2005 15:18:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07954 for ; Tue, 13 Sep 2005 15:18:46 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFGNH-00024e-FF for dnsext-archive@ietf.org; Tue, 13 Sep 2005 15:23:25 -0400 Received: from cpc1-blac2-5-0-cust243.manc.cable.ntl.com ([81.97.38.243] helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1EFGIX-0002BE-QL for dnsext-archive@ietf.org; Tue, 13 Sep 2005 15:18:30 -0400 Date: Tue, 13 Sep 2005 20:17:59 +0100 From: "Goldberg" To: Subject: save up to 7O% on the meds you need# Message-ID: <001101c5b861$74bd7900$306d81d4@sanya> MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C5B882.F46C6190" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C5B882.F46C6190 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C5B882.F46ED290" ------=_NextPart_001_000E_01C5B882.F46ED290 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
3D""
3D""
------=_NextPart_001_000E_01C5B882.F46ED290-- ------=_NextPart_000_000D_01C5B882.F46C6190 Content-Type: image/gif; name="ban_ci_soft.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c5b861$6d5877a0$306d81d4@sanya> Content-Transfer-Encoding: base64 R0lGODlh4QB1ANUAAD2Isfvs0P///9ra2vjQh/3JbPjbqANnn9FNBru7u+3t7f6yJ9PT0+Dg4P+m A/Dw8OTk5P7y3+np6aXC0srKyvy5RauPaPq8WfvlvHuqxNhyOuG5mv/58ezZx+2+b/etRvLy8vHp 3+umRuTLs//898+oa6urq/j4+M7Z37ekhb+JRdagTsfT2v/+/fX19drg5OagP+qtUO+0Wu3q5vz7 +/v6+P726tiYQPj18v/9+rXM2OGfe96NYfbw5+fn5/Hx8SH5BAAAAAAALAAAAADhAHUAAAb/QIFQ 2PpBBoykcslsOp/QqHRKrVqv2KwWO4D8WsOw8DRoSBSgtHrNbrvf8Lh8Tq/b7/i8Hq+QNAYnYgIt CgNocA+JiQqMZxI+EJEQDZSVZQOYmX+ZnJ2XlGWVopSTkqankj6qqz4Srq+wZ4yztLWziri4e7u8 d4UKYpE/cbmzr5CSDZOgns3Nm5ig0qPUpajXrKuxsbbdtLngveLjbkYQQw8NcsV9fY+n0pfO851/ 9vfU1crX2Nnb3N66gdNFrmDBBg8GDXiAiJ27R8giWaJHsd6nUKHy5TO1j5+/f68C2hpI0KDJXQ8G tEjXEFejh6ok2pvHAFPNipxmTtMoqpSy/478IGRrBVJkLZKJTirdhRCChDfgjB1DNrFZzauZblLU ybPrvp9BIw0FKcuoAqQMl+4a0cHFsF4SjqRlE7XdMaGiaCLJijMaRq9efYYVy4psWZFI1e4JoUED gg7jUjJwU9eRq4hVPWHVipMr4ErLRlkDeirmx39mz5JUrEfDBhBsEYx4u+dHEroOLb+bpCMDgN8A MmTgxGAC8N99o/UWLryBjuMAepL6CVZi6YimWxFFnToxazs/RiBI80D8DnG31dS1eznShAPw48sf jum9/Hk6Q9mP32A/fNLJDGYKdtoY1t1qbBBgwHdw7IBAWj8gwAMPHdCWR3ogrBcLMhnI5/9hfACw UJyHznhGiX8H9OehgGFBwopQqhh2GGIIrlEBAQyW46AaHSDgmoUXTqahK+5w+OGRBwAwAIoW4TMK iirKxyIq2Y0VI1kHDuSGgjm6sYFs4Tn2YC9JaPjQbigc+duR9HlionRRxtfilDAOdWVRRJrlXZd0 lCehayfw8BiZDDh0JkSRdOghfQwA4CEAyzEXDSW9QSdcFxCgCAELzAnHCqe+/SZcXHUWBpF2rxBQ QQUdKEikAQQQEMIssIZwQQUFhKBICLEaMBcBAaiahgE9vMWrgkAu5SACuv7g4AiEqtaNIzEJ9WEG 0DDwIZOUoOAokgdkkKmHPqC4iqJHTqD/zXbHwKKABw4ouMACBJxBgAMFXODArAoQMK8BBixwwQM/ zLDAjfGm8YMD8+IIggMLgtDDwf4WwNoDEyKAwDDhIXAeL2V6M5UkLHyogzxLdiqch5V8C+4BKJiL oivoIqmDjLBAALEqBuArQQgOdMBIBQM/cG8HifSciKpJOxDAMA5UsAbEafj7ww8YOIBBsr2EwIMG O4RwtaAzpNEjDw/swDUdIdsyVUQopjhTM1A69+Ga86E4w8wKLPrcfDi/0rNl8c7QgQOz+PtAvxX8 0HQiNzL0A70gLBxxGlT/cGPlkztMzgOMddCjBrM+S56Pzu6ShNuwrCIJigCEllFGUEIQ/ypwDfjw gstJzjyzDotKgILKgbvib1k3SqAqrQ4svrzjSj9AdRo3Qn35wxFD/BYGYhu0gQaJfMkDbB6/5dgP Griwx+q1tH6qe48Cpmm1RL0wQc29eygB8PJJUPLdGbhZI7BkmeXN4kYzuNeqKrCA5j2gABVQRPQY tsCEYW9q2bve2uxQHrDNCmwZCoHGfiBCDahBUI1RHQNY1y7XxU0mlGDBBGY4Q/zVyTi8exT/4iMB FPUhh/IJzksc0Y4iMkJVZ1gcrvq1AIA5cWkRbBrmFAQw7jFkepjLoPd4IB5dSUhh50PfeNIQgh3s oGzrW6ExDvW2/8lHB9XJobmEB8S7+f9wh/BhxN/AlYGXGAWCtEAg0wiGi0E+oGdZVBjBEqmG6WFR HCeQjfoS4aM0zEBQIFCAoCBDDvat8R/a8UEOARARPMIHf64AYnB4BykPKcCUtLhfHQ+gg9Qw8SyM oBfjFIGBKA4SBIh8GAbSUgCHQcwtjGziWwhgMV40hpMg0Jj6QOAghnxpA9NEjxppQSTdvOIF+EvS C8b1qJm94FGOw4EOXQnLxfXBBwqwXw5rmZqe6Qp08TqkA422gERAUA3B3FzlKHfBRkbsAs0EAUJ5 kTaN8WBWm6zcDkxIvo+Nw5PtkwoszvkyD+nAlPtbFCPw10r5vNJDD6gZADIJAY8GZBH/jHiAwJYW r7PoUnMXqJrUhuWAqi0gBMDcFyMZea8egCAAEJuLHn7wJY114EsfQwA2QeCCSnZymyLxZtyQlIEe uvIBd1MlLGEJO9+saHHFiAoG5iWw6j0ga2wF6g+ExVOFFSBqFizoUO9aAXyJ42plrCQKdzA+NaTw qu5MDSy26qEJnAGWCginmkz5AMr+QLLymYBq0IKLEBigLZFz3CGhqbA3/CAAxNpgGzwLVINMdBgj 2MEGDpEGB9GWUOsJiARmoAAfYDYDKGiFAnzYWyAGsLEopexZMAsAzXIWF71sLdAMcLWrVa4OqmXQ Azg5AhNW10JhKkgSRGso3TICVMLR/8ELhGuUH4BTOBNwAQ7Iy9nvipaqkcrABOj53FwcDGAM5NzV lMqnPUiouxVyAw82YEZkajNDJLFlTCU8YQVwjCT2zbCGresCtzAkEd8lmGirm4sQQBCB1S0wOb5H Ia65oDE7yOaDSRxhmCaWwt/o74Z3zOMe9xjE1lWxQRy3tg4n5aoKs29/vQHTHNfXx1COsoaTnGEh W9kk6fkxUnB5iyZvFi1SDnOU22DfK5tZvJOhMo/7y+YBi1jMcPjuGnZs2iCf+c6EmvOcdyxiILd5 zFPmRYrxTGjFYCjOYlbEiIEMZTZkt9CQxvOh5yDmSts50pjONBsmTQdLh1nToAY1p/87XWkyyznU qNb0qEn96XKk+tWZToIgZk3rFtj61rjOta1pzete+/rXwA62sIdN7GIb+9hDkDWyl83sZjv72dCO 9rOVLe1qW/va2M72tamt7W57+9vg1ja3w03ucpv73LweN7rXze52b5sB7o63vOeNbHXT+974xre9 883vfqN73/4OuMDFDe+BG/zg2AY4wsnNAAoUfOHeVjjEv42Jc0y82xK/eLZbUHGNE9zj4X5Ewylw CQqYgdknGDkFVk4BMCDbByxnuQ+AnfKYr9zlws44yJ2tgJUnISOVqMkPjk2DhgO9AcuWgMNHMXRf F53koyi2zneedIcfnRoDcIGxBwD/9agf+wdLZ/qvuX51qT+c6tU+QdgBY/FhN6DrXi+2C9Yuiqbz +u1XRzqxp472YsN8FFoXwg+oEQhhwzzveid2zTVi91kfXiNmL7eub53vBjBAFMAIw9FBYHi6x13Y NTA643kN88tDfu9nzzYJIoABJ1LRiZ/tQAhsQAOcs9tJEKhBGM7y3cL/uuemh4ACqCH1rg9e7LMG PimG//lg8/3YLYgArGJFfQVRsfUYyH4HPhuCHtCA3UcYBSZ8EHhjg2DtJyhE88fedWCYvhKNH8L5 35/+o0ce2xwwQAGKWcxewT772RcAAiiAGCA6HdAD6OYC75cXDUd+iod+AiABC5h4/8CGd5QgAUJg cnUnCGpHfxE4gfd3bQbgAReAUP1HfU4EgAMogBEwgAXYAbpnbqGhEUIXbDUXCpwnAD4AgsFWepTg Ay6ngfAnBjdICTm4g+v3a89HbDZAACWYLybYK/6ngiwYAC1IgKITAufmA4BRBr/2dEMoBEgoCsGm dMH3fRmIfEIAhpRgd2NYCSEobS0QAB5AgghVgnhYh69HhVXoghgwAlpobj/AdQ1XiA53iDXhawyQ AD5HgVyHiBQAbC6QAAlQiOUnAIxoiBiYbIy4dJrnc4cYh9LWASQIhXcoAjdwAx4ghSqIAQN4hQEA gAYwAwnYAJR4i7hIiZcoCLlIif8m8Iu/2IsmkABoOGsSMIy4CIzBmIu/OACYKIzKKIzE6HypB205 QIp4iIcxoAI3gIcF4AEjYAB8uIKumH0GMAI40G6W14sJQIG8yI7wiIu9dozxGI/nUI/1mHPVCG2k aId4mIoykI0yUEwAGICxSIAFeY7fdgLK+IvuSAG5uI9DgI/w2HK8Ro8UmYv3mJG5aJHAtoTDdgIl UIfZuAIwkI3ZWADiWJAHmZDnmIPdhoy36IxhsIi4KJFCwJEdOY8yqZMbqZOUGInUiG0tkAAlgJIX EAMBmZQoWUwpWJDmCDAE0AC2h23sSJMRmAA96Y5iAJTyKAAU0JCRiJFA+ZNeqY//2JYDIZACR4mS MYCKIiADFSCXefiUsiiVIzACVblt7NiQuZh5vLaXQmCLuSgGYXmTv9aL7iiYAkCYXzlsIElsFDCS S1mCRBOXRGOZH3ABH6CS4Yh9sBcrG1CM2XYCQCmUxsYAPZkAhhmRv7aaXElrqlmYqLdxPcCWMpCb 2Ug0vMmZnPkBSukBsBeaG6CX3tYCPsCRFBCDW7eaYdACEImYvdYCsBlsA+CctaltDWABJRCQcikD m7mZFfABH1ABIgADMHCeMiCFsDJ9HpAAJABuDxCd8cgAJ8CYH9mLhtmTODkE1ZmftAmZ/flsOUAB 3Jmb4Xkr4omK5BkD5AkDKyCc/9NHfRuwAfh5bVxIn7fYAPGXmtg5BBpaib5GnbkYm7M2m4+Jlt1G AiZQAkqJoL5JnuN5AyIgAhUAAzSKUASwAdRXhx5pbhD5o8d5ofMWmcbmAmzZneApl+Upox9Qox9w AzDwoKvYoyVgot+mlajZd9M2oNH2ACmQAiuglOTZpGVaplP6ATi6AvxXhymAA0SabUFJmlzKbEZ6 bAqQAhawAmMKnmd6pumJo2n6jR5QAgkQp9q2a3XapeSmACbAlisgAg76p2cqAmVqqTLgASnQA/G5 qFR3p8jWAwmgp3waA2/5pFBKniKwAOiJnitQAoHoqZ/qpdVGAzOQABZgASqgAv8meZ6t+qtSegMq YAEjoACIKqsCB6rGVgM+EAIB0AEmkKu7KqUmmYrWKqzDKnswiKw7p6zERgPNGgDOGgAjEK0rsKvo mq65mgIEGAIzcKzcym/eKmy2GgLjuoLQqqe5uq8WkAIjsIICGAJ0Gq8IN6/ARgg9EAIR0IIMa4UC 2AF5mZcd4LAO24L26nsEu3AGO6I/0AML+7Egu7BW2II9ULEhu7A9kI4ZC3EbG5gn0AMeawMnO7M0 C7IpC68ZGzAO4AAX4HI9s7MEAG4tS2s00AM2cLRIK7NKW7Myu7BLa7RwurK/Fn34IgBZQwBUG7T3 ggHfNrSC0AI4gANJO7ZkW7b/ZnufUvtr9xIAYMBAAnBXNgAG8YKz9Uary1YDOMABequ3Ztu3ZosD zNl3eMUwETAId0W4LVAAC3BXQSsEdzUEbuu2g+C2bMUwAXC4FzAIAdBAbJWadgt9J7C3oju6e2sD pHu6ezuwO7ezVngwAtAzEcABAvO2UYOf8yIArisElKs1uIsvLdAzBoC7C/C6DEO3AuC1Q9ACNFAD JEACHOC8qBu90VsDxitwPGtr98IBCGW4C5C4DsABvHYvBtACudsCDES+BSAE99ICORABEINUwSu8 nkuUNNC89nu/+Pu8euu8/Ku/+Nu81RtwVUu8a7WzO9u9iquoYnAvWEu+FQC5/927uGBwL0LgvrDi NI7bvaIYbS1AAjnwvyAcwiJMAgEswI2bNVmTvoPAvopLawxMBOV7vourvg5QwfECu9w7v9fGvjnQ wz7cwx78wR/swSE8xEJMwiXsb/EiBD2zuQVgewksCOKbA5D7wEJwMOhLxRQsABbcxGAQxdlpbbaW Azz8w2Z8xmhsxkmsxJnbAtnruom7ADnQwmJwtTjnxjUsABzguzMsAFvsvsACMVc8vBvMwZPHvohM xoqcyD/Mw5Qnq6wbAQLzu04ju0+suFQcBo8rBoBMu1y7uFqcxxacA7fbMxocxmJ8yKq8yo8MyX2F uC2gL1FjA3NMyJpswAZsa88/K8ikrMJ/DDFzyLm3W8iGzMrG3MrIusQjqsAj+pwrLJi4JgS3kskC 2m25lrzHDAZrfHDKvG48KwDwq8PgxszYnLaz1s3oVsBVa7zIa2zkbM7y9s6oDM/0jHGfW8/4XLfb nM/8/LU1gbH9HNDLRgYQkBACfdDI9gAF3XYI3dDCVtAcB9AOPdGzRgZgMHgUndG0hhBD0Ar7rNHc 2gKP8JwSkHUgTdEuMAASsJdkwKG7eNL17BZ/INHJawRIsAU4ndM6vdM83dM+nQVl8AViEAQAOw== ------=_NextPart_000_000D_01C5B882.F46C6190 Content-Type: image/gif; name="ban_le.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c5b861$6d5877a0$306d81d4@sanya> Content-Transfer-Encoding: base64 R0lGODlh4QB1ANUAAAJnn7u7u+3t7fy6RPzHa/bdr9PT0+Dg4PDw8P3jr/+mA6rF1PmjKv705+np 6eTk5PWcJ8rKyvzZmdzd3ZO4zdnZ2f3s0lWVufrlwf3ViP21NPO0YHurxf/68/nNf/Ly8vqrNzeF sP/8+PvBWqurq8za4fzfnPj4+P7x3vmXH/Ps4f/+/OW4iL7Q2/X19d3k6PfSk+rJpf747vPn0+/E f//////9++iiTPv7+9DX2/779vPavP///v+xIv7+/v/+/SH5BAAAAAAALAAAAADhAHUAAAb/wJpQ 6EM8JoakcslsOp/QqHRKrVqv2KwWO3kgfMOw8DQ5OASftHrNbrvf8Lh8Tq/b7/i8Hi9wHCYnYjU+ AhVobwiJiQJ9fQ4OD5EPB5SUE5eYFZiZm52Xf5aVopSTkqanko8Pqo+trq2MsbKzsoq2tnu5unyG YpEIcLexrqYHk3+eFcoTys3MnpugZdKjlaWo2JDa26+wtN+xt+K75OWIkUMIB3HCja2nlp3N8/Sa 9p7S09XV19iorKu6vQIHThwucwgTHkAwqAIwN+KGvSuGjFm9ixef4SszTd8+a5KM+VtFUuBAgrMM HkzIUheCCkXWQWx3hlikeJnoGcA4zyI0/46ggn40RrTfSIAmH6FMqfJhy6d7Fq6aaUvixGMV6+3c Om9nPY3RPA7dd9NotpJJzyxl1NQp1Ld2IDlsE9HdxEqbLnr1ytNZp6Bix4oqJXJkJFZp1wpoCrex nZcG6NJ01GKBZcs5cupUxrcvWEyUFoQYPXoo1sEiC5/dFlCgYsaOY7NLsqauXQchAOjWvUBzs859 NX0GemDBbt2nSSk/1k81yVSHW5tUvFilLhgFZO+incZ2TVW5j1O4ZG8zz+GgRxk/bmz97mKGj6JN +tq6rgEetOvi7p0Y7uMA9FZecM4IF9Y+E7iHXHEAxvcPdPPRV59Bu2CnXy5J9PedJOHtNv8egcug R9xHzJmiIAAOQgjJfNK5thZsF8aYRoZVMfKdKhwC2JtF9eQQAQcXjHYBBzsiYRkFlimXw2WWceCk k5VxoOMCObTwJJEPUBAkBZBMQAEHpIUwZAvTKUWLBxqMsAN2ihTggQcqJPJBATDMMMIABKighgpv ZqeGBzN4MEAaBeiZhgoweCCBjHLQuIhVVz3QoW4f8rhMBRcAuNsFORyQA4AUSCLlbpMCMKqmpiro 5G4cZIkqqS900wgtBChApwY9eJAIDAp4MIIChnrQgwYS7JAmMCqk6UGvaiiggQb5fWDroRrg1wMB bjG6Bo3fbGhKqUU+I1ypmrbwQKas5uj/IYCnakrkcejqxgEFr8Lryqy0OKCABIwU0CsCKvRQQCID jJDGsjOkIYECBw86pwIJS+twGtN+IOwHCGCgAAbaupEEODZ9C+pP7QIwGoAhuHpcl8eFcGLJx737 KpAok+vIUv6G86+/isDQQ8Nq+JsGfmr0AAPFizbrJ9FpQNtxGx/nG7K6u4WLzKfH9XbEpFwCSCa9 m574SMmtnBhzmCFwKQDYVb+IZnUI4IeAoHIKbfHEdlf8AdN6S+vnvt1hEPHTakQNKUAhgVsBNROU fGW8AFzgQLscTH5cZQCOnfkjZpuc9iwOtEABuCgpQrcici87wOoaMHx30K47u/oAzPq9/0bFCuxA OByG2/jKc1Tztg/Mr6bcQssvdBiCA2ILQPYZJ4ZQwnclgElu2wWZPoAtqWtQwPffA01o7B6AX0DE fePu5+5QGwB6N9FFAu40hBH/6iqTHs/qCyf2UXIsL1OKA9hWrwAhgCm3OB3B8iMoNzRwfBRb3+0k qD72ecx9NnIE/FYkKR2ZpWRMCuECINEuyLVAAP1zHoAAqCO1mC0Eq8oaLQwiLFvk6nUYw4DDHviw CKqBAEezndLS0IOkfQAGBLDgB3p3I/jJD0BDutKTAFSCgFTmMtNzQAmKB70VqvA4L2DEiRYQi5Kd cG06+gBbmuKvOAGMWXY7Yg+AwUO7Mf/tA0bz4RA/MIIkpmEEBrNg727WRFdcT1MnI9UEHPACUNXk ehxYTP8QALO0jdFGkANAGJOno7bYMJDLitYN9wZKvLnOZ3ryF/oo6Cde6WkGgBMkBkF3uEccEmUE 1E2plheLXOqmBGIE0AGJxwH9Ve2AX4QXqlrgSTlp7Fl3itYzhxUsU6rhV7QLohD1+IFa0S5aslzL jQRwy5YNsIAAOCMjGomyRRhTN4lwAKpkdswDshOdBvTkngrAsTvOiWN0cMEMCmUHgZ5PiTOapTht iU+T9UE0qJIcLTLJAUWcSBElCFLM3hkgjCXihSWYVAjQABsdGkoFfUOofhz1KILU5Db/rnGFlZ60 gBcgE4HNxMUBFdGdtqRhAU96gRpyKqfu9GAAEpDACDSgUkaxVBHUsYs7CNKOcBD1qkQdKlazpQIC rA5OTZXRU2sU1bLWYqtoTatPw9rUsUbkUTc1q1XVSte68pStYaVNWrM3Q7v6tZk9HQde8apXtS7m rHH9q2IpxIZbDPax/FmsZBlLFbfAqLFFfexguYOx2kwWqx51rEsyq9nS8i4y7PisPmtj2tbGhrNz UK1gXUtb2cCWDrK9a213C5fb4hatktEtb4f7Ft/+FrQQIa5ye2sAQTjXuT6IrnSnS93oPve62M2u drfL3e5697vgDa94w5CE8Zr3vOhN/69618ve9Za3vfCNr3znS9/5vre++M2vfveL3/vy978ADrCA sevfARv4wAi2b3MTzOAGO1i8BX6whCdM4QhT+MIYNrCFM8zhDvd3wR6ecAUiYAAwhPjDJ5awD5Tx gBSj2MUOZjGM6bvhGe8XEgaIQAQWN4EImOG8J8ixjod83gcMecgt1m6Qj6xj7tbYxvUVgI6TEJid MCS8OMixWMzrABKP4srYzXIEtrzdJ0NZvl02QGBGMQEXgHfFY67GeBHg5S9nF86BcTKIz5zfE9RZ MMYA7wF2vA/xuuDPogDzcwe9ODmXec98pq8PujwKNwtBHaMIRHeN3GhHf3fJa1a0IP84/RE9/1cE DbBAAla9agxgwAIokIEOKHwAA4hCAGIQywc2jehRgFfMa17IdY1s61I/Wr88WIEFTMBsZmeg2c1O wAwaMOsHM2MwOAgD3BKhae1KudgPEICnu6tlSmA60c/9NinE7etj45cHDSiACTJAbw/Q2wQSkDe0 z9cAH/CgwQ/otCUq8ABLh/fQxT4ADl7S7u72eBq4Tri5nYvwSixc4AcwNX2TbQEY0DsD9qZ3Upmd AJKX3ASvrnaCXSDxSlQgCQX/tI4rEQgHtNy7jKaEA4TgY3SLwc89P0DNb+7u+a4AAwTwAAGW/vFn SyDarF61CaR9gn8nODnVsDJ3l1z/iV3X4AFE3y6xSWHioE88DFynhNfB3vDsmtm8PPAB0vs4gpB/ XAIZ8HhSox71GWSbwVivRhm0C+yzfz3s2U0zKf5eA7MLewiFf/zh205gSLfXAjQgwJ0K9qam5z2p Eig5qzHQ6hmYOMEI6HGOV0/i1qvZ7QGYcsaH0OMpk/j013VBAAKweoPXIPas3/kQDBB7L4eh9q7H /XXfLt4VnEDpBKjW6vpod73DwOSjT4CrVeDgH7igx7sPv/gD4HtBjH/3JEh/+s9PggBg1wHtF7/6 1z/+9E/g9+yfP/vdX3n5/qAAfTQ7s9NHngcDI8d3rtZq3dZg0VVr5xcAs/dcDziB/+P3fvFHgQ/Y YhiIgW5neenlAw2QeQMogNRHb3oHddmnfTNgYCcwf+kXgTw3fh44BBs4gRFggTV4fhqYg+N3g/0H XzywAxuwVKuzAQJYMEkHcoqyd1OXgq7GeAF2gbtXAWJAfOI3g0LAgz0IhWIAf1oYfjv4hbHHhVWI heYlAzRwJyDwLEc4O0kXcqCXVAWAgBjAfQLmAw94f0LwAAEghTBofmIYezzngjfohWIYhl/og8tn huPVAEYIAmsofW1IfW9igHJoAnPYaqs2AzYwYFZYf/onfriGXdYlCAdwfoNgXREgg9p1fn9YimJw ihUoXT/YXkI4AJC4hpEogNUCAv9vaG9xiG+ZOIc7wIKJOF4VIIX8NwQRIIWM6APK+IfXlYwVWHTs JYS5CIkasIYDwIbdyHl2lwFxWAD5NocFoHz/5QA8GAEL+F2fGH5isIpXqF3R6GSoaI3q5QMsMAAM kIsMAAEQ0I/bCAGQ2I948iY04AEwsJAGaInfg2B0toEG0I7uqIxh4APyGH7PWI9lZpH4qF4sUJAF 2Y8BCQIByQAawAAqCQJKl5D2xpALKYcM5gDgN36SN17vuHvx6Iz0aJP2WI3axXzgFZIqqZInWZQB WZIg0I8bsHS/+CYKKQHYIWGrqIgfiI53iJVByYjiFQMbkAIq2QMA+Y//eJIB2QP//QgCG7ABmecB LlmJC6mVAwaPkeZeXPlmBXADR1mU/cgAPbCUImmQBNCUSweVUBkDErZ7VlmX5yWU32UBN0CWRfmX fGmUKTCWDIAnhLl0CUkANLADcjlgtMiY6OWY3eUDHbABklmZlYmZKzmEsLl0TUkDK0iatkledwle PxADrLmXRZkCl3mUajkCsDmEI0ADJxCat2ljpnmaKKCXrdmbwcmXwwmbA7ABiLmcy9mc3WUDNACQ rsma4qmSuLiWIDAALCBq2lmX3MldIKiXwCmeSXmZYImUubgBapmd62mb7emeO6CXJ3mZRvmPwAkC 8UmdN6CWLIADyrmfLtaf3CUC/zEAAdPZmsB5oGUJkJC4AerpoHwGodwlAxNKocCZlAFZoiUKngXK ApzYoB56YiCqXcn2ATFwAxcKnmOJmQB5ozdgei8aXxLQAwqgACNABCYwpAqQAQpWXzagAhhQoyp6 oxl6oZfJAjugAsn5o+yFAgpAADygMRnAA1zqATWQARuzAvEVo9n1Aw3gahiwAywAoFQ6pxBwAzcQ AxaQpyjQiVqqXmZqATzAA924AssiA0LQK/KlptglAzPwaq82A3Bqp8G5o3XKAjGAAnkKaxbQb306 BApAO86CAv9WK6HKAwRwLUk6BMsSqDUwAD3Qqhpgdc/CA8MipD1gAaQ6Av9mAf+2iisfuV42kKnC agGQGgMscKzIGgM7AGso0KzOigIU6aE8MKSwdlQ+cKSx1gMjsALeFAasOgTDUgNHNQSuKq4bwwOt 46ULkwC0qgE/kAAK8Kpb6X+phqnDqqkqQKwWoALP+qwNgAL/yqmdSqQrwANmKgN9JASnaqoKYKjP ZaYSIK4DQK6vei01YLAKEKhcKgEWoAAJ8APoKq8dKF+o1q8me7IA2wAqu7IqK2udOq1k+q4bI6RI 2gPcKrKCYKZKKrEUS6sEIARmerEbuzAWcLGn+qvp1QEB26z/arJNy7IrKwNSO7Uy0AEuSppJiqYa ozFeGgYL61w6C64TKwTlei3/aGqm/za0CiCqNfC1IwtfPyADUDu3UCu3dku1VdsBeqsDfPqj06qk PEC0FjsENwu2+xIGqzME1eKzQKsAQrsvRFsDhTuv8GUDUtsAl3u3mbu5U6u3ntsBOhC6fDuwulqm Dbu4bdsDpqq6YgCmYrAsQiADvbICZmu6absvHZsAaIorVleL7GUDHYC3eBu8Uvu5nyu6IpC8ImAD zDuwClCtukq0MmC2RzsEyQa73sqlGUCo5zq4QSum+9KuMouzixhfIqADxpu+xiu6oau8ysu8zIum ffqpQqoBbPsrnyoDq9u7CoukSPpvCzOkJgCytYu2NbCxNcCr8eqrlNteNnC+/6ILuujLvu3rvu4L v/G7Aj/wA336t/IrBN8Kwvwrwt0VwoLwrTywVEh7Xg9swS5swRgMvyswwz+gwRvMwfMbpgdGpAms ACbQoIoqCD8Qw0RcxDYwwzZ8w0pswtKaqgemMUNKpitsXjWMxCtwxFZsxUq8xTccqF48wp2aYEz8 XEEsBjzAxWicxiD7xWwMxmHsYWUsBmrMxW1cx2P8xjCam+Blx3zMx3gcaUlwtXvcx378x4zpAzsR relVxxeLwoa8nidAcB2qXnf8yB5qBEZgyZrMXl6wYoq8yaC8dTBRA+oQyqYsaGD2CIJ8yps8aQ5w epNWAeXHyrRcAy5QAa8sCCZksBCzXMuW7ALqAAjX5QMf8AdbcMzInMzKvMzM3MxaUAZfIAZBAAA7 ------=_NextPart_000_000D_01C5B882.F46C6190 Content-Type: image/gif; name="ban_vi_soft.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c5b861$6d5ac190$306d81d4@sanya> Content-Transfer-Encoding: base64 R0lGODlh4QB1ANUAANPo+9ra2v///4+00e3t7dFNBvrTiuDg4Lu7u9PT0/+mA/PYr/7JauXl5f/y 2qnS9fDw8MvLy4zE9Onp6VGTuHW28KrF1f6yKMTg+EqM1/28RC1ttH6ryfLy8uTx/Oa3njuHse3X zPzlulKW4TN1xqqqqvLq3hdypvP4/fj4+PX19WCk5z6B0Wefv9vs+/D1/L/R20eAwfr8/vj7/T52 ufv7+/z9/v7+/wJnn+Gfe//57thyOt6NYdzl78vX3tTe5iH5BAAAAAAALAAAAADhAHUAAAb/QIFQ eIM0AomkcslsOp/QqHRKrVqv2KwWG2hAbsOwMBU4TAidtHrNbrvf8Lh8Tq/b7/i8Hk+YHAIpYgI3 BAFobxCJiQSMZxMNkJAHk5RlAZeYf5ibnJaTZZShkw0HpJGnqJCPqw0Trq+wZ4yztLWziri4e7u8 fIZikBBwubOvqKWVncrKmpefz6LRpqWpqY+trbGxtty0ud+94eKIkEMQB3HEfX3XkqR/8MvynfHQ 0dLU1NWn16vasN26fdM1rqDBAxAGBRDm5lsxV6mSzZu4qR4oUPfumdq4D1u2f68C2hpI0KBJXhAC FEHXUJ0jiJGeyUtwiSbFip7gZRT1rmfH/0j9PmoTWYtkopNIeSFs1RLXQ5iSPi2jSRWTzYn1dmpF 5u6nR3//iN4ymnTcghC9Hi1s43CdsahSlVWtedPZxa0733H1ig1sWLFky6I0sWNHAbS7UiZg65Jd O70zkUiu6wkj3lEa8+nryAqkLKKBBe/a8aHDhxAFPqDQAyHJmrZuD1iYTdtHswARBljQrRuEb9+U c2bmSUnvNI4/O4MUyyi0aDwoPhTooCJ66l2u08B++QOH9+8cOIH47r0FeRzyLF7mms/d3s18PYcE TBKPgQXP0+QowFBFAR48hMDQHdltFwsF54Fw23knWHDeMllp5V5Mp8AHX3KqyMccAc7Rof+BAfl1 sF8aKqB2nR5JGPgSJAOchx4mLZLXQozfcRJhXnsh99OF+yjnGXMd0nFfiNKptoBhBayGYgLquPUW JCecZwEm5pGHAITCEYdZV3x1CVRfQg3lCpD1haiHCtLxQJqIh+2RoiK0xFJhld+1gMl4351wAAwt cNBneBhZwAEFv4EwYxnuwMCBbzM2MAAHkHLgQ6QcWOAooQNA8sOjhVLAAQyqhLmNLAZooEEI90HA yAIGGGCCIqyawIAGDJighgmt4qeGq6UKs4AJKqSBa6on7VeAFxDst8CABDKpqi2OpOIgeSBcAsN5 dk77HSU+4OkiDidkyqKLvpGnLQ5+guf/aJTf4qCghrJMwIAC911wgQGMGECvBgq8SoAB9i6wwAUa pEEAwfqC2AEECtirsAK6HkzrBQwYBAGABexAonQ5uJlAN0/GdAC72wbAgZQBnIsDJd62iwOoNLqM w7kIghdzuy38SIsJEK+qAAME8LwsAbRyqO+rHSygQBqlpqE00goUvHAHEAcLsDAiKCACs3mYoGYO r0JgGNIH/JdsHklwA0tEB5xM3gAH1OydgimfN4nKJ4BAsncc/LC3yyqTN2iCLXsnpi1K30IvAQMv DMHVEMzKkNILf6jdvWlAvIbmEFi+MOZ7QEBYCKjtYKuy2mUsItofx7n2Y5RcK+PIgpeh/3IpA3T6 Qystg+A2eHv+HTh4hYIwgCsqWzBfNwBzmMiH/2rgvNKJ9Or00lTr2sGHwmiuRtXZMyQC0nt8sEMi aSb93wtpGCZ2sM3W8npEpPSuMgx/3I7KIz9YQOfccgPXmG42PN8c7yEwyJ2UxDKBXi0CevoylQYu oABVNY06lKMawUxFr8xpL3seVAPX5oCmHYCNACZcmAkKwJ8GqC4NPMiYxvCQNtcZ4zE9udnv3DUK lZ1iAC0oHLV614jkMegHY5rApPQGOMBA7nlAA5jABLa1Dlgvadij1xTH170FwC97wQKfHj4QoMP4 hwfacV8HDHOrHORgAqwrhmPkdIwAyP+MA5LwYQN+IERyEZERRhQcLW7WLgswx4GqgqAGBsSQWZEo g95zXAi/p6tI4kFsH4BAsCDwQgLEsAOebFMvatiIOd4wFQE8D6ggoTJXFO4EnurdDnHgA0b8b2YL BCS5+iSlZzVnLNW7gPMgQLHHXUANIpDaFSFZxQ4w4GFepGSwLqA9A1TMDoVBTAdYqKT9CKNIX/SY /BxhysdMgJBza0crD3AeCqxjbyDAW7qklEsCzBIGHCIgMB3ytETwzAAQyKAVj/k4qakgg54jJjQ3 pytaqcGhdojhf0wQSrQkS2MEQE3HRtk6+T1lfhP4G98+0krZ1YkRNwMBAfroouQ9K5X/PSBADwpn AVUZRREUM9riOnAvYdBKGMvEHsBs1U8wStOKCkCD0EYYB+mwMAQcS0NqNvlCXpAyIC+R0y294wNY tDKkhCOXTFlKHpN6x5CJmGXeRFrTmy4ia/aaFYggAFd72cqZBs1g5KLWwUn6dV78uuYdRLcfjcXQ hGhUQ2HCcVWi/CNwIBCKymzZLnhyqAccINkJFmUuVTrPb98SnltxYYIFbA2iHXiBaesgul+FUw6l vesecnC+pOXgA4fQTwFy67EmYTWJBPgbBwAyWZmmcrMuVYQPLAADTbYsuaqywN9AAIPe3dRxybTV C4RmJpRY9EgLc94aSshYZ/nWsaUk/+eGfhAptA6EUhwYgAog0APNbtIoBBAUpH4gwtHqgpgaENgE 2dfdXfwnBDsQkBt48IEPbNSq5oXNhiZclEXU55Yz2lsL/MsQDpdJVqZyVYETY74AMVUFhUksR0fr vF9SeCQeTsRMZXaCH8T4xopAxIh7sQg4qOC12FkMjn1ZYRgPWRgQmEALROqu5h45x44Dx46nbBLX PJlD3ljEPp/MkN1EagD81c6QGQNlKpt5HAXispo5PDXq/JgNJYmylMl85jqjeTHaec2anyznMofu KHYOtGiyM4w9xxjOgk60ot9A6DkY2q2LjrSk29BoOjy6TJPO9KIrbWkckxnQmg71pv/xfMkb61jU qFZ0EgTBalbf4NWwjrWsX93qWtv61rjOta53zete+/rXwA7DqoNN7GIb+9jITraykT3sZTv72dCO trSh3expW/va2M72tKut7W57+9vgrjW3w03ucpub2gk4t7rXze5gj7vd8I53vN8t73rbO9z0vre+ 973tdPP73wCPdr4Dju8I+JvgAj84ws99iQYsPOEPP/cNGm5sAjQgAhjHeCmCnYIGJCDjEehCIKw9 8IhP+xEfD/kfImAGX6vg40kQBU0I4OsDYJwmoZBMDVh9cZD7HOQJuXXJTf5sAtwc5zJfyK4hYHDL RGMCu67Bx50uigCoQBAHSMBlRm7/66ETXdkTaPpWrJ7rFGgcL0HHNW6ofg8biCHmeOG6uBX+dWmb XeuXcbjaWZ73XBud7fdIuxBUHndce73uxr64KK4uhHOIQu6srgHhJzGBndvAD6Jw+62RsHghEOAe YVDB5LUCeVYfHvHEznooaB4Gp3fg1kwPhd6FUAOna77WNxg944WgF0rc3uihgLq76Y56Z+tkFDsf wjATUXoxTADvkxC8APg+ClybXRTOd3ryBaB6Ski/16cv/q+PUPUu7J7XNQADq1WAm1C8HvbUb3kY PJ75IXCeEh0HeRd2Hf5n32AGLgAAAOABMlBvL3cPSBABDXB+wIYbGIcRrAd70Ldx/0Nwd7IXBqOX dRN4Cd9nesSnbSjgAhgggAKIAR6AAvLWe/dAEx2oaxNHdbdna7TGainwcaKQdpK3HmQndB94bTMA ACMIAC4QgAEIhB4wA/Gmggh4AMHmDNEQgb7GdPFXCr83hRJieD1odyJIggJIhEMoghjgAkjYbilh cGYIc2cYAMB2c2dohs13azdwAAiAAGz4cecnh20ofOyHhh8HhR4IgmDIhUL4hUNIghiAAT2Agu2m AnI4h474iAjAgLt2A6IHiVfSaymAACVQApYofTqBKOonAJkIiVkoBP0XbAB4iIJIiB7gAq1YhECI ATAAAGMIb1lniQjAhLa2ibxYAv9QOIqPWIqC0ACaaIkR8Ia2Zow8aG0z4AGqyIVf6AHSOI1fWIKH +AAP0AMF+G0p0IubqItDEAGkeGuWKHxDoIy6lgCbaImz12oEQBOQh45zJ22pGITQOITTmI+vCIuH iAHYCACK2G2c+IhqKGzjmIyQGAFh0I0HiWsRsI6PGAGSaIreWAIF2XgD6YjCeIq6loqCOIiuqI/6 WI3W2I/Y2AO1iG24eJETUIyOCI6tFgCW6G8E4JKOqHcP2YsKGY4Z+ZK21gE9OYcF2ZJBCZN/uGwh +IwkGI0iOZIkWZIm+QAAsI3XlgC46I2Q6IeCUANBOYe8mJA7l3sNqY5dqYkVWQL/74eLZgmRj7h9 rcaRtVaP/WiPAriPIUmIhAiVUemPD2AB2UiVdqeWarmTmyeY7BiOB9mNZSmYjKcChmmJRnmUxmYD L4CN2MiXEvAA1ziX/QiVQmiNlnmND5CZlmkBEmABKRltxPiYcxgBbol7Vsma7fiQwSgEB7CYjDkE LcmauZhrcMlqoxmcEjCcFVABxDmaw2mZ2Eial9mPzOmPpJmcozkAAwADoShtTPeYCZAC11mYghkB 0ieOtSkA6sibj3h+2fmd7dh1wjiJA2CcxRmfFbAC81kBD1CcyJmZw7mfyrmfxXmc09mXAyAB1BmD 00YK4vmICAFst6igWimWtXkD/+VpnnMoiYWQoHRYCt3JnskmASvwoSD6oSMwAvRJnMYpAfaZnPyJ nMW5AiS6AiwwoiywAvBlARt6beLomtl2AzVgoIOQbDM4CDfKocd2A5g1AhmQpCM6ohlAn/AZn/qp olI6nyE6AiRwpVhKAjHAAS8Abo4ofsX2m6zmARaQATHAAmiqpCD6n/sppflpolQqoyxAAhuAAxuw AQPwAjYwpNPWmmBKbGIqCK/WAwMQA3RKAmn6oh8KpSfapiganyKaAXN6pxtAAxzQA3tKbpn6p8AW qK1mpBxAA3d6pSygpk4qn6hKn5GaAVd6ApV6qenHqRHnqa52AzaAWaK6AYhaqv9LuqaLGqIumqQg QAOiGgMD0ANBKqsLR6u4ZwPsJaqkqqQkqqggyqRmSqw0YKzIyqfK+m/Mins1UAPsFQM0gKjSuqTW aqbkWqnayq3dCnDfKoM8uikscKalmqT4iqYsUK53uqXb+q51F69waAM1QKiSqq/6eqWUaqn/CrAB 257O9mqbcrBZeqeW+gOw5rCIJ7CTWAMAwAGsiqX+6q4ai3Acy2u2igEDsAIzggF7SrIlq2v6EgYA owD0IgQ6wC8N4wDo9m02MAMoMI0l2AP4+AIz4KMxu2s24AAUNAQO8DMCoC8iIADz4gBMqwE9i20/ iwIvII1D2AMg6QI9QLQ94AH/EGC0m5q0uZY1NqsA6jcvOiAE9KIDNxu1ChC3znayYXADMgC0L/C3 TSmSXfu3L4ACKDADMpCsxcdXOysE89K4DEAxdRsG8zIEE2S5F5A1U2sDmvu0OqsBTGuzBiAE+sJX DICF0PZqNtC3MwC0hvu6sMu1sdu6iCsDNnC7sQamNmu1BBO1F+AAOkAxNQBYrVa5QtC7QjBBUisE WWMAT/u7T3uzcPu0BnAD83K6yxixsna73CsDrEu74Fu73Jux3Ro1YKAvNUArgxC5VHu3xasAQ4C8 AqC8WsO8EEO9yYu1dusA+hK3dIu9RDptGQtr3Hu7tju+suawdau5FNS2F0C1/w/8vvGrv/N7L/Ur AM37tAuQv0KgNA5gvAJAMahbboqrtjd7A5oLtZQbwawGwvI7QUoztRh8v3VrKqSrAB/MwiKcvWrb bnWrL0wLwI7LwoIAwjZ8vBqgufYrAvg7v/oLxC4sxG8JsT3cbVFzw8Grv+zLvhI8CDMrAP9Lt6Pb vjqgwRwsAB7cv2CswgFcxeq2u1e7v8F7ulzcwvArBPg7L1MbuWV8xU18xED8tHTMxvPoxuvGuKCb vDarAXFbx0V8xx1ss/eCs58bt3/8xDhst6Y7woZ8bpNbb588xZ38xmPMbkt7s0DMyaNMbqGsbjdQ uhDjm1S8yrTcxrV8y7ymt2u4rLFJgLS7/MtiYAPwCMzE3Gpk0ABaWczEbAQWp8zOPAheMHHI+Myr TAZgcA7UTMwLynsTALPZXLI38Ah7OwE7+M2dzH7dLAhkgBATac7vOl9/gIxFcARbUM/2fM/4nM/6 vM9aUAZfIAZBAAA7 ------=_NextPart_000_000D_01C5B882.F46C6190 Content-Type: image/gif; name="ban_vici.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c5b861$6d5ac190$306d81d4@sanya> Content-Transfer-Encoding: base64 R0lGODlh4QB1ANUAAJHH9AJnn+Dg4P///+zs7Gijz7q6u/y3Tf3sztHn+oOy0Nvb20OMtf3Uiv7K bP+zKNPT0//y377d9+/v7/7ktsrKyv+mAvzanrKXbv/47ix/rdHCp+Tx/PLy8sGVVf/8+Pm+Xvn4 +MqOP6uppzRvvtKqaVlwiPT4/e/ew+usTsHU3trs+/aqQvX19aGBWfD2/EB/zPz9/vnv4Pj7/ujF iejo6U+S3uOeQPn28/Hn1/v7+tLe5fz06eTk5KzI2d7PuiH5BAAAAAAALAAAAADhAHUAAAb/wIFw 2OktIMikcslsOp/QqHRKrVqv2Ox10esMv8PQQlCbdM7otHrNbrvf8Lh8Tq/b73j7pCZYhMBCNQtm bhOGhgSJiTU1PY49ApGRYwuVlpeYmZSTkp2SkI+hoo+MpaanjAQ1iqysh6+wsXmztHUECwRgjnCw rKWhApCTmsSafZt9nsqRoKPOv6inqq2tsdawtdnabY5DEwK8r76MopKUxeiXyWPJy8rNzqPk0aXT q9SJ1/rb/P0CE0IGFeql6BewYekSWlrXjpO7TsDiOZpHb9U9fAT0XevHsdaEBTG+DRRX0KCwY5og HDmiUqVChg0fMgtGUyKpRhUtYsyoEVvH/595/vWo0SbWOHKOzGFq2ZJlJZcJY8p0lxRePIrRpu3s +QqoVzuNBK4xWhKpUmJN0yqs5HDqQ1DBbA7NaQ8jV0Nf8875CIENWQICfAgeDEFpBR8KDCT2oYFB Yw0pix1z6+kkxLhxr86lt0OBZwU+qN0l1KGGggIMUhdQsEONitSw7Xz27KMFatgKcHREouZvIgEB ggtXgFCD8OAFjgdY+TSd1MuVZwqDl3liqEabT71WHkBD6HyjSyfnHpyBijMtfCiv04LBcQUd3A// yRvNX4s1xgvXgHKBcg0GKOccW+y4ZVVEcj2TXSkqkDcceFx1oIJxDg6nm3rH2SFfcPBtGP8AfLv1 dYZv+CnAHUomHreagOg8d1lVCcY41IwzokKAh+T1cFcHe1BYoXC1YSichu/FV2SIPBK0yCI4ceeD JfoFZ8BLyLxVnYwSYYfTlvQotwMBUcK3Y5TCOcadBtl4CKJeSPjGJHY5kFmAJT52t0AFBeSZJyaI pdYYA6txMRMEt63Ww2erqeDZaj4cmpoCjizgGWyPqpBTPcdpoIqQH+5Yw5k1tIBDisf50NlsaRAw KaUKnHeGmqPO5oN9feLW2h1tklSQKkj1wGkADFRSgXIFQPArWxDgqBykjpBaZp2cnjbcoT8ysMOl N5baQ50KRNiBs8ERgEYL4IK23hngKsf/AFFqGjmfhHUex4C4deQ6AT74ARNvJeD6AEGAxyUTL3kq UPtjcJx6WMCv5BVgo04ENLgfdzv0hIacapg2m7kZdsAwdwW4y6HIH3ZAwMEM2GEvImVhFwqZxHkI 2QK/RsKwme/5dzDCFSqAY2PcDcWrTheR+R5PG6GBY25v4CDxkCR3p+wE7bbrrHfg3jrHykeZBMnT yPVArADGKheJz5Tu4EidDJQbWLwfc0hp24386gPRrQhg9HAWp4HjrHD82gEOcyvQwgR2V/0e4Zm2 hthnWsuRayv49ZqUADIDLFwFNpt90iOBkZlapkL3S15jCuSgnQJwQ9zKwMfVAHYAreGl/8bfur0h +BotKAq34vMpq8HCXeAKATX0lFNuppP8Gsppypbp4bqr2P3ftdMoijN53+GT7n/cHsLG0mv4oMJg 55/bQWfbOwk8h+n9WEDkkh+P/Ck0gqKzgwoI6nwPO4CdumQ2Deu9pwfT+J6TRGMIYk1gb+UhDRtE l7sz/Mo751KgcnzwvpJ962AqaAEdkIC8oUFDFNELTsEg8atGKKttbCPTl/KzwQ0qgmHD61dGIIQ4 5ehoAgqknxpGxR1XDQ5HC1POBGbXnRWVqoNrYp+DUjZCCNyrhKjIX9w0EIoWAkdehqgB2y4orRqW ShFkUkEi+nWNX4kpgNwxHBw+VcT1Gf/NfOtJYwvItUEo8k5R6qpgHNpEOcpl0RH8Q4rzZleANaqr Bik0I5DygSMdbWuD16CjvASoAaI0TYPcSdmvGBc7k/2uSGragXJc5Swqbs2KO2nZKfZmqVK0UJP7 Gdi8Lnkwux0iXdHzgT4ieTpPvkGA/yFA/DIETO75cWkwq5cVDxFLE5IDh6f4VUYg+B9DGGw4HvKl IVS5swAI0xrrO1i8OjlHbpaHKMscEjl3xkFUvqd36jRm/XQVy8oRIF4KyKZyfqMsjk0SL+dzVTgx eYibbWc/SdtB9Bz2T3XFAXHR04AcLXium0k0U36UUAodprJpKikfJXyTNFyniHuN8zP/s7KGqjbm TR9pABs4fRxrRiQ+dKrhVJ4JoTZ8NRsjwkGEOhWiHUS4A52CpgzGSxJXqnmRWJ6Uh6+QE+tUhLTR eGsk/SDEHvXCC23wxqv8rKYr0JokXlYocrbjUZLSQIi4doWseM3rGurDU7Resass86tPzkBD8phH hHpNrGK3wdfeCPaxdy0KDnDg1J0u9rKYzUNjRwLZHdHBDGZAbGZHS9o3bDYcnb1rXEvL2tbW4rRy qKtsv+ra2tp2FrD1CF52K8Hb+va3gxQRcIdL3MvmtrjITS5Hjqvc5joXD8x9rnSn6wYkAOK62M2u drfL3e5697vgDa94x0ve8l7XuuZN/69618ve9rr3veJFL3znS9/62ve+7JUvfvfL3/76F776/a+A B0zgAn8hwAZOsIIX7F4EM/jBEI7wdh0s4Qpb+MEUvrCGN/zfDHP4wyCer4dDLOA7QYDEHT4xihes kh6suL8jfvF+K+FiGV+XDxXIcQUg0IM/jDfGNoZvIyCQY0pwrgbfFYCOl8xkJvuYu02OcgUWcN0J EBkJnTiCAH6s4iDvlwA5RkKBJKESgHDXRQ/RQXd1wDm3IFkXOx6zMtQMXiB7Wb012LFbFtCCMxeG MpGg83bBTJk3DyHPf5ZJjb9r5zuXNwR6psyis4tmdwhauz1ItEwMPQBIa1omuWB0l/8dPd88e6LP QuiAMp6MXbIBOtDd1bKbv6BkT5g5BJaJBKsnPOr9zoADCUgAB2LAYVdLItRDkLMXtFtpZXBauyrp xK6vy+Yxm1kIIVDGtbnbaPWeYAUSCLa4OXACDcekB5fOSBqm/V1VQ4TY3K12J7pr6k7Aewi5njSv fb0Cca/g3/0O9gpmYGEjeILGqGZvDyIdjEtrtwVtjoQhiKzjUIHB2MwABAE+7fDsdnu8IQC3wBPQ b4AHXAIDl3AHPj0JJPQg4eUFs6bZjd16kznaZN7yEHAeCWQPQQefhjm0e+3eb4db3CQ3OcCDLQGU vyDCuVZGmR/N8H+AF+NTWTTPwXH/3YhHYtncJvp6ZyBypCf93xxYQdr/zfSmJ4DgD466MsZA3ju9 u84sf4iZp9wJsH/B61zv7se5++uj+xvgHEi84pcu7qb7IAH3VvBHdkz5K1eeyuElgAHCvONnc3fz l/cxoi8vBANYHgKeH8DmLZ/684qdvCfggOEPr3bF2z7xbG+74xNQbga34E4GCL7why90KI9g+AYI L9CzDPMFIN8ALYjB83UOhuMPX98ef314yZ6AcAfc5LcPP+N17/iUQ5hszzcA9bvbAesLH/PtFcDz c/F8oofA/cFvPSAGDwaje5/24Sd+Jod0TVeAggF5/3V/I7CAC7h+A1AByKd954V//wbgd+EVbRdH gQQQA/8yfBUACAJAgR2HXfwnBGRXgN13dCW3dmjHgkp3cihYgAUIAD5gfvxFgfAnBB0ofBIICAaA fx8YXgzIgAbAahVAgV4gf8gndBAAhKJGXhygAgAggwAwhU03hSlYgP3mdt63hRKgAhWwATQghhtQ hmYYfBXQASM4X+kHfzXwg8PngNo1ATiYXUc4hEEIgchXAWbWhM8nBDpQh0PQAoIoeD2YXT5QhYpY haexiIooAVZYhVdYgDsghjTgAA7QAJqoiRfQiRRAASgQiiiQAznAA5EHYOk3hBS4bRNGgdg3BHrI g4GQfj+4gNMHi/U3ixRYfNk3Xv8xAAAKAIwAUADDCAA2UIzC6IjKKAEbAAIggImZuIkN0IkX8Imf iADYmAPYOIoW2F4hQIu0GITdFQOxKHzdiIvD12U7CI7CVwGC1gG0SITDl4NhR16nUQA2kI96ko/H WIXEyIjKCADN6IzPiImbSI3WSAHYiI0RkI0IQIprmF5vyI7tSHPYRYEGEJHlaHp/R5FoaIE94JFo eIGHiF0roAD8mJL8uBrF+I8BSQMEGZMG2QA0MI0JuZDYKAMLSYo4MF8TsJH1Z5HXdX9/aIcReHEU CQHs5nwU6Y4kWV4cYIwwMJUwsJJ5EpCO6AMxuZUgkAIlQAMIqZA42ZALiQIIgAL/MkBfODZ957hd NUCB4th1RwmC62h6AhCRA5Bn4FiS+8eX1xUDMaAqMEAChDmVKqknweiIIwCTW3kAKSACN3AAIKCJ YHmTOImToNiT9gWBcYlfgGlfRuCBAsCLhrheCaAAg1mYVamPxKgnLakAXNmVkCmZICCZJWCZl4kA CgmKKICX6iV8pCZifqldgKk3hFmYh6knylkCMSmZNxCZziiZjpmJNymWC2mNo3iK7jWSwfleJZhd O1AAx0kCq7mSNoCPeYIBzFmbzvic0smetOkA1WiNuqmbCXkBKKCZ3Rli35ldMdAZg2mYKpmSJrCe 75kC0omgtXkADJqJnkif93kB/zmwnyTWn8QJoFQ5oDYwlS7AnO/pmI+JoAw6oimQAmD5AwlpjZ34 AyignRRqYRa6XTFwmhtKlTZKmCbQodK5oyI6oiPKAgfgAJX5idVIjTTwAy76ohIWo9z1nyh5o+PZ oV25oD5apQzKAixwAyUwjdRIjTT5A0r6YUzaXTNwmql5nAqQAAugngpqpT6apTcApybapZ34pUka phg2nOpVpsO4GgmgA4BZAerZlW56AM+JpUCKpZApn2BJmUd6p3jKYnrqizMQe2nXfQKXeC9wfxhQ ooRqpVmaAkB6AyIApEFak44KppF6YWMKCDFQqS+Ae2w3gD3wb6owAiVQAggqov+JegBYGqdw+qs3 MJkNIKQl8IqrymCtKgSvegKxGqsBGH7P2gMjwKaieqW+mq2/+quzKaQgQAMloJ8h1gAW8AUXYAHo 2gBCkAEHgK4PEAFf8ACd+ADoCgJD4ADuSgH71aqAOQP+WqknELAC66wv8AIDewL/OgM1gAEY4AEl iqiJCrHCCqws4IwlsAGQWmEIQK9DEAEW4AADQK76iq8REAEPcABDgAAWoLIgSwEWoK7nqq/t+gH4 tayAebM3m7A6+684OwAx0H7qeQMPK7FEi6hCm6ukaWEui67lKgT4mgED8AEP4AAZ8LFCQK5QG7KT ubJCcAAPMAAP8LUDoLL6el//y+qqOJu2agsGLbABDOsBQiuqRWu0z3kDGOBz/WUB7WoB7+q07gqv DjC1LwsI+DoEXjsEYUu2QuCyFECzD1CsTTsAhzu4A1C1IBu29PoACICvFmCvY5u5YfuUEjYDBOC2 DQu3h1q3qlu3IuABP8CK/IWuCGCyKHuuEZABD2Cv+Iqy11W4QnCyhiuvFlC2LnsBY2sBWYu470q5 A2C19Kqv9AqyMQu2D/ABLiu2TxhhOlADpPgD1eoCHiACkLm6pCq+4BuKApC8eeu5WPuMTlu9T4td vgu2B0Czkiu8xGsBxtsAvDsE5HoBHquuQuC8IBuyTeuxF6C41Cu6D6YDPUCK/9qIAN7bsCLgAuJ7 webrAhvwkA+Jt/tltdY7vPTKtPCLvYTbtFLLux/gtdM7AMULtgJ8tYMbwEPwsVJbwOQqBAh8rgjw vgy8YDpAADkgAxFclqbrAkiMxBgwAiyKk6SYsfBFuYxrtV8QuPZ7wohbv137uMO7uPrrsclLrgJM wwN8uQ5Aszk8ADtsAfA6AFaMdw8WmDIwxzIQAXVMlg+JAj+wx028kDr5xzkglPNFuTw8tV/wAYGb Xb67wv17sozrxRTQANj7v19AuVXbADcswzqsvzwctYkMxwzWAXRcsqQ8u3ask6Q8yqScyjKQtPTV uTKMu1qcyG/cu5Hru5b7Af+U+7SP68Ux/Lue+8JTi8YHrL9k67gmXJoLhgMTwAMR4MyrHM3SPM2n LK4fvLIma688jLtn/Mm23LGDi68j+wAZwAN6W7VtPL9D0Mn0mgGZbMCbbLyhe70/XGA60AE8kM/6 /Mz8DM0l68//HND6bM34pbd/KwQggK4H4M61jMXrzLTGW7l7u9CSfK9My7R+y7dtPMzwrMb6+wEb y7ehC8oGFgM4wAMZkNL6XM7lrM8u/dIt3dL5TND3xbyAYL9XnGA5vV0gkMz1mGA6gAMpPdREXdQo fdQsXdRDjQOCHMW/7GWwrLIRnb0FZtIfoNRYndVajQO+6dTBqbLpGl+T+l7POvABZm3W7pzSV33V WM3WbJ3Wa03TyaqsY+1eZX3WeI3WeO3Oeg3XeX3Wcw2jdd1ef13Yhn3YZw3FgT1gZyteMYDYkA3Z i11hSKDY9vUBj/3YkR3Zjz3ZEsaBfgBhOB21mY3Zpl3anW3anl1hYqAjCkazo+2Lq11hE2BJD5bT sB21up3bvD3bBQcQoe3bwj1fYkBsqjbcyO1eVhcI+pfczk1vzyYIrvzc1P0Fv5d6YvAP013dwy1C fSCUqsYSWjDe5F3e5n3e6J3eWxB4XxAEADs= ------=_NextPart_000_000D_01C5B882.F46C6190-- From newman@yourblindbiz.com Tue Sep 13 15:18:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGIy-00026C-NQ for dnsext-archive@megatron.ietf.org; Tue, 13 Sep 2005 15:18:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07971 for ; Tue, 13 Sep 2005 15:18:54 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFGNP-00024w-Jn for dnsext-archive@ietf.org; Tue, 13 Sep 2005 15:23:33 -0400 Received: from cpc1-blac2-5-0-cust243.manc.cable.ntl.com ([81.97.38.243] helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1EFGHm-00023S-JT for dnsext-archive@ietf.org; Tue, 13 Sep 2005 15:17:43 -0400 Date: Tue, 13 Sep 2005 20:17:07 +0100 From: "Goldberg" To: Subject: save up to 7O% on the meds you need# Message-ID: <001101c5b861$74bd7900$306d81d4@sanya> MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C5B882.F46C6190" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C5B882.F46C6190 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C5B882.F46ED290" ------=_NextPart_001_000E_01C5B882.F46ED290 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
3D""
3D""
------=_NextPart_001_000E_01C5B882.F46ED290-- ------=_NextPart_000_000D_01C5B882.F46C6190 Content-Type: image/gif; name="ban_ci_soft.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c5b861$6d5877a0$306d81d4@sanya> Content-Transfer-Encoding: base64 R0lGODlh4QB1ANUAAD2Isfvs0P///9ra2vjQh/3JbPjbqANnn9FNBru7u+3t7f6yJ9PT0+Dg4P+m A/Dw8OTk5P7y3+np6aXC0srKyvy5RauPaPq8WfvlvHuqxNhyOuG5mv/58ezZx+2+b/etRvLy8vHp 3+umRuTLs//898+oa6urq/j4+M7Z37ekhb+JRdagTsfT2v/+/fX19drg5OagP+qtUO+0Wu3q5vz7 +/v6+P726tiYQPj18v/9+rXM2OGfe96NYfbw5+fn5/Hx8SH5BAAAAAAALAAAAADhAHUAAAb/QIFQ 2PpBBoykcslsOp/QqHRKrVqv2KwWO4D8WsOw8DRoSBSgtHrNbrvf8Lh8Tq/b7/i8Hq+QNAYnYgIt CgNocA+JiQqMZxI+EJEQDZSVZQOYmX+ZnJ2XlGWVopSTkqankj6qqz4Srq+wZ4yztLWziri4e7u8 d4UKYpE/cbmzr5CSDZOgns3Nm5ig0qPUpajXrKuxsbbdtLngveLjbkYQQw8NcsV9fY+n0pfO851/ 9vfU1crX2Nnb3N66gdNFrmDBBg8GDXiAiJ27R8giWaJHsd6nUKHy5TO1j5+/f68C2hpI0KDJXQ8G tEjXEFejh6ok2pvHAFPNipxmTtMoqpSy/478IGRrBVJkLZKJTirdhRCChDfgjB1DNrFZzauZblLU ybPrvp9BIw0FKcuoAqQMl+4a0cHFsF4SjqRlE7XdMaGiaCLJijMaRq9efYYVy4psWZFI1e4JoUED gg7jUjJwU9eRq4hVPWHVipMr4ErLRlkDeirmx39mz5JUrEfDBhBsEYx4u+dHEroOLb+bpCMDgN8A MmTgxGAC8N99o/UWLryBjuMAepL6CVZi6YimWxFFnToxazs/RiBI80D8DnG31dS1eznShAPw48sf jum9/Hk6Q9mP32A/fNLJDGYKdtoY1t1qbBBgwHdw7IBAWj8gwAMPHdCWR3ogrBcLMhnI5/9hfACw UJyHznhGiX8H9OehgGFBwopQqhh2GGIIrlEBAQyW46AaHSDgmoUXTqahK+5w+OGRBwAwAIoW4TMK iirKxyIq2Y0VI1kHDuSGgjm6sYFs4Tn2YC9JaPjQbigc+duR9HlionRRxtfilDAOdWVRRJrlXZd0 lCehayfw8BiZDDh0JkSRdOghfQwA4CEAyzEXDSW9QSdcFxCgCAELzAnHCqe+/SZcXHUWBpF2rxBQ QQUdKEikAQQQEMIssIZwQQUFhKBICLEaMBcBAaiahgE9vMWrgkAu5SACuv7g4AiEqtaNIzEJ9WEG 0DDwIZOUoOAokgdkkKmHPqC4iqJHTqD/zXbHwKKABw4ouMACBJxBgAMFXODArAoQMK8BBixwwQM/ zLDAjfGm8YMD8+IIggMLgtDDwf4WwNoDEyKAwDDhIXAeL2V6M5UkLHyogzxLdiqch5V8C+4BKJiL oivoIqmDjLBAALEqBuArQQgOdMBIBQM/cG8HifSciKpJOxDAMA5UsAbEafj7ww8YOIBBsr2EwIMG O4RwtaAzpNEjDw/swDUdIdsyVUQopjhTM1A69+Ga86E4w8wKLPrcfDi/0rNl8c7QgQOz+PtAvxX8 0HQiNzL0A70gLBxxGlT/cGPlkztMzgOMddCjBrM+S56Pzu6ShNuwrCIJigCEllFGUEIQ/ypwDfjw gstJzjyzDotKgILKgbvib1k3SqAqrQ4svrzjSj9AdRo3Qn35wxFD/BYGYhu0gQaJfMkDbB6/5dgP Griwx+q1tH6qe48Cpmm1RL0wQc29eygB8PJJUPLdGbhZI7BkmeXN4kYzuNeqKrCA5j2gABVQRPQY tsCEYW9q2bve2uxQHrDNCmwZCoHGfiBCDahBUI1RHQNY1y7XxU0mlGDBBGY4Q/zVyTi8exT/4iMB FPUhh/IJzksc0Y4iMkJVZ1gcrvq1AIA5cWkRbBrmFAQw7jFkepjLoPd4IB5dSUhh50PfeNIQgh3s oGzrW6ExDvW2/8lHB9XJobmEB8S7+f9wh/BhxN/AlYGXGAWCtEAg0wiGi0E+oGdZVBjBEqmG6WFR HCeQjfoS4aM0zEBQIFCAoCBDDvat8R/a8UEOARARPMIHf64AYnB4BykPKcCUtLhfHQ+gg9Qw8SyM oBfjFIGBKA4SBIh8GAbSUgCHQcwtjGziWwhgMV40hpMg0Jj6QOAghnxpA9NEjxppQSTdvOIF+EvS C8b1qJm94FGOw4EOXQnLxfXBBwqwXw5rmZqe6Qp08TqkA422gERAUA3B3FzlKHfBRkbsAs0EAUJ5 kTaN8WBWm6zcDkxIvo+Nw5PtkwoszvkyD+nAlPtbFCPw10r5vNJDD6gZADIJAY8GZBH/jHiAwJYW r7PoUnMXqJrUhuWAqi0gBMDcFyMZea8egCAAEJuLHn7wJY114EsfQwA2QeCCSnZymyLxZtyQlIEe uvIBd1MlLGEJO9+saHHFiAoG5iWw6j0ga2wF6g+ExVOFFSBqFizoUO9aAXyJ42plrCQKdzA+NaTw qu5MDSy26qEJnAGWCginmkz5AMr+QLLymYBq0IKLEBigLZFz3CGhqbA3/CAAxNpgGzwLVINMdBgj 2MEGDpEGB9GWUOsJiARmoAAfYDYDKGiFAnzYWyAGsLEopexZMAsAzXIWF71sLdAMcLWrVa4OqmXQ Azg5AhNW10JhKkgSRGso3TICVMLR/8ELhGuUH4BTOBNwAQ7Iy9nvipaqkcrABOj53FwcDGAM5NzV lMqnPUiouxVyAw82YEZkajNDJLFlTCU8YQVwjCT2zbCGresCtzAkEd8lmGirm4sQQBCB1S0wOb5H Ia65oDE7yOaDSRxhmCaWwt/o74Z3zOMe9xjE1lWxQRy3tg4n5aoKs29/vQHTHNfXx1COsoaTnGEh W9kk6fkxUnB5iyZvFi1SDnOU22DfK5tZvJOhMo/7y+YBi1jMcPjuGnZs2iCf+c6EmvOcdyxiILd5 zFPmRYrxTGjFYCjOYlbEiIEMZTZkt9CQxvOh5yDmSts50pjONBsmTQdLh1nToAY1p/87XWkyyznU qNb0qEn96XKk+tWZToIgZk3rFtj61rjOta1pzete+/rXwA62sIdN7GIb+9hDkDWyl83sZjv72dCO 9rOVLe1qW/va2M72tamt7W57+9vg1ja3w03ucpv73LweN7rXze52b5sB7o63vOeNbHXT+974xre9 883vfqN73/4OuMDFDe+BG/zg2AY4wsnNAAoUfOHeVjjEv42Jc0y82xK/eLZbUHGNE9zj4X5Ewylw CQqYgdknGDkFVk4BMCDbByxnuQ+AnfKYr9zlws44yJ2tgJUnISOVqMkPjk2DhgO9AcuWgMNHMXRf F53koyi2zneedIcfnRoDcIGxBwD/9agf+wdLZ/qvuX51qT+c6tU+QdgBY/FhN6DrXi+2C9Yuiqbz +u1XRzqxp472YsN8FFoXwg+oEQhhwzzveid2zTVi91kfXiNmL7eub53vBjBAFMAIw9FBYHi6x13Y NTA643kN88tDfu9nzzYJIoABJ1LRiZ/tQAhsQAOcs9tJEKhBGM7y3cL/uuemh4ACqCH1rg9e7LMG PimG//lg8/3YLYgArGJFfQVRsfUYyH4HPhuCHtCA3UcYBSZ8EHhjg2DtJyhE88fedWCYvhKNH8L5 35/+o0ce2xwwQAGKWcxewT772RcAAiiAGCA6HdAD6OYC75cXDUd+iod+AiABC5h4/8CGd5QgAUJg cnUnCGpHfxE4gfd3bQbgAReAUP1HfU4EgAMogBEwgAXYAbpnbqGhEUIXbDUXCpwnAD4AgsFWepTg Ay6ngfAnBjdICTm4g+v3a89HbDZAACWYLybYK/6ngiwYAC1IgKITAufmA4BRBr/2dEMoBEgoCsGm dMH3fRmIfEIAhpRgd2NYCSEobS0QAB5AgghVgnhYh69HhVXoghgwAlpobj/AdQ1XiA53iDXhawyQ AD5HgVyHiBQAbC6QAAlQiOUnAIxoiBiYbIy4dJrnc4cYh9LWASQIhXcoAjdwAx4ghSqIAQN4hQEA gAYwAwnYAJR4i7hIiZcoCLlIif8m8Iu/2IsmkABoOGsSMIy4CIzBmIu/OACYKIzKKIzE6HypB205 QIp4iIcxoAI3gIcF4AEjYAB8uIKumH0GMAI40G6W14sJQIG8yI7wiIu9dozxGI/nUI/1mHPVCG2k aId4mIoykI0yUEwAGICxSIAFeY7fdgLK+IvuSAG5uI9DgI/w2HK8Ro8UmYv3mJG5aJHAtoTDdgIl UIfZuAIwkI3ZWADiWJAHmZDnmIPdhoy36IxhsIi4KJFCwJEdOY8yqZMbqZOUGInUiG0tkAAlgJIX EAMBmZQoWUwpWJDmCDAE0AC2h23sSJMRmAA96Y5iAJTyKAAU0JCRiJFA+ZNeqY//2JYDIZACR4mS MYCKIiADFSCXefiUsiiVIzACVblt7NiQuZh5vLaXQmCLuSgGYXmTv9aL7iiYAkCYXzlsIElsFDCS S1mCRBOXRGOZH3ABH6CS4Yh9sBcrG1CM2XYCQCmUxsYAPZkAhhmRv7aaXElrqlmYqLdxPcCWMpCb 2Ug0vMmZnPkBSukBsBeaG6CX3tYCPsCRFBCDW7eaYdACEImYvdYCsBlsA+CctaltDWABJRCQcikD m7mZFfABH1ABIgADMHCeMiCFsDJ9HpAAJABuDxCd8cgAJ8CYH9mLhtmTODkE1ZmftAmZ/flsOUAB 3Jmb4Xkr4omK5BkD5AkDKyCc/9NHfRuwAfh5bVxIn7fYAPGXmtg5BBpaib5GnbkYm7M2m4+Jlt1G AiZQAkqJoL5JnuN5AyIgAhUAAzSKUASwAdRXhx5pbhD5o8d5ofMWmcbmAmzZneApl+Upox9Qox9w AzDwoKvYoyVgot+mlajZd9M2oNH2ACmQAiuglOTZpGVaplP6ATi6AvxXhymAA0SabUFJmlzKbEZ6 bAqQAhawAmMKnmd6pumJo2n6jR5QAgkQp9q2a3XapeSmACbAlisgAg76p2cqAmVqqTLgASnQA/G5 qFR3p8jWAwmgp3waA2/5pFBKniKwAOiJnitQAoHoqZ/qpdVGAzOQABZgASqgAv8meZ6t+qtSegMq YAEjoACIKqsCB6rGVgM+EAIB0AEmkKu7KqUmmYrWKqzDKnswiKw7p6zERgPNGgDOGgAjEK0rsKvo mq65mgIEGAIzcKzcym/eKmy2GgLjuoLQqqe5uq8WkAIjsIICGAJ0Gq8IN6/ARgg9EAIR0IIMa4UC 2AF5mZcd4LAO24L26nsEu3AGO6I/0AML+7Egu7BW2II9ULEhu7A9kI4ZC3EbG5gn0AMeawMnO7M0 C7IpC68ZGzAO4AAX4HI9s7MEAG4tS2s00AM2cLRIK7NKW7Myu7BLa7RwurK/Fn34IgBZQwBUG7T3 ggHfNrSC0AI4gANJO7ZkW7b/ZnufUvtr9xIAYMBAAnBXNgAG8YKz9Uary1YDOMABequ3Ztu3ZosD zNl3eMUwETAId0W4LVAAC3BXQSsEdzUEbuu2g+C2bMUwAXC4FzAIAdBAbJWadgt9J7C3oju6e2sD pHu6ezuwO7ezVngwAtAzEcABAvO2UYOf8yIArisElKs1uIsvLdAzBoC7C/C6DEO3AuC1Q9ACNFAD JEACHOC8qBu90VsDxitwPGtr98IBCGW4C5C4DsABvHYvBtACudsCDES+BSAE99ICORABEINUwSu8 nkuUNNC89nu/+Pu8euu8/Ku/+Nu81RtwVUu8a7WzO9u9iquoYnAvWEu+FQC5/927uGBwL0LgvrDi NI7bvaIYbS1AAjnwvyAcwiJMAgEswI2bNVmTvoPAvopLawxMBOV7vourvg5QwfECu9w7v9fGvjnQ wz7cwx78wR/swSE8xEJMwiXsb/EiBD2zuQVgewksCOKbA5D7wEJwMOhLxRQsABbcxGAQxdlpbbaW Azz8w2Z8xmhsxkmsxJnbAtnruom7ADnQwmJwtTjnxjUsABzguzMsAFvsvsACMVc8vBvMwZPHvohM xoqcyD/Mw5Qnq6wbAQLzu04ju0+suFQcBo8rBoBMu1y7uFqcxxacA7fbMxocxmJ8yKq8yo8MyX2F uC2gL1FjA3NMyJpswAZsa88/K8ikrMJ/DDFzyLm3W8iGzMrG3MrIusQjqsAj+pwrLJi4JgS3kskC 2m25lrzHDAZrfHDKvG48KwDwq8PgxszYnLaz1s3oVsBVa7zIa2zkbM7y9s6oDM/0jHGfW8/4XLfb nM/8/LU1gbH9HNDLRgYQkBACfdDI9gAF3XYI3dDCVtAcB9AOPdGzRgZgMHgUndG0hhBD0Ar7rNHc 2gKP8JwSkHUgTdEuMAASsJdkwKG7eNL17BZ/INHJawRIsAU4ndM6vdM83dM+nQVl8AViEAQAOw== ------=_NextPart_000_000D_01C5B882.F46C6190 Content-Type: image/gif; name="ban_le.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c5b861$6d5877a0$306d81d4@sanya> Content-Transfer-Encoding: base64 R0lGODlh4QB1ANUAAAJnn7u7u+3t7fy6RPzHa/bdr9PT0+Dg4PDw8P3jr/+mA6rF1PmjKv705+np 6eTk5PWcJ8rKyvzZmdzd3ZO4zdnZ2f3s0lWVufrlwf3ViP21NPO0YHurxf/68/nNf/Ly8vqrNzeF sP/8+PvBWqurq8za4fzfnPj4+P7x3vmXH/Ps4f/+/OW4iL7Q2/X19d3k6PfSk+rJpf747vPn0+/E f//////9++iiTPv7+9DX2/779vPavP///v+xIv7+/v/+/SH5BAAAAAAALAAAAADhAHUAAAb/wJpQ 6EM8JoakcslsOp/QqHRKrVqv2KwWO3kgfMOw8DQ5OASftHrNbrvf8Lh8Tq/b7/i8Hi9wHCYnYjU+ AhVobwiJiQJ9fQ4OD5EPB5SUE5eYFZiZm52Xf5aVopSTkqanko8Pqo+trq2MsbKzsoq2tnu5unyG YpEIcLexrqYHk3+eFcoTys3MnpugZdKjlaWo2JDa26+wtN+xt+K75OWIkUMIB3HCja2nlp3N8/Sa 9p7S09XV19iorKu6vQIHThwucwgTHkAwqAIwN+KGvSuGjFm9ixef4SszTd8+a5KM+VtFUuBAgrMM HkzIUheCCkXWQWx3hlikeJnoGcA4zyI0/46ggn40RrTfSIAmH6FMqfJhy6d7Fq6aaUvixGMV6+3c Om9nPY3RPA7dd9NotpJJzyxl1NQp1Ld2IDlsE9HdxEqbLnr1ytNZp6Bix4oqJXJkJFZp1wpoCrex nZcG6NJ01GKBZcs5cupUxrcvWEyUFoQYPXoo1sEiC5/dFlCgYsaOY7NLsqauXQchAOjWvUBzs859 NX0GemDBbt2nSSk/1k81yVSHW5tUvFilLhgFZO+incZ2TVW5j1O4ZG8zz+GgRxk/bmz97mKGj6JN +tq6rgEetOvi7p0Y7uMA9FZecM4IF9Y+E7iHXHEAxvcPdPPRV59Bu2CnXy5J9PedJOHtNv8egcug R9xHzJmiIAAOQgjJfNK5thZsF8aYRoZVMfKdKhwC2JtF9eQQAQcXjHYBBzsiYRkFlimXw2WWceCk k5VxoOMCObTwJJEPUBAkBZBMQAEHpIUwZAvTKUWLBxqMsAN2ihTggQcqJPJBATDMMMIABKighgpv ZqeGBzN4MEAaBeiZhgoweCCBjHLQuIhVVz3QoW4f8rhMBRcAuNsFORyQA4AUSCLlbpMCMKqmpiro 5G4cZIkqqS900wgtBChApwY9eJAIDAp4MIIChnrQgwYS7JAmMCqk6UGvaiiggQb5fWDroRrg1wMB bjG6Bo3fbGhKqUU+I1ypmrbwQKas5uj/IYCnakrkcejqxgEFr8Lryqy0OKCABIwU0CsCKvRQQCID jJDGsjOkIYECBw86pwIJS+twGtN+IOwHCGCgAAbaupEEODZ9C+pP7QIwGoAhuHpcl8eFcGLJx737 KpAok+vIUv6G86+/isDQQ8Nq+JsGfmr0AAPFizbrJ9FpQNtxGx/nG7K6u4WLzKfH9XbEpFwCSCa9 m574SMmtnBhzmCFwKQDYVb+IZnUI4IeAoHIKbfHEdlf8AdN6S+vnvt1hEPHTakQNKUAhgVsBNROU fGW8AFzgQLscTH5cZQCOnfkjZpuc9iwOtEABuCgpQrcici87wOoaMHx30K47u/oAzPq9/0bFCuxA OByG2/jKc1Tztg/Mr6bcQssvdBiCA2ILQPYZJ4ZQwnclgElu2wWZPoAtqWtQwPffA01o7B6AX0DE fePu5+5QGwB6N9FFAu40hBH/6iqTHs/qCyf2UXIsL1OKA9hWrwAhgCm3OB3B8iMoNzRwfBRb3+0k qD72ecx9NnIE/FYkKR2ZpWRMCuECINEuyLVAAP1zHoAAqCO1mC0Eq8oaLQwiLFvk6nUYw4DDHviw CKqBAEezndLS0IOkfQAGBLDgB3p3I/jJD0BDutKTAFSCgFTmMtNzQAmKB70VqvA4L2DEiRYQi5Kd cG06+gBbmuKvOAGMWXY7Yg+AwUO7Mf/tA0bz4RA/MIIkpmEEBrNg727WRFdcT1MnI9UEHPACUNXk ehxYTP8QALO0jdFGkANAGJOno7bYMJDLitYN9wZKvLnOZ3ryF/oo6Cde6WkGgBMkBkF3uEccEmUE 1E2plheLXOqmBGIE0AGJxwH9Ve2AX4QXqlrgSTlp7Fl3itYzhxUsU6rhV7QLohD1+IFa0S5aslzL jQRwy5YNsIAAOCMjGomyRRhTN4lwAKpkdswDshOdBvTkngrAsTvOiWN0cMEMCmUHgZ5PiTOapTht iU+T9UE0qJIcLTLJAUWcSBElCFLM3hkgjCXihSWYVAjQABsdGkoFfUOofhz1KILU5Db/rnGFlZ60 gBcgE4HNxMUBFdGdtqRhAU96gRpyKqfu9GAAEpDACDSgUkaxVBHUsYs7CNKOcBD1qkQdKlazpQIC rA5OTZXRU2sU1bLWYqtoTatPw9rUsUbkUTc1q1XVSte68pStYaVNWrM3Q7v6tZk9HQde8apXtS7m rHH9q2IpxIZbDPax/FmsZBlLFbfAqLFFfexguYOx2kwWqx51rEsyq9nS8i4y7PisPmtj2tbGhrNz UK1gXUtb2cCWDrK9a213C5fb4hatktEtb4f7Ft/+FrQQIa5ye2sAQTjXuT6IrnSnS93oPve62M2u drfL3e5697vgDa94w5CE8Zr3vOhN/69618ve9Za3vfCNr3znS9/5vre++M2vfveL3/vy978ADrCA sevfARv4wAi2b3MTzOAGO1i8BX6whCdM4QhT+MIYNrCFM8zhDvd3wR6ecAUiYAAwhPjDJ5awD5Tx gBSj2MUOZjGM6bvhGe8XEgaIQAQWN4EImOG8J8ixjod83gcMecgt1m6Qj6xj7tbYxvUVgI6TEJid MCS8OMixWMzrABKP4srYzXIEtrzdJ0NZvl02QGBGMQEXgHfFY67GeBHg5S9nF86BcTKIz5zfE9RZ MMYA7wF2vA/xuuDPogDzcwe9ODmXec98pq8PujwKNwtBHaMIRHeN3GhHf3fJa1a0IP84/RE9/1cE DbBAAla9agxgwAIokIEOKHwAA4hCAGIQywc2jehRgFfMa17IdY1s61I/Wr88WIEFTMBsZmeg2c1O wAwaMOsHM2MwOAgD3BKhae1KudgPEICnu6tlSmA60c/9NinE7etj45cHDSiACTJAbw/Q2wQSkDe0 z9cAH/CgwQ/otCUq8ABLh/fQxT4ADl7S7u72eBq4Tri5nYvwSixc4AcwNX2TbQEY0DsD9qZ3Upmd AJKX3ASvrnaCXSDxSlQgCQX/tI4rEQgHtNy7jKaEA4TgY3SLwc89P0DNb+7u+a4AAwTwAAGW/vFn SyDarF61CaR9gn8nODnVsDJ3l1z/iV3X4AFE3y6xSWHioE88DFynhNfB3vDsmtm8PPAB0vs4gpB/ XAIZ8HhSox71GWSbwVivRhm0C+yzfz3s2U0zKf5eA7MLewiFf/zh205gSLfXAjQgwJ0K9qam5z2p Eig5qzHQ6hmYOMEI6HGOV0/i1qvZ7QGYcsaH0OMpk/j013VBAAKweoPXIPas3/kQDBB7L4eh9q7H /XXfLt4VnEDpBKjW6vpod73DwOSjT4CrVeDgH7igx7sPv/gD4HtBjH/3JEh/+s9PggBg1wHtF7/6 1z/+9E/g9+yfP/vdX3n5/qAAfTQ7s9NHngcDI8d3rtZq3dZg0VVr5xcAs/dcDziB/+P3fvFHgQ/Y YhiIgW5neenlAw2QeQMogNRHb3oHddmnfTNgYCcwf+kXgTw3fh44BBs4gRFggTV4fhqYg+N3g/0H XzywAxuwVKuzAQJYMEkHcoqyd1OXgq7GeAF2gbtXAWJAfOI3g0LAgz0IhWIAf1oYfjv4hbHHhVWI heYlAzRwJyDwLEc4O0kXcqCXVAWAgBjAfQLmAw94f0LwAAEghTBofmIYezzngjfohWIYhl/og8tn huPVAEYIAmsofW1IfW9igHJoAnPYaqs2AzYwYFZYf/onfriGXdYlCAdwfoNgXREgg9p1fn9YimJw ihUoXT/YXkI4AJC4hpEogNUCAv9vaG9xiG+ZOIc7wIKJOF4VIIX8NwQRIIWM6APK+IfXlYwVWHTs JYS5CIkasIYDwIbdyHl2lwFxWAD5NocFoHz/5QA8GAEL+F2fGH5isIpXqF3R6GSoaI3q5QMsMAAM kIsMAAEQ0I/bCAGQ2I948iY04AEwsJAGaInfg2B0toEG0I7uqIxh4APyGH7PWI9lZpH4qF4sUJAF 2Y8BCQIByQAawAAqCQJKl5D2xpALKYcM5gDgN36SN17vuHvx6Iz0aJP2WI3axXzgFZIqqZInWZQB WZIg0I8bsHS/+CYKKQHYIWGrqIgfiI53iJVByYjiFQMbkAIq2QMA+Y//eJIB2QP//QgCG7ABmecB LlmJC6mVAwaPkeZeXPlmBXADR1mU/cgAPbCUImmQBNCUSweVUBkDErZ7VlmX5yWU32UBN0CWRfmX fGmUKTCWDIAnhLl0CUkANLADcjlgtMiY6OWY3eUDHbABklmZlYmZKzmEsLl0TUkDK0iatkledwle PxADrLmXRZkCl3mUajkCsDmEI0ADJxCat2ljpnmaKKCXrdmbwcmXwwmbA7ABiLmcy9mc3WUDNACQ rsma4qmSuLiWIDAALCBq2lmX3MldIKiXwCmeSXmZYImUubgBapmd62mb7emeO6CXJ3mZRvmPwAkC 8UmdN6CWLIADyrmfLtaf3CUC/zEAAdPZmsB5oGUJkJC4AerpoHwGodwlAxNKocCZlAFZoiUKngXK ApzYoB56YiCqXcn2ATFwAxcKnmOJmQB5ozdgei8aXxLQAwqgACNABCYwpAqQAQpWXzagAhhQoyp6 oxl6oZfJAjugAsn5o+yFAgpAADygMRnAA1zqATWQARuzAvEVo9n1Aw3gahiwAywAoFQ6pxBwAzcQ AxaQpyjQiVqqXmZqATzAA924AssiA0LQK/KlptglAzPwaq82A3Bqp8G5o3XKAjGAAnkKaxbQb306 BApAO86CAv9WK6HKAwRwLUk6BMsSqDUwAD3Qqhpgdc/CA8MipD1gAaQ6Av9mAf+2iisfuV42kKnC agGQGgMscKzIGgM7AGso0KzOigIU6aE8MKSwdlQ+cKSx1gMjsALeFAasOgTDUgNHNQSuKq4bwwOt 46ULkwC0qgE/kAAK8Kpb6X+phqnDqqkqQKwWoALP+qwNgAL/yqmdSqQrwANmKgN9JASnaqoKYKjP ZaYSIK4DQK6vei01YLAKEKhcKgEWoAAJ8APoKq8dKF+o1q8me7IA2wAqu7IqK2udOq1k+q4bI6RI 2gPcKrKCYKZKKrEUS6sEIARmerEbuzAWcLGn+qvp1QEB26z/arJNy7IrKwNSO7Uy0AEuSppJiqYa ozFeGgYL61w6C64TKwTlei3/aGqm/za0CiCqNfC1IwtfPyADUDu3UCu3dku1VdsBeqsDfPqj06qk PEC0FjsENwu2+xIGqzME1eKzQKsAQrsvRFsDhTuv8GUDUtsAl3u3mbu5U6u3ntsBOhC6fDuwulqm Dbu4bdsDpqq6YgCmYrAsQiADvbICZmu6absvHZsAaIorVleL7GUDHYC3eBu8Uvu5nyu6IpC8ImAD zDuwClCtukq0MmC2RzsEyQa73sqlGUCo5zq4QSum+9KuMouzixhfIqADxpu+xiu6oau8ysu8zIum ffqpQqoBbPsrnyoDq9u7CoukSPpvCzOkJgCytYu2NbCxNcCr8eqrlNteNnC+/6ILuujLvu3rvu4L v/G7Aj/wA336t/IrBN8Kwvwrwt0VwoLwrTywVEh7Xg9swS5swRgMvyswwz+gwRvMwfMbpgdGpAms ACbQoIoqCD8Qw0RcxDYwwzZ8w0pswtKaqgemMUNKpitsXjWMxCtwxFZsxUq8xTccqF48wp2aYEz8 XEEsBjzAxWicxiD7xWwMxmHsYWUsBmrMxW1cx2P8xjCam+Blx3zMx3gcaUlwtXvcx378x4zpAzsR relVxxeLwoa8nidAcB2qXnf8yB5qBEZgyZrMXl6wYoq8yaC8dTBRA+oQyqYsaGD2CIJ8yps8aQ5w epNWAeXHyrRcAy5QAa8sCCZksBCzXMuW7ALqAAjX5QMf8AdbcMzInMzKvMzM3MxaUAZfIAZBAAA7 ------=_NextPart_000_000D_01C5B882.F46C6190 Content-Type: image/gif; name="ban_vi_soft.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c5b861$6d5ac190$306d81d4@sanya> Content-Transfer-Encoding: base64 R0lGODlh4QB1ANUAANPo+9ra2v///4+00e3t7dFNBvrTiuDg4Lu7u9PT0/+mA/PYr/7JauXl5f/y 2qnS9fDw8MvLy4zE9Onp6VGTuHW28KrF1f6yKMTg+EqM1/28RC1ttH6ryfLy8uTx/Oa3njuHse3X zPzlulKW4TN1xqqqqvLq3hdypvP4/fj4+PX19WCk5z6B0Wefv9vs+/D1/L/R20eAwfr8/vj7/T52 ufv7+/z9/v7+/wJnn+Gfe//57thyOt6NYdzl78vX3tTe5iH5BAAAAAAALAAAAADhAHUAAAb/QIFQ eIM0AomkcslsOp/QqHRKrVqv2KwWG2hAbsOwMBU4TAidtHrNbrvf8Lh8Tq/b7/i8Hk+YHAIpYgI3 BAFobxCJiQSMZxMNkJAHk5RlAZeYf5ibnJaTZZShkw0HpJGnqJCPqw0Trq+wZ4yztLWziri4e7u8 fIZikBBwubOvqKWVncrKmpefz6LRpqWpqY+trbGxtty0ud+94eKIkEMQB3HEfX3XkqR/8MvynfHQ 0dLU1NWn16vasN26fdM1rqDBAxAGBRDm5lsxV6mSzZu4qR4oUPfumdq4D1u2f68C2hpI0KBJXhAC FEHXUJ0jiJGeyUtwiSbFip7gZRT1rmfH/0j9PmoTWYtkopNIeSFs1RLXQ5iSPi2jSRWTzYn1dmpF 5u6nR3//iN4ymnTcghC9Hi1s43CdsahSlVWtedPZxa0733H1ig1sWLFky6I0sWNHAbS7UiZg65Jd O70zkUiu6wkj3lEa8+nryAqkLKKBBe/a8aHDhxAFPqDQAyHJmrZuD1iYTdtHswARBljQrRuEb9+U c2bmSUnvNI4/O4MUyyi0aDwoPhTooCJ66l2u08B++QOH9+8cOIH47r0FeRzyLF7mms/d3s18PYcE TBKPgQXP0+QowFBFAR48hMDQHdltFwsF54Fw23knWHDeMllp5V5Mp8AHX3KqyMccAc7Rof+BAfl1 sF8aKqB2nR5JGPgSJAOchx4mLZLXQozfcRJhXnsh99OF+yjnGXMd0nFfiNKptoBhBayGYgLquPUW JCecZwEm5pGHAITCEYdZV3x1CVRfQg3lCpD1haiHCtLxQJqIh+2RoiK0xFJhld+1gMl4351wAAwt cNBneBhZwAEFv4EwYxnuwMCBbzM2MAAHkHLgQ6QcWOAooQNA8sOjhVLAAQyqhLmNLAZooEEI90HA yAIGGGCCIqyawIAGDJighgmt4qeGq6UKs4AJKqSBa6on7VeAFxDst8CABDKpqi2OpOIgeSBcAsN5 dk77HSU+4OkiDidkyqKLvpGnLQ5+guf/aJTf4qCghrJMwIAC911wgQGMGECvBgq8SoAB9i6wwAUa pEEAwfqC2AEECtirsAK6HkzrBQwYBAGABexAonQ5uJlAN0/GdAC72wbAgZQBnIsDJd62iwOoNLqM w7kIghdzuy38SIsJEK+qAAME8LwsAbRyqO+rHSygQBqlpqE00goUvHAHEAcLsDAiKCACs3mYoGYO r0JgGNIH/JdsHklwA0tEB5xM3gAH1OydgimfN4nKJ4BAsncc/LC3yyqTN2iCLXsnpi1K30IvAQMv DMHVEMzKkNILf6jdvWlAvIbmEFi+MOZ7QEBYCKjtYKuy2mUsItofx7n2Y5RcK+PIgpeh/3IpA3T6 Qystg+A2eHv+HTh4hYIwgCsqWzBfNwBzmMiH/2rgvNKJ9Or00lTr2sGHwmiuRtXZMyQC0nt8sEMi aSb93wtpGCZ2sM3W8npEpPSuMgx/3I7KIz9YQOfccgPXmG42PN8c7yEwyJ2UxDKBXi0CevoylQYu oABVNY06lKMawUxFr8xpL3seVAPX5oCmHYCNACZcmAkKwJ8GqC4NPMiYxvCQNtcZ4zE9udnv3DUK lZ1iAC0oHLV614jkMegHY5rApPQGOMBA7nlAA5jABLa1Dlgvadij1xTH170FwC97wQKfHj4QoMP4 hwfacV8HDHOrHORgAqwrhmPkdIwAyP+MA5LwYQN+IERyEZERRhQcLW7WLgswx4GqgqAGBsSQWZEo g95zXAi/p6tI4kFsH4BAsCDwQgLEsAOebFMvatiIOd4wFQE8D6ggoTJXFO4EnurdDnHgA0b8b2YL BCS5+iSlZzVnLNW7gPMgQLHHXUANIpDaFSFZxQ4w4GFepGSwLqA9A1TMDoVBTAdYqKT9CKNIX/SY /BxhysdMgJBza0crD3AeCqxjbyDAW7qklEsCzBIGHCIgMB3ytETwzAAQyKAVj/k4qakgg54jJjQ3 pytaqcGhdojhf0wQSrQkS2MEQE3HRtk6+T1lfhP4G98+0krZ1YkRNwMBAfroouQ9K5X/PSBADwpn AVUZRREUM9riOnAvYdBKGMvEHsBs1U8wStOKCkCD0EYYB+mwMAQcS0NqNvlCXpAyIC+R0y294wNY tDKkhCOXTFlKHpN6x5CJmGXeRFrTmy4ia/aaFYggAFd72cqZBs1g5KLWwUn6dV78uuYdRLcfjcXQ hGhUQ2HCcVWi/CNwIBCKymzZLnhyqAccINkJFmUuVTrPb98SnltxYYIFbA2iHXiBaesgul+FUw6l vesecnC+pOXgA4fQTwFy67EmYTWJBPgbBwAyWZmmcrMuVYQPLAADTbYsuaqywN9AAIPe3dRxybTV C4RmJpRY9EgLc94aSshYZ/nWsaUk/+eGfhAptA6EUhwYgAog0APNbtIoBBAUpH4gwtHqgpgaENgE 2dfdXfwnBDsQkBt48IEPbNSq5oXNhiZclEXU55Yz2lsL/MsQDpdJVqZyVYETY74AMVUFhUksR0fr vF9SeCQeTsRMZXaCH8T4xopAxIh7sQg4qOC12FkMjn1ZYRgPWRgQmEALROqu5h45x44Dx46nbBLX PJlD3ljEPp/MkN1EagD81c6QGQNlKpt5HAXispo5PDXq/JgNJYmylMl85jqjeTHaec2anyznMofu KHYOtGiyM4w9xxjOgk60ot9A6DkY2q2LjrSk29BoOjy6TJPO9KIrbWkckxnQmg71pv/xfMkb61jU qFZ0EgTBalbf4NWwjrWsX93qWtv61rjOta53zete+/rXwA7DqoNN7GIb+9jITraykT3sZTv72dCO trSh3expW/va2M72tKut7W57+9vgrjW3w03ucpub2gk4t7rXze5gj7vd8I53vN8t73rbO9z0vre+ 973tdPP73wCPdr4Dju8I+JvgAj84ws99iQYsPOEPP/cNGm5sAjQgAhjHeCmCnYIGJCDjEehCIKw9 8IhP+xEfD/kfImAGX6vg40kQBU0I4OsDYJwmoZBMDVh9cZD7HOQJuXXJTf5sAtwc5zJfyK4hYHDL RGMCu67Bx50uigCoQBAHSMBlRm7/66ETXdkTaPpWrJ7rFGgcL0HHNW6ofg8biCHmeOG6uBX+dWmb XeuXcbjaWZ73XBud7fdIuxBUHndce73uxr64KK4uhHOIQu6srgHhJzGBndvAD6Jw+62RsHghEOAe YVDB5LUCeVYfHvHEznooaB4Gp3fg1kwPhd6FUAOna77WNxg944WgF0rc3uihgLq76Y56Z+tkFDsf wjATUXoxTADvkxC8APg+ClybXRTOd3ryBaB6Ski/16cv/q+PUPUu7J7XNQADq1WAm1C8HvbUb3kY PJ75IXCeEh0HeRd2Hf5n32AGLgAAAOABMlBvL3cPSBABDXB+wIYbGIcRrAd70Ldx/0Nwd7IXBqOX dRN4Cd9nesSnbSjgAhgggAKIAR6AAvLWe/dAEx2oaxNHdbdna7TGainwcaKQdpK3HmQndB94bTMA ACMIAC4QgAEIhB4wA/Gmggh4AMHmDNEQgb7GdPFXCr83hRJieD1odyJIggJIhEMoghjgAkjYbilh cGYIc2cYAMB2c2dohs13azdwAAiAAGz4cecnh20ofOyHhh8HhR4IgmDIhUL4hUNIghiAAT2Agu2m AnI4h474iAjAgLt2A6IHiVfSaymAACVQApYofTqBKOonAJkIiVkoBP0XbAB4iIJIiB7gAq1YhECI ATAAAGMIb1lniQjAhLa2ibxYAv9QOIqPWIqC0ACaaIkR8Ia2Zow8aG0z4AGqyIVf6AHSOI1fWIKH +AAP0AMF+G0p0IubqItDEAGkeGuWKHxDoIy6lgCbaImz12oEQBOQh45zJ22pGITQOITTmI+vCIuH iAHYCACK2G2c+IhqKGzjmIyQGAFh0I0HiWsRsI6PGAGSaIreWAIF2XgD6YjCeIq6loqCOIiuqI/6 WI3W2I/Y2AO1iG24eJETUIyOCI6tFgCW6G8E4JKOqHcP2YsKGY4Z+ZK21gE9OYcF2ZJBCZN/uGwh +IwkGI0iOZIkWZIm+QAAsI3XlgC46I2Q6IeCUANBOYe8mJA7l3sNqY5dqYkVWQL/74eLZgmRj7h9 rcaRtVaP/WiPAriPIUmIhAiVUemPD2AB2UiVdqeWarmTmyeY7BiOB9mNZSmYjKcChmmJRnmUxmYD L4CN2MiXEvAA1ziX/QiVQmiNlnmND5CZlmkBEmABKRltxPiYcxgBbol7Vsma7fiQwSgEB7CYjDkE LcmauZhrcMlqoxmcEjCcFVABxDmaw2mZ2Eial9mPzOmPpJmcozkAAwADoShtTPeYCZAC11mYghkB 0ieOtSkA6sibj3h+2fmd7dh1wjiJA2CcxRmfFbAC81kBD1CcyJmZw7mfyrmfxXmc09mXAyAB1BmD 00YK4vmICAFst6igWimWtXkD/+VpnnMoiYWQoHRYCt3JnskmASvwoSD6oSMwAvRJnMYpAfaZnPyJ nMW5AiS6AiwwoiywAvBlARt6beLomtl2AzVgoIOQbDM4CDfKocd2A5g1AhmQpCM6ohlAn/AZn/qp olI6nyE6AiRwpVhKAjHAAS8Abo4ofsX2m6zmARaQATHAAmiqpCD6n/sppflpolQqoyxAAhuAAxuw AQPwAjYwpNPWmmBKbGIqCK/WAwMQA3RKAmn6oh8KpSfapiganyKaAXN6pxtAAxzQA3tKbpn6p8AW qK1mpBxAA3d6pSygpk4qn6hKn5GaAVd6ApV6qenHqRHnqa52AzaAWaK6AYhaqv9LuqaLGqIumqQg QAOiGgMD0ANBKqsLR6u4ZwPsJaqkqqQkqqggyqRmSqw0YKzIyqfK+m/Mins1UAPsFQM0gKjSuqTW aqbkWqnayq3dCnDfKoM8uikscKalmqT4iqYsUK53uqXb+q51F69waAM1QKiSqq/6eqWUaqn/CrAB 257O9mqbcrBZeqeW+gOw5rCIJ7CTWAMAwAGsiqX+6q4ai3Acy2u2igEDsAIzggF7SrIlq2v6EgYA owD0IgQ6wC8N4wDo9m02MAMoMI0l2AP4+AIz4KMxu2s24AAUNAQO8DMCoC8iIADz4gBMqwE9i20/ iwIvII1D2AMg6QI9QLQ94AH/EGC0m5q0uZY1NqsA6jcvOiAE9KIDNxu1ChC3znayYXADMgC0L/C3 TSmSXfu3L4ACKDADMpCsxcdXOysE89K4DEAxdRsG8zIEE2S5F5A1U2sDmvu0OqsBTGuzBiAE+sJX DICF0PZqNtC3MwC0hvu6sMu1sdu6iCsDNnC7sQamNmu1BBO1F+AAOkAxNQBYrVa5QtC7QjBBUisE WWMAT/u7T3uzcPu0BnAD83K6yxixsna73CsDrEu74Fu73Jux3Ro1YKAvNUArgxC5VHu3xasAQ4C8 AqC8WsO8EEO9yYu1dusA+hK3dIu9RDptGQtr3Hu7tju+suawdau5FNS2F0C1/w/8vvGrv/N7L/Ur AM37tAuQv0KgNA5gvAJAMahbboqrtjd7A5oLtZQbwawGwvI7QUoztRh8v3VrKqSrAB/MwiKcvWrb bnWrL0wLwI7LwoIAwjZ8vBqgufYrAvg7v/oLxC4sxG8JsT3cbVFzw8Grv+zLvhI8CDMrAP9Lt6Pb vjqgwRwsAB7cv2CswgFcxeq2u1e7v8F7ulzcwvArBPg7L1MbuWV8xU18xED8tHTMxvPoxuvGuKCb vDarAXFbx0V8xx1ss/eCs58bt3/8xDhst6Y7woZ8bpNbb588xZ38xmPMbkt7s0DMyaNMbqGsbjdQ uhDjm1S8yrTcxrV8y7ymt2u4rLFJgLS7/MtiYAPwCMzE3Gpk0ABaWczEbAQWp8zOPAheMHHI+Myr TAZgcA7UTMwLynsTALPZXLI38Ah7OwE7+M2dzH7dLAhkgBATac7vOl9/gIxFcARbUM/2fM/4nM/6 vM9aUAZfIAZBAAA7 ------=_NextPart_000_000D_01C5B882.F46C6190 Content-Type: image/gif; name="ban_vici.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c5b861$6d5ac190$306d81d4@sanya> Content-Transfer-Encoding: base64 R0lGODlh4QB1ANUAAJHH9AJnn+Dg4P///+zs7Gijz7q6u/y3Tf3sztHn+oOy0Nvb20OMtf3Uiv7K bP+zKNPT0//y377d9+/v7/7ktsrKyv+mAvzanrKXbv/47ix/rdHCp+Tx/PLy8sGVVf/8+Pm+Xvn4 +MqOP6uppzRvvtKqaVlwiPT4/e/ew+usTsHU3trs+/aqQvX19aGBWfD2/EB/zPz9/vnv4Pj7/ujF iejo6U+S3uOeQPn28/Hn1/v7+tLe5fz06eTk5KzI2d7PuiH5BAAAAAAALAAAAADhAHUAAAb/wIFw 2OktIMikcslsOp/QqHRKrVqv2Ox10esMv8PQQlCbdM7otHrNbrvf8Lh8Tq/b73j7pCZYhMBCNQtm bhOGhgSJiTU1PY49ApGRYwuVlpeYmZSTkp2SkI+hoo+MpaanjAQ1iqysh6+wsXmztHUECwRgjnCw rKWhApCTmsSafZt9nsqRoKPOv6inqq2tsdawtdnabY5DEwK8r76MopKUxeiXyWPJy8rNzqPk0aXT q9SJ1/rb/P0CE0IGFeql6BewYekSWlrXjpO7TsDiOZpHb9U9fAT0XevHsdaEBTG+DRRX0KCwY5og HDmiUqVChg0fMgtGUyKpRhUtYsyoEVvH/595/vWo0SbWOHKOzGFq2ZJlJZcJY8p0lxRePIrRpu3s +QqoVzuNBK4xWhKpUmJN0yqs5HDqQ1DBbA7NaQ8jV0Nf8875CIENWQICfAgeDEFpBR8KDCT2oYFB Yw0pix1z6+kkxLhxr86lt0OBZwU+qN0l1KGGggIMUhdQsEONitSw7Xz27KMFatgKcHREouZvIgEB ggtXgFCD8OAFjgdY+TSd1MuVZwqDl3liqEabT71WHkBD6HyjSyfnHpyBijMtfCiv04LBcQUd3A// yRvNX4s1xgvXgHKBcg0GKOccW+y4ZVVEcj2TXSkqkDcceFx1oIJxDg6nm3rH2SFfcPBtGP8AfLv1 dYZv+CnAHUomHreagOg8d1lVCcY41IwzokKAh+T1cFcHe1BYoXC1YSichu/FV2SIPBK0yCI4ceeD JfoFZ8BLyLxVnYwSYYfTlvQotwMBUcK3Y5TCOcadBtl4CKJeSPjGJHY5kFmAJT52t0AFBeSZJyaI pdYYA6txMRMEt63Ww2erqeDZaj4cmpoCjizgGWyPqpBTPcdpoIqQH+5Yw5k1tIBDisf50NlsaRAw KaUKnHeGmqPO5oN9feLW2h1tklSQKkj1wGkADFRSgXIFQPArWxDgqBykjpBaZp2cnjbcoT8ysMOl N5baQ50KRNiBs8ERgEYL4IK23hngKsf/AFFqGjmfhHUex4C4deQ6AT74ARNvJeD6AEGAxyUTL3kq UPtjcJx6WMCv5BVgo04ENLgfdzv0hIacapg2m7kZdsAwdwW4y6HIH3ZAwMEM2GEvImVhFwqZxHkI 2QK/RsKwme/5dzDCFSqAY2PcDcWrTheR+R5PG6GBY25v4CDxkCR3p+wE7bbrrHfg3jrHykeZBMnT yPVArADGKheJz5Tu4EidDJQbWLwfc0hp24386gPRrQhg9HAWp4HjrHD82gEOcyvQwgR2V/0e4Zm2 hthnWsuRayv49ZqUADIDLFwFNpt90iOBkZlapkL3S15jCuSgnQJwQ9zKwMfVAHYAreGl/8bfur0h +BotKAq34vMpq8HCXeAKATX0lFNuppP8Gsppypbp4bqr2P3ftdMoijN53+GT7n/cHsLG0mv4oMJg 55/bQWfbOwk8h+n9WEDkkh+P/Ck0gqKzgwoI6nwPO4CdumQ2Deu9pwfT+J6TRGMIYk1gb+UhDRtE l7sz/Mo751KgcnzwvpJ962AqaAEdkIC8oUFDFNELTsEg8atGKKttbCPTl/KzwQ0qgmHD61dGIIQ4 5ehoAgqknxpGxR1XDQ5HC1POBGbXnRWVqoNrYp+DUjZCCNyrhKjIX9w0EIoWAkdehqgB2y4orRqW ShFkUkEi+nWNX4kpgNwxHBw+VcT1Gf/NfOtJYwvItUEo8k5R6qpgHNpEOcpl0RH8Q4rzZleANaqr Bik0I5DygSMdbWuD16CjvASoAaI0TYPcSdmvGBc7k/2uSGragXJc5Swqbs2KO2nZKfZmqVK0UJP7 Gdi8Lnkwux0iXdHzgT4ieTpPvkGA/yFA/DIETO75cWkwq5cVDxFLE5IDh6f4VUYg+B9DGGw4HvKl IVS5swAI0xrrO1i8OjlHbpaHKMscEjl3xkFUvqd36jRm/XQVy8oRIF4KyKZyfqMsjk0SL+dzVTgx eYibbWc/SdtB9Bz2T3XFAXHR04AcLXium0k0U36UUAodprJpKikfJXyTNFyniHuN8zP/s7KGqjbm TR9pABs4fRxrRiQ+dKrhVJ4JoTZ8NRsjwkGEOhWiHUS4A52CpgzGSxJXqnmRWJ6Uh6+QE+tUhLTR eGsk/SDEHvXCC23wxqv8rKYr0JokXlYocrbjUZLSQIi4doWseM3rGurDU7Resass86tPzkBD8phH hHpNrGK3wdfeCPaxdy0KDnDg1J0u9rKYzUNjRwLZHdHBDGZAbGZHS9o3bDYcnb1rXEvL2tbW4rRy qKtsv+ra2tp2FrD1CF52K8Hb+va3gxQRcIdL3MvmtrjITS5Hjqvc5joXD8x9rnSn6wYkAOK62M2u drfL3e5697vgDa94x0ve8l7XuuZN/69618ve9rr3veJFL3znS9/62ve+7JUvfvfL3/76F776/a+A B0zgAn8hwAZOsIIX7F4EM/jBEI7wdh0s4Qpb+MEUvrCGN/zfDHP4wyCer4dDLOA7QYDEHT4xihes kh6suL8jfvF+K+FiGV+XDxXIcQUg0IM/jDfGNoZvIyCQY0pwrgbfFYCOl8xkJvuYu02OcgUWcN0J EBkJnTiCAH6s4iDvlwA5RkKBJKESgHDXRQ/RQXd1wDm3IFkXOx6zMtQMXiB7Wb012LFbFtCCMxeG MpGg83bBTJk3DyHPf5ZJjb9r5zuXNwR6psyis4tmdwhauz1ItEwMPQBIa1omuWB0l/8dPd88e6LP QuiAMp6MXbIBOtDd1bKbv6BkT5g5BJaJBKsnPOr9zoADCUgAB2LAYVdLItRDkLMXtFtpZXBauyrp xK6vy+Yxm1kIIVDGtbnbaPWeYAUSCLa4OXACDcekB5fOSBqm/V1VQ4TY3K12J7pr6k7Aewi5njSv fb0Cca/g3/0O9gpmYGEjeILGqGZvDyIdjEtrtwVtjoQhiKzjUIHB2MwABAE+7fDsdnu8IQC3wBPQ b4AHXAIDl3AHPj0JJPQg4eUFs6bZjd16kznaZN7yEHAeCWQPQQefhjm0e+3eb4db3CQ3OcCDLQGU vyDCuVZGmR/N8H+AF+NTWTTPwXH/3YhHYtncJvp6ZyBypCf93xxYQdr/zfSmJ4DgD466MsZA3ju9 u84sf4iZp9wJsH/B61zv7se5++uj+xvgHEi84pcu7qb7IAH3VvBHdkz5K1eeyuElgAHCvONnc3fz l/cxoi8vBANYHgKeH8DmLZ/684qdvCfggOEPr3bF2z7xbG+74xNQbga34E4GCL7why90KI9g+AYI L9CzDPMFIN8ALYjB83UOhuMPX98ef314yZ6AcAfc5LcPP+N17/iUQ5hszzcA9bvbAesLH/PtFcDz c/F8oofA/cFvPSAGDwaje5/24Sd+Jod0TVeAggF5/3V/I7CAC7h+A1AByKd954V//wbgd+EVbRdH gQQQA/8yfBUACAJAgR2HXfwnBGRXgN13dCW3dmjHgkp3cihYgAUIAD5gfvxFgfAnBB0ofBIICAaA fx8YXgzIgAbAahVAgV4gf8gndBAAhKJGXhygAgAggwAwhU03hSlYgP3mdt63hRKgAhWwATQghhtQ hmYYfBXQASM4X+kHfzXwg8PngNo1ATiYXUc4hEEIgchXAWbWhM8nBDpQh0PQAoIoeD2YXT5QhYpY haexiIooAVZYhVdYgDsghjTgAA7QAJqoiRfQiRRAASgQiiiQAznAA5EHYOk3hBS4bRNGgdg3BHrI g4GQfj+4gNMHi/U3ixRYfNk3Xv8xAAAKAIwAUADDCAA2UIzC6IjKKAEbAAIggImZuIkN0IkX8Imf iADYmAPYOIoW2F4hQIu0GITdFQOxKHzdiIvD12U7CI7CVwGC1gG0SITDl4NhR16nUQA2kI96ko/H WIXEyIjKCADN6IzPiImbSI3WSAHYiI0RkI0IQIprmF5vyI7tSHPYRYEGEJHlaHp/R5FoaIE94JFo eIGHiF0roAD8mJL8uBrF+I8BSQMEGZMG2QA0MI0JuZDYKAMLSYo4MF8TsJH1Z5HXdX9/aIcReHEU CQHs5nwU6Y4kWV4cYIwwMJUwsJJ5EpCO6AMxuZUgkAIlQAMIqZA42ZALiQIIgAL/MkBfODZ957hd NUCB4th1RwmC62h6AhCRA5Bn4FiS+8eX1xUDMaAqMEAChDmVKqknweiIIwCTW3kAKSACN3AAIKCJ YHmTOImToNiT9gWBcYlfgGlfRuCBAsCLhrheCaAAg1mYVamPxKgnLakAXNmVkCmZICCZJWCZl4kA CgmKKICX6iV8pCZifqldgKk3hFmYh6knylkCMSmZNxCZziiZjpmJNymWC2mNo3iK7jWSwfleJZhd O1AAx0kCq7mSNoCPeYIBzFmbzvic0smetOkA1WiNuqmbCXkBKKCZ3Rli35ldMdAZg2mYKpmSJrCe 75kC0omgtXkADJqJnkif93kB/zmwnyTWn8QJoFQ5oDYwlS7AnO/pmI+JoAw6oimQAmD5AwlpjZ34 AyignRRqYRa6XTFwmhtKlTZKmCbQodK5oyI6oiPKAgfgAJX5idVIjTTwAy76ohIWo9z1nyh5o+PZ oV25oD5apQzKAixwAyUwjdRIjTT5A0r6YUzaXTNwmql5nAqQAAugngpqpT6apTcApybapZ34pUka phg2nOpVpsO4GgmgA4BZAerZlW56AM+JpUCKpZApn2BJmUd6p3jKYnrqizMQe2nXfQKXeC9wfxhQ ooRqpVmaAkB6AyIApEFak44KppF6YWMKCDFQqS+Ae2w3gD3wb6owAiVQAggqov+JegBYGqdw+qs3 MJkNIKQl8IqrymCtKgSvegKxGqsBGH7P2gMjwKaieqW+mq2/+quzKaQgQAMloJ8h1gAW8AUXYAHo 2gBCkAEHgK4PEAFf8ACd+ADoCgJD4ADuSgH71aqAOQP+WqknELAC66wv8AIDewL/OgM1gAEY4AEl iqiJCrHCCqws4IwlsAGQWmEIQK9DEAEW4AADQK76iq8REAEPcABDgAAWoLIgSwEWoK7nqq/t+gH4 tayAebM3m7A6+684OwAx0H7qeQMPK7FEi6hCm6ukaWEui67lKgT4mgED8AEP4AAZ8LFCQK5QG7KT ubJCcAAPMAAP8LUDoLL6el//y+qqOJu2agsGLbABDOsBQiuqRWu0z3kDGOBz/WUB7WoB7+q07gqv DjC1LwsI+DoEXjsEYUu2QuCyFECzD1CsTTsAhzu4A1C1IBu29PoACICvFmCvY5u5YfuUEjYDBOC2 DQu3h1q3qlu3IuABP8CK/IWuCGCyKHuuEZABD2Cv+Iqy11W4QnCyhiuvFlC2LnsBY2sBWYu470q5 A2C19Kqv9AqyMQu2D/ABLiu2TxhhOlADpPgD1eoCHiACkLm6pCq+4BuKApC8eeu5WPuMTlu9T4td vgu2B0Czkiu8xGsBxtsAvDsE5HoBHquuQuC8IBuyTeuxF6C41Cu6D6YDPUCK/9qIAN7bsCLgAuJ7 webrAhvwkA+Jt/tltdY7vPTKtPCLvYTbtFLLux/gtdM7AMULtgJ8tYMbwEPwsVJbwOQqBAh8rgjw vgy8YDpAADkgAxFclqbrAkiMxBgwAiyKk6SYsfBFuYxrtV8QuPZ7wohbv137uMO7uPrrsclLrgJM wwN8uQ5Aszk8ADtsAfA6AFaMdw8WmDIwxzIQAXVMlg+JAj+wx028kDr5xzkglPNFuTw8tV/wAYGb Xb67wv17sozrxRTQANj7v19AuVXbADcswzqsvzwctYkMxwzWAXRcsqQ8u3ask6Q8yqScyjKQtPTV uTKMu1qcyG/cu5Hru5b7Af+U+7SP68Ux/Lue+8JTi8YHrL9k67gmXJoLhgMTwAMR4MyrHM3SPM2n LK4fvLIma688jLtn/Mm23LGDi68j+wAZwAN6W7VtPL9D0Mn0mgGZbMCbbLyhe70/XGA60AE8kM/6 /Mz8DM0l68//HND6bM34pbd/KwQggK4H4M61jMXrzLTGW7l7u9CSfK9My7R+y7dtPMzwrMb6+wEb y7ehC8oGFgM4wAMZkNL6XM7lrM8u/dIt3dL5TND3xbyAYL9XnGA5vV0gkMz1mGA6gAMpPdREXdQo fdQsXdRDjQOCHMW/7GWwrLIRnb0FZtIfoNRYndVajQO+6dTBqbLpGl+T+l7POvABZm3W7pzSV33V WM3WbJ3Wa03TyaqsY+1eZX3WeI3WeO3Oeg3XeX3Wcw2jdd1ef13Yhn3YZw3FgT1gZyteMYDYkA3Z i11hSKDY9vUBj/3YkR3Zjz3ZEsaBfgBhOB21mY3Zpl3anW3anl1hYqAjCkazo+2Lq11hE2BJD5bT sB21up3bvD3bBQcQoe3bwj1fYkBsqjbcyO1eVhcI+pfczk1vzyYIrvzc1P0Fv5d6YvAP013dwy1C fSCUqsYSWjDe5F3e5n3e6J3eWxB4XxAEADs= ------=_NextPart_000_000D_01C5B882.F46C6190-- From owner-namedroppers@ops.ietf.org Tue Sep 13 15:57:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGuh-0004IA-TS for dnsext-archive@megatron.ietf.org; Tue, 13 Sep 2005 15:57:56 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12145 for ; Tue, 13 Sep 2005 15:57:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFGqI-000Idj-7C for namedroppers-data@psg.com; Tue, 13 Sep 2005 19:53:22 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EFGqH-000IdM-6k for namedroppers@ops.ietf.org; Tue, 13 Sep 2005 19:53:21 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7807F11444 for ; Tue, 13 Sep 2005 19:53:20 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard In-Reply-To: Your message of "Tue, 13 Sep 2005 10:44:13 +0200." References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> Date: Tue, 13 Sep 2005 19:53:20 +0000 Message-Id: <20050913195320.7807F11444@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # > With tens of millions of emails sent every minute, and where the number of # > email accounts per individual is growing, adding a sizable user-key # > component per mailbox into DNS may be deleterious to the performance of # > DNS. # # The keyword here is "may". Everything MAY happen. Without any evidence, I # don't think it is wise to add these fearful sounding phrases to the # document. i agree. doug has been very polite to me over the years, and so i didn't want to accuse him of "slinging FUD" with that passage. so, thank you :-). # > Due to the iterative query strategy, DNS largely depends upon caching in # > random access memory to meet performance expectations. Random access # > memory avoids latencies found in disk storage that have not changed # > substantially, principally due to heat dissipation limitations. # # I don't understand this. Are you saying that RAM accesses is the bottleneck # for DNS? i interpretted this as a variation on the "working set size" argument against a million-tld root zone. basically it goes like this: supposedly, a nameserver seeing N queries per unit time is implicitly benefitting from query suppression due to caching, such that names from zones served by that nameserver are being consumed N*M times, and it's considered unlikely that a given nameserver has enough headroom to respond to all N*M queries if caching weren't occuring at all. there's also end-user RTT delays to be considered -- even if the name server has enough headroom, making applications wait for a cache-miss would be an undue burden. into this quixotic morass, we're to suppose that an intermediate cache has a configured maximum working set size which is in the same order of magnitude as the actual working set, such that if we were to increase the number of names or the size of the data that was offered for caching, the overall cache hit rate would decline, thus simulating uncacheability. with my high respect and regard for doug completely intact, i have to say: all of this is just crap. from beginning to end, there is no truth to any of it. caching is already not happening for reasons unrelated to this; intermediate caches either do not have a configured maximum working set size, or it's not in the same order of magnitude as the current offered load; applications who face high end-to-end RTT toward authority servers are already seeing it; there is no NEW disincentive offered by the size or number of certificates or DNSSEC metadata. the system is NOT doing what you think it's doing, and it will NOT fall apart as a result of implementation of any proposal i have seen here. we could put a million, or ten million, names into the root zone, too, with no harm to anybody. i've said that it's safe to bet on the implementors and operators to cope with these results. that's because i consider it unsafe to bet on new alternative systems to carry data as well as DNS can already do. "crunch all you want, we'll make more." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 13 19:21:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFK5s-0003mT-9a for dnsext-archive@megatron.ietf.org; Tue, 13 Sep 2005 19:21:40 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09537 for ; Tue, 13 Sep 2005 19:21:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFK3D-0008if-Ej for namedroppers-data@psg.com; Tue, 13 Sep 2005 23:18:55 +0000 Received: from [64.142.19.5] (helo=b.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EFK3C-0008iQ-LU for namedroppers@ops.ietf.org; Tue, 13 Sep 2005 23:18:54 +0000 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j8DNIq4E031748 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 13 Sep 2005 16:18:53 -0700 In-Reply-To: References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Date: Tue, 13 Sep 2005 16:18:54 -0700 To: David Conrad X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sep 13, 2005, at 11:01 AM, David Conrad wrote: > Hi, > > On Sep 12, 2005, at 10:12 AM, Douglas Otis wrote: > >> The user-key may change the amount of information exchanged in DNS >> from a few hundred to billions of bytes per domain. >> > > The size of a particular domain in the context of caching servers > isn't particularly relevant (at least in the caching servers I'm > aware of). I agree the size of the domain is not important, but rather the amount active. This was mentioned to offer a sense of the relative change that could occur. User-keys per mailbox will create a sizable change in the amount of active data, as well as the number of records. >> This increased exchange could cause a dramatic reduction in the >> ability of DNS to adequately cache information. From a >> performance consideration perspective, the impact upon the DNS >> cache has been ignored. >> > > If you try to keep the cache the same size as today, yes, there > will be an impact (particularly in caching servers whose memory > management techniques are to crash when they aren't able to > allocate sufficient memory to cache new items. Perhaps this will > finally kill off BINDv8?). If an increase in cache requires even one or two orders of magnitude increase, there should also be equal concern about the relative amount of UDP traffic as well. TCP is relatively reactive to congestion, but will be much less effective as a buffer when the UDP traffic increases substantially. The DNS server rightfully do not care about congestion. The client gets what's requested. DNS certificates are more of an appropriate use issue than a protocol issue. > If there is wide scale deployment of this, caches in front of > mail servers (and other apps that make use of user keys) will > probably require more RAM in order to achieve the same level of > performance they have now. When these applications need keys for both reading and writing are on the desktop, this will effectively burden the entire system with few options for isolating the problem to select servers. > While I am not too concerned about this myself (perhaps due to who > pays my salary :-)), I suppose it might be prudent to do a bit of > analysis and make note of this in some sort of operational forum. > Perhaps an "Operational Considerations of User Keys in the DNS" > document in DNSOP? Why not include an analysis within this draft? This draft offers the potential for disrupting DNS. It has added enough features to justify review prior to acceptance. I have great respect for Paul, and even want to believe he may have solutions. Forgive my doubts about the infinite capacity of DNS, or that caching offers no benefit. There are hundreds of millions of corporate mailboxes, and perhaps billions of private mailboxes with messages being exchanged at tens of millions per minute. When having a certificate becomes a new paradigm for exchange, there will be a fairly flat distribution of activity at every phase of email use. This live distribution of information could be problematic as well as a wasted expense. Add in wildcards and DNSSEC, then this quadruples the related traffic that is never cached. Add to this concern possible follow-on applications as DNSSEC and DNS certificates become a new currency for user interchange. A key server using disk based caching seems like a _much_ better approach for user certificates. This is not the proper approach for DNS however. These are different problems and deserve different solutions. Look at this carefully and recommend the appropriate use for this type of record. I also think there is a cheaper alternative that uses the SSH opportunistic strategy where there is an opaque- identifier and a single domain signature. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 14 04:19:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFSUZ-0001ZZ-M5 for dnsext-archive@megatron.ietf.org; Wed, 14 Sep 2005 04:19:44 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27905 for ; Wed, 14 Sep 2005 04:19:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFSQK-000K6h-7X for namedroppers-data@psg.com; Wed, 14 Sep 2005 08:15:20 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EFSQF-000K6F-Em for namedroppers@ops.ietf.org; Wed, 14 Sep 2005 08:15:16 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j8E8F8LY014724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2005 10:15:09 +0200 From: Simon Josefsson To: Douglas Otis Cc: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050914:namedroppers@ops.ietf.org::LxW2b1pzIQoFRMz6:2abx X-Hashcash: 1:21:050914:dotis@mail-abuse.org::ZDC6ihuMMGZNmqB8:B2bn Date: Wed, 14 Sep 2005 10:15:06 +0200 In-Reply-To: (Douglas Otis's message of "Tue, 13 Sep 2005 10:04:50 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Douglas Otis writes: > When doing a comparison of the two documents, I did notice an error > unrelated to this topic. > > + The IPKIX, ISPKI and IPGP types indicate a URL which will serve the > + content that would have been in the "certificate, CRL or URL" field > + of the corresponding (PKIX, SPKI or PGP) packet types. These types > + are known as "indirect". These packet types MUST be used when the > + content is too large to fit in the CERT RR, and MAY be used at the > + implementer's discretion. They SHOULD NOT be used where the entire > + UDP packet would have fit in 512 bytes. > > In RFC1035 for UDP, a message size is limited to 512 bytes, not the > packet size as indicated in this statement. The data-gram limitation > is 576 bytes per RFC879. Thanks for spotting this. I have changed the last sentence to: They SHOULD NOT be used where the DNS message would have fit in a 512 byte UDP packet. Is that OK with you? >> I think we generally disagree. >> >> First, everyone is welcome to measure a before and after performance >> characteristic. If you do this thoroughly, and report your findings, >> it would be a valuable resource and we could reference it in this >> document. However, at this point, I see nothing more than >> speculations here. Keep in mind that RFC 2538 has already been >> published. > > > This draft is recommending multiple owner-names and discusses use of > wildcard record synthesis. This was the point I found alarming when > a method to synthesize records for every email message was described > in MASS. This was the reason I suggested there should be some advice > given in the performance considerations section. This version of the > draft very much adds to this concern. Sure. And I have no problem adding text to mention this potential problem. But I think your suggested text was biased and implied that deploying this on a wide scale would be harmful. I believe the opposite would be true. But let's try to move back to actually fixing the document... >> It is already possible to deploy this mechanism, without >> RFC 2538bis. RFC 2538bis can only be based on what we know today, not >> what we may know in a few years, so if you like to see this wide-scale >> performance estimate done, please start working on it! > > > I am not the one advocating use of this record, nor am I attempting > to embellish use of this record. In the absence of modeling or > testing at projections of possible deployment, then _some_ statement > regarding a lack of this review should be made in the performance > section. At least warn that this may cause foot damage. : ) ...right. So how about adding the following under "Performance considerations"? Deploying CERT RRs to support digitally signed e-mail change the access patterns of DNS lookups from per-domain to per-user. If digitally signed e-mail, and a key/certificate lookup based on CERT RRs, is deployed on a wide scale, this may lead to an increase of DNS load. Whether this load increase will be noticable is not known. Would that address your concerns? Feel free to adapt and modify the text, or even merge it with your proposal, then maybe we can get something we both agree on. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 14 07:02:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFV21-0003T8-V6 for dnsext-archive@megatron.ietf.org; Wed, 14 Sep 2005 07:02:28 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04248 for ; Wed, 14 Sep 2005 07:02:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFUyk-0005Qo-C8 for namedroppers-data@psg.com; Wed, 14 Sep 2005 10:59:02 +0000 Received: from [64.142.19.5] (helo=b.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EFUye-0005QC-GN for namedroppers@ops.ietf.org; Wed, 14 Sep 2005 10:58:56 +0000 Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j8EAwlXn030494 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 14 Sep 2005 03:58:49 -0700 Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard From: Douglas Otis To: Simon Josefsson Cc: namedroppers@ops.ietf.org In-Reply-To: References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> Content-Type: text/plain Date: Wed, 14 Sep 2005 03:58:47 -0700 Message-Id: <1126695527.9288.52.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2005-09-14 at 10:15 +0200, Simon Josefsson wrote: > Douglas Otis writes: > > > When doing a comparison of the two documents, I did notice an error > > unrelated to this topic. > > > > + The IPKIX, ISPKI and IPGP types indicate a URL which will serve the > > + content that would have been in the "certificate, CRL or URL" field > > + of the corresponding (PKIX, SPKI or PGP) packet types. These types > > + are known as "indirect". These packet types MUST be used when the > > + content is too large to fit in the CERT RR, and MAY be used at the > > + implementer's discretion. They SHOULD NOT be used where the entire > > + UDP packet would have fit in 512 bytes. > > > > In RFC1035 for UDP, a message size is limited to 512 bytes, not the > > packet size as indicated in this statement. The data-gram limitation > > is 576 bytes per RFC879. > > Thanks for spotting this. I have changed the last sentence to: > > They SHOULD NOT be used where the DNS message would have fit in > a 512 byte UDP packet. The term packet is used in 10 locations in this draft where it confuses message content with the physical packet. These are not the same. This unfortunate terminology was added by this draft. I suspect the prior Performance Consideration section suffers from similar confusion. Read RFC1035 4.2.1. UDP usage & RFC879. | Messages carried by UDP are restricted to 512 bytes (not counting the | IP or UDP headers). Longer messages are truncated and the TC bit is | set in the header. > ...right. So how about adding the following under "Performance > considerations"? > > Deploying CERT RRs to support digitally signed e-mail change the > access patterns of DNS lookups from per-domain to per-user. If > digitally signed e-mail, and a key/certificate lookup based on > CERT RRs, is deployed on a wide scale, this may lead to an > increase of DNS load. Whether this load increase will be > noticable is not known. > > Would that address your concerns? Feel free to adapt and modify the > text, or even merge it with your proposal, then maybe we can get > something we both agree on. There needs to be more information. Do you want this to work with DNSSEC? Do you want this to work with wildcards? -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 14 07:31:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFVTz-0000gv-6X for dnsext-archive@megatron.ietf.org; Wed, 14 Sep 2005 07:31:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04983 for ; Wed, 14 Sep 2005 07:31:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFVOH-0007Qt-3M for namedroppers-data@psg.com; Wed, 14 Sep 2005 11:25:25 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EFVOD-0007Pg-I3 for namedroppers@ops.ietf.org; Wed, 14 Sep 2005 11:25:22 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j8EBP200031254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2005 13:25:04 +0200 From: Simon Josefsson To: Douglas Otis Cc: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050914:namedroppers@ops.ietf.org::nlhEclnYmZhN1bQC:UGt X-Hashcash: 1:21:050914:dotis@mail-abuse.org::9GU146JBiwT9QMDs:HGqg Date: Wed, 14 Sep 2005 13:24:59 +0200 In-Reply-To: <1126695527.9288.52.camel@bash.adsl-64-142-13-68> (Douglas Otis's message of "Wed, 14 Sep 2005 03:58:47 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Douglas Otis writes: > On Wed, 2005-09-14 at 10:15 +0200, Simon Josefsson wrote: >> Douglas Otis writes: >> >> > When doing a comparison of the two documents, I did notice an error >> > unrelated to this topic. >> > >> > + The IPKIX, ISPKI and IPGP types indicate a URL which will serve the >> > + content that would have been in the "certificate, CRL or URL" field >> > + of the corresponding (PKIX, SPKI or PGP) packet types. These types >> > + are known as "indirect". These packet types MUST be used when the >> > + content is too large to fit in the CERT RR, and MAY be used at the >> > + implementer's discretion. They SHOULD NOT be used where the entire >> > + UDP packet would have fit in 512 bytes. >> > >> > In RFC1035 for UDP, a message size is limited to 512 bytes, not the >> > packet size as indicated in this statement. The data-gram limitation >> > is 576 bytes per RFC879. >> >> Thanks for spotting this. I have changed the last sentence to: >> >> They SHOULD NOT be used where the DNS message would have fit in >> a 512 byte UDP packet. > > > The term packet is used in 10 locations in this draft where it confuses > message content with the physical packet. These are not the same. This > unfortunate terminology was added by this draft. I suspect the prior > Performance Consideration section suffers from similar confusion. > > > Read RFC1035 4.2.1. UDP usage & RFC879. > > | Messages carried by UDP are restricted to 512 bytes (not counting the > | IP or UDP headers). Longer messages are truncated and the TC bit is > | set in the header. All occurrences of "packet" that I could find referred to "OpenPGP packets", and that is terminology borrowed from RFC 2440. However, in the same paragraph as you identified above, it did use "packet type" to refer to the CERT RR "type" field. That was incorrect. The new paragraph reads: The IPKIX, ISPKI and IPGP types indicate a URL which will serve the content that would have been in the "certificate, CRL or URL" field of the corresponding types; PKIX, SPKI or PGP, respectively. The IPKIX, ISPKI and IPGP types are known as "indirect". These types MUST be used when the content is too large to fit in the CERT RR, and MAY be used at the implementer's discretion. They SHOULD NOT be used where the DNS message is 512 bytes or smaller, and could thus be expected to fit a UDP packet. Is this satisfactory to you? Please point out the other occurrences you found. >> ...right. So how about adding the following under "Performance >> considerations"? >> >> Deploying CERT RRs to support digitally signed e-mail change the >> access patterns of DNS lookups from per-domain to per-user. If >> digitally signed e-mail, and a key/certificate lookup based on >> CERT RRs, is deployed on a wide scale, this may lead to an >> increase of DNS load. Whether this load increase will be >> noticable is not known. >> >> Would that address your concerns? Feel free to adapt and modify the >> text, or even merge it with your proposal, then maybe we can get >> something we both agree on. > > > There needs to be more information. > > Do you want this to work with DNSSEC? > > Do you want this to work with wildcards? To make it possible for me to add more information, I need to understand what problems you see with using CERT RR together with DNSSEC or wildcards. For me, there is no additional problematic complexity in either case. Maybe you could suggest text. To answer the questions, yes, I see some potential in combining CERT RR with DNSSEC. I do not see any point in having a CERT RR at a wildcard owner name, the semantics of that seem unclear. But I also do not see any need to forbid it, if someone will find it useful in some scenario. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 14 08:09:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFW5J-0000aX-08 for dnsext-archive@megatron.ietf.org; Wed, 14 Sep 2005 08:09:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06810 for ; Wed, 14 Sep 2005 08:09:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFW1X-000AcF-0C for namedroppers-data@psg.com; Wed, 14 Sep 2005 12:05:59 +0000 Received: from [192.240.143.61] (helo=nic002.nic.mil) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1EFW1V-000Abt-RN for namedroppers@ops.ietf.org; Wed, 14 Sep 2005 12:05:57 +0000 Received: from nicws020 ([10.1.0.220]) by nic002.nic.mil with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Sep 2005 08:05:08 -0400 From: "Jim Cassell" To: "Namedroppers" Subject: DNSEXT Minutes @ IETF-63 Date: Wed, 14 Sep 2005 08:05:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcW4n+Ao1Ai9bHQySqSBj7i+FQid/AAg+x0A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 14 Sep 2005 12:05:08.0585 (UTC) FILETIME=[8D05B590:01C5B924] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At the DNSEXT meeting in Paris I was "volunteered" to review the two draft proposals that deal with updating trust anchors. If the intention was for me to somehow define which draft is the "best", then I have failed. I do not feel qualified to make that determination. But, perhaps this review will at least stimulate some discussion on the subject, which will eventually lead to a clearer way ahead. To differentiate between them I am going to call the Mike St Johns draft the "timers" draft; and the Ihren, Kolkman, Manning draft the "threshold" draft. First, I've written a very short overview of each draft, then listed the major differences, then a short conclusion. Automated Updates of DNSSEC Trust Anchors - draft-ietf-dnsext-trustupdate-timers-00 (Timers Draft): Provides a means for automated, authenticated, and authorized updating of trust anchors. Protects against single key compromise. Requires changes to resolver management behavior, and the addition of a single bit flag to the DNSKEY record. Existing trust anchors are used to authenticate new trust anchors at the same point in the DNS hierarchy. Protection against key compromise is accomplished via a revocation bit. When set to "1" in the key, this bit signifies that it must not be used as a trust anchor. Further protection against compromise is provided by the implementation of both "add" and "remove" hold-down timers. An In-Band Rollover Mechanism and an Out-of-Band Priming Method for DNSSEC Trust Anchors - draft-ietf-dnsext-trustupdate-threshold-00 (Threshold Draft): Assumes that keys with the SEP flag set are used as key signing keys. Provides an in-DNS mechanism to track key rollovers and modify the configured trust anchors. The key update algorithm can be expressed as M of N; where N represents the total number of SEP keys a zone owner publishes, and M represents the minimum number of those keys needed to verify a key rollover (the number M is chosen by the resolver administrator). Also provides an out-of-band method to establish the validity of trust anchors for initial configuration (or priming). This method can also be used to recover from a trust anchor "stale" state. Differences: Perhaps my previous relative lack of familiarity with DNSSEC in general, and specifically with these drafts, is preventing me from discerning all the various nuances involved. But, to me at least, it seems that there is a lot in similarity between them. I don't mean to over-simplify, as certainly there are many differences between them, but the major differences seem to come down to: 1. The Timers draft includes a revocation mechanism as a security measure to protect against a key being compromised. The Threshold draft intentionally does not include a revocation mechanism based on the fact that "any reasonable trust anchor rollover policy (in validating resolvers) will require more than one RRSIG to validate", and that zone admins can store private keys separately "thereby decreasing the likelihood of simultaneous compromise". 2. The Threshold draft includes the concept of a "priming key" that can be used to establish the validity of trust anchors for initial configuration or when trust anchor become stale. The Timers draft states that it "does not discuss the general problem of the initial configuration of trust anchors for the resolver". Conclusion: There was some discussion at the Paris meeting about the possibility of allowing both proposals to be implemented and developing some kind of signaling mechanism to identify which method is being used. Of course others may disagree, but I think that while this kind of arrangement makes sense to try to reconcile two methodologies that are already deployed, I don't think it is the optimal way to design/implement a new feature. Although I do not feel qualified to choose the "best" draft, I do think a single choice should be made. -Jim -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 14 20:26:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFhZl-0006ji-Gq for dnsext-archive@megatron.ietf.org; Wed, 14 Sep 2005 20:26:05 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22153 for ; Wed, 14 Sep 2005 20:26:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFhU8-000BMj-Tf for namedroppers-data@psg.com; Thu, 15 Sep 2005 00:20:16 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EFhU7-000BMP-HA for namedroppers@ops.ietf.org; Thu, 15 Sep 2005 00:20:15 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1EFhU5-0006zJ-SZ for namedroppers@ops.ietf.org; Wed, 14 Sep 2005 20:20:14 -0400 Received: by internaut.com (Postfix, from userid 1000) id DC3CD34E50; Wed, 14 Sep 2005 17:20:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id CEE7625281 for ; Wed, 14 Sep 2005 17:20:12 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 14 Sep 2005 17:20:12 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 101: Comments on -43 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 101: Comments on -43 Submitter: Yi Zhao Submitter email address: yizhao@microsoft.com Date first submitted: September 11, 2005 Reference: Document: LLMNR-43 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Section 1.2 The term "Positively resolved" is not used in -43. I suggest it be deleted. Section 2 "For example, a sender configured with a DNS server MAY send LLMNR queries only for unqualified names or for fully qualified names within configured zones." I think you mean "for single-label names" instead of unqualified names, right? Suggest changing to: "For example, by default a sender MAY send LLMNR queries only for single-label names and for fully qualified domain names within configured zones." Section 2.1.1 TC bit "If the TC bit is set in an LLMNR response, then the sender SHOULD resend the LLMNR query over TCP using the unicast address of the responder as the destination address. If the sender receives a response to the TCP query, then it SHOULD discard the UDP response with the TC bit set." Does this make sense? It is possible that the TCP query will not be answered, in which case the sender would have discarded the UDP response and would have nothing. I suggest the following: "If the TC bit is set in an LLMNR response, then the sender SHOULD resend the LLMNR query over TCP using the unicast address of the responder as the destination address. If the sender receives a response over TCP, then it SHOULD discard the UDP response with the TC bit set." RCODE " If an LLMNR responder is authoritative for the name in a multicast query, but an error is encountered, the responder SHOULD send an LLMNR response with an RCODE of zero, no RRs in the answer section, and the TC bit set. This will cause the query to be resent using TCP, and allow the inclusion of a non-zero RCODE in the response to the TCP query. Responding with the TC bit set is preferable to not sending a response, since it enables errors to be diagnosed. Errors include those defined in [RFC2845], such as BADSIG(16), BADKEY(17) and BADTIME(18)." This paragraph could be more descriptive. For example, you could refer to specific TSIG errors such as RCODE=1 (FORMERR) (TSIG RR in an unacceptable position), or RCODE=9 (NOAUTH) with TSIG ERROR 17 (BADKEY) or 16 (BADSIG). My suggestion is to change the paragraph to the following: " If an LLMNR responder is authoritative for the name in a multicast query, but an error is encountered, the responder SHOULD send an LLMNR response with an RCODE of zero, no RRs in the answer section, and the TC bit set. This will cause the query to be resent using TCP, and allow the inclusion of a non-zero RCODE in the response to the TCP query. Responding with the TC bit set is preferable to not sending a response, since it enables errors to be diagnosed. This may be required, for example, when an LLMNR query includes a TSIG RR in the additional section, and the responder encounters a problem that requires returning a non-zero RCODE. TSIG error conditions defined in [RFC2845] include a TSIG RR in an unacceptable position (RCODE=1) or a TSIG RR which does not validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16 (BADSIG))." 2.2 Sender Behavior This section does not say whether retransmissions should use the same ID field or not. If an LLMNR query is sent over multiple interfaces, should the same ID field be used? Perhaps this is implementation dependent? 2.3 Responder Behavior "[a] Responders MUST listen on UDP port 5355 on the link-scope multicast address(es) defined in Section 2, and on UDP and TCP port 5355 on the unicast address(es) that could be set as the source address(es) when the responder responds to the LLMNR query." But UDP unicast queries are prohibited, no? I suggest changing to: "[a] Responders MUST listen on UDP port 5355 on the link-scope multicast address(es) defined in Section 2, and on TCP port 5355 on the unicast address(es) that could be set as the source address(es) when the responder responds to the LLMNR query." "An SOA RR is synthesized only when a responder has another RR in addition to the SOA RR; the SOA RR MUST NOT be the only RR that the responder has." The specification only mentions returning the SOA in the additional section of a negative response. In this case, the SOA RR can be synthesized on the fly. Or was this sentence inserted so that a responder should not respond to an LLMNR query for type = "ANY" if it only has an SOA RR, but no other RRs? 2.4 Unicast Queries and Responses "If TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section)." This looks wrong. If TCP connection setup cannot be completed after a response is returned via UDP with the TC bit set, then the sender should just use the UDP response. If TCP connection setup fails for a PTR RR query, it means that the responder does not reside on the link. This is equivalent to RCODE=3 (no such name), not ROCDE=0. Also, as I understand it, the point of using TCP instead of multicast UDP for PTR RR queries is to improve performance. Many PTR RR queries will not be answered, so that if you use multicast UDP then the sender will retransmit, requiring multiple timeouts. However, if TCP is used with TTL=1, an ICMP TTL exceeded message will be received if the destination is off-link, so that the TCP connection can be aborted earlier. However, this requires the implementation to process ICMP TTL exceeded messages; TCP implementations typically treat this as a soft error and do not abort the connection setup. If a sender implementation cannot easily do this (e.g. if it does not have rights to open a raw socket), then it seems to me that there is no advantage to using TCP for PTR RR queries. Suggest that Section 2.4 be changed to the following: "2.4. Unicast Queries and Responses Unicast queries SHOULD be sent when: [a] A sender repeats a query after it received a response with the TC bit set to the previous LLMNR multicast query, or [b] The sender queries for a PTR RR of a fully formed IP address within the "in-addr.arpa" or "ip6.arpa" zones. Unicast LLMNR queries MUST be done using TCP and the responses MUST be sent using the same TCP connection as the query. Senders MUST support sending TCP queries, and responders MUST support listening for TCP queries. If the sender of a TCP query receives a response to that query not using TCP, the response MUST be silently discarded. Unicast UDP queries MUST be silently discarded. A unicast PTR RR query for an off-link address will not elicit a response, but instead an ICMP TTL or Hop Limit exceeded message will be received. An implementation receiving an ICMP message in response to a TCP connection setup attempt can return immediately, treating this as a response that no such name exists (RCODE=3 is returned). An implementation that cannot process ICMP messages MAY send multicast UDP queries for PTR RRs. Since TCP implementations will not retransmit prior to RTOmin, a considerable period will elapse before TCP retransmits multiple times, resulting in a long timeout for TCP PTR RR queries sent to an off-link destination." 2.5 "Off Link" Detection "However, it is recommended that the value 255 be used for compatibility with Apple Bonjour [Bonjour]." Using a TTL of 255 will not make LLMNR compatible with Bonjour's mDNS. Or is the issue compatibility with Apple's IPv4 Link Local implementation, which tests for TTL=255? Perhaps this sentence should be removed? 2.7 Retransmission and Jitter "while increasing the value of LLMNR_TIMEOUT exponentially" Why? Using multiplicative increase just increases the total timeout. I suggest these words be deleted. "A unicast query sender considers the query answered after the first response is received, so it only waits for LLMNR_TIMEOUT if no response has been received." Unicast queries are only sent over TCP not UDP. Are you saying that a query sent over TCP should be aborted after LLMNR_TIMEOUT? This doesn't make sense if LLMNR_TIMEOUT < RTOmin, because the TCP implementation won't have retransmitted even once before the connection is aborted. I suggest that "so it only waits.." be deleted. "However, if the first response has the 'C' bit set, then the sender SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses." If a response is received with the 'C' bit set, is it sufficient to only wait for LLMNR_TIMEOUT to receive all responses? If LLMNR_TIMEOUT is set to a low value (100 ms) it might make sense to wait longer to collect all responses, particularly since non-unique responses will have jitter added to them. I recommend this be changed to "LLMNR_TIMEOUT + JITTER_INTERVAL." 2.9 Use of the Authority and Additional Sections "In queries where the 'C' bit is set, the sender SHOULD include the conflicting RRs in the additional section." Why? The responder will not look at the additional section, it will just begin UNIQUEness detection. Is this only for debugging purposes? 3. Usage Model In this section it is probably worth saying that resolvers implementing both DNS and LLMNR should not send DNS queries for single-label names. That way if a user types in "http://foo/" a DNS query will not be sent for "foo." although DNS queries will be composed via the searchlist. Suggest the following sentence be added to Section 3: "In order to reduce unnecessary DNS queries, stub resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS queries for single-label names." 5.3 Authentication Suggest deleting the paragraph starting "LLMNR does not support..." and adding an element [c]: "[c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to support DNSSEC, LLMNR implementations may be configured with trust anchors, or they may make use of keys obtained from DNS queries. Since LLMNR does not support "delegated trust" (CD or AD bits), LLMNR implementations cannot make use of DNSSEC unless they are DNSSEC aware." Section 6 I think you need to say that the rights to use an FQDN name in LLMNR derives from the right to use the same name within DNS. My recommendation is that Section 6 be rewritten as follows: "6. IANA Considerations LLMNR requires allocation of port 5355 for both TCP and UDP. LLMNR requires allocation of link-scope multicast IPv4 address 224.0.0.252, as well as link-scope multicast IPv6 address FF02:0:0:0:0:0:1:3. This specification creates two new name spaces: the LLMNR namespace and the reserved bits in the LLMNR header. The reserved bits in the LLMNR header are allocated by IETF Consensus, in accordance with BCP 26 [RFC2434]. In order to to avoid creating any new administrative procedures, administration of the LLMNR namespace will piggyback on the administration of the DNS and NETBIOS namespaces. The rights to use a given LLMNR name are obtained coincident with acquiring the rights to use a particular name within NETBIOS or DNS. NETBIOS names, defined in [RFC1001], are single-label names that are not required to be globally unique. Those wishing to use a fully qualified domain name (FQDN) within LLMNR should first acquire the rights to use the corresponding FQDN within DNS. Using an LLMNR name without ownership of the corresponding name in DNS or NETBIOS creates the possibility of conflict and therefore is to be discouraged." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 15 01:06:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFlx6-0007Ww-ML for dnsext-archive@megatron.ietf.org; Thu, 15 Sep 2005 01:06:30 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04194 for ; Thu, 15 Sep 2005 01:06:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFls8-0005BJ-7F for namedroppers-data@psg.com; Thu, 15 Sep 2005 05:01:20 +0000 Received: from [64.142.19.5] (helo=b.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EFls6-0005Av-2F for namedroppers@ops.ietf.org; Thu, 15 Sep 2005 05:01:18 +0000 Received: from [192.168.2.41] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j8F50tSC031297 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 14 Sep 2005 22:00:56 -0700 In-Reply-To: References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Date: Wed, 14 Sep 2005 22:00:57 -0700 To: Simon Josefsson X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sep 14, 2005, at 4:24 AM, Simon Josefsson wrote: > Douglas Otis writes: > > The new paragraph reads: > > The IPKIX, ISPKI and IPGP types indicate a URL which will serve > the content that would have been in the "certificate, CRL or > URL" field of the corresponding types; PKIX, SPKI or PGP, > respectively. The IPKIX, ISPKI and IPGP types are known as > "indirect". These types MUST be used when the content is too > large to fit in the CERT RR, and MAY be used at the > implementer's discretion. They SHOULD NOT be used where the DNS > message is 512 bytes or smaller, and could thus be expected to > fit a UDP packet. > > Is this satisfactory to you? This is better. The size noted as including overhead in the Performance Consideration section could be seen as misleading as well. Perhaps this was the message overhead and not the transport overhead. This is not clear. >> There needs to be more information. >> >> Do you want this to work with DNSSEC? >> >> Do you want this to work with wildcards? >> > > To make it possible for me to add more information, I need to > understand what problems you see with using CERT RR together with > DNSSEC or wildcards. For me, there is no additional problematic > complexity in either case. Maybe you could suggest text. > > To answer the questions, yes, I see some potential in combining CERT > RR with DNSSEC. I do not see any point in having a CERT RR at a > wildcard owner name, the semantics of that seem unclear. But I also > do not see any need to forbid it, if someone will find it useful in > some scenario. It takes very little effort to generate traffic using wildcards. DNSSEC makes dealing with wildcards even more problematic assuming there is a desire to obtain a valid signature and have something more secure than the IP address. I will ignore black-holes lists as this represents a special case that can be localized. I'll attempt to estimate the impact on DNS handling user-keys. I am sure I will be corrected where needed. About 25% of DNS lookups obtain no answer, and about 12% return an error. Due to aggressive retries, the no answer category represent about half of the WAN DNS traffic. The WAN DNS traffic is about 8% overall with about a 10% packet loss rate, perhaps due to server limitations. The distribution of A records narrowly benefits from caching across a large population of machines which often have short TTLs as a means for load balancing or mobility. A third of these A record lookups are not repeated. Of this DNS traffic, perhaps 8% is related to email. MX and NS records may benefit from caching with adequate TTLs. NS caching likely represents the most significant performance benefit. From the WAN perspective, caching does not appear wildly successful, while caching still offers improved performance. Assume there are 1 billion mailboxes distributed across 20 million reputable domains. This provides an average of 50 mailboxes per domain. There is a steep distribution profile where tens of millions of mailboxes may be found within a single domain. Deployment using user certs in DNS (identifiers and public keys) could be dramatically swift from a percentage standpoint, with adoption by several of these larger domains. While public key related protocols suggest certs should be retained, this then requires a provision for revocation. When a large domain offers free mailboxes, a revocation list will likely necessitate frequent updates. These updates must be timely or abuse signed by their certs will remain chronic. A corporation will also desire rapid retraction of certs when an employee's laptop becomes compromised or something or someone runs afoul. One strategy was to simply put an expiration on the signed message and assume the cert is not be compromised. Even with this, the period of time needed to assure delivery still allows for a fair amount of abuse. Another alternative would be to put a short TTL on the cert for a short retention in DNS. By then not retaining the cert in the application deals with the revocation problem. The payloads normally exchanged in DNS per email may then include a mailbox cert query when writing the message to enable privacy. A key- id cert query by the MTA when verifying the signature would then be followed by a perhaps a mailbox cert query by the recipient or recipients at some later date. The size of the response will be larger, as will the query compared to the other still required DNS exchanges for email. Rather than a dozen or so bytes to cache results, there is now a need for perhaps 30 times that amount, or perhaps these certs are simply not cached at all. After all, these large records will be more thinly dispersed than A records. Assuming some caching still happens in the normal exchange, this new cert per user may perhaps double the email DNS payload per cert exchange and increase the 8% of DNS traffic associated with email. Assume the average number of recipients is 4 per session where the initial mailbox was encrypted for a timed or group functionary. A cert is needed to encrypt at the sender, and then a key-id cert will be needed by the MDA to check the signer. Perhaps the mailbox-cert will then be obtained by each recipient for 6 cert exchanges for a 12 times increase in payload doubling DNS traffic. Then consider DNSSEC. This will roughly double this traffic again. Now 16% becomes 32% of overall traffic. I have not added the wildcards and DNSSEC. The concept expressed in MASS was to use wildcards to create separate certs using a hierarchy of message/mailbox as the cert owner, where the good messages and mailboxes are handled by a wildcard and the bad are assigned a specific cert. This would mean that to use DNSSEC effectively, the actual wildcard record will require a subsequent query. Of course there are also the cname records to translate between key-ids and mailbox-addresses. The wildcard doubles the traffic for these certs where 32% becomes 40% where the cname perhaps adds still more. This seems to be going from about 8% of the DNS traffic to nearly half the overall traffic for an application that previously required very little. Assume there are 30 million messages being exchanged every minute to perhaps an average of 3 recipients per session that are not encrypted, but where 20% are signed. The amount of additional traffic just this generates using wildcards and DNSSEC would be about 10k per exchange or an additional network burden of about 1 gigabyte per second of double cryptography for these early adopters to handle. My advice: Remove any mention of wildcards except to say wildcards are is not recommended. Suggest how these cert records could be handled by the application and the DNS cache. Add some warning that their use on a per user basis may impact DNS performance with a reduction in cache effectiveness, together with reductions in server and network capacity. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 15 04:26:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFp4u-0000Gj-5E for dnsext-archive@megatron.ietf.org; Thu, 15 Sep 2005 04:26:44 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26391 for ; Thu, 15 Sep 2005 04:26:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFp1e-000Jcx-7s for namedroppers-data@psg.com; Thu, 15 Sep 2005 08:23:22 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EFp1b-000JcY-0m for namedroppers@ops.ietf.org; Thu, 15 Sep 2005 08:23:19 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j8F8NB25003523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2005 10:23:12 +0200 From: Simon Josefsson To: Douglas Otis Cc: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050915:dotis@mail-abuse.org::gDOHX/SwcZZIDbJw:IWX X-Hashcash: 1:21:050915:namedroppers@ops.ietf.org::/I33PtnZbEh4VG1L:5S9e Date: Thu, 15 Sep 2005 10:23:08 +0200 In-Reply-To: (Douglas Otis's message of "Wed, 14 Sep 2005 22:00:57 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Douglas Otis writes: > On Sep 14, 2005, at 4:24 AM, Simon Josefsson wrote: > >> Douglas Otis writes: >> >> The new paragraph reads: >> >> The IPKIX, ISPKI and IPGP types indicate a URL which will serve >> the content that would have been in the "certificate, CRL or >> URL" field of the corresponding types; PKIX, SPKI or PGP, >> respectively. The IPKIX, ISPKI and IPGP types are known as >> "indirect". These types MUST be used when the content is too >> large to fit in the CERT RR, and MAY be used at the >> implementer's discretion. They SHOULD NOT be used where the DNS >> message is 512 bytes or smaller, and could thus be expected to >> fit a UDP packet. >> >> Is this satisfactory to you? > > This is better. Good. > The size noted as including overhead in the Performance > Consideration section could be seen as misleading as well. Perhaps > this was the message overhead and not the transport overhead. This > is not clear. OLD: Current Domain Name System (DNS) implementations are optimized for small transfers, typically not more than 512 bytes including overhead. NEW: The Domain Name System (DNS) protocol was designed for small transfers, typically below 512 bytes. I think the reference to what "current" DNS implementations are optimized for may be wrong. Current implementations support EDNS.0 and DNSSEC, and must handle larger messages. However, it is certainly true that the DNS protocol was originally designed for small transfers, and saying that should be harmless. Do this change solve your problem? >>> There needs to be more information. >>> >>> Do you want this to work with DNSSEC? >>> >>> Do you want this to work with wildcards? >>> >> >> To make it possible for me to add more information, I need to >> understand what problems you see with using CERT RR together with >> DNSSEC or wildcards. For me, there is no additional problematic >> complexity in either case. Maybe you could suggest text. >> >> To answer the questions, yes, I see some potential in combining CERT >> RR with DNSSEC. I do not see any point in having a CERT RR at a >> wildcard owner name, the semantics of that seem unclear. But I also >> do not see any need to forbid it, if someone will find it useful in >> some scenario. > > It takes very little effort to generate traffic using wildcards. > DNSSEC makes dealing with wildcards even more problematic assuming > there is a desire to obtain a valid signature and have something more > secure than the IP address. I will ignore black-holes lists as this > represents a special case that can be localized. > > I'll attempt to estimate the impact on DNS handling user-keys. I am > sure I will be corrected where needed. > > About 25% of DNS lookups obtain no answer, and about 12% return an > error. Due to aggressive retries, the no answer category represent > about half of the WAN DNS traffic. The WAN DNS traffic is about 8% > overall with about a 10% packet loss rate, perhaps due to server > limitations. Do you have a reference for these numbers? Is there anything that suggest the same would hold for CERT RRs? > Assume there are 1 billion mailboxes distributed across 20 million > reputable domains. This provides an average of 50 mailboxes per > domain. There is a steep distribution profile where tens of millions > of mailboxes may be found within a single domain. Deployment using > user certs in DNS (identifiers and public keys) could be dramatically > swift from a percentage standpoint, with adoption by several of these > larger domains. I don't think it is fair to use the current number of mailboxes as the number of CERT RRs that will be used tomorrow. Things will be deployed incrementally, starting with a few RRs, then a couple of hundred, and then gradually more and more. If things break, the experiment is aborted. This is the same for all technical advancements. We can certainly warn about this potential problem, but without solid evidence, I think we should be careful about including speculation. A more realistic number to use would be the number of digitally signed or encrypted S/MIME and OpenPGP e-mail messages exchanged today, where the user had to involve LDAP or HTTP to lookup a certificate. I believe this number is very small compared to all other traffic on the Internet. How often to you lookup a certificate from a remote database? Your colleges? Your mom? I do it perhaps once per week. > While public key related protocols suggest certs should be retained, > this then requires a provision for revocation. When a large domain > offers free mailboxes, a revocation list will likely necessitate > frequent updates. These updates must be timely or abuse signed by > their certs will remain chronic. A corporation will also desire > rapid retraction of certs when an employee's laptop becomes > compromised or something or someone runs afoul. One strategy was to > simply put an expiration on the signed message and assume the cert is > not be compromised. Even with this, the period of time needed to > assure delivery still allows for a fair amount of abuse. Another > alternative would be to put a short TTL on the cert for a short > retention in DNS. By then not retaining the cert in the application > deals with the revocation problem. Further, CERT RRs may store OpenPGP revocation certificates. They are small, about 100 bytes, so querying for them would be quick. > The payloads normally exchanged in DNS per email may then include a > mailbox cert query when writing the message to enable privacy. A key- > id cert query by the MTA when verifying the signature would then be > followed by a perhaps a mailbox cert query by the recipient or > recipients at some later date. The size of the response will be > larger, as will the query compared to the other still required DNS > exchanges for email. Rather than a dozen or so bytes to cache > results, there is now a need for perhaps 30 times that amount, or > perhaps these certs are simply not cached at all. After all, these > large records will be more thinly dispersed than A records. The draft doesn't imply MTA's should lookup certificates nor verify the signature. I think you are jumping to conclusions here. Today, not even many MUAs are able to lookup certificates and verify signatures. > Assuming some caching still happens in the normal exchange, this new > cert per user may perhaps double the email DNS payload per cert > exchange and increase the 8% of DNS traffic associated with email. > Assume the average number of recipients is 4 per session where the > initial mailbox was encrypted for a timed or group functionary. A > cert is needed to encrypt at the sender, and then a key-id cert will > be needed by the MDA to check the signer. Perhaps the mailbox-cert > will then be obtained by each recipient for 6 cert exchanges for a 12 > times increase in payload doubling DNS traffic. Then consider > DNSSEC. This will roughly double this traffic again. Now 16% > becomes 32% of overall traffic. All these numbers assume many things that are not in the draft, and that nobody has proposed to do. > I have not added the wildcards and DNSSEC. The concept expressed in > MASS was to use wildcards to create separate certs using a hierarchy > of message/mailbox as the cert owner, where the good messages and > mailboxes are handled by a wildcard and the bad are assigned a > specific cert. This would mean that to use DNSSEC effectively, the > actual wildcard record will require a subsequent query. Of course > there are also the cname records to translate between key-ids and > mailbox-addresses. The wildcard doubles the traffic for these certs > where 32% becomes 40% where the cname perhaps adds still more. This > seems to be going from about 8% of the DNS traffic to nearly half the > overall traffic for an application that previously required very little. Is anyone deploying this? > Assume there are 30 million messages being exchanged every minute to > perhaps an average of 3 recipients per session that are not > encrypted, but where 20% are signed. The amount of additional > traffic just this generates using wildcards and DNSSEC would be about > 10k per exchange or an additional network burden of about 1 gigabyte > per second of double cryptography for these early adopters to handle. Again, I think your numbers are way off. > My advice: Thanks for reaching a conclusion. > Remove any mention of wildcards except to say wildcards are is not > recommended. The document does not mention wildcards, except for Edward Lewis statement that, if I understood him correctly, was added precisely to warn MASS people about the problem with wildcards. The text reads: if multiple labels are used when mapping from a CERT identifier to a domain name then care must be taken in understanding wildcard record synthesis. Does this solve your problem? Please suggest text if not. > Suggest how these cert records could be handled by the application > and the DNS cache. I don't know how to translate this into anything that would go into the document. I don't think a DNS cache has to, or even should, treat CERT RRs differently from any other data. How applications handle CERT RRs depend very much on the application, and is better of profiled in separate documents. Perhaps you could propose some text, to allow me to see what you are thinking of. > Add some warning that their use on a per user basis may impact DNS > performance with a reduction in cache effectiveness, together with > reductions in server and network capacity. I slightly re-worded the earlier text I proposed: Deploying CERT RRs to support digitally signed e-mail change the access patterns of DNS lookups from per-domain to per-user. If digitally signed e-mail, and a key/certificate lookup based on CERT RRs, is deployed on a wide scale, this may lead to an increased DNS load, with potential performance and cache effectiveness consequencess. Whether this load increase will be noticable or not is not known. Is this ok with you? Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 15 15:55:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFzpW-0001pi-Al for dnsext-archive@megatron.ietf.org; Thu, 15 Sep 2005 15:55:34 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01270 for ; Thu, 15 Sep 2005 15:55:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFzkE-000Gkt-OQ for namedroppers-data@psg.com; Thu, 15 Sep 2005 19:50:06 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EFzkD-000GkH-SO for namedroppers@ops.ietf.org; Thu, 15 Sep 2005 19:50:06 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EFzk9-0001gd-SI; Thu, 15 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2538bis-06.txt Message-Id: Date: Thu, 15 Sep 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Storing Certificates in the Domain Name System (DNS) Author(s) : S. Josefsson Filename : draft-ietf-dnsext-rfc2538bis-06.txt Pages : 16 Date : 2005-9-15 Cryptographic public keys are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). This document obsoletes RFC 2538. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2538bis-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-06.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: <2005-9-15114422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2538bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-15114422.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 16 00:58:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG8Ip-0007ZD-OQ for dnsext-archive@megatron.ietf.org; Fri, 16 Sep 2005 00:58:24 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10470 for ; Fri, 16 Sep 2005 00:58:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EG8Ds-000PG4-MX for namedroppers-data@psg.com; Fri, 16 Sep 2005 04:53:16 +0000 Received: from [64.142.16.245] (helo=a.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EG8Dr-000PFo-Fq for namedroppers@ops.ietf.org; Fri, 16 Sep 2005 04:53:15 +0000 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j8G4quis011637 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 15 Sep 2005 21:52:56 -0700 In-Reply-To: References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Date: Thu, 15 Sep 2005 21:52:53 -0700 To: Simon Josefsson X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sep 15, 2005, at 1:23 AM, Simon Josefsson wrote: > > OLD: > > Current Domain Name System (DNS) implementations are optimized for > small transfers, typically not more than 512 bytes including > overhead. > > NEW: > > The Domain Name System (DNS) protocol was designed for small > transfers, typically below 512 bytes. This looks better as well. > > Do you have a reference for these numbers? Is there anything that > suggest the same would hold for CERT RRs? There was a DNS performance study looking at MIT in 2002. This comment was not about CERT RR, but rather to agree with the view that from the WAN perspective, caching appears to be of little value. It looks even worse from the root server perspective. It still helps. : ) > I don't think it is fair to use the current number of mailboxes as the > number of CERT RRs that will be used tomorrow. Things will be > deployed incrementally, starting with a few RRs, then a couple of > hundred, and then gradually more and more. If things break, the > experiment is aborted. This is the same for all technical > advancements. We can certainly warn about this potential problem, but > without solid evidence, I think we should be careful about including > speculation. You missed the point that I was attempting to make. Adoption by many of the larger domains may create a rapid change in the baseline. Do not depend upon only a few using this record. > A more realistic number to use would be the number of digitally signed > or encrypted S/MIME and OpenPGP e-mail messages exchanged today, where > the user had to involve LDAP or HTTP to lookup a certificate. I > believe this number is very small compared to all other traffic on the > Internet. How often to you lookup a certificate from a remote > database? Your colleges? Your mom? I do it perhaps once per week. Again you are depending upon this not being adopted on a large scale. I only hope you are right. Once this is attempted where there are hundreds of millions of messages using certs, a leisurely pace of obtaining certs and checking for revocations will need to change rather substantially. > Further, CERT RRs may store OpenPGP revocation certificates. They are > small, about 100 bytes, so querying for them would be quick. While a list of cert serial numbers may be small for some domains, this may not be the case where it is most needed. This added record may grow to be very large as well. Of course, this could use TCP fall-back or a redirection to a standard cert service. This situation has made implementing revocation mechanisms questionable, and this takes away control from the sending domain. The shear size of the data that needs to be copied to millions of places still represents a sizable task. Shortening the duration of the record to keep the CRL within reason also means this information needs to be copied even more frequently. At some point, it may be easier to just get the cert. > The draft doesn't imply MTA's should lookup certificates nor verify > the signature. I think you are jumping to conclusions here. Today, > not even many MUAs are able to lookup certificates and verify > signatures. That situation is changing very rapidly. >> Assuming some caching still happens in the normal exchange, this new >> cert per user may perhaps double the email DNS payload per cert >> exchange and increase the 8% of DNS traffic associated with email. >> Assume the average number of recipients is 4 per session where the >> initial mailbox was encrypted for a timed or group functionary. A >> cert is needed to encrypt at the sender, and then a key-id cert will >> be needed by the MDA to check the signer. Perhaps the mailbox-cert >> will then be obtained by each recipient for 6 cert exchanges for a 12 >> times increase in payload doubling DNS traffic. Then consider >> DNSSEC. This will roughly double this traffic again. Now 16% >> becomes 32% of overall traffic. >> > > All these numbers assume many things that are not in the draft, and > that nobody has proposed to do. What do you mean by things? >> I have not added the wildcards and DNSSEC. The concept expressed in >> MASS was to use wildcards to create separate certs using a hierarchy >> of message/mailbox as the cert owner, where the good messages and >> mailboxes are handled by a wildcard and the bad are assigned a >> specific cert. This would mean that to use DNSSEC effectively, the >> actual wildcard record will require a subsequent query. Of course >> there are also the cname records to translate between key-ids and >> mailbox-addresses. The wildcard doubles the traffic for these certs >> where 32% becomes 40% where the cname perhaps adds still more. This >> seems to be going from about 8% of the DNS traffic to nearly half the >> overall traffic for an application that previously required very >> little. >> > > Is anyone deploying this? DomainKeys and DKIM could do this now. > > >> Assume there are 30 million messages being exchanged every minute to >> perhaps an average of 3 recipients per session that are not >> encrypted, but where 20% are signed. The amount of additional >> traffic just this generates using wildcards and DNSSEC would be about >> 10k per exchange or an additional network burden of about 1 gigabyte >> per second of double cryptography for these early adopters to handle. >> > > Again, I think your numbers are way off. I was looking at a marketing study. I was attempting to estimate the network impacts. >> Remove any mention of wildcards except to say wildcards are is not >> recommended. >> > > The document does not mention wildcards, except for Edward Lewis > statement that, if I understood him correctly, was added precisely to > warn MASS people about the problem with wildcards. The text reads: > > if multiple > labels are used when mapping from a CERT identifier to a domain > name then care must be taken in understanding wildcard record > synthesis. This text seems to suggest that when wildcards are used to be careful. Certs and DNSSEC will get ugly with wildcards. Perhaps adding or replacing this sentence with: It is not recommended that a CERT RR be published as a wildcard. >> Suggest how these cert records could be handled by the application >> and the DNS cache. >> > > I don't know how to translate this into anything that would go into > the document. I don't think a DNS cache has to, or even should, treat > CERT RRs differently from any other data. How applications handle > CERT RRs depend very much on the application, and is better of > profiled in separate documents. Perhaps you could propose some text, > to allow me to see what you are thinking of. When CERT RRs are found to occupy too much cache, it may be required to limit the maximum TTL for this type of record. > >> Add some warning that their use on a per user basis may impact DNS >> performance with a reduction in cache effectiveness, together with >> reductions in server and network capacity. >> > > I slightly re-worded the earlier text I proposed: > > Deploying CERT RRs to support digitally signed e-mail change the > access patterns of DNS lookups from per-domain to per-user. If > digitally signed e-mail, and a key/certificate lookup based on > CERT RRs, is deployed on a wide scale, this may lead to an > increased DNS load, with potential performance and cache > effectiveness consequencess. Whether this load increase will be > noticable or not is not known. I would drop the last sentence. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 16 05:04:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGC8d-00064h-KK for dnsext-archive@megatron.ietf.org; Fri, 16 Sep 2005 05:04:08 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03277 for ; Fri, 16 Sep 2005 05:04:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EGC3e-000HGb-J3 for namedroppers-data@psg.com; Fri, 16 Sep 2005 08:58:58 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EGC3b-000HG3-Fu for namedroppers@ops.ietf.org; Fri, 16 Sep 2005 08:58:56 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j8G8wZIP019361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2005 10:58:36 +0200 From: Simon Josefsson To: Douglas Otis Cc: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050916:namedroppers@ops.ietf.org::XcP1p0qkE4B0l5bD:lAH X-Hashcash: 1:21:050916:dotis@mail-abuse.org::U34Di07yYz5CRWE3:8RTc Date: Fri, 16 Sep 2005 10:58:31 +0200 In-Reply-To: <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> (Douglas Otis's message of "Thu, 15 Sep 2005 21:52:53 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Douglas Otis writes: >> Do you have a reference for these numbers? Is there anything that >> suggest the same would hold for CERT RRs? > > There was a DNS performance study looking at MIT in 2002. This > comment was not about CERT RR, but rather to agree with the view that > from the WAN perspective, caching appears to be of little value. It > looks even worse from the root server perspective. It still helps. : ) Thanks for the reference. >> I don't think it is fair to use the current number of mailboxes as the >> number of CERT RRs that will be used tomorrow. Things will be >> deployed incrementally, starting with a few RRs, then a couple of >> hundred, and then gradually more and more. If things break, the >> experiment is aborted. This is the same for all technical >> advancements. We can certainly warn about this potential problem, but >> without solid evidence, I think we should be careful about including >> speculation. > > You missed the point that I was attempting to make. Adoption by many > of the larger domains may create a rapid change in the baseline. Do > not depend upon only a few using this record. I don't. But I simply don't see the same problems that you do when many people would start to use it. Distributing the certificates through DNS is a small step compared to everything else that has to be modified to support a e-mail PKI on a wide scale. Thus fixing any implementations problems in DNS servers that there may be (although I am not aware of any problems affecting this, nor do I expect there to be any) can be done without any rush. If you only assume the infrastructure we have today, and throw numbers at it that may hold in 10 years, then showing that things will break is not difficult. But it doesn't work like that. The Internet evolve and adapt to changing user habits. Don't get me wrong, I see no problem warning about potential problems, but we shouldn't recommend against exploring this technology further, nor should these warnings imply that we know for sure that there will be potential problems. >> Further, CERT RRs may store OpenPGP revocation certificates. They are >> small, about 100 bytes, so querying for them would be quick. > > While a list of cert serial numbers may be small for some domains, > this may not be the case where it is most needed. This added record > may grow to be very large as well. Of course, this could use TCP > fall-back or a redirection to a standard cert service. This > situation has made implementing revocation mechanisms questionable, > and this takes away control from the sending domain. The shear size > of the data that needs to be copied to millions of places still > represents a sizable task. Shortening the duration of the record to > keep the CRL within reason also means this information needs to be > copied even more frequently. At some point, it may be easier to just > get the cert. OpenPGP revocation certificates doesn't work like you describe. There is no list of cert serial numbers. It appears as if you are talking about X.509. For X.509, there are more efficient revocation checking methods than using CRLs, there is OCSP and XKMS. Still, if the CERT RR would be used to serve X.509 CRLs, it will be done through the IPKIX type, because most CRLs become larger than 64kb sooner or later. And a IPKIX CERT RR would typically be below 100 bytes. So I don't see a problem here either. >> The draft doesn't imply MTA's should lookup certificates nor verify >> the signature. I think you are jumping to conclusions here. Today, >> not even many MUAs are able to lookup certificates and verify >> signatures. > > That situation is changing very rapidly. Yes, but I'm talking about this document. >>> Assuming some caching still happens in the normal exchange, this new >>> cert per user may perhaps double the email DNS payload per cert >>> exchange and increase the 8% of DNS traffic associated with email. >>> Assume the average number of recipients is 4 per session where the >>> initial mailbox was encrypted for a timed or group functionary. A >>> cert is needed to encrypt at the sender, and then a key-id cert will >>> be needed by the MDA to check the signer. Perhaps the mailbox-cert >>> will then be obtained by each recipient for 6 cert exchanges for a 12 >>> times increase in payload doubling DNS traffic. Then consider >>> DNSSEC. This will roughly double this traffic again. Now 16% >>> becomes 32% of overall traffic. >>> >> >> All these numbers assume many things that are not in the draft, and >> that nobody has proposed to do. > > What do you mean by things? Performing certificate lookups and verification inside MTAs nor MDA. Eventually, a MUA may want to lookup the certificate and perform verification. But this is done on the user's request, and is currently handled by LDAP or HTTP. If DNS is used, the LDAP/HTTP traffic would go away (including the DNS lookups resulting from the LDAP/HTTP requests). The total network impact is the same, or actually lower because DNS is more efficient. I don't see where the problem is. >>> I have not added the wildcards and DNSSEC. The concept expressed in >>> MASS was to use wildcards to create separate certs using a hierarchy >>> of message/mailbox as the cert owner, where the good messages and >>> mailboxes are handled by a wildcard and the bad are assigned a >>> specific cert. This would mean that to use DNSSEC effectively, the >>> actual wildcard record will require a subsequent query. Of course >>> there are also the cname records to translate between key-ids and >>> mailbox-addresses. The wildcard doubles the traffic for these certs >>> where 32% becomes 40% where the cname perhaps adds still more. This >>> seems to be going from about 8% of the DNS traffic to nearly half the >>> overall traffic for an application that previously required very >>> little. >>> >> >> Is anyone deploying this? > > DomainKeys and DKIM could do this now. A lot of protocols could use CERT RRs for stupid things. Maybe the problem is with those protocols, and not the CERT RR itself. >>> Remove any mention of wildcards except to say wildcards are is not >>> recommended. >>> >> >> The document does not mention wildcards, except for Edward Lewis >> statement that, if I understood him correctly, was added precisely to >> warn MASS people about the problem with wildcards. The text reads: >> >> if multiple >> labels are used when mapping from a CERT identifier to a domain >> name then care must be taken in understanding wildcard record >> synthesis. > > > This text seems to suggest that when wildcards are used to be > careful. Certs and DNSSEC will get ugly with wildcards. Perhaps > adding or replacing this sentence with: > > It is not recommended that a CERT RR be published as a wildcard. I have problems agreeing with this. I see no justification for recommending against CERT RRs at wildcard names. My reasons are as follows. If some application somewhere is designed so that it can utilize, for a good purpose, CERT RR data placed at a wildcard owner name, then that is justification enough to allow CERT RRs at wildcard names. If there are no such application, CERT RRs at wildcard names simply won't be used, and there is no problem. The protocol using CERT RRs at wildcard names may not scale well, but on the other hand, it might scale just fine. That depends on the design and usage pattern. In any case, I believe that any problem is with that application, not with the CERT RR per se. Possibly the problem is with the wildcard concept in DNS, there are similar concerns with wildcard names for other RRs too (remember the '*.COM IN A' situation?). Placing A RRs at wildcard names is still permitted by the specification, but whether people chose to do this in practice depend on other things. I expect the same will be true for CERT RRs. Remember, the text says to be careful about wildcards. That is sufficient warning for me. At this point, I would appreciate hearing input from others on whether we should explicitly recommend against placing CERT RRs at wildcard names or whether the current text above suggesting that care is in order when wildcards is involved is sufficient. >>> Suggest how these cert records could be handled by the application >>> and the DNS cache. >>> >> >> I don't know how to translate this into anything that would go into >> the document. I don't think a DNS cache has to, or even should, treat >> CERT RRs differently from any other data. How applications handle >> CERT RRs depend very much on the application, and is better of >> profiled in separate documents. Perhaps you could propose some text, >> to allow me to see what you are thinking of. > > > When CERT RRs are found to occupy too much cache, it may be required > to limit the maximum TTL for this type of record. DNS caches must be able to handle too much cached data, typically they discard data that hasn't been used for a while. Creating additional administrator burdens to protect poor DNS cache implementations is the wrong approach, in my opinion. >>> Add some warning that their use on a per user basis may impact DNS >>> performance with a reduction in cache effectiveness, together with >>> reductions in server and network capacity. >>> >> >> I slightly re-worded the earlier text I proposed: >> >> Deploying CERT RRs to support digitally signed e-mail change the >> access patterns of DNS lookups from per-domain to per-user. If >> digitally signed e-mail, and a key/certificate lookup based on >> CERT RRs, is deployed on a wide scale, this may lead to an >> increased DNS load, with potential performance and cache >> effectiveness consequencess. Whether this load increase will be >> noticable or not is not known. > > > I would drop the last sentence. Without it, it is implied that we know for certain that there may be potential performance and cache effectiveness consequences. I don't believe we know this. Expressing these doubts is thus fair to the reader. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 16 05:16:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGCKh-0000oN-2U for dnsext-archive@megatron.ietf.org; Fri, 16 Sep 2005 05:16:35 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03773 for ; Fri, 16 Sep 2005 05:16:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EGCHq-000IeI-Fs for namedroppers-data@psg.com; Fri, 16 Sep 2005 09:13:38 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EGCHn-000Idz-Bx for namedroppers@ops.ietf.org; Fri, 16 Sep 2005 09:13:35 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j8G9DW3u021454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 16 Sep 2005 11:13:33 +0200 From: Simon Josefsson To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-rfc2538bis-06.txt References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050916:i-d-announce@ietf.org::Bv5hk5+TI/GImRGD:3+fm X-Hashcash: 1:21:050916:namedroppers@ops.ietf.org::3jo1Nsnyx/b9AjIo:5BZh X-Hashcash: 1:21:050916:internet-drafts@ietf.org::3TfLchsSeEg370IK:Ctfa Date: Fri, 16 Sep 2005 11:13:29 +0200 In-Reply-To: (Internet-Drafts@ietf.org's message of "Thu, 15 Sep 2005 15:50:01 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Internet-Drafts@ietf.org writes: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-06.txt Dear WG, FYI: With the -06 document, the last call comments made by Pekka Savola and Edward Lewis, as well as the post last call comments from Peter Koch and Marcos Sanz, should be resolved. Some changes to address Douglas Otis last call comment has been applied, but I believe an "OK" from Douglas is still pending. A rfcdiff against the -05 is availble at: http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis-from--05.diff.html I believe the only pending issue before we can hand this document to the IESG is the issues discussed in the thread with Douglas Otis and myself. All other comments should be address, please prod me if this is not the case. Sadly there is little input from other WG members in the current thread. If you want to help this document forward, then please participate in that discussion! Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From AnneMorris@pewoosuk.com Fri Sep 16 09:00:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGFp7-0005hE-K7 for dnsext-archive@megatron.ietf.org; Fri, 16 Sep 2005 09:00:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14685 for ; Fri, 16 Sep 2005 09:00:11 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGFu5-0005HE-Ei for dnsext-archive@ietf.org; Fri, 16 Sep 2005 09:05:24 -0400 Received: from [59.3.101.86] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1EGFoy-0005PD-RG for dnsext-archive@ietf.org; Fri, 16 Sep 2005 09:00:05 -0400 Received: from Sv7i@localhost by OK3u.int (8.11.6/8.11.6); Fri, 16 Sep 2005 08:23:05 -0600 Message-ID: From: "Wendy Fleisher" Reply-To: "Wendy Fleisher" To: dnsext-archive@ietf.org Cc: aipv6@ietf.org Subject: Top of the Line MS 2003 Software at Guaranteed L0W PRlCES Date: Fri, 16 Sep 2005 09:24:05 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: AnneMorris@pewoosuk.com Content-Type: multipart/mixed; boundary="--GNv2654BIjBZ2RTs" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 bcaU ----GNv2654BIjBZ2RTs Content-Type: text/html; Content-Transfer-Encoding: quoted-printable o
Opt-in Email Special Offer   = ;  unsubscribe me
=

<= td width=3D5 bgcolor=3D#000080>
SEARCH

<= td vAlign=3Dbottom>

TOP 10 NEW TITLES

34=

 = ON SALE NOW!

 1 Office Pro 2003
 2 Adobe Photoshop 9.0
  Windows XP Pro
  Adobe Acrobat 7 Pro
 5 Flash MX 2004
 6 Corel Draw 12
 7 Norton Antivirus 2005
&n= bsp;8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
 10<= /td> Adobe Illustrator 1= 1
  See more by this= manufacturer
   Microsoft
   Symantec
   Adobe
  Customers also bought
   these other items...

Microsoft Office Professional Ed= ition *2003*
Microsoft<= br>

<= td vAlign=3Dtop noWrap>
Choose:
 
= Price:
= List Price:$499.00
$69.99
You Save:$429.01 (86%)



Availability: Available for INSTANT download!
<= b>Coupon Code: sp5WU
 

Sal= es Rank: #1
System requirements  |  Other Versions
Date Coup= on Expires: August 31st, 2005
Average= Customer Review:3D"5 Based on 138898 reviews. Write a review.

<= tr>

Adobe Photoshop CS2 V 9= 0
Adobe=

Choose:
 

=
List Pr= ice:$599.00
Pric= e:$69.99
You Save:$529.01 (90%)



Availability: Available for INSTANT download!
Cou= pon Code: cGYkqFs
 

Sales = Rank: #2
System requirements  |  Other Versions
Date Coupon = Expires: August 31st, 2005
Average Cu= stomer Review:3D"5 Based on 1868 reviews. Write a review.

<= /td>

Microsoft Win= dows XP Professional or Longhorn Edition
Microsoft

Choose:
 

=

List Price:$279.00
Price:$49.99
You Save:<= /td>$229.01 (= 85%)



Availability:= Available for INSTANT download!
Coupon Code: 693tiaX
&= nbsp;

Sales Rank: #3
System requirements=   |  Other Versions
Date Coupon Expires: August 31st, 2= 005
Average Customer Review:3D"5 = Based on 1615 reviews. Write a revie= w.

Adobe Acrobat Professional V 7.0
= Adobe

Choose:<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 width=3D164>
 

List Price:$499.00
Price:$69.99
You Save:$429.0= 1 (85%)

=

Availabili= ty: Available for INSTANT download!
Coupon Code: kXZklRGto<= br>  

Sales Rank: #4
System require= ments  |  Other Versio= ns
Date Coupon Expires: August 31= st, 2005
Average Customer Review: Based on 13193 reviews. Write a r= eview.

----GNv2654BIjBZ2RTs-- From owner-namedroppers@ops.ietf.org Fri Sep 16 10:04:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGp2-000742-69 for dnsext-archive@megatron.ietf.org; Fri, 16 Sep 2005 10:04:13 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18460 for ; Fri, 16 Sep 2005 10:04:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EGGkJ-000EEV-JE for namedroppers-data@psg.com; Fri, 16 Sep 2005 13:59:19 +0000 Received: from [213.154.224.90] (helo=dhcp-90.nlnetlabs.nl) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EGGkG-000EE0-OK for namedroppers@ops.ietf.org; Fri, 16 Sep 2005 13:59:16 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by dhcp-90.nlnetlabs.nl (Postfix) with ESMTP id E366E1C5FE9; Fri, 16 Sep 2005 15:59:13 +0200 (CEST) In-Reply-To: <200509131745.j8DHjxx09029@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200509131745.j8DHjxx09029@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8152015F-E132-462F-AC7E-A4D6997493B1@ripe.net> Cc: Andreas Gustafsson Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Typo/bug in RFC 3597 Date: Fri, 16 Sep 2005 15:59:11 +0200 To: namedroppers@ops.ietf.org X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 13, 2005, at 19:45 , Peter Koch wrote: > When advancing 3597 it might be a good idea to drop section 7 > completely, > which would also reduce the number of necessary down-references. > The above > list would then be corrected in the RFC 4034 errata document. This sounds like a good idea and off-list Andreas has been found prepared to edit the changes, it will solve one of the down-ref problem that is now holding 3597 to go to draft std. In addition to the above suggestion the intention is to solve the "downref" problem with 2163 by treating 2163 as informational and bein updated by 3597 (cf https://datatracker.ietf.org/public/ pidtracker.cgi?command=view_comment&id=38217) Please voice objections soon, if you have any. - --Olaf PS see https://datatracker.ietf.org/public/pidtracker.cgi? command=view_id&dTag=3597&rfc_flag=1 for the complete IESG discussion history. - -------------------------------------- Olaf M. Kolkman As of September 1, 2005 my email address is olaf@nlnetlabs.nl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDKs+vtN/ca3YJIocRAltYAKCEq6zOzXNvNgsVPnTdft1jrHhyOwCgh8Pr gTQKsp2uc0vQHb3rpXe1ou8= =5HLu -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 16 10:09:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGu4-00008z-LI for dnsext-archive@megatron.ietf.org; Fri, 16 Sep 2005 10:09:24 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18950 for ; Fri, 16 Sep 2005 10:09:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EGGrC-000F0V-J5 for namedroppers-data@psg.com; Fri, 16 Sep 2005 14:06:26 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EGGr9-000F01-6q for namedroppers@ops.ietf.org; Fri, 16 Sep 2005 14:06:23 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.3/8.13.3) with ESMTP id j8GE6F7s070571 for ; Fri, 16 Sep 2005 16:06:15 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: <430D8289-1E88-452B-ADF3-7F8B1D97F5BB@NLnetLabs.nl> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: namedroppers@ops.ietf.org From: "Olaf M. Kolkman" Subject: Conclusion WGLC white lies documents Date: Fri, 16 Sep 2005 16:06:14 +0200 X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Colleagues On Jul 28, 2005, at 20:00 we had a last call for the white lies documents http://ops.ietf.org/lists/namedroppers/namedroppers.2005/ msg01184.html This concludes the last call. In that mail I asked for specific guidance on two issues. The _only_ feedback on this document that I can trace is a remark by Peter Koch that he would like to see the document proceed on the standard track. Without having had any guidance from this group I think this is an appropriate way forward: On the issue of having this document update 4034, 4035, so be it. I would like to ask the editors to add appropriate text that reflects what we paraphrased in the last mail on this topic. > - RFC4034 Section 4.1.1 describes how the NSEC "next domain name" > field > contains the next owner name in the canonical ordering of the zone. > Again, Epsilon does something different. > > - RFC4035, Section 2.3, 3rd paragraph requires (with a 2119 MUST NOT) > that an NSEC RR not be the only RR at a given owner name. When > Epsilon NSEC RRs are synthesised to cover a non-existing name, that > constraint is violated. This should not require any changes to > deployed code, but it is a change in 2119 language. > > Once that text is published we'll forward the documents, without another LC, to the IESG, to be published on the standards track. - - --Olaf & Olafur DNSEXT Co-hairs. PS. Apologies for concluding this last call so long after its dead-line, - ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ We have employment opportunities, see the website. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDKtFWtN/ca3YJIocRAnIUAJ4zuvnfYOO2HgU0ozzhz9sWXIRIUACfUwBZ LcShR8aLhO7H9hpRoIV5vZw= =AUGw -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 16 11:48:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGIRc-00015N-Rp for dnsext-archive@megatron.ietf.org; Fri, 16 Sep 2005 11:48:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25120 for ; Fri, 16 Sep 2005 11:48:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EGIM0-000MKZ-0D for namedroppers-data@psg.com; Fri, 16 Sep 2005 15:42:20 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EGILu-000MKB-Kr for namedroppers@ops.ietf.org; Fri, 16 Sep 2005 15:42:15 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.3/8.13.3) with ESMTP id j8GFg6p8071266; Fri, 16 Sep 2005 17:42:07 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <20050916073200.T17799@fledge.watson.org> References: <430D8289-1E88-452B-ADF3-7F8B1D97F5BB@NLnetLabs.nl> <20050916073200.T17799@fledge.watson.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Conclusion WGLC white lies documents Date: Fri, 16 Sep 2005 17:42:01 +0200 To: Sam Weiler X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam, I have CC-ed namedroppers, since your confusion might be shared, I hope you do not mind. On Sep 16, 2005, at 16:33 , Sam Weiler wrote: >> On the issue of having this document update 4034, 4035, so be it. >> I would like to ask the editors to add appropriate text that >> reflects what we paraphrased in the last mail on this topic. >> > > I'm confused. I thought epsilon did, in fact, have the appropriate > text re: updating. Can you be more specific? Sorry, this is my error. Off course the text as it is now updates 4034 and 4035. We did not get consensus to remove the need to update 4034/4035 (as paraphrased in the WGLC). In other words there is no need to rev the doc. > >> Once that text is published we'll forward the documents, without >> another LC, to the IESG, to be published on the standards track. >> > > I think the p-s doc was supposed to be informational from the > beginning, not standards. > Well in the last call we actually proposed the p-s to go to experimental. I interpreted the feedback during the WG meeting in Paris as a preference for both documents to go on standards track. Your message made me reread the minutes and listen to the recorded archive. It seems that his feedback is mostly towards the online- signing document. So I think we are doing the right thing if we'll forward online-signing for standards track and p-s for experimental. > (...) > there are trivial edits to epsilon that we want to do, > (...) > (We want the word "epsilon" to appear in the text, and maybe the > title, since that's how people refer to it. and one or two trivial > text errors) As for the minor edits you mentioned, we wait for version 01 to appear before pushing to the IESG. There does not seem to be a need for a new last call. - --Olaf - ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ We have employment opportunities, see the website. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDKufOtN/ca3YJIocRAkCOAKDfO3KCZ9KcjDkhrimrRPL69HxCzgCeLdgl EY3O/U/2yv6nykNHrb9ujxs= =qW0n -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 16 14:54:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGLLe-0006dZ-Mr for dnsext-archive@megatron.ietf.org; Fri, 16 Sep 2005 14:54:11 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03975 for ; Fri, 16 Sep 2005 14:54:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EGLG2-000Bb4-Kg for namedroppers-data@psg.com; Fri, 16 Sep 2005 18:48:22 +0000 Received: from [64.142.19.5] (helo=b.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EGLFr-000BaD-DK for namedroppers@ops.ietf.org; Fri, 16 Sep 2005 18:48:11 +0000 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j8GIm3TA003089 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 16 Sep 2005 11:48:04 -0700 In-Reply-To: References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Date: Fri, 16 Sep 2005 11:48:02 -0700 To: Simon Josefsson X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sep 16, 2005, at 1:58 AM, Simon Josefsson wrote: > Douglas Otis writes: > >> >> You missed the point that I was attempting to make. Adoption by many >> of the larger domains may create a rapid change in the baseline. Do >> not depend upon only a few using this record. >> > > I don't. But I simply don't see the same problems that you do when > many people would start to use it. Distributing the certificates > through DNS is a small step compared to everything else that has to be > modified to support a e-mail PKI on a wide scale. Thus fixing any > implementations problems in DNS servers that there may be (although I > am not aware of any problems affecting this, nor do I expect there to > be any) can be done without any rush. Rather than 10 years, the time frame could be much less. Consider deployment at the MTA rather than at the MUA. There is potential for this being done at both locations. When done at the MTA, changes can be far more rapid. >> While a list of cert serial numbers may be small for some domains, >> this may not be the case where it is most needed. This added record >> may grow to be very large as well. Of course, this could use TCP >> fall-back or a redirection to a standard cert service. This >> situation has made implementing revocation mechanisms questionable, >> and this takes away control from the sending domain. The shear size >> of the data that needs to be copied to millions of places still >> represents a sizable task. Shortening the duration of the record to >> keep the CRL within reason also means this information needs to be >> copied even more frequently. At some point, it may be easier to just >> get the cert. >> > > OpenPGP revocation certificates doesn't work like you describe. There > is no list of cert serial numbers. OpenPGP disperses revocation information and uses key finger-prints. This dispersal technique increases the overall size and number of exchanges to obtain the aggregate revocation information. This operation is performed at some time-frame by every node holding an associated key. What is a reasonable time-frame for key revocation? > It appears as if you are talking about X.509. For X.509, there are > more efficient revocation checking methods than using CRLs, there is > OCSP and XKMS. Once a session is required to either of these servers, what is the point of also placing the cert information into DNS? It seems revocation is an item often lacking with respect to compliance within a diverse deployment. This goes back to the reasonable time-frame question. >>> The draft doesn't imply MTA's should lookup certificates nor verify >>> the signature. I think you are jumping to conclusions here. Today, >>> not even many MUAs are able to lookup certificates and verify >>> signatures. >>> >> >> That situation is changing very rapidly. >> > > Yes, but I'm talking about this document. Imagine the worst case and then consider what advice can lessen the potential for harm. Looking at DKIM and imagining how this document could be applied does not see unreasonable. >>> All these numbers assume many things that are not in the draft, and >>> that nobody has proposed to do. >>> >> >> What do you mean by things? >> > > Performing certificate lookups and verification inside MTAs nor MDA. > > Eventually, a MUA may want to lookup the certificate and perform > verification. But this is done on the user's request, and is > currently handled by LDAP or HTTP. If DNS is used, the LDAP/HTTP > traffic would go away (including the DNS lookups resulting from the > LDAP/HTTP requests). The total network impact is the same, or > actually lower because DNS is more efficient. I don't see where the > problem is. It depends upon how this information is deployed, how it is used, and the reaction time related to revocation. >> This text seems to suggest that when wildcards are used to be >> careful. Certs and DNSSEC will get ugly with wildcards. Perhaps >> adding or replacing this sentence with: >> >> It is not recommended that a CERT RR be published as a wildcard. >> > > I have problems agreeing with this. I see no justification for > recommending against CERT RRs at wildcard names. Wildcard records offer the possibility of unexpected names referring to the cert. In addition, when DNSSEC is deployed, a wildcard requires extra steps to validate. These extra steps may not be implemented properly and may create possible security issues. It would seem a simple recommendation against the use of wildcards would be a stronger caution than saying be careful. It would not be saying this MUST NOT be used as a wildcard. >> When CERT RRs are found to occupy too much cache, it may be required >> to limit the maximum TTL for this type of record. >> > > DNS caches must be able to handle too much cached data, typically they > discard data that hasn't been used for a while. Creating additional > administrator burdens to protect poor DNS cache implementations is the > wrong approach, in my opinion. The cache is within the recipient's domain where an inordinate size and number of user-certs could rapidly consume DNS cache. This cache would be better reserved for other record types more critical to overall performance. When this RR type is accommodated, there may be need to consider this MAX TTL provision. >>> Deploying CERT RRs to support digitally signed e-mail change >>> the >>> access patterns of DNS lookups from per-domain to per-user. If >>> digitally signed e-mail, and a key/certificate lookup based on >>> CERT RRs, is deployed on a wide scale, this may lead to an >>> increased DNS load, with potential performance and cache >>> effectiveness consequencess. Whether this load increase will be >>> noticable or not is not known. >>> >> >> >> I would drop the last sentence. >> > > Without it, it is implied that we know for certain that there may be > potential performance and cache effectiveness consequences. I don't > believe we know this. Expressing these doubts is thus fair to the > reader. You have already indicated this "may lead". (consequencess should be consequences.) You have already indicated the modeling for the use of this type of CERT RR is unknown and can be used in a highly variable fashion. I see no problem erring on the side of caution, rather than reinforcing an inability to judge consequences. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 16 18:18:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGOWy-0007gz-TH for dnsext-archive@megatron.ietf.org; Fri, 16 Sep 2005 18:18:05 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23382 for ; Fri, 16 Sep 2005 18:18:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EGORs-0004OE-8o for namedroppers-data@psg.com; Fri, 16 Sep 2005 22:12:48 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EGORq-0004Nz-My for namedroppers@ops.ietf.org; Fri, 16 Sep 2005 22:12:46 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j8GM8Tf1006010 for ; Fri, 16 Sep 2005 18:08:29 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAPjaiVl; Fri, 16 Sep 05 18:08:26 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j8GMALKI006261; Fri, 16 Sep 2005 18:10:23 -0400 (EDT) Date: Fri, 16 Sep 2005 18:10:21 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: vixie@isc.org cc: Namedroppers Subject: state of vixie-dnssec-ter? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Using the draft dependency graphs at tools.ietf.org, I noticed that NSEC3 has two references to expired docs: an informative reference to dnsext-trustupdate-threshhold and an in-line (only) reference to vixie-dnssec-ter. Presumably the first will be updated at some point. Is vixie-dnssec-ter dead? I think it only existed as namedroppers posts, in any case... http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00813.html http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00967.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Sep 17 12:53:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGfwn-0007iz-N7 for dnsext-archive@megatron.ietf.org; Sat, 17 Sep 2005 12:53:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24370 for ; Sat, 17 Sep 2005 12:53:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EGfrE-000EPB-S3 for namedroppers-data@psg.com; Sat, 17 Sep 2005 16:48:08 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EGfrE-000EOz-9z for namedroppers@ops.ietf.org; Sat, 17 Sep 2005 16:48:08 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C3EF911450 for ; Sat, 17 Sep 2005 16:48:07 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: state of vixie-dnssec-ter? In-Reply-To: Your message of "Fri, 16 Sep 2005 18:10:21 -0400." References: Date: Sat, 17 Sep 2005 16:48:07 +0000 Message-Id: <20050917164807.C3EF911450@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # Is vixie-dnssec-ter dead? I think it only existed as namedroppers posts, in # any case... # # http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00813.html # http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00967.html if anybody, even one person, tells me that it's useful, i'll dress it up and send it in. so far noone, not even one person, has said it was useful other than as a discussion point for discussions which have now moved on. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Sep 17 13:30:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGgW0-00065G-Te for dnsext-archive@megatron.ietf.org; Sat, 17 Sep 2005 13:30:17 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25429 for ; Sat, 17 Sep 2005 13:30:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EGgTW-000Hf4-8O for namedroppers-data@psg.com; Sat, 17 Sep 2005 17:27:42 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EGgTU-000Heo-OA for namedroppers@ops.ietf.org; Sat, 17 Sep 2005 17:27:40 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id CA66D2E00A; Sat, 17 Sep 2005 19:27:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id C86CC2DF21; Sat, 17 Sep 2005 19:27:38 +0200 (CEST) Date: Sat, 17 Sep 2005 19:27:38 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Paul Vixie cc: Namedroppers Subject: Re: state of vixie-dnssec-ter? In-Reply-To: <20050917164807.C3EF911450@sa.vix.com> Message-ID: References: <20050917164807.C3EF911450@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk It's useful. Roy On Sat, 17 Sep 2005, Paul Vixie wrote: > # Is vixie-dnssec-ter dead? I think it only existed as namedroppers posts, in > # any case... > # > # http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00813.html > # http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00967.html > > if anybody, even one person, tells me that it's useful, i'll dress it up > and send it in. so far noone, not even one person, has said it was useful > other than as a discussion point for discussions which have now moved on. > > -- > 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: > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Sep 17 13:44:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGgjZ-0000vQ-Kw for dnsext-archive@megatron.ietf.org; Sat, 17 Sep 2005 13:44:17 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25964 for ; Sat, 17 Sep 2005 13:44:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EGghP-000Iiy-3h for namedroppers-data@psg.com; Sat, 17 Sep 2005 17:42:03 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EGghN-000Iil-Ja for namedroppers@ops.ietf.org; Sat, 17 Sep 2005 17:42:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3122311449 for ; Sat, 17 Sep 2005 17:42:01 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: state of vixie-dnssec-ter? In-Reply-To: Your message of "Sat, 17 Sep 2005 19:27:38 +0200." References: <20050917164807.C3EF911450@sa.vix.com> Date: Sat, 17 Sep 2005 17:42:01 +0000 Message-Id: <20050917174201.3122311449@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # It's useful. for what, prospectively? right now it appears that NSEC3 has its own coexistence mechanisms, that white-lies updates the -BIS docset, and there is nothing else on the horizon that could deserve to be called -TER. shouldn't we wait to define a transition mechanism until we know where we're going? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Sep 18 07:42:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGxYq-0006Pg-8D for dnsext-archive@megatron.ietf.org; Sun, 18 Sep 2005 07:42:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18963 for ; Sun, 18 Sep 2005 07:42:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EGxT0-000KuL-Lo for namedroppers-data@psg.com; Sun, 18 Sep 2005 11:36:18 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EGxSx-000Ktp-Cz for namedroppers@ops.ietf.org; Sun, 18 Sep 2005 11:36:16 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 7B0BC33C1E; Sun, 18 Sep 2005 12:36:04 +0100 (BST) Message-ID: <432D5126.7070106@algroup.co.uk> Date: Sun, 18 Sep 2005 12:36:06 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie CC: Namedroppers Subject: Re: state of vixie-dnssec-ter? References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> In-Reply-To: <20050917174201.3122311449@sa.vix.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > # It's useful. > > for what, prospectively? right now it appears that NSEC3 has its own > coexistence mechanisms, that white-lies updates the -BIS docset, and > there is nothing else on the horizon that could deserve to be called -TER. There are those that claim that NSEC3's introduction needs to be signalled, and hence that -ter is required. This is why we reference it in the NSEC3 I-D. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Sep 18 13:14:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EH2kg-0004JV-VM for dnsext-archive@megatron.ietf.org; Sun, 18 Sep 2005 13:14:57 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04485 for ; Sun, 18 Sep 2005 13:14:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EH2eN-000M93-Gs for namedroppers-data@psg.com; Sun, 18 Sep 2005 17:08:23 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EH2eL-000M8m-VF for namedroppers@ops.ietf.org; Sun, 18 Sep 2005 17:08:21 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0A61A11455 for ; Sun, 18 Sep 2005 17:08:21 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: state of vixie-dnssec-ter? In-Reply-To: Your message of "Sun, 18 Sep 2005 12:36:06 +0100." <432D5126.7070106@algroup.co.uk> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432D5126.7070106@algroup.co.uk> Date: Sun, 18 Sep 2005 17:08:21 +0000 Message-Id: <20050918170821.0A61A11455@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # There are those that claim that NSEC3's introduction needs to be signalled, # and hence that -ter is required. This is why we reference it in the NSEC3 # I-D. well, ok then. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 19 06:28:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHItN-0008AK-JK for dnsext-archive@megatron.ietf.org; Mon, 19 Sep 2005 06:28:58 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10421 for ; Mon, 19 Sep 2005 06:28:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHIor-00007k-Kj for namedroppers-data@psg.com; Mon, 19 Sep 2005 10:24:17 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EHIoo-00007P-4i for namedroppers@ops.ietf.org; Mon, 19 Sep 2005 10:24:14 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j8JAO003028379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Sep 2005 12:24:04 +0200 From: Simon Josefsson To: Douglas Otis Cc: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050919:namedroppers@ops.ietf.org::VUe00w/ymHqPgCib:0UQV X-Hashcash: 1:21:050919:dotis@mail-abuse.org::fRJWUdFBoXOmUSTt:EPnN Date: Mon, 19 Sep 2005 12:23:51 +0200 In-Reply-To: (Douglas Otis's message of "Fri, 16 Sep 2005 11:48:02 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm trying to wrap this up, so I'm not responding to most of your e-mail that is not strictly related to modifying the document. Douglas, have you seen the -06 version? You can get it from: It would be good if we could move back the discuss to whatever changes to the document that you feel are needed. Please review the new document to see whether it address your concerns. Several suggestions from this thread has been incorporated. Douglas Otis writes: > In addition, when DNSSEC is deployed, a wildcard requires extra > steps to validate. These extra steps may not be implemented > properly and may create possible security issues. I strongly disagree with this view. Wildcard handling must be implemented correctly in a DNSSEC application. DNSSEC is insecure if wildcards aren't handled correctly. > It would seem a simple recommendation against the use of wildcards > would be a stronger caution than saying be careful. It would not be > saying this MUST NOT be used as a wildcard. But the document do caution against using wildcards: Note that this section describes an application-based mapping from the name space used in a certificate to the name space used by DNS. The DNS does not infer any relationship amongst CERT resource records based on similarities or differences of the DNS owner name(s) of CERT resource records. For example, if multiple labels are used when mapping from a CERT identifier to a domain name then care must be taken in understanding wildcard record synthesis. I believe your concern here has been addressed. Note that this paragraph was added after the last call completed, to address another last call comment. If you'd like to see different wording, please propose text. >>>> Deploying CERT RRs to support digitally signed e-mail change >>>> the >>>> access patterns of DNS lookups from per-domain to per-user. If >>>> digitally signed e-mail, and a key/certificate lookup based on >>>> CERT RRs, is deployed on a wide scale, this may lead to an >>>> increased DNS load, with potential performance and cache >>>> effectiveness consequencess. Whether this load increase will be >>>> noticable or not is not known. >>>> >>> >>> >>> I would drop the last sentence. >>> >> >> Without it, it is implied that we know for certain that there may be >> potential performance and cache effectiveness consequences. I don't >> believe we know this. Expressing these doubts is thus fair to the >> reader. > > You have already indicated this "may lead". (consequencess should be > consequences.) You have already indicated the modeling for the use > of this type of CERT RR is unknown and can be used in a highly > variable fashion. I see no problem erring on the side of caution, > rather than reinforcing an inability to judge consequences. If I drop that sentence, are you happy with the document? I still believe the paragraph without the last sentence paint the wrong picture for the reader, but your argument here is convincing, and because (sadly) nobody else has stepped into this discussion to give more opinions on the matter, I can make this change if doing so will move the document ahead. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 19 07:25:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHJm1-0004Yz-Ur for dnsext-archive@megatron.ietf.org; Mon, 19 Sep 2005 07:25:26 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12963 for ; Mon, 19 Sep 2005 07:25:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHJiq-0005BK-Cq for namedroppers-data@psg.com; Mon, 19 Sep 2005 11:22:08 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EHJim-0005Ap-HS for namedroppers@ops.ietf.org; Mon, 19 Sep 2005 11:22:04 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id DE4E9C2DA8; Mon, 19 Sep 2005 12:22:02 +0100 (BST) Date: Mon, 19 Sep 2005 12:21:57 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Simon Josefsson , Douglas Otis Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Message-ID: In-Reply-To: References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 19 September 2005 12:23 +0200 Simon Josefsson wrote: >> In addition, when DNSSEC is deployed, a wildcard requires extra >> steps to validate. These extra steps may not be implemented >> properly and may create possible security issues. > > I strongly disagree with this view. Wildcard handling must be > implemented correctly in a DNSSEC application. DNSSEC is insecure if > wildcards aren't handled correctly. I'd tend to agree with that. If people do not implement algorithms according to the specifications, that isn't a security concern relating to the specifications, merely concerns about deficient implementations thereof. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 19 08:23:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHKgb-00029T-IS for dnsext-archive@megatron.ietf.org; Mon, 19 Sep 2005 08:23:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16517 for ; Mon, 19 Sep 2005 08:23:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHKci-000ANv-NI for namedroppers-data@psg.com; Mon, 19 Sep 2005 12:19:52 +0000 Received: from [204.9.221.21] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EHKcg-000ANf-LO for namedroppers@ops.ietf.org; Mon, 19 Sep 2005 12:19:50 +0000 Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 523371 for namedroppers@ops.ietf.org; Mon, 19 Sep 2005 08:21:24 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 19 Sep 2005 08:19:49 -0400 To: namedroppers@ops.ietf.org From: Margaret Wasserman Subject: Fwd: Summary of the LLMNR Last Call Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sorry, I mistyped "namedroppers" on this message the first time... Margaret >Date: Sun, 18 Sep 2005 10:09:07 -0400 >To: ietf@ietf.org >From: Margaret Wasserman >Subject: Summary of the LLMNR Last Call >Cc: iesg@ietf.org, namedropers@ops.ietf.org >Bcc: >X-Attachments: > > >Hi All, > >As I am sure many of you have noticed, there was extensive >discussion during the IETF Last Call for the "Link Local Multicast >Name Resolution (LLMNR)" specification that is currently available >as draft-ietf-dnsext-mdns-43.txt. Thanks to all who participated! >The discussion appears to have quieted down at this point, so I will >attempt to summarize the discussion and see if we can reach some >conclusions. > >First, I'll give a brief summary of the responses received: > >By my count 38 separate individuals responded to the Last Call. >Some of these people responded on the IETF list, some on the IESG >list, and some privately to me. People who responded privately to >others were not counted :-). > >Of the 38 respondents, only 18 of them stated an explicit opinion on >the publication of LLMNR as a Proposed Standard RFC. Others >provided useful facts to inform the discussion and/or discussed >other topics, such as the structure of the DNS root. I was quite >conservative about how I determined people's opinions, and I tried >not to infer peoples' opinions from factual statements about only >one of the protocols, etc. > >Of the 18 people who expressed an explicit opinion, 14 people argued >against the publication of LLMNR as a Proposed Standard. I realize >that we don't vote on specifications in the IETF. I also realize >that the IETF LC is worded to encourage the statements of objection >and not to encourage statements of support. However, the fact that >14 separate individuals felt strongly enough that this document >should not be published to say so explicitly in response to an IETF >LC must be taken quite seriously. > >In addition to a few minor nits or comments, all of which have been >captured in the issue tracker, there seem to be three major concerns >with the publication of this protocol: > >(1) Concerns that publication of this protocol will be confusing or >actively harmful given the existing wide deployment of Apple's mDNS >protocol. > >Concerns here seem to hinge on whether end-users will use .local >extensions because they _think_ that they have mDNS available when >they actually do not, which, when combined with LLMNR's default >behavior of querying the DNS first, will result in a larger number >of .local lookups in the global DNS. There are several possible >ways to alleviate this issue, including suppression of global >queries for .local domains as part of an LLMNR implementation, or >suppressing recursive lookups for names in the .local domain on the >local DNS server, but none of these solutions is currently specified >in the LLMNR specification or elsewhere. > >(2) Security concerns have been raised about the fact that >applications on hosts that implement LLMNR will not be able to tell >if a response has come from the DNS or from a local lookup. > >This opens applications to attack from nodes that can block global >DNS access and substitute local resolution. Some ways to eliminate >or alleviate this issue might include: using different domains >(such as .local) to distinguish global and local lookups, explicitly >using different global and local lookup mechanisms at the >application level, only falling back to local resolution when a "no >such name" response is received from the global DNS, placing further >limits on what answers are acceptable from local lookups (only for >certain domains configured as local, only within certain IP >subnets...). > >This security concern does not seem to be adequately explored and >addressed in the LLMNR specification. At the very minimum, it >should be carefully explored in the security considerations section >so that implementers and users can be aware of these concerns. > >(3) Separate, but perhaps underlying both of the previous issues, >there seems be a fundamental disagreement about what technical >approach we should take to link-local name lookup. LLMNR takes the >approach that local lookups should use the same names as global >lookups and that upper layers should not care whether a name was >resolved in the global DNS or locally, essentially making the local >lookup mechanism an extension of the DNS. mDNS takes the approach >that local lookups should be distinguishable from global lookups and >accomplishes this through the use of a special local domain (.local). > >This is an issue that has been discussed extensively in the DNSEXT >WG at various times, and consensus was found to proceed with the >LLMNR approach. However, it is not clear whether that consensus is >held by the wider IETF community, as there are at least 14 people in >the IETF who have explicitly disagreed with that decision during >IETF LC. > >So, based on the IETF LC discussion of this document, I have come to >two conclusions: > >CONCLUSION 1: There are at least two blocking technical issues with >the LLMNR specification (raised in items #1 and #2 above) that would >need to be resolved before this document is technically ready for >publication as an Proposed Standard RFC. We should resolve these >issues and determine that the IETF community is satisfied with their >resolution before sending the document to IESG review. > >CONCLUSION 2: The IETF community does not currently have consensus >to standardize a local name resolution mechanism that takes the >approach described in LLMNR. Further work would be needed to >establish the IETF consensus required to publish this document as a >Proposed Standard. > >Based on these conclusions, I do not intend to forward the LLMNR >specification to the IESG for review and approval. I am planning to >send the document back to the WG for resolution of these issues and >would issue another IETF LC if/when the WG believes that they have a >document that will address these issues and reach IETF consensus. > >We have a number of choices about how to proceed in this situation, >but before we talk about next steps, I would like to hear any >feedback that people might have regarding my summary of the >discussion so far and the conclusions that I have reached from it. > >Margaret > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 19 09:32:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHLkn-0003hM-7C for dnsext-archive@megatron.ietf.org; Mon, 19 Sep 2005 09:32:17 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21032 for ; Mon, 19 Sep 2005 09:32:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHLhE-000HR1-DW for namedroppers-data@psg.com; Mon, 19 Sep 2005 13:28:36 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EHLhC-000HQj-Bq for namedroppers@ops.ietf.org; Mon, 19 Sep 2005 13:28:34 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j8JDSIO3077482; Mon, 19 Sep 2005 09:28:22 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> Date: Mon, 19 Sep 2005 08:27:03 -0400 To: Simon Josefsson From: Edward Lewis Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Cc: Douglas Otis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Potential rat hole... At 12:23 +0200 9/19/05, Simon Josefsson wrote: >Douglas Otis writes: > >> In addition, when DNSSEC is deployed, a wildcard requires extra >> steps to validate. These extra steps may not be implemented >> properly and may create possible security issues. > >I strongly disagree with this view. Wildcard handling must be >implemented correctly in a DNSSEC application. DNSSEC is insecure if >wildcards aren't handled correctly. If any part of any system is improperly implemented, problems ensue. Wild cards aren't especially more complex. >> It would seem a simple recommendation against the use of wildcards >> would be a stronger caution than saying be careful. It would not be >> saying this MUST NOT be used as a wildcard. > >But the document do caution against using wildcards: > > Note that this section describes an application-based mapping from > the name space used in a certificate to the name space used by DNS. > The DNS does not infer any relationship amongst CERT resource records > based on similarities or differences of the DNS owner name(s) of CERT > resource records. For example, if multiple labels are used when > mapping from a CERT identifier to a domain name then care must be > taken in understanding wildcard record synthesis. > >I believe your concern here has been addressed. Note that this >paragraph was added after the last call completed, to address another >last call comment. If you'd like to see different wording, please >propose text. I agree with Simon. The "danger" is that an application may assume that the synthesized record's owner name matches the certificate's identifying information. This danger is in the text Simon has already included. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 19 09:32:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHLkt-0003i0-05 for dnsext-archive@megatron.ietf.org; Mon, 19 Sep 2005 09:32:23 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21042 for ; Mon, 19 Sep 2005 09:32:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHLiE-000HXB-CE for namedroppers-data@psg.com; Mon, 19 Sep 2005 13:29:38 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EHLiB-000HWo-8j for namedroppers@ops.ietf.org; Mon, 19 Sep 2005 13:29:35 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.3/8.13.3) with ESMTP id j8JDTLic048072; Mon, 19 Sep 2005 15:29:21 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <20050917174201.3122311449@sa.vix.com> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: state of vixie-dnssec-ter? Date: Mon, 19 Sep 2005 15:29:20 +0200 To: Paul Vixie X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > shouldn't we wait to define a transition mechanism until we know where > we're going? Although this list has been silence on the engineering of automatic key rollover (except for Jim's mail [1]) we did discuss the issue in Paris. Mike's design does need some of "backwards incompatible" addition, hence a transition mechanism (if I'm not mistaken). I wonder why "algorithm roll" is not sufficient as a transition mechanism, did we ever conclude it has deficiencies compared to type roll? Also see draft-ietf-dnsext-dnssec-experiments-01 that covers that mechanism and is supposed to be last called soon (at least that is what we promised during the last meeting). - --Olaf [1]: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/ msg01231.html - ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ We have employment opportunities, see the website. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDLr0wtN/ca3YJIocRAgYHAJ445UV02BHfh4MIe51445QdmWD1wQCeMVar EurNCNBt36/F4eV05z5V6xA= =8AaK -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 19 10:34:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMj8-00011w-E5 for dnsext-archive@megatron.ietf.org; Mon, 19 Sep 2005 10:34:40 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24878 for ; Mon, 19 Sep 2005 10:34:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHMfD-000NwO-Li for namedroppers-data@psg.com; Mon, 19 Sep 2005 14:30:35 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EHMfC-000Nw9-0F for namedroppers@ops.ietf.org; Mon, 19 Sep 2005 14:30:34 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 419CA11449 for ; Mon, 19 Sep 2005 14:07:03 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard In-Reply-To: Your message of "Mon, 19 Sep 2005 08:27:03 -0400." References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> Date: Mon, 19 Sep 2005 14:07:03 +0000 Message-Id: <20050919140703.419CA11449@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # Potential rat hole... potential? # >> In addition, when DNSSEC is deployed, a wildcard requires extra steps to # >> validate. These extra steps may not be implemented properly and may # >> create possible security issues. # > # > I strongly disagree with this view. Wildcard handling must be implemented # > correctly in a DNSSEC application. DNSSEC is insecure if wildcards aren't # > handled correctly. # # If any part of any system is improperly implemented, problems ensue. Wild # cards aren't especially more complex. agreed in general, but as a specific example wildcards demonstrate the likelihood that no matter how clear a specification is, implementors are likely to get it wrong, and arguments will ensue as to interpretation. if there's a way to turn this point into a document improvement, it's to come up with some kind of objective complexity metric and state that when complexity is higher, the text must be even clearer and better reviewed. i just can't think of which document to improve in that way. certainly not the storing-certs draft, which is quite clear enough by this time. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 19 10:58:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHN6L-00066A-UV for dnsext-archive@megatron.ietf.org; Mon, 19 Sep 2005 10:58:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26935 for ; Mon, 19 Sep 2005 10:58:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHN3v-0000bG-Lw for namedroppers-data@psg.com; Mon, 19 Sep 2005 14:56:07 +0000 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EHN3r-0000ae-BT for namedroppers@ops.ietf.org; Mon, 19 Sep 2005 14:56:03 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO015C23; 19 Sep 2005 10:59:30 -0400 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 19 Sep 2005 10:59:04 -0400 Received: from connotech.com (209.71.204.122) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG015C22; 19 Sep 2005 10:59:00 -0400 Message-ID: <432ED904.2060902@connotech.com> Date: Mon, 19 Sep 2005 11:28:04 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Paul Vixie , Namedroppers Subject: Re: state of vixie-dnssec-ter? References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RCVD_IN_SBL autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: > > Although this list has been silence on the engineering of automatic key > rollover (except for Jim's mail [1]) we did discuss the issue in > Paris. These two messages are also part of the engineering discussion on KSK rollover: From: Mike StJohns Subject: Issues with draft-ietf-dnsext-trustupdate-threshold-00.txt at: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01128.html and From: Thierry Moreau Subject: Re: DNSEXT Minutes @ IETF-63 at: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01204.html > Mike's design does need some of "backwards incompatible" > addition, hence a transition mechanism (if I'm not mistaken). I think this is an overstatement (unless the fact that a zone has more than one KSK creates a backwards incompatibility). In any event, against which key rollover scheme would a scheme be backwards incompatible? The only KSK rollover scheme as of now is no rollover, long-lasting KSK, isn't it? However, I have reservations about the effective security of the two schemes which use a number of KSK with the assumption that a single KSK compromise is sufficiently more likely than a simultaneous compromise of every KSK (for to justify either scheme deployment). As you may know, the document http://www.connotech.com/takrem_for_dnssec_01.pdf contains a comprehensive discussion. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 19 11:23:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNTz-0001jT-Id for dnsext-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:23:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02851 for ; Mon, 19 Sep 2005 11:23:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHNRp-0003Qr-Up for namedroppers-data@psg.com; Mon, 19 Sep 2005 15:20:49 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EHNRk-0003QJ-Mp for namedroppers@ops.ietf.org; Mon, 19 Sep 2005 15:20:45 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j8JFKeG0017700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Sep 2005 17:20:41 +0200 From: Simon Josefsson To: namedroppers@ops.ietf.org Subject: DNSSEC Walker 3.7 now available OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050919:namedroppers@ops.ietf.org::DPqPfRIyTsfk7FbU:CDbf Date: Mon, 19 Sep 2005 17:20:39 +0200 Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi! I have released a new version of the DNSSEC Walker tool. The tool can be used to download DNS zone files when DNSSEC is used. While this tool has been around for a long time -- some of you might remember when I proposed to fix the NXT walking issue back in 2000 and developed this tool to demonstrate the problem -- the recent work of using DNSSEC in .se has increased the relevance of the tool. The tool is now able to download live data not available publicly by other means, to the amusement for those of us who'd like to create statistics over DNS zone contents. See for more information. Please report all problems to me privately; this is just an announcement. Happy hacking, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 19 15:04:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQvp-0002Gh-3B for dnsext-archive@megatron.ietf.org; Mon, 19 Sep 2005 15:04:01 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14678 for ; Mon, 19 Sep 2005 15:03:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHQqR-000Olh-Bv for namedroppers-data@psg.com; Mon, 19 Sep 2005 18:58:27 +0000 Received: from [64.142.19.5] (helo=b.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EHQqP-000OlK-BR for namedroppers@ops.ietf.org; Mon, 19 Sep 2005 18:58:25 +0000 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j8JIwIl6018131 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 19 Sep 2005 11:58:18 -0700 In-Reply-To: References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98A6DD22-0DA4-48CF-BC49-183BE8024451@mail-abuse.org> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Date: Mon, 19 Sep 2005 11:58:20 -0700 To: Simon Josefsson X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sep 19, 2005, at 3:23 AM, Simon Josefsson wrote: > > > > Douglas Otis writes: > > >> In addition, when DNSSEC is deployed, a wildcard requires extra >> steps to validate. These extra steps may not be implemented >> properly and may create possible security issues. >> > > I strongly disagree with this view. Wildcard handling must be > implemented correctly in a DNSSEC application. DNSSEC is insecure if > wildcards aren't handled correctly. RFC2119: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Add in the Performance Consideration section: # It is NOT RECOMMENDED that a CERT RR be published as a wildcard. This is a clear statement that a wildcard requires a higher level of caution. My initial concern was related to added checks. There could be increased overhead and possible implementation exploits. Adding a caution that recommends against wildcards does not prevent the their use, but rather raises caution over their use. This seems like a prudent caution, especially in light of some suggested uses. > But the document do caution against using wildcards: > > Note that this section describes an application-based mapping from > the name space used in a certificate to the name space used by DNS. > The DNS does not infer any relationship amongst CERT resource > records > based on similarities or differences of the DNS owner name(s) of > CERT > resource records. For example, if multiple labels are used when > mapping from a CERT identifier to a domain name then care must be > taken in understanding wildcard record synthesis. Read carefully and you will not find any caution made with respect to the use of a wildcard, but rather how the CERT name space may not be related to DNS owner names. This includes mapping with CNAMEs. In establishing the bridge from the purpose-based name to the content- based name, there is an added comment that cautions about weak relationships between the CERT name space and the name owner of the CERT, especially with multiple labels. As part of this, a reference to a wildcard is made. This says little about the use of the wildcard, but rather is about the nature of the relationship between the domain name the separate CERT name space. If anything, this tangential reference seems to validate the use of the CERT wildcard and offers no specific caution. > > If I drop that sentence, are you happy with the document? Yes. Also add a caution against the use of the wildcard as described. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 19 15:31:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHRMr-0002cP-4y for dnsext-archive@megatron.ietf.org; Mon, 19 Sep 2005 15:31:57 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18256 for ; Mon, 19 Sep 2005 15:31:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHRJe-0001UT-81 for namedroppers-data@psg.com; Mon, 19 Sep 2005 19:28:38 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EHRJd-0001UE-9Z for namedroppers@ops.ietf.org; Mon, 19 Sep 2005 19:28:37 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 0E48C72 for ; Mon, 19 Sep 2005 15:28:36 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 5C87841B6 for ; Mon, 19 Sep 2005 15:28:35 -0400 (EDT) Date: Mon, 19 Sep 2005 15:28:35 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: state of vixie-dnssec-ter? In-Reply-To: References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050919192835.5C87841B6@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Mon, 19 Sep 2005 15:29:20 +0200, Olaf M Kolkman wrote: > > I wonder why "algorithm roll" is not sufficient as a transition > mechanism, did we ever conclude it has deficiencies compared to type > roll? We concluded that type code roll was sufficient; we deferred decision on whether type code roll was necessary. Keep in mind the context at the time we were looking at transition mechanisms: we were trying to figure out whether transition was -possible- so that we'd know whether we could ship DNSSECbis or needed to go back to the drawing board (yet again) for (another) few years while we looked zone walking. In that context, all we needed was one transition mechanism that was demonstrably sufficient. Evaluation of whether any particular transition mechanism necessary depends upon the specifics of the world to which we wish to transition. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 19 16:00:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHRoB-0003Ck-SA for dnsext-archive@megatron.ietf.org; Mon, 19 Sep 2005 16:00:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22569 for ; Mon, 19 Sep 2005 16:00:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHRkz-0003nk-FS for namedroppers-data@psg.com; Mon, 19 Sep 2005 19:56:53 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EHRky-0003nS-Fp for namedroppers@ops.ietf.org; Mon, 19 Sep 2005 19:56:52 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j8JJuQce079155; Mon, 19 Sep 2005 15:56:26 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <98A6DD22-0DA4-48CF-BC49-183BE8024451@mail-abuse.org> References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> <98A6DD22-0DA4-48CF-BC49-183BE8024451@mail-abuse.org> Date: Mon, 19 Sep 2005 15:56:31 -0400 To: Douglas Otis From: Edward Lewis Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Cc: Simon Josefsson , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:58 -0700 9/19/05, Douglas Otis wrote: >This is a clear statement that a wildcard requires a higher level of caution. I believe this is a tempest in a teapot. Wildcards are not dangerous, although they have been misunderstood and poorly considered in many RFCs over the past decade. Hopefully the wcard draft will fix that. >Read carefully and you will not find any caution made with respect to the use >of a wildcard, but rather how the CERT name space may not be related to DNS >owner names. That's explicitly the intent. An application should always be careful of the data it receives, making sure the data is appropriate to the question. In this case, the application should not assume that the queried domain name is related to identifying information in the certificate. It is possible that the queried name bear no 1:1 mapping to the identity borne by the certificate. Specifications ought to be clear and unambiguous, yet retaining as much flexibility as possible. This is why I would recommend against tightening language on this topic. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 19 16:52:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHScZ-0005qb-4I for dnsext-archive@megatron.ietf.org; Mon, 19 Sep 2005 16:52:15 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28703 for ; Mon, 19 Sep 2005 16:52:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHSYq-0007jR-MV for namedroppers-data@psg.com; Mon, 19 Sep 2005 20:48:24 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EHSYp-0007j8-Qo for namedroppers@ops.ietf.org; Mon, 19 Sep 2005 20:48:23 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1EHSYo-000OCA-DQ for namedroppers@ops.ietf.org; Mon, 19 Sep 2005 16:48:22 -0400 Received: by internaut.com (Postfix, from userid 1000) id 117093501C; Mon, 19 Sep 2005 13:48:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 02ADA35015 for ; Mon, 19 Sep 2005 13:48:21 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Mon, 19 Sep 2005 13:48:21 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: Summary of LLMNR Last Call Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >extensions because they _think_ that they have mDNS available when they >actually do not, which, when combined with LLMNR's default behavior of >querying the DNS first, will result in a larger number of .local lookups >in the global DNS. Today more than 95% of all users on the Internet do not have mDNS or LLMNR available. If these users were to type a ".local" name into their Web browsers, this would generate a bogus DNS query. This is not a new problem, and it relates to DNS resolver behavior, not to LLMNR. It is certainly possible to insert text in Section 3 saying "don't send DNS queries for .local". However, if the goal is to change the behavior of DNS resolver implementations (whether they support LLMNR or not) this doesn't make much sense. >Security concerns have been raised about the fact that applications on >hosts that implement LLMNR will not be able to tell if a response has >come from the DNS or from a local lookup. May I remind you that this is not a new problem. For at least twenty years, Internet hosts have implemented multiple name resolution mechanisms in a way that has been transparent to applications. For example, Microsoft Windows systems support both DNS and NetBIOS name resolution mechanisms today. The way in which NetBIOS names and DNS FQDNs are distinguished is that the DNS resolver does not send queries for single-label names; these names are assumed to be NetBIOS names, and so are resolved only via NetBIOS. To my knowledge, no issue has arisen from this. >This security concern does not seem to be adequately explored and >addressed in the LLMNR specification. At the very minimum, it should be >carefully explored in the security considerations section so that >implementers and users can be aware of these concerns. The LLMNR specification specifies a mechanism for link local name resolution. It also discusses potential policies for the sending of link local queries, as well as security mechanisms (IPsec, TSIG, DNSSEC) available for ensuring the integrity and authenticity of responses. What it does not do is to mandate a particular policy. For example, the document could say "By default send LLMNR implementations SHOULD only send queries for single-label names unless security mechanisms (IPsec, TSIG, DNSSEC) are supported." However, in the past there has not been consensus for this. For example, it has been argued that within an adhoc network secured at layer 2, where all hosts are trusted, LLMNR queries may be safely sent for any FQDN. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 19 20:07:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHVft-0003UL-Kt for dnsext-archive@megatron.ietf.org; Mon, 19 Sep 2005 20:07:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09585 for ; Mon, 19 Sep 2005 20:07:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHVaZ-000LjU-12 for namedroppers-data@psg.com; Tue, 20 Sep 2005 00:02:23 +0000 Received: from [64.142.16.245] (helo=a.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EHVaY-000LjE-1W for namedroppers@ops.ietf.org; Tue, 20 Sep 2005 00:02:22 +0000 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j8K02IZT027641 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 19 Sep 2005 17:02:20 -0700 In-Reply-To: References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> <98A6DD22-0DA4-48CF-BC49-183BE8024451@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Date: Mon, 19 Sep 2005 17:02:22 -0700 To: Edward Lewis X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sep 19, 2005, at 12:56 PM, Edward Lewis wrote: > At 11:58 -0700 9/19/05, Douglas Otis wrote: > > >> This is a clear statement that a wildcard requires a higher level >> of caution. >> > > I believe this is a tempest in a teapot. Wildcards are not > dangerous, although they have been misunderstood and poorly > considered in many RFCs over the past decade. Hopefully the wcard > draft will fix that. The concern is not about use of wildcards in general, but rather specifically in the case of user CERT RRs. With user CERT RRs, overhead and security is a greater concern. This draft proposes multiple CERT RRs or CNAMEs be published per individual mailbox. One suggested strategy on the MASS reflector was multiple labels with a wildcard to permit millions of default references to a "good" CERT, versus specific references to a "bad" CERT thereby avoiding CERT revocation. Depending upon whether a specialized cache is used, this strategy could cause user CERT information to become a significant portion of network traffic. A wildcard user CERT RR eases publication for hundreds of millions of mailboxes, but then adds a fair amount overhead and complexity, especially in conjunction with DNSSEC. In general, the strategy should attempt to place burdens on the sender rather than on the receiver. Simply not recommending a wildcard to publish user CERTs conveys a note of caution. This does not prevent use of wildcards, only that there are other considerations that should be made, such as looking for wcard draft. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 20 03:58:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHd0x-000109-13 for dnsext-archive@megatron.ietf.org; Tue, 20 Sep 2005 03:58:07 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14133 for ; Tue, 20 Sep 2005 03:58:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHcwV-0002hQ-OI for namedroppers-data@psg.com; Tue, 20 Sep 2005 07:53:31 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EHcwR-0002gZ-BE for namedroppers@ops.ietf.org; Tue, 20 Sep 2005 07:53:27 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.3/8.13.3) with ESMTP id j8K7r5KI072200; Tue, 20 Sep 2005 09:53:18 +0200 (CEST) (envelope-from olaf@nlnetlabs.nl) In-Reply-To: References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> <98A6DD22-0DA4-48CF-BC49-183BE8024451@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v734) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Date: Tue, 20 Sep 2005 09:53:17 +0200 To: Douglas Otis X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Colleagues, I have the impression we are going around in circles and that we are not converging any further. I'd like to ask if we can all consent with the document as is now (http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis-06.txt). - --Olaf (In capacity of "document shepherd" ) - ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDL72KtN/ca3YJIocRAh4/AKDbCRwSA9litRCBewJgUZP/FZrw6ACcDnUq XA0WL2UqUt5SjPvJeb30Uc0= =4U9o -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 20 05:25:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHeNy-0008IX-Vb for dnsext-archive@megatron.ietf.org; Tue, 20 Sep 2005 05:25:59 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18344 for ; Tue, 20 Sep 2005 05:25:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHeKw-0009ni-R0 for namedroppers-data@psg.com; Tue, 20 Sep 2005 09:22:50 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EHeKt-0009nR-RN for namedroppers@ops.ietf.org; Tue, 20 Sep 2005 09:22:48 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.3/8.13.3) with ESMTP id j8K9MeSf079891; Tue, 20 Sep 2005 11:22:40 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <432ED904.2060902@connotech.com> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Takrem for DNSSEC (was Re: state of vixie-dnssec-ter?) Date: Tue, 20 Sep 2005 11:22:34 +0200 To: Thierry Moreau X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >> Mike's design does need some of "backwards incompatible" >> addition, hence a transition mechanism (if I'm not mistaken). >> > > I think this is an overstatement (unless the fact that a zone has > more than one KSK creates a backwards incompatibility). In any > event, against which key rollover scheme would a scheme be > backwards incompatible? The only KSK rollover scheme as of now is > no rollover, long-lasting KSK, isn't it? The problem is that when flipping the revoke bit the key-tag changes. It could be, although the public key material stays the same, that implementations fail to find the key for validation. AFAIK the specs only mention that keytag collisions can occur. In that sense flipping bits is backwards incompatible, I think :-) > > However, I have reservations about the effective security of the > two schemes which use a number of KSK with the assumption that a > single KSK compromise is sufficiently more likely than a > simultaneous compromise of every KSK (for to justify either scheme > deployment). > > As you may know, the document http://www.connotech.com/ > takrem_for_dnssec_01.pdf contains a comprehensive discussion. In an earlier mail you asked for feedback; Folk may be hesitant to invest any time in this document as long as it does not meet the requirement of rfc3978. If you submit this as an internet-draft with proper boiler plate you may get more feedback. (Milage may vary, I don't expect miracles...) I reckon that takrem for dnssec would be covered by the same or similar IPR disclosure as takrem for x.509. https:// datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=626 As for this proposal becoming part of the solution space for automatic key rollover done in DNSEXT, thats up to the folk on this list. - --Olaf - ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDL9TftN/ca3YJIocRArLpAJ9GRyvNaS0R5mkmWSmWlvHgCSoOawCfWQF9 Wyq6yyph/U7W7BBAZBpz0SQ= =itP9 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 20 10:01:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHigT-0003Xc-Uf for dnsext-archive@megatron.ietf.org; Tue, 20 Sep 2005 10:01:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01633 for ; Tue, 20 Sep 2005 10:01:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHibp-0003gL-KW for namedroppers-data@psg.com; Tue, 20 Sep 2005 13:56:33 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EHibl-0003fw-VV for namedroppers@ops.ietf.org; Tue, 20 Sep 2005 13:56:30 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0EE6911450 for ; Tue, 20 Sep 2005 13:56:29 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard In-Reply-To: Your message of "Tue, 20 Sep 2005 09:53:17 +0200." References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> <98A6DD22-0DA4-48CF-BC49-183BE8024451@mail-abuse.org> Date: Tue, 20 Sep 2005 13:56:29 +0000 Message-Id: <20050920135629.0EE6911450@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # I'd like to ask if we can all consent with the document as is now # (http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis-06.txt). aye. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 20 15:35:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHntP-0005zq-Mw for dnsext-archive@megatron.ietf.org; Tue, 20 Sep 2005 15:35:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26228 for ; Tue, 20 Sep 2005 15:34:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHnoD-0002CU-Tw for namedroppers-data@psg.com; Tue, 20 Sep 2005 19:29:41 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EHnoD-0002CF-7V for namedroppers@ops.ietf.org; Tue, 20 Sep 2005 19:29:41 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 48A5056881; Tue, 20 Sep 2005 12:29:38 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.2.1.2.2.20050920150957.047c4bb0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 20 Sep 2005 15:30:03 -0400 To: "Olaf M. Kolkman" , Thierry Moreau From: Mike StJohns Subject: Re: Takrem for DNSSEC (was Re: state of vixie-dnssec-ter?) Cc: Namedroppers In-Reply-To: References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_17087780==.ALT" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --=====================_17087780==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 05:22 AM 9/20/2005, Olaf M. Kolkman wrote: >-----BEGIN PGP SIGNED MESSAGE----- >> >>I think this is an overstatement (unless the fact that a zone has >>more than one KSK creates a backwards incompatibility). In any >>event, against which key rollover scheme would a scheme be >>backwards incompatible? The only KSK rollover scheme as of now is >>no rollover, long-lasting KSK, isn't it? > > >The problem is that when flipping the revoke bit the key-tag >changes. It could be, although the public key material stays the >same, that implementations fail to find the key for validation. >AFAIK the specs only mention that keytag collisions can occur. In >that sense flipping bits is backwards incompatible, I think :-) From the BIND9 ARM: The trusted-keys statement can contain multiple key entries, each consisting of the key's domain name, flags, protocol, algorithm, and the base-64 representation of the key data. Let's do the analysis here. If I set the revoke bit for a key, and publish it, that key will no longer be trusted by the resolver both in current implementations and in an implementation that understands the revoke bit. Isn't that the desired behavior? If the key is not a trust anchor and I set the revoke bit, (and re-sign the key RR set) then the chain through from a superior trust anchor will work, but since I'm not actually using the key to sign anything else (or at least I shouldn't be if I'm the zone owner) there's also no problem. The only "problem" is that you do stand the possibility of revoking all the valid trust anchors and would then have to re-configure the resolvers. OTOH until the resolvers actually understand the revoke bit you can unset it and go back to where you were before. Let's drop this objection to the revoke bit - it's a red herring. Mike --=====================_17087780==.ALT Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA26228 At 05:22 AM 9/20/2005, Olaf M. Kolkman wrote:
-----BEGIN PGP SIGNED MESSAGE-----

I think this is an overstatement (unless the fact that a zone has 
more than one KSK creates a backwards incompatibility). In any 
event, against which key rollover scheme would a scheme be 
backwards incompatible? The only KSK rollover scheme as of now is 
no rollover, long-lasting KSK, isn't it?


The problem is that when flipping the revoke bit the key-tag 
changes.  It could be, although the public key material stays the 
same,  that implementations fail to find the key for validation.  
AFAIK the specs only mention that keytag collisions can occur. In 
that sense flipping bits is backwards incompatible, I think :-)

From the BIND9 ARM:

The trusted-keys statement c= an contain multiple key entries, each consisting of the key=92s domain name,
flags, protocol, algorithm, and the base-64 representation of the key data.

Let's do the analysis here.  If I set the revoke bit for a key, and publish it, that key will no longer be trusted by the resolver both in current implementations and in an implementation that understands the revoke bit.  Isn't that the desired behavior?

If the key is not a trust anchor and I set the revoke bit, (and re-sign the key RR set) then the chain through from a superior trust anchor will work, but since I'm not actually using the key to sign anything else (or at least I shouldn't be if I'm the zone owner) there's also no problem.

The only "problem" is that you do stand the possibility of revoking all the valid trust anchors and would then have to re-configure the resolvers.  OTOH until the resolvers actually understand the revoke bit you can unset it and go back to where you were before.

Let's drop this objection to the revoke bit - it's a red herring.

Mike
--=====================_17087780==.ALT-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 20 16:04:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHoML-00052Z-Lv for dnsext-archive@megatron.ietf.org; Tue, 20 Sep 2005 16:04:57 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29115 for ; Tue, 20 Sep 2005 16:04:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHoK5-0004hP-4h for namedroppers-data@psg.com; Tue, 20 Sep 2005 20:02:37 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EHoK4-0004h2-9W for namedroppers@ops.ietf.org; Tue, 20 Sep 2005 20:02:36 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 26553316 for ; Tue, 20 Sep 2005 16:02:35 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2C15E41AB for ; Tue, 20 Sep 2005 16:02:34 -0400 (EDT) Date: Tue, 20 Sep 2005 16:02:34 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Takrem for DNSSEC (was Re: state of vixie-dnssec-ter?) In-Reply-To: References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050920200234.2C15E41AB@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 20 Sep 2005 11:22:34 +0200, Olaf M Kolkman wrote: > > The problem is that when flipping the revoke bit the key-tag > changes. It could be, although the public key material stays the > same, that implementations fail to find the key for validation. > AFAIK the specs only mention that keytag collisions can occur. In > that sense flipping bits is backwards incompatible, I think :-) Changing the key tag when the revocation bit flips is a -feature- of Mike's design. I don't see any obvious need for a transition mechanism, since the behavior of a revoke-bit-ignorant validator seems be what we'd want here anyway (well, absent bugs that would cause said validator to choke on key bits that it doesn't understand). What am I missing? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 20 20:02:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHs4P-0005S1-0T for dnsext-archive@megatron.ietf.org; Tue, 20 Sep 2005 20:02:41 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15741 for ; Tue, 20 Sep 2005 20:02:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHrzB-000KF5-QL for namedroppers-data@psg.com; Tue, 20 Sep 2005 23:57:17 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EHrzB-000KEn-3B for namedroppers@ops.ietf.org; Tue, 20 Sep 2005 23:57:17 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j8KNqw7E027181 for ; Tue, 20 Sep 2005 19:52:58 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAnRaGf1; Tue, 20 Sep 05 19:52:55 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j8KNspSu022349; Tue, 20 Sep 2005 19:54:51 -0400 (EDT) Date: Tue, 20 Sep 2005 19:54:51 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Rob Austein cc: namedroppers@ops.ietf.org Subject: rollover transition mechanisms (yet another Subject line) In-Reply-To: <20050920200234.2C15E41AB@thrintun.hactrn.net> Message-ID: References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <20050920200234.2C15E41AB@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 20 Sep 2005, Rob Austein wrote: > I don't see any obvious need for a transition mechanism, since the > behavior of a revoke-bit-ignorant validator seems be what we'd want > here anyway (well, absent bugs that would cause said validator to > choke on key bits that it doesn't understand). > > What am I missing? The obvious questions, from my perspective: 1) What happens when an old (DNSSECbis, 4033-5) validator runs into a zone using one of these funky transition mechanisms? 2) What happens when a new (funky transition mechanism aware) validator runs into an old (manual roll) zone? For the threshhold scheme, I think #2 above could be very colorful if the new validators all assume that every zone is using threshhold stuff -- they could leave old zones unintentionally Bogus. It may be that Mike's proposal doesn't need a signaling mechanism, but I'm not convinced anyone has looked that closely at it. What scared me in Paris was hearing the suggestion that it would be safe to ignore the questions above and assume everyone will be using new code -- assume a flag day. It could be that I heard something that wasn't being said, but that doesn't remove the need to answer the two questions above. -- 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: From owner-namedroppers@ops.ietf.org Wed Sep 21 05:41:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI16k-0006x1-9A for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 05:41:42 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08305 for ; Wed, 21 Sep 2005 05:41:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EI12D-000DHh-Aa for namedroppers-data@psg.com; Wed, 21 Sep 2005 09:37:01 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EI12B-000DHM-7N for namedroppers@ops.ietf.org; Wed, 21 Sep 2005 09:36:59 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.3/8.13.3) with ESMTP id j8L9annd020198; Wed, 21 Sep 2005 11:36:50 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <6.2.1.2.2.20050920150957.047c4bb0@localhost> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> Mime-Version: 1.0 (Apple Message framework v734) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: rollover transition mechanism Date: Wed, 21 Sep 2005 11:36:48 +0200 To: Mike StJohns X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 20, 2005, at 21:30 , Mike StJohns wrote: > > Let's do the analysis here. If I set the revoke bit for a key, and > publish it, that key will no longer be trusted by the resolver both > in current implementations and in an implementation that > understands the revoke bit. Isn't that the desired behavior? > Off course the assumption is that the folk that do not follow this mechanism had sufficient heads up to configure the new trust-key; but that is a fact of current day operations. It took some repetition but finally it registered. > Let's drop this objection to the revoke bit - it's a red herring. > Withdrawn your honor. :-) In response to Sam's remark: > It may be that Mike's proposal doesn't need a signaling mechanism, but > I'm not convinced anyone has looked that closely at it. > The magic words are: implementation and testing. AFAIK Mike's proposal only consists of spec-ware (correct?). - --Olaf - ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ We have employment opportunities, see the website. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDMSmItN/ca3YJIocRApdvAJ47iMGZL0wd1n9TVyu0Khf5qAvmUACfdwyV YINvy9GSJMnwjkucRh2Be9E= =zdH3 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 21 08:25:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI3fR-0007qz-94 for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 08:25:41 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16053 for ; Wed, 21 Sep 2005 08:25:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EI3cM-000Pkl-Hh for namedroppers-data@psg.com; Wed, 21 Sep 2005 12:22:30 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EI3cH-000Pk8-Sh for namedroppers@ops.ietf.org; Wed, 21 Sep 2005 12:22:26 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2899833C1B; Wed, 21 Sep 2005 13:22:09 +0100 (BST) Message-ID: <43315071.7090504@algroup.co.uk> Date: Wed, 21 Sep 2005 13:22:09 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Thierry Moreau , Namedroppers Subject: Re: Takrem for DNSSEC (was Re: state of vixie-dnssec-ter?) References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: >>> However, I have reservations about the effective security of the two >>> schemes which use a number of KSK with the assumption that a single >>> KSK compromise is sufficiently more likely than a simultaneous >>> compromise of every KSK (for to justify either scheme deployment). >>> >>> As you may know, the document http://www.connotech.com/ >>> takrem_for_dnssec_01.pdf contains a comprehensive discussion. > > > > In an earlier mail you asked for feedback; Folk may be hesitant to > invest any time in this document as long as it does not meet the > requirement of rfc3978. If you submit this as an internet-draft with > proper boiler plate you may get more feedback. (Milage may vary, I > don't expect miracles...) > > I reckon that takrem for dnssec would be covered by the same or > similar IPR disclosure as takrem for x.509. https:// > datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=626 > > As for this proposal becoming part of the solution space for automatic > key rollover done in DNSEXT, thats up to the folk on this list. FWIW, I took some time to review the document. Essentially the proposal is to publish at some point a list of digests of future keys. Key rollover is then just a matter of producing the key corresponding to the next digest (or, indeed, any digest in the list). This means, of course, that one needs an offline method of initially verifying the digests. This is no worse than the requirement to offline verify the initial keys. There do appear to me to be two flaws with this proposal, one correctable. a) It uses MASH for the digests. It should probably use SHA-1 (or -256 et al). b) It requires all keys to be pregenerated, so a compromise of the pregenerated keys cannot be recovered from. Also, the document includes no IP statement that I could find. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 21 08:53:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI46k-0005nR-30 for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 08:53:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17094 for ; Wed, 21 Sep 2005 08:53:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EI44J-0001iK-TO for namedroppers-data@psg.com; Wed, 21 Sep 2005 12:51:23 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EI44D-0001hV-Mn for namedroppers@ops.ietf.org; Wed, 21 Sep 2005 12:51:18 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 534D733C1A; Wed, 21 Sep 2005 13:51:14 +0100 (BST) Message-ID: <43315743.6030106@algroup.co.uk> Date: Wed, 21 Sep 2005 13:51:15 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Douglas Otis , Namedroppers Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> <98A6DD22-0DA4-48CF-BC49-183BE8024451@mail-abuse.org> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: > > Dear Colleagues, > > I have the impression we are going around in circles and that we are > not converging any further. > > I'd like to ask if we can all consent with the document as is now > (http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis-06.txt). Yes. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 21 11:12:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI6GS-000312-7X for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 11:12:04 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27433 for ; Wed, 21 Sep 2005 11:12:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EI6BR-000Cul-WB for namedroppers-data@psg.com; Wed, 21 Sep 2005 15:06:54 +0000 Received: from [204.9.221.21] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EI6BQ-000CuA-0q for namedroppers@ops.ietf.org; Wed, 21 Sep 2005 15:06:52 +0000 Received: from [64.3.161.67] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 526330; Wed, 21 Sep 2005 11:08:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <29723.1127313120@munnari.OZ.AU> References: <29723.1127313120@munnari.OZ.AU> Date: Wed, 21 Sep 2005 11:06:52 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: Summary of the LLMNR Last Call Cc: namedroppers@ops.ietf.org, ietf@ietf.org, iesg@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi Robert, Our process, as currently instantiated, has three stages after a document is submitted to the IESG for review/approval: 1. AD Review -- the responsible AD reviews the document and determines if is ready for IETF LC. Sometimes other things happen at this stage, like review by certain specialist groups (such as the MIB doctors) and/or resolution of AD Review comments. 2. IETF LC -- the document goes to IETF LC, after which the responsible AD determines whether the community has consensus to publish the document. Any issues raised in IETF LC need to be addressed before he document is approved by the IESG. 3. IETF Evaluation -- the full IESG reviews the document on a telechat, stating positions (yes, no objection, discuss, abstain or recuse) on the document. Any discuss positions have to be resolved before the document is forwarded to the RFC editor for publication. For a standards track document, there must also be at least one 'yes' position and at least 9 'yes/no-ob' positions for a document to be approved for publication. It was my job (as responsible AD for DNSEXT) to perform the AD review, send the document to IETF LC, determine whether or not we have IETF consensus to publish the documen and make sure that any substantive issues raised during IETF LC are addressed before sending the document to the IESG for review. In my opinion, based on the results of the IETF LC, the IETF LC raised two substantive technical issues with this specification, and the IETF community does not currently have consensus to publish this document as a Proposed Standard. If the WG continues to believe that this document should be published as a Proposed Standard, they will address these technical issues (through changes to the document, informing the community why changes are not needed, or other means) and produce a document that will achieve IETF community consensus. Like all decisions made by ADs, my decision is, of course, subject to appeal. Margaret At 9:32 PM +0700 9/21/05, Robert Elz wrote: > Date: Sun, 18 Sep 2005 10:09:07 -0400 > From: Margaret Wasserman > Message-ID: > >I am not going to comment on the substance of the issues, or the >doc in question, as I haven't been following what is happening with >it, nor have a read a recent version. > >But ... > > | Based on these conclusions, I do not intend to forward the LLMNR > | specification to the IESG for review and approval. > >What kind of process is going on here? As I recall it, from rfc2026, >it is the IESG that issues last calls, when it has a doc for review, and >the IESG that decides if a last call has passed or not (that is, the IESG >takes input from the comments received during the last call to help it make >its decision on what to do with the doc that has been presented to it). > >How did we ever get an IETF last call on a doc that hasn't even gone to >the IESG (apparently) but is still (apparently) under AD review ? > >And how does one AD (alone, apparently) get to draw conclusions based upon >the results of the last call ? > >What is happening here? Can't the IETF manage to either follow its >own documented processes, or change them in the approved way? > >kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 21 11:19:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI6NH-0004kt-29 for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 11:19:07 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27731 for ; Wed, 21 Sep 2005 11:19:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EI6KZ-000Dik-FT for namedroppers-data@psg.com; Wed, 21 Sep 2005 15:16:19 +0000 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EI6KW-000DiK-KA for namedroppers@ops.ietf.org; Wed, 21 Sep 2005 15:16:16 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0187ED; 21 Sep 2005 11:19:37 -0400 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 21 Sep 2005 11:19:15 -0400 Received: from connotech.com (209.71.204.103) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0187EB; 21 Sep 2005 11:19:07 -0400 Message-ID: <433180BD.9010504@connotech.com> Date: Wed, 21 Sep 2005 11:48:13 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie CC: "Olaf M. Kolkman" , Namedroppers Subject: Re: Takrem for DNSSEC (was Re: state of vixie-dnssec-ter?) References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED <43315071.7090504@algroup.co.uk> In-Reply-To: <43315071.7090504@algroup.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RCVD_IN_SBL autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ben Laurie wrote: > Olaf M. Kolkman wrote: > >> In an earlier mail you asked for feedback; Folk may be hesitant to >> invest any time in this document as long as it does not meet the >> requirement of rfc3978. If you submit this as an internet-draft with >> proper boiler plate you may get more feedback. (Milage may vary, I >> don't expect miracles...) >> >> I reckon that takrem for dnssec would be covered by the same or >> similar IPR disclosure as takrem for x.509. https:// >> datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=626 >> >> As for this proposal becoming part of the solution space for >> automatic key rollover done in DNSEXT, thats up to the folk on this >> list. > > > FWIW, I took some time to review the document. Essentially the proposal > is to publish at some point a list of digests of future keys. Key > rollover is then just a matter of producing the key corresponding to the > next digest (or, indeed, any digest in the list). Thanks for the feedback on http://www.connotech.com/takrem_for_dnssec_01.pdf. > This means, of course, that one needs an offline method of initially > verifying the digests. This is no worse than the requirement to offline > verify the initial keys. I don't exactly understand who is the *one* who needs verification, and what is *offline* in this context? Perhaps you refer to a veryfing party (a DNS resolver system) needing initial *trust* by an *out-of-band* mechanism upon initial trust anchor configuration. This is part of the picture for any scheme. Indeed, a resolver initially accepts the digests as trusted as originating from the DNS zone manager. Any trust anchor key renewal proposal is based on an initial trust decision. > There do appear to me to be two flaws with this proposal, one correctable. > > a) It uses MASH for the digests. It should probably use SHA-1 (or -256 > et al). The key idea is cryptographic strength over the long run (which is a justification for key rollover in the first place). MASH with hidden parameters (until the key rollover message is received) is assumed to be more resistant than a fixed Hash function. This can lead to the follwing sub-issues: a) Is such attention paid to cryptographic strength required by typical DNSSEC participants? Perhaps no. b) Is such attention paid to cryptographic strength required by some DNSSEC extension influencors? Perhaps yes. c) What the cryptographers would think of MASH with hidden parameters as a *strong* mechanism in the long run? ... > b) It requires all keys to be pregenerated, so a compromise of the > pregenerated keys cannot be recovered from. Any proposal for trust anchor rollover has a catastrophic failure mode (i.e. when the security incident recovery is exactly like the initial trust anchor configuration). You correctly point to the one specific to the TAKREM proposal. In practice, to reduce the likelihood of a catastrophic failure, each of the pregenerated keys can be stored in a couple of pages of bar code labels put in a tamper-evident sealed envelope, in dual-components (i.e. two sets of envelopes, each set stored in a different safe box). > Also, the document includes no IP statement that I could find. Such IP statement would be in the IETF IPR disclosure database. Since a formal draft is not yet submitted, the IPR disclosure is not files. But see the observation by Olaf above, TAKREM for X.509 being covered by the draft draft-moreau-pkix-takrem-01.txt, which has an IPR disclosure in the IETF database. > Cheers, > > Ben. > Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 21 11:29:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI6XT-0007SA-MZ for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 11:29:39 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28277 for ; Wed, 21 Sep 2005 11:29:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EI6VB-000Ecw-Dg for namedroppers-data@psg.com; Wed, 21 Sep 2005 15:27:17 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EI6VA-000Ecg-Aw for namedroppers@ops.ietf.org; Wed, 21 Sep 2005 15:27:16 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j8LFR9Gb017712; Wed, 21 Sep 2005 11:27:10 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 21 Sep 2005 11:26:47 -0400 To: Margaret Wasserman From: Edward Lewis Subject: Re: Fwd: Summary of the LLMNR Last Call Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Speaking as a working group participant and ... At 8:19 -0400 9/19/05, Margaret Wasserman wrote: ...taking Margaret's message out of order... >>I am planning to send the document back to the WG for resolution of these >>issues and would issue another IETF LC if/when the WG believes that they have >>a document that will address these issues and reach IETF consensus. Will this be fruitful? I am directing the question to other WG participants. (To Bernard - this is in no way to slight your work or your efforts. I am asking to judge whether I want to tune into the discussion on this.) No insult is intended towards Bernard's efforts, but has there been significant interest by others (i.e., non-Bernard) in the WG? I am asking because until now I have ignored the issue completely as I have no real driving interest in this topic. But if the WG is being asked to take on what would be major work to solve the problems, I'll start to take notice. If the goal of the IETF is interoperability, it seems unwise to standardize one approach to a problem when there is a incompatible approach in use. I don't want to make this about Microsoft vs. Apple (I am saying that openly because it seems to be a smoldering concern in the LC comments), but rather the granting of the title of "standard" when there is clearly a choice of approaches. LLMNR vs. mDNS isn't an isolated case of this, but it's the one case being put before the WG. It seems to me that concerns 1 and 3 could be erased by removing LLMNR from standards track and publishing it as informational or even experimental. Security concerns I understand and would become a work item, although my senses are that "security concerns" can become a work item that fills all space and time allotted for it. I'm curious if the WG wants to take this back. It's (I mean the problem, not the proposed solution) lingered so long, is there energy to solve the concerns raise in the last call? Is there any, *any*, chance we can merge LLMNR and mDNS? If not, I really don't think it'll be worth an interoperable standardization effort. >>(1) Concerns that publication of this protocol will be confusing or actively >>harmful given the existing wide deployment of Apple's mDNS protocol. >>(2) Security concerns have been raised about the fact that applications on >>hosts that implement LLMNR will not be able to tell if a response has come >>from the DNS or from a local lookup. >>(3) Separate, but perhaps underlying both of the previous issues, there seems >>be a fundamental disagreement about what technical approach we >>should take to >>link-local name lookup. >>CONCLUSION 1: There are at least two blocking technical issues with the >>LLMNR specification (raised in items #1 and #2 above)... >>CONCLUSION 2: The IETF community does not currently have consensus to >>standardize a local name resolution mechanism... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 21 11:37:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI6ef-0001LJ-Pv for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 11:37:06 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29105 for ; Wed, 21 Sep 2005 11:37:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EI6cN-000FIW-FB for namedroppers-data@psg.com; Wed, 21 Sep 2005 15:34:43 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EI6cK-000FI3-2w for namedroppers@ops.ietf.org; Wed, 21 Sep 2005 15:34:40 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 399BC33C1B; Wed, 21 Sep 2005 16:34:38 +0100 (BST) Message-ID: <43317D8F.5010103@algroup.co.uk> Date: Wed, 21 Sep 2005 16:34:39 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Moreau CC: "Olaf M. Kolkman" , Namedroppers Subject: Re: Takrem for DNSSEC (was Re: state of vixie-dnssec-ter?) References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED <43315071.7090504@algroup.co.uk> <433180BD.9010504@connotech.com> In-Reply-To: <433180BD.9010504@connotech.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thierry Moreau wrote: > > > Ben Laurie wrote: > >> Olaf M. Kolkman wrote: >> >>> In an earlier mail you asked for feedback; Folk may be hesitant to >>> invest any time in this document as long as it does not meet the >>> requirement of rfc3978. If you submit this as an internet-draft with >>> proper boiler plate you may get more feedback. (Milage may vary, I >>> don't expect miracles...) >>> >>> I reckon that takrem for dnssec would be covered by the same or >>> similar IPR disclosure as takrem for x.509. https:// >>> datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=626 >>> >>> As for this proposal becoming part of the solution space for >>> automatic key rollover done in DNSEXT, thats up to the folk on this >>> list. >> >> >> >> FWIW, I took some time to review the document. Essentially the >> proposal is to publish at some point a list of digests of future keys. >> Key rollover is then just a matter of producing the key corresponding >> to the next digest (or, indeed, any digest in the list). > > > Thanks for the feedback on > http://www.connotech.com/takrem_for_dnssec_01.pdf. > >> This means, of course, that one needs an offline method of initially >> verifying the digests. This is no worse than the requirement to >> offline verify the initial keys. > > > I don't exactly understand who is the *one* who needs verification, and > what is *offline* in this context? Perhaps you refer to a veryfing party > (a DNS resolver system) needing initial *trust* by an *out-of-band* > mechanism upon initial trust anchor configuration. Indeed I am. > This is part of the picture for any scheme. This is what I said. > Indeed, a resolver initially accepts the digests as trusted as > originating from the DNS zone manager. Any trust anchor key renewal > proposal is based on an initial trust decision. True. >> There do appear to me to be two flaws with this proposal, one >> correctable. >> >> a) It uses MASH for the digests. It should probably use SHA-1 (or -256 >> et al). > > The key idea is cryptographic strength over the long run (which is a > justification for key rollover in the first place). MASH with hidden > parameters (until the key rollover message is received) is assumed to be > more resistant than a fixed Hash function. On what basis? > This can lead to the follwing sub-issues: > > a) Is such attention paid to cryptographic strength required by typical > DNSSEC participants? Perhaps no. > > b) Is such attention paid to cryptographic strength required by some > DNSSEC extension influencors? Perhaps yes. > > c) What the cryptographers would think of MASH with hidden parameters as > a *strong* mechanism in the long run? ... > >> b) It requires all keys to be pregenerated, so a compromise of the >> pregenerated keys cannot be recovered from. > > Any proposal for trust anchor rollover has a catastrophic failure mode > (i.e. when the security incident recovery is exactly like the initial > trust anchor configuration). You correctly point to the one specific to > the TAKREM proposal. > > In practice, to reduce the likelihood of a catastrophic failure, each of > the pregenerated keys can be stored in a couple of pages of bar code > labels put in a tamper-evident sealed envelope, in dual-components (i.e. > two sets of envelopes, each set stored in a different safe box). > >> Also, the document includes no IP statement that I could find. > > Such IP statement would be in the IETF IPR disclosure database. Since a > formal draft is not yet submitted, the IPR disclosure is not files. But > see the observation by Olaf above, TAKREM for X.509 being covered by the > draft draft-moreau-pkix-takrem-01.txt, which has an IPR disclosure in > the IETF database. Are you going to make us look for it, or just tell us what it says? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 21 13:02:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7zY-0000aq-Kj for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 13:02:44 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04816 for ; Wed, 21 Sep 2005 13:02:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EI7vg-000MUx-DX for namedroppers-data@psg.com; Wed, 21 Sep 2005 16:58:44 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EI7vf-000MUf-6a for namedroppers@ops.ietf.org; Wed, 21 Sep 2005 16:58:43 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j8LGsOe4026395 for ; Wed, 21 Sep 2005 12:54:24 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAy7aODZ; Wed, 21 Sep 05 12:54:13 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j8LGuCtX021635 for ; Wed, 21 Sep 2005 12:56:12 -0400 (EDT) Date: Wed, 21 Sep 2005 12:56:12 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: comments on p-s Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sorry for getting these out after the last call closed. Four comments of some substance, the rest is editorial. None of these need block the document. -- Add a specific reminder in section 5 that before using the output of P and P' in an NSEC RR, the server needs to test for that name's existence and possibly use a non-synthesized NSEC RR. Refer to online-signing section 2. This could really be clarified in P'(N) Step 2, which needs to say "Use the apex NSEC RR" or at least "this is the name of the zone". -- In Sections 3 & 4, I kept wondering where the maximum label/name lengths were defined. 5.4.1 mentions total name length only. Suggestion: To make it easier for the reader, add, in 3 or 5.4.1: As a reminder, the maximum DNS label length (as defined in [RFC1034] Section 3.1) is 63 octets and the maximum total name length is 255 octets. I first wondered about this in section 3.1, step 1. -- Are you certain that P' and S' (section 4) handle arbitrary queries, noting that an attacker can send any query, independent of what's in the zone? I think it is, but I haven't convinced myself yet. -- I thought p-s was destined for experimental, per the last call. -------------- 3.2 step four. "do nothing" confuses me. Does this mean "use the current value as S(N)"? 3.1 step four, add "in the lest significant (left-most) label" 3.2 step two, s/"If N is one or more"/"If N is one"/, since "or more" should have been taken care of by step one. Lastly, in section 1, item 2: s/owner name/label/, and don't hyphenate "online signing" OLD: This method is restricted to use with zones consisting only of single-label owner names where a maximum-length owner name would not result in a DNS name exceeding the maximum DNS name length. This is, however, the type of zone for which the technique of online- signing is most likely to be used. NEW: This method is restricted to use with zones consisting only of single-label owner names where a maximum-length label would not result in a DNS name exceeding the maximum DNS name length. This is, however, the type of zone for which the technique of online signing is most likely to be used. ----------------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 21 13:16:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8Cq-0004Hj-FP for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 13:16:28 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05449 for ; Wed, 21 Sep 2005 13:16:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EI89Z-000O5L-2c for namedroppers-data@psg.com; Wed, 21 Sep 2005 17:13:05 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EI89U-000O51-4a for namedroppers@ops.ietf.org; Wed, 21 Sep 2005 17:13:00 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9F0EF11449 for ; Wed, 21 Sep 2005 17:12:59 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Fwd: Summary of the LLMNR Last Call In-Reply-To: Your message of "Wed, 21 Sep 2005 11:26:47 -0400." References: Date: Wed, 21 Sep 2005 17:12:59 +0000 Message-Id: <20050921171259.9F0EF11449@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # It seems to me that concerns 1 and 3 could be erased by removing LLMNR from # standards track and publishing it as informational or even experimental. that's what happened to the SRV RR, and it hasn't hurt apple's or microsoft's business at all to have the dreaded "experimental" tag on that RFC. # I'm curious if the WG wants to take this back. It's (I mean the problem, # not the proposed solution) lingered so long, is there energy to solve the # concerns raise in the last call? Is there any, *any*, chance we can merge # LLMNR and mDNS? If not, I really don't think it'll be worth an # interoperable standardization effort. while i agree with this in general, i have three specific concerns. 1. the right way to do multicast DNS is draft-manning-opcode-discover-01, and while apple and microsoft both call their approaches "multicast dns" they are really "overloading dns to carry service discovery in multicast". 2. any attempt to merge mdns and llmnr MUST be backward compatible with mdns, since apple has created an important new economy of mdns services/devices and ietf should only ignore this economy if mdns is the provably wrong approach, rather than merely suboptimal in some way (that i'm unaware of). 3. if this is really about PnP, i sure wish that everybody would just say so and re-frame the debate in PnP terms and stop treating it as a dns issue that's somehow relevant to the skills of the core namedroppers community. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 21 13:25:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8Lo-0006df-Na for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 13:25:44 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06201 for ; Wed, 21 Sep 2005 13:25:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EI8I0-000OmR-RP for namedroppers-data@psg.com; Wed, 21 Sep 2005 17:21:48 +0000 Received: from [64.142.16.245] (helo=a.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EI8Hx-000OlR-4O for namedroppers@ops.ietf.org; Wed, 21 Sep 2005 17:21:45 +0000 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j8LHLX55010985 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 21 Sep 2005 10:21:34 -0700 In-Reply-To: References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> <98A6DD22-0DA4-48CF-BC49-183BE8024451@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <842B1531-C5B3-476F-99E7-E6B7EB99AFDE@mail-abuse.org> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Date: Wed, 21 Sep 2005 10:21:35 -0700 To: "Olaf M. Kolkman" X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sep 20, 2005, at 12:53 AM, Olaf M. Kolkman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Dear Colleagues, > > I have the impression we are going around in circles and that we > are not converging any further. > > I'd like to ask if we can all consent with the document as is now > (http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis-06.txt). There are parameters wherein a user-CERT record should not be disruptive. With most records defined for DNS, patterns of expected record use is not a concern. When dealing with large records on a large scale also expected to provide authentication at the desktop, it would seem there is a requisite for greater caution than provided in this draft. This could include specific suggestions on cache consumption, or perhaps wildcards owing to increased overhead and possible resulting name space weaknesses. Derogatory expressions reflect confidence, but unfortunately are without substance. As such, the cycling is from confidence to specific concerns. It would seem these concerns regarding wide-scale deployment of user-CERTs should not be dismissed in this cavalier manner. Within the thread of this conversation, there have been suggestions DNS has infinite capacity and does not rely upon cache for performance, to noting that some older versions may crash. This issue involves understanding the name space, revocation mechanisms, query rates, and where records are ultimately cached. Although concerns could very well be misplaced, related questions were not answered in this thread, nor made clear in the draft. I have no desire to distract from other valuable efforts. I will leave the fitness of this draft be judged by others in the WG. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 21 16:22:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIB77-0007ga-HD for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 16:22:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25148 for ; Wed, 21 Sep 2005 16:22:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIB16-000EY6-5J for namedroppers-data@psg.com; Wed, 21 Sep 2005 20:16:32 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EIB12-000EXY-I6 for namedroppers@ops.ietf.org; Wed, 21 Sep 2005 20:16:28 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j8LKFojI012565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2005 22:15:52 +0200 From: Simon Josefsson To: Douglas Otis Cc: Namedroppers , "Olaf M. Kolkman" Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> <98A6DD22-0DA4-48CF-BC49-183BE8024451@mail-abuse.org> <842B1531-C5B3-476F-99E7-E6B7EB99AFDE@mail-abuse.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050921:dotis@mail-abuse.org::bq48Ltxb23X9tL5t:601v X-Hashcash: 1:21:050921:namedroppers@ops.ietf.org::WhP5W565xNFqxrEB:zEL X-Hashcash: 1:21:050921:olaf@nlnetlabs.nl::5FJJ2WrGe+rFiOyF:AH+1 X-Hashcash: 1:21:050921:olaf@nlnetlabs.nl::xdSV2jjP1+lgWjWn:7O53 Date: Wed, 21 Sep 2005 22:15:48 +0200 In-Reply-To: <842B1531-C5B3-476F-99E7-E6B7EB99AFDE@mail-abuse.org> (Douglas Otis's message of "Wed, 21 Sep 2005 10:21:35 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Douglas Otis writes: > There are parameters wherein a user-CERT record should not be > disruptive. With most records defined for DNS, patterns of expected > record use is not a concern. When dealing with large records on a > large scale also expected to provide authentication at the desktop, > it would seem there is a requisite for greater caution than provided > in this draft. This could include specific suggestions on cache > consumption, or perhaps wildcards owing to increased overhead and > possible resulting name space weaknesses. There is an entire section called "Performance Considerations". It state that an increase of DNS load may occur and that it may have performance and cache effectiveness consequences, and further that CERT RRs may change the access pattern of DNS. We don't have hard data to offer more specific suggestions or warnings at this point. Exactly what more are looking for? 4. Performance Considerations The Domain Name System (DNS) protocol was designed for small transfers, typically below 512 bytes. While larger transfers will perform correctly and work is underway to make larger transfers more efficient, it is still advisable at this time to make every reasonable effort to minimize the size of certificates stored within the DNS. Steps that can be taken may include using the fewest possible optional or extension fields and using short field values for necessary variable length fields. The RDATA field in the DNS protocol may only hold data of size 65535 octets (64kb) or less. This means that each CERT RR MUST NOT contain more than 64kb of payload, even if the corresponding certificate or certificate revocation list is larger. This document addresses this by defining "indirect" data types for each normal type. Deploying CERT RRs to support digitally signed e-mail change the access patterns of DNS lookups from per-domain to per-user. If digitally signed e-mail, and a key/certificate lookup based on CERT RRs, is deployed on a wide scale, this may lead to an increased DNS load, with potential performance and cache effectiveness consequencess. Whether this load increase will be noticable or not is not known. > Derogatory expressions reflect confidence, but unfortunately are > without substance. As such, the cycling is from confidence to > specific concerns. It would seem these concerns regarding wide-scale > deployment of user-CERTs should not be dismissed in this cavalier > manner. Within the thread of this conversation, there have been > suggestions DNS has infinite capacity and does not rely upon cache > for performance, to noting that some older versions may crash. I don't think anyone is dismissing the problems you are bringing up. I believe the document discuss them. The DNS clearly do not have infinite capacity. I believe the finite capacity is more than sufficient to handle CERT RRs. To some extent the DNS depend on caching for performance. There are different opinions on how much caching improve performance. Software defects should not prohibit progress, people should fix their servers. If something can crash old servers, it will do so independently of whether this document is advanced or not. Crashing servers may negatively affect deployment of CERT RRs, but that is "our" problem. What I'm saying is: if CERT RRs doesn't work, CERT RRs won't be used. > This issue involves understanding the name space, revocation > mechanisms, query rates, and where records are ultimately cached. > Although concerns could very well be misplaced, related questions > were not answered in this thread, nor made clear in the draft. I think the performance survey you are looking for simply doesn't exist. I think it would be very valuable to have such a survey available (and I'm available for hire as a consultant if anyone wishes to pay me to work on it). If that survey would exist, it could be referenced in the document. But now all we can do is hint about broad potential problems, which is done. > I have no desire to distract from other valuable efforts. I will > leave the fitness of this draft be judged by others in the WG. I hope others will chime in with their opinions. I'm open to adding text to address this issue if there is consensus on a specific proposal. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 21 16:59:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIBgS-0000rq-Or for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 16:59:17 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00454 for ; Wed, 21 Sep 2005 16:59:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIBbt-000ITK-Ki for namedroppers-data@psg.com; Wed, 21 Sep 2005 20:54:33 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EIBbt-000ISz-0F for namedroppers@ops.ietf.org; Wed, 21 Sep 2005 20:54:33 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id CD188568BA; Wed, 21 Sep 2005 13:54:31 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.2.1.2.2.20050921164406.04d49eb0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 21 Sep 2005 16:54:56 -0400 To: "Olaf M. Kolkman" From: Mike StJohns Subject: Re: rollover transition mechanism Cc: Namedroppers In-Reply-To: <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 05:36 AM 9/21/2005, Olaf M. Kolkman wrote: In response to Sam's remark: >>It may be that Mike's proposal doesn't need a signaling mechanism, but >>I'm not convinced anyone has looked that closely at it. > >The magic words are: implementation and testing. AFAIK Mike's >proposal only consists of spec-ware (correct?). In a private note to Olaf I pointed out that this is neither a requirement of becoming an ID nor of becoming an RFC. Its not an appropriate comment from a WG chair to suggest this is a failing of an ID or proposal. I'd also like to point out that my draft is the only active draft as the other one has been expired for a while and has not been re-submitted as promised. Also, my comments on the faults in the timing model of the other proposal haven't garnered any counter-comments so I have to assume there are no counter arguments. In any event this has been going on for 18 months with little if any movement. Either we're going to do something about trust anchor rollover or we're not. If there is no conclusion by the end of November, and absent any compelling reason not to, I'll be withdrawing my draft. Later, Mike -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 21 17:24:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIC4j-00063d-Pc for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 17:24:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03365 for ; Wed, 21 Sep 2005 17:24:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIC0o-000LHo-H5 for namedroppers-data@psg.com; Wed, 21 Sep 2005 21:20:18 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EIC0k-000LHJ-MO for namedroppers@ops.ietf.org; Wed, 21 Sep 2005 21:20:14 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 38F2511449 for ; Wed, 21 Sep 2005 21:20:12 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: rollover transition mechanism In-Reply-To: Your message of "Wed, 21 Sep 2005 16:54:56 -0400." <6.2.1.2.2.20050921164406.04d49eb0@localhost> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> <6.2.1.2.2.20050921164406.04d49eb0@localhost> Date: Wed, 21 Sep 2005 21:20:12 +0000 Message-Id: <20050921212012.38F2511449@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # In any event this has been going on for 18 mos with little if any movement. but what a lovely excuse this has made for further delaying deployment, even among the people who have been too busy to even read your draft. # Either we're going to do something about trust anchor rollover or we're not. i estimate "not". but i feel sure we won't deploy without it, or if without this, then not without something else somebody hasn't mentioned yet or lately. # If there is no conclusion by the end of November, and absent any compelling # reason not to, I'll be withdrawing my draft. can the chairs ask some pointed questions? like: 1. is dnssec-bis deployable without this kind of key management? 2. is dnssec-bis deployable without any other kinds of key management? 3. is dnssec-bis deployable without anything unrelated to key management? 4. does mike's proposal appear to be unworkable? if so, how or why? 5. does mike's proposal solve the wrong problem? if so, how or why? 6. does mike's proposal fail to solve the whole problem? if so, how or why? 7. does a competing proposal offer a more provable/testable/simple solution? 8. does a competing proposal solve at least the same important problems? 9. does a competing proposal solve important problems this one doesn't address? silence on these questions should equal "i have either read the draft and find none of these faults, or i promise to shut up about it if i read it later on." here's something fun from the archives: Date: Thu, 5 Dec 1996 09:52:33 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Samuli Mattila Cc: dns-security@tis.com, zam@iki.fi, Jarmo.Kaikkonen@hut.fi Subject: Re: key revokation in DNSSEC Sender: owner-dns-security@ex.tis.com The original DNSSEC proposal by myself and Charlie Kaufman had a key revocation scheme but the overwhelming consensus of the WG was to leave that out for now. ... what do we want to be talking about on 5-DEC-2016? still dnssec deployability? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 21 18:44:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIDJy-0006UF-2j for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 18:44:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07739 for ; Wed, 21 Sep 2005 18:44:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIDGW-0001XE-7p for namedroppers-data@psg.com; Wed, 21 Sep 2005 22:40:36 +0000 Received: from [64.142.16.245] (helo=a.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EIDGU-0001Wz-Jr for namedroppers@ops.ietf.org; Wed, 21 Sep 2005 22:40:34 +0000 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j8LMeSVD030024 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 21 Sep 2005 15:40:29 -0700 In-Reply-To: References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> <98A6DD22-0DA4-48CF-BC49-183BE8024451@mail-abuse.org> <842B1531-C5B3-476F-99E7-E6B7EB99AFDE@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2E0422D0-CB6C-4C07-8AF2-49795B3E3BC0@mail-abuse.org> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Date: Wed, 21 Sep 2005 15:40:33 -0700 To: Simon Josefsson X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sep 21, 2005, at 1:15 PM, Simon Josefsson wrote: > Douglas Otis writes: > > >> I have no desire to distract from other valuable efforts. I will >> leave the fitness of this draft be judged by others in the WG. >> > > I hope others will chime in with their opinions. I'm open to adding > text to address this issue if there is consensus on a specific > proposal. I am pleased there is now a general caution added. For the specific suggestions, there was not consensus in regard to possible maximal TTL parameters or recommending against using a user-CERT wildcard. Unfortunately, the antithetical argument seemed too expedient as a basis of note. Nevertheless, several expressed a desire this draft move forward without further discussion. I suspect this ends the discussion. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 21 18:57:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIDX0-0001nR-Q0 for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 18:57:39 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08386 for ; Wed, 21 Sep 2005 18:57:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIDUT-0002ml-H0 for namedroppers-data@psg.com; Wed, 21 Sep 2005 22:55:01 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EIDUS-0002mD-SW for namedroppers@ops.ietf.org; Wed, 21 Sep 2005 22:55:00 +0000 Received: from [81.200.65.114] (terminus.ddns.nominum.com [81.200.65.114]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 5036456903; Wed, 21 Sep 2005 15:55:00 -0700 (PDT) (envelope-from david.conrad@nominum.com) In-Reply-To: <6.2.1.2.2.20050921164406.04d49eb0@localhost> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> <6.2.1.2.2.20050921164406.04d49eb0@localhost> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1F42CA23-D8C2-47A1-A1F4-1DCBA73BA97A@nominum.com> Cc: "Olaf M. Kolkman" , Namedroppers Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: rollover transition mechanism Date: Wed, 21 Sep 2005 15:54:57 -0700 To: Mike StJohns X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Having not read the draft, I can make no comment on it, however: On Sep 21, 2005, at 1:54 PM, Mike StJohns wrote: >> The magic words are: implementation and testing. AFAIK Mike's >> proposal only consists of spec-ware (correct?). > In a private note to Olaf I pointed out that this is neither a > requirement of becoming an ID nor of becoming an RFC. Its not an > appropriate comment from a WG chair to suggest this is a failing of > an ID or proposal. What Mike says is true. The IETF moved away from "running code" long ago. To impose a requirement of implementation and testing on a particular document and not others is ... questionable. My personal preference would be to require implementation for all drafts, but that's neither here nor there... Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 21 23:08:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIHRZ-0003mB-TJ for dnsext-archive@megatron.ietf.org; Wed, 21 Sep 2005 23:08:18 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18418 for ; Wed, 21 Sep 2005 23:08:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIHLr-000OBR-3P for namedroppers-data@psg.com; Thu, 22 Sep 2005 03:02:23 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EIHLq-000OB1-Ax for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 03:02:22 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j8M322ar008658; Wed, 21 Sep 2005 23:02:05 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.1.2.2.20050921164406.04d49eb0@localhost> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> <6.2.1.2.2.20050921164406.04d49eb0@localhost> Date: Wed, 21 Sep 2005 23:01:41 -0400 To: Mike StJohns From: Edward Lewis Subject: Re: rollover transition mechanism Cc: "Olaf M. Kolkman" , Namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:54 -0400 9/21/05, Mike StJohns wrote: >In any event this has been going on for 18 months with little if any movement. >Either we're going to do something about trust anchor rollover or we're not. >If there is no conclusion by the end of November, and absent any compelling >reason not to, I'll be withdrawing my draft. IMHO, with the recent developments in "se." and "ripe.net.", perhaps interest will rise. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 22 02:06:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIKDx-0007zM-9y for dnsext-archive@megatron.ietf.org; Thu, 22 Sep 2005 02:06:25 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01692 for ; Thu, 22 Sep 2005 02:06:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIK9v-000DXx-R4 for namedroppers-data@psg.com; Thu, 22 Sep 2005 06:02:15 +0000 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIK9s-000DXV-Uv for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 06:02:13 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO01940C; 22 Sep 2005 02:05:32 -0400 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 22 Sep 2005 02:05:19 -0400 Received: from connotech.com (209.71.204.107) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG019409; 22 Sep 2005 02:05:13 -0400 Message-ID: <4332506A.90708@connotech.com> Date: Thu, 22 Sep 2005 02:34:18 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie CC: Namedroppers Subject: Re: Takrem for DNSSEC (was Re: state of vixie-dnssec-ter?) References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED <43315071.7090504@algroup.co.uk> <433180BD.9010504@connotech.com> <43317D8F.5010103@algroup.co.uk> In-Reply-To: <43317D8F.5010103@algroup.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RCVD_IN_SBL autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Ben Laurie wrote: >> >>> [...] >>> >>> There do appear to me to be two flaws with this proposal, one >>> correctable. >>> >>> a) It uses MASH for the digests. It should probably use SHA-1 (or >>> -256 et al). >> > Thierry Moreau wrote: >> >> The key idea is cryptographic strength over the long run (which is a >> justification for key rollover in the first place). MASH with hidden >> parameters (until the key rollover message is received) is assumed to >> be more resistant than a fixed Hash function. > Ben Laurie wrote: > > On what basis? Primo, MASH is "Modular Arithmetic" cryptographic primitive based on the X^2 mod N primitive (Rabin-Williams cryptosystems family). We can then refer to the initial MASH design rationales, the history of Rabin-Williams cryptosystems, and recent theoretical results on the "provable security". Secundo, MASH allows the flexible selection of cryptographic strength (no issue of algorithm rollover, no digest type to select among e.g. SHA-1 or SHA-..., just pick up larger parameters). Tertio, MASH has parameters that allow the (hidden) selection of parameters, i.e. a hash function selection among a family. Quarto, the bad performance of MASH has negligible impact for trust anchor key rollover, at a nominal frequency of 0.000000032 transaction per second (once per year). Quinto, the alternative, SHA-1 SHA-... carries the potential for delay-incuding debates due to the recent security weakening of SHA-1 from 2^80 to 2^69. About primo, I can provide a few academic references if it helps About secundo and tertio, see http://www.connotech.com/takrem.pdf About quinto, see e.g. http://www.csrc.nist.gov/pki/HashWorkshop/participation.html Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 22 04:13:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIMCv-0008GC-7V for dnsext-archive@megatron.ietf.org; Thu, 22 Sep 2005 04:13:30 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14049 for ; Thu, 22 Sep 2005 04:13:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIM87-000O8h-99 for namedroppers-data@psg.com; Thu, 22 Sep 2005 08:08:31 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIM84-000O8A-Pa for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 08:08:29 +0000 Received: from staff.nominet.org.uk ([213.248.199.129]) by mx3.nominet.org.uk with ESMTP; 22 Sep 2005 09:08:27 +0100 X-IronPort-AV: i="3.97,135,1125874800"; d="scan'208"; a="1298119:sNHT23978636" Received: (from geoff@localhost) by staff.nominet.org.uk (8.12.9/8.12.9) id j8M88Q2K018623 for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 09:08:26 +0100 (BST) Date: Thu, 22 Sep 2005 09:08:26 +0100 (BST) From: Geoffrey Sisson Message-Id: <200509220808.j8M88Q2K018623@staff.nominet.org.uk> To: namedroppers@ops.ietf.org Subject: Re: comments on p-s X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi Sam Thanks for the thorough review; A revised (pre-submitted) draft is available at: http://www.panix.com/~geoff/draft-ietf-dnsext-dns-name-p-s-01pre1.txt An rfcdiff of -00 to -01pre1 is available at: http://www.panix.com/~geoff/draft-ietf-dnsext-dns-name-p-s-01pre1-from-00.diff.html Comments inline: Samuel Weiler writes: > Four comments of some substance, the rest is editorial. None of these > need block the document. > > -- Add a specific reminder in section 5 that before using the output > of P and P' in an NSEC RR, the server needs to test for that name's > existence and possibly use a non-synthesized NSEC RR. Refer to > online-signing section 2. Thanks, good catch. I've added the following text: ------------------------ Begin included text ------------------------ 4.1. Test for Existence Before using the result of P(N) or P'(N) as the owner name of an NSEC RR in a DNS response, a name server should test to see whether the name exists. If it does, either a standard non-synthesised NSEC RR should be used, or the synthesised NSEC RR should reflect the RRset types that exist at the NSEC RR's owner name in the Type Bit Map field as specified by Section 4.1.2 of [RFC4034]. Implementors will likely find it simpler to use a non-synthesised NSEC RR. For further details see Section 2 of [I-D.ietf-dnsext-dnssec-online-signing]. ------------------------- End included text ------------------------- BTW should `must' be `MUST' in this sentence from online-signing? ------------------------ Begin included text ------------------------ Before answering a query with these records, an authoritative server must test for the existence of names between these endpoints. ------------------------- End included text ------------------------- > This could really be clarified in P'(N) Step 2, which needs to say > "Use the apex NSEC RR" or at least "this is the name of the zone". I've added this text to Step 2 of P'(N): ------------------------ Begin included text ------------------------ (If this condition is met, P'(N) is the owner name of the apex.) ------------------------- End included text ------------------------- . . . and have also added equivalent text to Step 2 of P(N). > -- In Sections 3 & 4, I kept wondering where the maximum label/name > lengths were defined. 5.4.1 mentions total name length only. > Suggestion: To make it easier for the reader, add, in 3 or 5.4.1: > As a reminder, the maximum DNS label length (as defined in > [RFC1034] Section 3.1) is 63 octets and the maximum total name > length is 255 octets. > I first wondered about this in section 3.1, step 1. I've added the following text to the (now unified) introduction to the derivations: ------------------------ Begin included text ------------------------ The derivations make reference to maximum label length and maximum DNS name length; these are defined in Section 3.1 of [RFC1034] to be 63 and 255 octets respectively. ------------------------- End included text ------------------------- > -- Are you certain that P' and S' (section 4) handle arbitrary > queries, noting that an attacker can send any query, independent of > what's in the zone? I think it is, but I haven't convinced myself > yet. I've tested it pretty thourougly, but I think I will subject it to additional testing in view of the pointed nature of this question. :) > -------------- > > 3.2 step four. "do nothing" confuses me. Does this mean "use the > current value as S(N)"? It means make no changes to the value of N. I've changed it to: ------------------------ Begin included text ------------------------ 4. Remove the least significant (left-most) label. Unless N is the same as the owner name of the zone apex (this will occur only if N is the maximum possible name in canonical DNS name order, and thus has wrapped to the owner name of zone apex), repeat starting at step 2. ------------------------- End included text ------------------------- This removes the awkward "do nothing", though at the expense of creating a slightly over-long sentence. Note that in this doc, N has been overloaded to mean: 1. The value of the input. 2. The variable whose value changes (or persists) as successive steps of a derivation are applied. I don't think this is more confusing than any other method of expression, short of using pseudo code. (I was initially tempted to use pseudo-code, but this is broadly discouraged by http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt) > 3.1 step four, add "in the lest significant (left-most) label" Done (with a minor variation); this is the new text: ------------------------ Begin included text ------------------------ 4. Decrement the value of the least significant (right-most) octet of the least significant (left-most) label, skipping any values that correspond to uppercase US-ASCII letters, and then append the least significant label with as many octets as possible of the maximum sort value. Continue to the next step. ------------------------- End included text ------------------------- > 3.2 step two, s/"If N is one or more"/"If N is one"/, since "or more" > should have been taken care of by step one. Done. > Lastly, in section 1, item 2: s/owner name/label/, This is the new text: ------------------------ Begin included text ------------------------ 2. A ``modified method'', which returns a predecessor and successor which are more economical in size and computation. This method is restricted to use with zones consisting exclusively of owner names that contain no more than one label more than the owner name of the apex, where the longest possible owner name (i.e. one with a maximum length left-most label) would not exceed the maximum DNS name length. This is, however, the type of zone for which the technique of online signing is most likely to be used. ------------------------- End included text ------------------------- > and don't hyphenate > "online signing" Done. > OLD: This method > is restricted to use with zones consisting only of single-label > owner names where a maximum-length owner name would not result > in a DNS name exceeding the maximum DNS name length. This is, > however, the type of zone for which the technique of online- > signing is most likely to be used. > > NEW: This method > is restricted to use with zones consisting only of single-label > owner names where a maximum-length label would not result > in a DNS name exceeding the maximum DNS name length. This is, > however, the type of zone for which the technique of online > signing is most likely to be used. Thanks again. Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 22 05:18:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EINDr-0000W8-Mr for dnsext-archive@megatron.ietf.org; Thu, 22 Sep 2005 05:18:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17047 for ; Thu, 22 Sep 2005 05:18:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIN9l-0003Da-E8 for namedroppers-data@psg.com; Thu, 22 Sep 2005 09:14:17 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIN9h-0003DI-Ih for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 09:14:13 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 0C08EC2DFC; Thu, 22 Sep 2005 10:14:12 +0100 (BST) Date: Thu, 22 Sep 2005 10:14:08 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Thierry Moreau , Ben Laurie Cc: Namedroppers , Alex Bligh Subject: Re: Takrem for DNSSEC (was Re: state of vixie-dnssec-ter?) Message-ID: <7566782BB24E0862F412827F@[192.168.100.25]> In-Reply-To: <4332506A.90708@connotech.com> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED <43315071.7090504@algroup.co.uk> <433180BD.9010504@connotech.com> <43317D8F.5010103@algroup.co.uk> <4332506A.90708@connotech.com> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 22 September 2005 02:34 -0400 Thierry Moreau wrote: > Primo, MASH is "Modular Arithmetic" cryptographic primitive Excuse my ignorance on the subject, but is MASH demonstrably unencumbered by IPR concerns (like SHA-x)? Given the main attack on *long* hashes these days seems to be legal as opposed to computational, I wonder whether selecting SHA-(largenum) isn't better purely because the algorithms, implementations, and IPR considerations are already widely known. (No, I don't feel strongly about this, my eyebrows just raise when we pick another crypto-algorithm-du-jour) Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 22 10:25:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIS1L-0005Yc-8t for dnsext-archive@megatron.ietf.org; Thu, 22 Sep 2005 10:25:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03526 for ; Thu, 22 Sep 2005 10:25:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIRva-0001DX-RJ for namedroppers-data@psg.com; Thu, 22 Sep 2005 14:19:58 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EIRvZ-0001DH-HZ for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 14:19:57 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.3/8.13.3) with ESMTP id j8MEJojn064739; Thu, 22 Sep 2005 16:19:50 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <6.2.1.2.2.20050921164406.04d49eb0@localhost> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> <6.2.1.2.2.20050921164406.04d49eb0@localhost> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-915216962" Message-Id: <0FBB5217-09DC-4A5B-A3D0-A228CC1226EE@NLnetLabs.nl> Cc: Namedroppers From: "Olaf M. Kolkman" Subject: Re: rollover transition mechanism Date: Thu, 22 Sep 2005 16:19:48 +0200 To: Mike StJohns Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_30_40, HTML_MESSAGE autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2-915216962 Content-Type: multipart/alternative; boundary=Apple-Mail-1-915216764 --Apple-Mail-1-915216764 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit I am afraid I fell in the trap of wearing to many hats; chair, "competing" document co-author, interested participant of DNSEXT and active deployer of DNSSEC. On Sep 21, 2005, at 22:54 , Mike StJohns wrote: > In a private note to Olaf I pointed out that this is neither a > requirement of becoming an ID nor of becoming an RFC. Its not an > appropriate comment from a WG chair to suggest this is a failing of > an ID or proposal. I did not try suggest that this document could not go forward without an implementation. I was merely responding to Sam's statement. He was questioning if there needed to be a signaling mechanism. My experience with DNSSEC protocol development I've been involved in is that that is the kind of thing one finds out by actually going through the operational motions i.e. by experimenting with an implementation. It would be nice to have such implementation was essentially what I tried to say, as "namedropper". But you are correct: There is no IETF-process requirement on having an implementation. And I, as chair, don't want to break the process by imposing such requirement. [*] > In any event this has been going on for 18 months with little if > any movement. Either we're going to do something about trust > anchor rollover or we're not. If there is no conclusion by the > end of November, and absent any compelling reason not to, I'll be > withdrawing my draft. There are many reasons for not seeing any progress and I share Mike's frustration. I am prepared to take some of the blame, not all. But lets not As a co-author of the 'competing' work I have not done much to push that work, as a matter of fact I over the last months I have been more and more convinced that there is very little difference between the two proposals and that it is not worth to turn those into religious items. As a DNSSEC deployer I agree with Paul's statement that DNSSEC will not fly without some rollover mechanism. As a namedropper I'd happily spend my energy on getting closure on Mike's document. --Olaf [*] I do think that --- although there is no process requirement -- this group agreed that some experiments with NSEC3 would be useful for forward progress, please tell me if you think I'm wrong. --Apple-Mail-1-915216764 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


I am afraid I fell in the = trap of wearing to many hats; chair, "competing" document co-author, = interested participant of DNSEXT and active deployer of = DNSSEC.=A0=A0

On Sep 21, 2005, at = 22:54 , Mike StJohns wrote:

In a = private note to Olaf I pointed out that this is neither a requirement of = becoming an ID nor of becoming an RFC.=A0 Its not an appropriate comment = from a WG chair to suggest this is a failing of an ID or = proposal.

I did not try suggest that = this document could not go forward without an implementation. I was = merely responding to Sam's statement. He was questioning if there needed = to be a signaling mechanism. My experience with DNSSEC protocol = development I've been involved in is that that is the kind of thing one = finds out by actually going through the operational motions i.e. by = experimenting with an implementation. It would be nice to have such = implementation was essentially what I tried to say, as = "namedropper".

But you are correct: = There is no IETF-process requirement=A0 on having an implementation. And = I, as chair, don't want to break the process by imposing such = requirement. [*]

In = any event this has been going on for 18 months with little if any = movement.=A0 Either we're going to do something about trust anchor = rollover or we're not. =A0 If there is no conclusion by the end of = November, and absent any compelling reason not to, I'll be withdrawing = my draft.


There are many reasons for = not seeing any progress and I share Mike's frustration. I am prepared to = take some of the blame, not all. But lets not=A0

As a co-author of the = 'competing' work I have not done much to push that work, as a matter of = fact I over the last months I have been more and more convinced that = there is very little difference between the two proposals and that it is = not worth to turn those into=A0religious=A0items.=A0

As a DNSSEC deployer I = agree with Paul's statement that DNSSEC will not fly without some = rollover mechanism.

As a namedropper = I'd=A0happily spend my energy on getting closure on Mike's = document.=A0

--Olaf=A0


[*] <chair hat> I do = think that --- although there is no process requirement -- this group = agreed that some experiments with NSEC3 would be useful for forward = progress, please tell me if you think I'm wrong.</chair = hat>

= --Apple-Mail-1-915216764-- --Apple-Mail-2-915216962 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDMr2EtN/ca3YJIocRAmuRAKDcRCP+ksd4/o/sPyLiFeQlenjSIQCcDo3y RI2gWUtqj9jCn2F5ZuLHF2Y= =jedT -----END PGP SIGNATURE----- --Apple-Mail-2-915216962-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 22 10:26:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIS1j-0005eM-Tl for dnsext-archive@megatron.ietf.org; Thu, 22 Sep 2005 10:26:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03553 for ; Thu, 22 Sep 2005 10:26:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIRyg-0001Qd-80 for namedroppers-data@psg.com; Thu, 22 Sep 2005 14:23:10 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EIRyf-0001QQ-DO for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 14:23:09 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.3/8.13.3) with ESMTP id j8MEN3YF064760; Thu, 22 Sep 2005 16:23:04 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <20050921212012.38F2511449@sa.vix.com> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> <6.2.1.2.2.20050921164406.04d49eb0@localhost> <20050921212012.38F2511449@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5DE67BFB-8A53-4C77-9520-471A98D462E5@NLnetLabs.nl> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: rollover transition mechanism Date: Thu, 22 Sep 2005 16:23:01 +0200 To: Paul Vixie X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > can the chairs ask some pointed questions? like: Thanks for the instructions .... ;-) On Sep 21, 2005, at 23:20 , Paul Vixie wrote: > 1. is dnssec-bis deployable without this kind of key management? > 2. is dnssec-bis deployable without any other kinds of key management? > 3. is dnssec-bis deployable without anything unrelated to key > management? > > 4. does mike's proposal appear to be unworkable? if so, how or why? > 5. does mike's proposal solve the wrong problem? if so, how or why? > 6. does mike's proposal fail to solve the whole problem? if so, > how or why? > > 7. does a competing proposal offer a more provable/testable/simple > solution? > 8. does a competing proposal solve at least the same important > problems? > 9. does a competing proposal solve important problems this one > doesn't address? > Sounds like you are asking us to do a last call. - --Olaf (hat on) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDMr5GtN/ca3YJIocRAhQ4AJ9ljPoP8vPI8S5gfS3hUBnmyepe6QCg13VV 5O7an9u45a1pS8lcsALnVXU= =fmZ9 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 22 10:43:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EISIa-0002rU-OP for dnsext-archive@megatron.ietf.org; Thu, 22 Sep 2005 10:43:44 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04646 for ; Thu, 22 Sep 2005 10:43:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EISFV-0002yy-8z for namedroppers-data@psg.com; Thu, 22 Sep 2005 14:40:33 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EISFT-0002yS-HX for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 14:40:31 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j8MEeIP3011504; Thu, 22 Sep 2005 10:40:20 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <5DE67BFB-8A53-4C77-9520-471A98D462E5@NLnetLabs.nl> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> <6.2.1.2.2.20050921164406.04d49eb0@localhost> <20050921212012.38F2511449@sa.vix.com> <5DE67BFB-8A53-4C77-9520-471A98D462E5@NLnetLabs.nl> Date: Thu, 22 Sep 2005 10:40:29 -0400 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: rollover transition mechanism Cc: Paul Vixie , Namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:23 +0200 9/22/05, Olaf M. Kolkman wrote: >Sounds like you are asking us to do a last call. More like a "first call" to me... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 22 11:13:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EISlF-0001tZ-6O for dnsext-archive@megatron.ietf.org; Thu, 22 Sep 2005 11:13:21 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05990 for ; Thu, 22 Sep 2005 11:13:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EISio-0006Yu-Fd for namedroppers-data@psg.com; Thu, 22 Sep 2005 15:10:50 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EISim-0006Yg-Mm for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 15:10:48 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j8MF6TWA018593 for ; Thu, 22 Sep 2005 11:06:29 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAd8aOsK; Thu, 22 Sep 05 11:06:26 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j8MF8LMn027493; Thu, 22 Sep 2005 11:08:21 -0400 (EDT) Date: Thu, 22 Sep 2005 11:08:21 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Mike StJohns cc: Namedroppers Subject: Re: rollover transition mechanism In-Reply-To: <6.2.1.2.2.20050921164406.04d49eb0@localhost> Message-ID: References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> <6.2.1.2.2.20050921164406.04d49eb0@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 21 Sep 2005, Mike StJohns wrote: > In any event this has been going on for 18 months with little if any > movement. Either we're going to do something about trust anchor rollover > or we're not. If there is no conclusion by the end of November, and > absent any compelling reason not to, I'll be withdrawing my draft. It's not clear to me what you want the WG to "do" or "conclude". Could you be more specific? I see no problem with the WG keeping both drafts active, assuming there are proponents for each approach. Your message above as well as your comments in Paris suggest to me that you don't want to be such a proponent for this technology -- if that is indeed the case, then I hope you will withdraw the draft posthaste. -- 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: From owner-namedroppers@ops.ietf.org Thu Sep 22 11:30:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIT1y-000076-4T for dnsext-archive@megatron.ietf.org; Thu, 22 Sep 2005 11:30:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06878 for ; Thu, 22 Sep 2005 11:30:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EISz6-0007ti-TK for namedroppers-data@psg.com; Thu, 22 Sep 2005 15:27:40 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EISz5-0007tP-7T for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 15:27:39 +0000 Received: from monsoon.verisignlabs.com ([::ffff:172.25.170.10]) by mail.verisignlabs.com with esmtp; Thu, 22 Sep 2005 11:27:37 -0400 id 005BC054.4332CD6A.000018D6 Received: by monsoon.verisignlabs.com (Postfix, from userid 1000) id B8252137E6B; Thu, 22 Sep 2005 11:27:37 -0400 (EDT) Date: Thu, 22 Sep 2005 11:27:37 -0400 From: Matt Larson To: "Olaf M. Kolkman" Cc: Mike StJohns , Namedroppers Subject: Re: rollover transition mechanism Message-ID: <20050922152737.GQ28972@monsoon.verisignlabs.com> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> <6.2.1.2.2.20050921164406.04d49eb0@localhost> <0FBB5217-09DC-4A5B-A3D0-A228CC1226EE@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <0FBB5217-09DC-4A5B-A3D0-A228CC1226EE@NLnetLabs.nl> User-Agent: Mutt/1.5.10i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 22 Sep 2005, Olaf M. Kolkman wrote: > [*] I do think that --- although there is no process > requirement -- this group agreed that some experiments with NSEC3 > would be useful for forward progress, please tell me if you think I'm > wrong. We have heard from multiple parties who want the various features offered by NSEC3. Therefore, keeping this document moving and having a workshop seems like a good idea. VeriSign will have an implementation to participate with. Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 22 13:22:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIUmO-0000MM-6Y for dnsext-archive@megatron.ietf.org; Thu, 22 Sep 2005 13:22:40 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11934 for ; Thu, 22 Sep 2005 13:22:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIUjG-000HUc-3S for namedroppers-data@psg.com; Thu, 22 Sep 2005 17:19:26 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EIUjF-000HUQ-GP for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 17:19:25 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 05F9611449; Thu, 22 Sep 2005 17:19:25 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "Olaf M. Kolkman" cc: Namedroppers Subject: Re: rollover transition mechanism In-Reply-To: Your message of "Thu, 22 Sep 2005 16:23:01 +0200." <5DE67BFB-8A53-4C77-9520-471A98D462E5@NLnetLabs.nl> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> <6.2.1.2.2.20050921164406.04d49eb0@localhost> <20050921212012.38F2511449@sa.vix.com> <5DE67BFB-8A53-4C77-9520-471A98D462E5@NLnetLabs.nl> Date: Thu, 22 Sep 2005 17:19:25 +0000 Message-Id: <20050922171925.05F9611449@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # > can the chairs ask some pointed questions? like: # # Thanks for the instructions .... ;-) not instructions, just a request. # > 1. is dnssec-bis deployable without this kind of key management? # > 2. is dnssec-bis deployable without any other kinds of key management? # > 3. is dnssec-bis deployable without anything unrelated to key management? # > # > 4. does mike's proposal appear to be unworkable? if so, how or why? # > 5. does mike's proposal solve the wrong problem? if so, how or why? # > 6. does mike's proposal fail to solve the whole problem? if so, how or # > why? # > # > 7. does a competing proposal offer a more provable/testable/simple # > solution? # > 8. does a competing proposal solve at least the same important problems? # > 9. does a competing proposal solve important problems this one doesn't # > address? # > # # Sounds like you are asking us to do a last call. not at all. if the WG doesn't know the answers to those questions well before we get to the point of WGLC, then we're going to be "in the weeds" forever. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 22 13:22:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIUmT-0000Mh-95 for dnsext-archive@megatron.ietf.org; Thu, 22 Sep 2005 13:22:45 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11940 for ; Thu, 22 Sep 2005 13:22:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIUkc-000Hbw-CM for namedroppers-data@psg.com; Thu, 22 Sep 2005 17:20:50 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EIUkb-000Hbh-KL for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 17:20:49 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id EE33156881; Thu, 22 Sep 2005 10:20:47 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.2.1.2.2.20050922131344.07950a30@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 22 Sep 2005 13:21:11 -0400 To: Samuel Weiler From: Mike StJohns Subject: Re: rollover transition mechanism Cc: Namedroppers In-Reply-To: References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> <6.2.1.2.2.20050921164406.04d49eb0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:08 AM 9/22/2005, Samuel Weiler wrote: >On Wed, 21 Sep 2005, Mike StJohns wrote: > > > In any event this has been going on for 18 months with little if any > > movement. Either we're going to do something about trust anchor rollover > > or we're not. If there is no conclusion by the end of November, and > > absent any compelling reason not to, I'll be withdrawing my draft. > >It's not clear to me what you want the WG to "do" or "conclude". >Could you be more specific? Check the record. 18 months ago the WG accepted these two drafts as work items with the idea that one approach would become blessed and the WG would do an RFC from it. That decision never happened. Unlike you I see large problems with having two different approaches to doing a trust anchor rollover. So the "conclusion" I'm looking for is which approach to pursue and the default is that if the WG doesn't decide by November it will be the other draft. At this point its becoming more important to get something published and fielded than to argue about which approach is better. OTOH unless the other draft is resubmitted soon that's going to leave us with no approach. >I see no problem with the WG keeping both drafts active, assuming >there are proponents for each approach. Your message above as well as >your comments in Paris suggest to me that you don't want to be such a >proponent for this technology -- if that is indeed the case, then I >hope you will withdraw the draft posthaste. > >-- 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: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 22 14:13:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIVZ9-0007Ig-8Z for dnsext-archive@megatron.ietf.org; Thu, 22 Sep 2005 14:13:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14851 for ; Thu, 22 Sep 2005 14:13:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIVWL-000MAQ-Aa for namedroppers-data@psg.com; Thu, 22 Sep 2005 18:10:09 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EIVWJ-000MAE-7z for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 18:10:07 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1EIVWH-000FTe-LF for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 14:10:05 -0400 Received: by internaut.com (Postfix, from userid 1000) id C825F34FF3; Thu, 22 Sep 2005 11:10:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id BA61132887 for ; Thu, 22 Sep 2005 11:10:05 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Thu, 22 Sep 2005 11:10:05 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Response to LLMNR Last Call Comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis said: "Security concerns I understand and would become a work item" Since security issues came up in the LLMNR Last Call discussions, it would be useful for DNSEXT WG to discuss that issue, although I'm not clear that a separate work item would be required. For example, it would be useful to understand what if any barriers exist to the use of TSIG, SIG(0) and DNSSEC in the mDNS and LLMNR specifications, and how they could be overcome. It would also be useful for the DNSEXT WG to discuss the other issues that were raised, such as defining the behavior of DNS resolvers with respect to the .local domain. Paul Vixie stated: >while i agree with this in general, i have three specific concerns. > >1. the right way to do multicast DNS is draft-manning-opcode-discover-01, So why not publish that document as well? > and while apple and microsoft both call their approaches "multicast > dns" they are really "overloading dns to carry service discovery in > multicast". LLMNR is not a service discovery protocol. It is usable solely for name resolution. While the discussion of mDNS in the two ZEROCONF BOFs centered on service discovery, discussion in the ZEROCONF WG did not converge and work on service discovery was not chartered in ZEROCONF or DNSEXT. Since people's memory of events that occurred more than 6 years ago may be a bit foggy, I've gone back through the proceedings, which document what happened in the ZEROCONF BOFs, as well as early discussions in the DNSEXT WG. That information is available here: http://www.drizzle.com/~aboba/DNSEXT/history.txt >2. any attempt to merge mdns and llmnr MUST be backward compatible with >mdns, since apple has created an important new economy of mdns >services/devices and ietf should only ignore this economy if mdns is the >provably wrong approach, rather than merely suboptimal in some way (that >i'm unaware of). mDNS is designed to serve as a service discovery substrate for DNS-SD. If the DNSEXT WG and IESG want to reverse their prior edicts against DNS-SD and use of DNS for service discovery, as well as the refusal to allow Bill's document to move forward, that is fine with me. However, that is really an orthogonal issue as far as LLMNR is concerned. At this point, LLMNR has also shipped in multiple implementations, and given the past history of IETF activity, I doubt there is anyone interested in working on a "merger" effort. The only reasonable thing to do is to address the LC comments, publish (as Experimental or Informational, probably) and move on. >3. if this is really about PnP, i sure wish that everybody would just say >so and re-frame the debate in PnP terms and stop treating it as a dns >issue that's somehow relevant to the skills of the core namedroppers >community. While mDNS relates to PnP service discovery, LLMNR does not. So no, the LLMNR discussion isn't about PnP or service discovery. It's largely about security issues, and resolver behavior. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 22 17:56:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZ3K-0003wk-6I for dnsext-archive@megatron.ietf.org; Thu, 22 Sep 2005 17:56:26 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28100 for ; Thu, 22 Sep 2005 17:56:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIYyU-000GSD-Is for namedroppers-data@psg.com; Thu, 22 Sep 2005 21:51:26 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EIYyR-000GRn-FJ for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 21:51:23 +0000 Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j8MLpAP2018293 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 22 Sep 2005 17:51:13 -0400 Date: Thu, 22 Sep 2005 17:51:10 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: David Conrad cc: Mike StJohns , "Olaf M. Kolkman" , Namedroppers Subject: Re: rollover transition mechanism In-Reply-To: <1F42CA23-D8C2-47A1-A1F4-1DCBA73BA97A@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Err, I don't think Mike or David are correct. While many have lamented the "lack of running code" for many RFCs, I think the official policy (RFC2026) for 2 or more working implementations for "Draft Standard" status has not been changed. While there is no requirement for a _draft_ to have working code, obviously chicken and egg, it is entirely appropriate for the chairs of various working groups to criticize moving ahead drafts that aren't supported at all by working code to "Proposed Standard" RFCs. "Proposed Standard" status requires among other things, that there be no technical omissions unless waived by the IESG. While a working implementation is not absolutely required, as RFC2026 notes in section 4.1.1, working code is a strong argument in favor. It goes unsaid that lack of working code is a strong argument against considering a draft mature enough to become a "Proposed Standard". Plainly, if no one is going to bother to implement something, its consideration of RFC maturity is probably a waste of time. The recent failures [hence the grumbling about having "moved away"] of some WG chairs to require working code does not alter the policy of the IETF. If, however, the IETF policy has in fact been changed without my noticing, please provide a link to the new controlling RFC updating this policy. --Dean On Wed, 21 Sep 2005, David Conrad wrote: > Hi, > > Having not read the draft, I can make no comment on it, however: > > On Sep 21, 2005, at 1:54 PM, Mike StJohns wrote: > >> The magic words are: implementation and testing. AFAIK Mike's > >> proposal only consists of spec-ware (correct?). > > In a private note to Olaf I pointed out that this is neither a > > requirement of becoming an ID nor of becoming an RFC. Its not an > > appropriate comment from a WG chair to suggest this is a failing of > > an ID or proposal. > > What Mike says is true. The IETF moved away from "running code" long > ago. To impose a requirement of implementation and testing on a > particular document and not others is ... questionable. My personal > preference would be to require implementation for all drafts, but > that's neither here nor there... > > Rgds, > -drc > > > -- > 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: > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 23 08:06:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EImJj-0000ry-H2 for dnsext-archive@megatron.ietf.org; Fri, 23 Sep 2005 08:06:17 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10591 for ; Fri, 23 Sep 2005 08:06:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EImFs-000Oaz-R3 for namedroppers-data@psg.com; Fri, 23 Sep 2005 12:02:16 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EImFq-000OaT-Uc for namedroppers@ops.ietf.org; Fri, 23 Sep 2005 12:02:15 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 056F133C1B; Fri, 23 Sep 2005 13:02:13 +0100 (BST) Message-ID: <4333EEC8.5060307@algroup.co.uk> Date: Fri, 23 Sep 2005 13:02:16 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matt Larson CC: "Olaf M. Kolkman" , Mike StJohns , Namedroppers Subject: Re: rollover transition mechanism References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> <6.2.1.2.2.20050921164406.04d49eb0@localhost> <0FBB5217-09DC-4A5B-A3D0-A228CC1226EE@NLnetLabs.nl> <20050922152737.GQ28972@monsoon.verisignlabs.com> In-Reply-To: <20050922152737.GQ28972@monsoon.verisignlabs.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Matt Larson wrote: > On Thu, 22 Sep 2005, Olaf M. Kolkman wrote: > >>[*] I do think that --- although there is no process >>requirement -- this group agreed that some experiments with NSEC3 >>would be useful for forward progress, please tell me if you think I'm >>wrong. > > > We have heard from multiple parties who want the various features > offered by NSEC3. Therefore, keeping this document moving and having > a workshop seems like a good idea. VeriSign will have an > implementation to participate with. And I have one for BIND 9 (server and dig). -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 23 08:07:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EImLE-0001C3-JI for dnsext-archive@megatron.ietf.org; Fri, 23 Sep 2005 08:07:48 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10677 for ; Fri, 23 Sep 2005 08:07:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EImJf-000PAO-1A for namedroppers-data@psg.com; Fri, 23 Sep 2005 12:06:11 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EImJd-000P9s-Lv for namedroppers@ops.ietf.org; Fri, 23 Sep 2005 12:06:09 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id CA9F333C1E; Fri, 23 Sep 2005 13:06:07 +0100 (BST) Message-ID: <4333EFB3.8080100@algroup.co.uk> Date: Fri, 23 Sep 2005 13:06:11 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike StJohns CC: Samuel Weiler , Namedroppers Subject: Re: rollover transition mechanism References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> <6.2.1.2.2.20050921164406.04d49eb0@localhost> <6.2.1.2.2.20050922131344.07950a30@localhost> In-Reply-To: <6.2.1.2.2.20050922131344.07950a30@localhost> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mike StJohns wrote: > At 11:08 AM 9/22/2005, Samuel Weiler wrote: > >> On Wed, 21 Sep 2005, Mike StJohns wrote: >> >> > In any event this has been going on for 18 months with little if any >> > movement. Either we're going to do something about trust anchor >> rollover >> > or we're not. If there is no conclusion by the end of November, and >> > absent any compelling reason not to, I'll be withdrawing my draft. >> >> It's not clear to me what you want the WG to "do" or "conclude". >> Could you be more specific? > > > Check the record. 18 months ago the WG accepted these two drafts as > work items with the idea that one approach would become blessed and the > WG would do an RFC from it. That decision never happened. Unlike you I > see large problems with having two different approaches to doing a trust > anchor rollover. So the "conclusion" I'm looking for is which approach > to pursue and the default is that if the WG doesn't decide by November > it will be the other draft. At this point its becoming more important > to get something published and fielded than to argue about which > approach is better. OTOH unless the other draft is resubmitted soon > that's going to leave us with no approach. There's my "web of trust" approach (which also handles key distribution). I've heard renewed interest in this recently. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 23 10:33:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIocA-00048i-NR for dnsext-archive@megatron.ietf.org; Fri, 23 Sep 2005 10:33:26 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18684 for ; Fri, 23 Sep 2005 10:33:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIoYu-000ExZ-4g for namedroppers-data@psg.com; Fri, 23 Sep 2005 14:30:04 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EIoYp-000EtE-RD for namedroppers@ops.ietf.org; Fri, 23 Sep 2005 14:30:00 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j8NETqou017822; Fri, 23 Sep 2005 10:29:52 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.3.4.2.20050923102256.047ba5f0@wheresmymailserver.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 23 Sep 2005 10:29:40 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Cc: ogud@ogud.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 03:53 20/09/2005, Olaf M. Kolkman wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >Dear Colleagues, > >I have the impression we are going around in circles and that we are >not converging any further. > >I'd like to ask if we can all consent with the document as is now >(http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis-06.txt). I hate to do this at this late time, but IANA section is not sufficient. IANA dropped the ball on RFC2538 and never created the requested CERT RR registry and the WG never noticed this. So the new document needs to say explicitly that the registry needs to be created and define the initial contents. Suggested IANA considerations section: -------- IANA needs to create a new registry for CERT RR, certificate types. The initial contents of this registry is: 0 reserved 1 PKIX X.509 as per PKIX 2 SPKI SPKI certificate 3 PGP OpenPGP packet 4 IPKIX The URL of an X.509 data object 5 ISPKI The URL of an SPKI certificate 6 IPGP The URL of an OpenPGP packet 7-252 available for IANA assignment by IETF Standards action 253 URI URI private 254 OID OID private 255-65023 available for IANA assignment by IETF Consensus. 65024-65534 experimental 65535 reserved Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can only be assigned by an IETF standards action [7]. This document assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate types 0x0100 through 0xFEFF are assigned through IETF Consensus [7] based on RFC documentation of the certificate type. The availability of private types under 0x00FD and 0x00FE ought to satisfy most requirements for proprietary or private types. The CERT RR reuses the DNS Security Algorithm Numbers registry. In particular, the CERT RR requires that algorithm number 0 remain reserved, as described in Section 2. The IANA is directed to reference the CERT RR as a user of this registry and value 0, in particular. ------ >- --Olaf (In capacity of "document shepherd" ) I do not think this is controversial, and in off-list discussion Simon and Olaf seem to agree with this change. The main change is that range 65024-65534 is defined as experimental and no allocations will be made in that area. Olafur (as the nit-picker-in-residence) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 23 12:03:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIq12-0000Cp-4o for dnsext-archive@megatron.ietf.org; Fri, 23 Sep 2005 12:03:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22682 for ; Fri, 23 Sep 2005 12:03:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIpxE-000PLG-GH for namedroppers-data@psg.com; Fri, 23 Sep 2005 15:59:16 +0000 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIpxB-000PKp-HI for namedroppers@ops.ietf.org; Fri, 23 Sep 2005 15:59:13 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO01B2A2; 23 Sep 2005 12:02:28 -0400 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 23 Sep 2005 12:02:19 -0400 Received: from connotech.com (209.71.204.110) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG01B2A0; 23 Sep 2005 12:02:05 -0400 Message-ID: <43342DDE.60602@connotech.com> Date: Fri, 23 Sep 2005 12:31:26 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Namedroppers Subject: Survey of Rollover Mechanisms Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RCVD_IN_SBL autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all: In order to assist the discussion, here is a survey of trust anchor key mechanisms. The 1 1/2 Internet drafts that are being discussed are in survey entries 2.a) and 2.b). Other entries do not appear in the current IETF agenda but may be relevant since they address the same rollover requirement. As a reminder, trust anchor key rollover relates to the need to change the KSK of a DNSSEC-aware DNS zone when the parent zone is DNSSEC-obvlious. It will apply to the root zone if and when it becomes DNSSEC-aware, and to "islands of trust" in the meantime. Trust anchor key rollover is a tough problem, linked ultimately to the trust anchor key initial distribution. Any rollover mechanism has a catastrophic failure mode, so there is no good solution: if a security incident falls in the catastrophic failure mode definition, the rollover mechanism becomes insecure and the trust anchor key initial distribution must be re-done. For now, I leave to the readers the task of identifying the catastrophic failure mode definition for each entry, but for the easiest one. 1. Outside Certification Description: outside certification relies on the digital signatures in a context different from the DNS hierarchy. In terms of security fundamentals, it shifts the "root" to some other set of rules. 1.a) Ben Laurie's "Distributing Keys for DNSSEC" use X.509 security certificates for outside certification of trust anchor keys. See reference [1]. 1.b) DLV is not presented as a rollover mechanism, but it does fit the definition of outside certification. DLV uses a "lookaside" digital signature by a "DLV operator" who more or less replaces the higher part of the DNSSEC hierarchy until "islands of trust" vanishes because the root and TLDs become DNSSEC-aware. For DNSSEC-aware resolvers, the DLV approach makes use of familiar DNSSEC protocol elements. See references [2] and [3]. 2. Plurality of trust anchor keys Description: with these two schemes, a trust anchor should be materialized with a set of public keys, and the rollover operation is done by the zone manager a subset at a time, so that the DNS resolvers can rely on the "not-rolled" keys to get confidence in the new keys. 2.a) The threshold mechanism being discussed currently in the DNSEXT working group, despite being an expired draft. See reference [4]. 2.b) The timing mechanism also discussed now in DNSEXT. See reference [5]. 3. Pre-announcement with plurality of digests Description: upon trust anchor key initial distribution, a list of cryptographic digests of future keys is distributed as well. The DNS resolvers validate a key rollover against the digest originally received. 3.a) The TAKREM mechanism, which I introducte to DNSEXT as a pre-draft document with discussion, rationales. See reference [6]. 3.b) The same TAKREM mechanism may be used with a "plain" hash function (e.g. SHA-1) instead of a parameterized one like MASH (ISO/IEC 10118-4:1998). 4. Long-lasting trust anchor keys Description: if no rollover method is found adequate, a long-lasting trust anchor key is an easy to specify method. With this method, any type of incident falls under the definition of catastrophic failure mode, while other methods leave some type of incidents in this category. 5. Out-of-band Validated Rollover Description: the "textbook" rollover method is to distribute the key to DNS resolvers and use an out-of- band channel to let the end-users validate the new key. There isn't the slightest chance that this is operationally feasible in any context. The out-of-band validated rollover method is documented to support the long-lasting trust anchor key method. The above survey is the easy part. The tough part is to determine what would be reasonable requirements for DNSSEC good fate, while no good solution exist. Thereafter, these requirements may, or might not, or might partly, be considered within the scope of the IETF mandate. For instance, the DLV promoters would like to have a DLV RR type assigned to the DLV method, but leave every other aspects of the specification outside of the IETF activities. Hope it helps. References: [1] Ben Laurie, "Distributing Keys for DNSSEC"draft-laurie-dnssec-key-distribution-00, September 30, 2004 [2] Mark Andrews, Sam Weiler, "The DNSSEC Lookaside Validation (DLV) DNS Resource Record" draft-andrews-dlv-dns-rr-00 June 23, 2005 [3] Sam Weiler, "DNSSEC Lookaside Validation (DLV)" 22 May 2005, http://www.watson.org/~weiler/dlv/ draft-weiler-dnssec-dlv-pre00.txt [4] J. Ihren, O. Kolkman, B. Manning, "An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for DNSSEC Trust Anchors", draft-ietf-dnsext-trustupdate-threshold-00, October 18, 2004 [5] Mike StJohns, "Automated Updates of DNSSEC Trust Anchors", draft-ietf-dnsext-trustupdate-timers-01, August 15, 2005 [6] Thierry Moreau, "'Trust Anchor' Integrity Mechanisms for Internet DNS Security" 2005/08/24 http://www.connotech.com/takrem_for_dnssec_01.pdf -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 23 13:12:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIr5m-0001EH-QF for dnsext-archive@megatron.ietf.org; Fri, 23 Sep 2005 13:12:11 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25779 for ; Fri, 23 Sep 2005 13:12:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIr2T-0008RK-Vh for namedroppers-data@psg.com; Fri, 23 Sep 2005 17:08:45 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EIr2S-0008R1-Pe for namedroppers@ops.ietf.org; Fri, 23 Sep 2005 17:08:45 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j8NH8a2q018531; Fri, 23 Sep 2005 13:08:36 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.3.4.2.20050922231257.03cd38b0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 23 Sep 2005 13:08:25 -0400 To: Paul Vixie From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: rollover transition mechanism Cc: Namedroppers In-Reply-To: <20050922171925.05F9611449@sa.vix.com> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> <6.2.1.2.2.20050921164406.04d49eb0@localhost> <20050921212012.38F2511449@sa.vix.com> <5DE67BFB-8A53-4C77-9520-471A98D462E5@NLnetLabs.nl> <20050922171925.05F9611449@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk For the discussion below I will only comment on the proposals that I have studied, Mike's, N-of-M and DLV. At 13:19 22/09/2005, Paul Vixie wrote: ># > can the chairs ask some pointed questions? like: ># ># Thanks for the instructions .... ;-) > >not instructions, just a request. > ># > 1. is dnssec-bis deployable without this kind of key management? Yes, on a small scale. Someone can configure a validator to trust a small set of zones, and maintain that, but not on a global scale. ># > 2. is dnssec-bis deployable without any other kinds of key management? Not on a wide scale. ># > 3. is dnssec-bis deployable without anything unrelated to key management? Not sure what exactly you are asking here :-) But if you are asking is what does DNSSEC need to get deployed the answer is "Large customer that can not live without it!" ># > ># > 4. does mike's proposal appear to be unworkable? if so, how or why? Not at all, it works fine. I have spent quite a bit of time thinking about it and doing simulations of it (in my head and on paper). In my mind there are three things in Mike's proposal that are real elegant and make it an attractive solution. 1. Probation on trust relation ship: A new DNSKEY with SEP bit can not be inserted into a DNSKEY RRset and be trusted, it needs to stay around to gain acceptance. 2. Immediate revocation: The beauty of the Revoke bit is as soon as the bit is set it the DNSKEY it is set on is not trusted anymore. But at the same time a Mike-aware keymanager[1] can notice that a DNSKEY it trusted has been revoked and remove it from the trusted list. 3. Omission leads to probation which leads to removal: If DNSKEY is removed from the DNSKEY RRset it is put on probation, if it does not appear again during the probation it can be deleted from memory. ># > 5. does mike's proposal solve the wrong problem? if so, how or why? No it is solving the right problem. ># > 6. does mike's proposal fail to solve the whole problem? if so, how or ># > why? ># > It does not solve one part of the Key Management problem: initial trust. But the same goes for all the other proposals I have seen so far. DLV is one that attempts to aggregate trust relationships and allow new trust relationships to be established over time. (In this case I thought is that some combination of Mike's probation and using multiple (N-of-M) DLV trees before starting to trust a new entity). Mike's proposal solves the problem of continuing trusting someone. There is one sub problem that I have not convinced myself if that needs to be solved in general> Thus I have not thought the issue through but want to mention the issue: Can a *-aware keymanger[1] be configured, then put on the shelf for x months before being connected to the Internet and learn all changes to trust anchors and be up to date in a short order? IMHO this is a question of requirements, we can either solve this in protocol, or the KM can securely fetch an updated configuration from the entity that configured the KM, which hopefully was on-line during this time. ># > 7. does a competing proposal offer a more provable/testable/simple ># > solution? The tradeoffs are in how rapidly new keys can be introduced/revoked. The N-of-M proposal allows more rapid changes, mainly in introducing new DNSKEY's. The N-of-M proposal is little bit simpler to test as it does not need long testing or simulated time. Mike's proposal can be tested by using shortened timer values. ># > 8. does a competing proposal solve at least the same important problems? yes ># > 9. does a competing proposal solve important problems this one doesn't ># > address? ># > None that I can express. Olafur [1] Terminology nit: Keymanager: people keep using the words "resolver" or "validator" when talking about the functional unit that decides which DNSKEY's to trust. In my mind the resolver is a traditional DNS resolver that looks for answers, validator is a tool that is given a set of trusted-keys and it checks if it can validate some DNS signatures to allow it to assess the status of a particular RRset. The entity that supplies the trusted-keys is a KeyManager. This can be static as in Bind9 via the trusted-keys statement, or a functional unit that maintains a list of keys to trust, using some mechanism, this could be DLV lookup, Mike-aware DNS lookups, N-of-M-aware lookups, LDAP into a database (that is somehow maintained), etc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 23 13:19:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIrDD-0003OR-Sh for dnsext-archive@megatron.ietf.org; Fri, 23 Sep 2005 13:19:51 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26050 for ; Fri, 23 Sep 2005 13:19:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIrBJ-0009T8-Bu for namedroppers-data@psg.com; Fri, 23 Sep 2005 17:17:53 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIrBG-0009Sm-C1 for namedroppers@ops.ietf.org; Fri, 23 Sep 2005 17:17:50 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8NHHgr16346; Fri, 23 Sep 2005 20:17:42 +0300 Date: Fri, 23 Sep 2005 20:17:42 +0300 (EEST) From: Pekka Savola To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= cc: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard In-Reply-To: <6.2.3.4.2.20050923102256.047ba5f0@wheresmymailserver.com> Message-ID: References: <6.2.3.4.2.20050923102256.047ba5f0@wheresmymailserver.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-954282190-1127495862=:16175" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-954282190-1127495862=:16175 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA26050 On Fri, 23 Sep 2005, =D3lafur Gu=F0mundsson wrote: > 0 reserved > 1 PKIX X.509 as per PKIX > 2 SPKI SPKI certificate > 3 PGP OpenPGP packet > 4 IPKIX The URL of an X.509 data object > 5 ISPKI The URL of an SPKI certificate > 6 IPGP The URL of an OpenPGP packet > 7-252 available for IANA assignment by IETF Standards acti= on > 253 URI URI private > 254 OID OID private > 255-65023 available for IANA assignment by IETF Consensus. > 65024-65534 experimental > 65535 reserved Please also add references here to the documents which define those=20 CERT types. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-954282190-1127495862=3D:16175-- -- 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: --1589707168-954282190-1127495862=:16175-- From owner-namedroppers@ops.ietf.org Fri Sep 23 13:40:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIrWm-0007xo-VR for dnsext-archive@megatron.ietf.org; Fri, 23 Sep 2005 13:40:05 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26745 for ; Fri, 23 Sep 2005 13:40:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIrTA-000Bb9-0S for namedroppers-data@psg.com; Fri, 23 Sep 2005 17:36:20 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EIrT9-000Bav-DP for namedroppers@ops.ietf.org; Fri, 23 Sep 2005 17:36:19 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 6B3C656890; Fri, 23 Sep 2005 10:36:18 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.2.1.2.2.20050923132654.09a4fd80@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 23 Sep 2005 13:36:43 -0400 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= From: Mike StJohns Subject: Re: rollover transition mechanism Cc: Namedroppers In-Reply-To: <6.2.3.4.2.20050922231257.03cd38b0@localhost> References: <20050917164807.C3EF911450@sa.vix.com> <20050917174201.3122311449@sa.vix.com> <432ED904.2060902@connotech.com> <6.2.1.2.2.20050920150957.047c4bb0@localhost> <11997543-CB7A-4929-9584-23F0BDB8FE17@NLnetLabs.nl> <6.2.1.2.2.20050921164406.04d49eb0@localhost> <20050921212012.38F2511449@sa.vix.com> <5DE67BFB-8A53-4C77-9520-471A98D462E5@NLnetLabs.nl> <20050922171925.05F9611449@sa.vix.com> <6.2.3.4.2.20050922231257.03cd38b0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 01:08 PM 9/23/2005, =D3lafur Gu=F0mundsson wrote: >3. Omission leads to probation which leads to removal: >If DNSKEY is removed from the DNSKEY RRset it is put on probation, if it >does not appear again during the probation it can be deleted from memory. Actually, see the state table in the last two drafts. The above was the=20 case in the first (non-WG) draft, and was reflected in a set of slides I=20 did to brief the initial draft, but I removed the delete on time out for=20 missing (but unrevoked) keys. The reason for that was to prevent an=20 attacker who gets the private part of one key from causing another key to=20 go invalid. A design decision, but one which made sense with the overall= =20 goal of being able to recover from an N-1 key compromise where N was the=20 number of keys at a trust point.=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 23 15:53:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EItc3-0004Wj-10 for dnsext-archive@megatron.ietf.org; Fri, 23 Sep 2005 15:53:39 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03735 for ; Fri, 23 Sep 2005 15:53:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EItYa-0001xl-TK for namedroppers-data@psg.com; Fri, 23 Sep 2005 19:50:04 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EItYZ-0001wC-4G for namedroppers@ops.ietf.org; Fri, 23 Sep 2005 19:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EItYX-0002hU-LH; Fri, 23 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2538bis-07.txt Message-Id: Date: Fri, 23 Sep 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Storing Certificates in the Domain Name System (DNS) Author(s) : S. Josefsson Filename : draft-ietf-dnsext-rfc2538bis-07.txt Pages : 16 Date : 2005-9-23 Cryptographic public keys are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). This document obsoletes RFC 2538. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2538bis-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-07.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: <2005-9-23111121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2538bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-23111121.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 23 18:28:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIw1l-0003jO-Mx for dnsext-archive@megatron.ietf.org; Fri, 23 Sep 2005 18:28:24 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19500 for ; Fri, 23 Sep 2005 18:28:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIvy5-000L3O-U3 for namedroppers-data@psg.com; Fri, 23 Sep 2005 22:24:33 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EIvy2-000L2t-Kr for namedroppers@ops.ietf.org; Fri, 23 Sep 2005 22:24:31 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j8NMOC3Z008191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Sep 2005 00:24:15 +0200 From: Simon Josefsson To: Pekka Savola Cc: namedroppers@ops.ietf.org, =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard References: <6.2.3.4.2.20050923102256.047ba5f0@wheresmymailserver.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050923:pekkas@netcore.fi::J4IGVJl2hx47wpY8:DbMd X-Hashcash: 1:21:050923:ogud@ogud.com::H/qS1J5V24gJ8HB1:CL7Q X-Hashcash: 1:21:050923:namedroppers@ops.ietf.org::VoZCWTnDaFvX6poS:CLPe Date: Sat, 24 Sep 2005 00:24:11 +0200 In-Reply-To: (Pekka Savola's message of "Fri, 23 Sep 2005 20:17:42 +0300 (EEST)") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA19500 Pekka Savola writes: > On Fri, 23 Sep 2005, =D3lafur Gu=F0mundsson wrote: >> 0 reserved >> 1 PKIX X.509 as per PKIX >> 2 SPKI SPKI certificate >> 3 PGP OpenPGP packet >> 4 IPKIX The URL of an X.509 data object >> 5 ISPKI The URL of an SPKI certificate >> 6 IPGP The URL of an OpenPGP packet >> 7-252 available for IANA assignment by IETF Standards act= ion >> 253 URI URI private >> 254 OID OID private >> 255-65023 available for IANA assignment by IETF Consensus. >> 65024-65534 experimental >> 65535 reserved > > Please also add references here to the documents which define those=20 > CERT types. What do you mean? The types are defined by the same document, RFC 2538bis. Regards, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Sep 24 06:25:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJ7DO-0007re-Ni for dnsext-archive@megatron.ietf.org; Sat, 24 Sep 2005 06:25:08 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28842 for ; Sat, 24 Sep 2005 06:25:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EJ78g-0004Uz-75 for namedroppers-data@psg.com; Sat, 24 Sep 2005 10:20:14 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EJ78e-0004Ui-4N for namedroppers@ops.ietf.org; Sat, 24 Sep 2005 10:20:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8OAJrt06421; Sat, 24 Sep 2005 13:19:58 +0300 Date: Sat, 24 Sep 2005 13:19:53 +0300 (EEST) From: Pekka Savola To: Simon Josefsson cc: namedroppers@ops.ietf.org, =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard In-Reply-To: Message-ID: References: <6.2.3.4.2.20050923102256.047ba5f0@wheresmymailserver.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-2016890406-1127557193=:6255" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-2016890406-1127557193=:6255 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA28842 On Sat, 24 Sep 2005, Simon Josefsson wrote: > Pekka Savola writes: >> On Fri, 23 Sep 2005, =D3lafur Gu=F0mundsson wrote: >>> 0 reserved >>> 1 PKIX X.509 as per PKIX >>> 2 SPKI SPKI certificate >>> 3 PGP OpenPGP packet >>> 4 IPKIX The URL of an X.509 data object >>> 5 ISPKI The URL of an SPKI certificate >>> 6 IPGP The URL of an OpenPGP packet >>> 7-252 available for IANA assignment by IETF Standards ac= tion >>> 253 URI URI private >>> 254 OID OID private >>> 255-65023 available for IANA assignment by IETF Consensus. >>> 65024-65534 experimental >>> 65535 reserved >> >> Please also add references here to the documents which define those >> CERT types. > > What do you mean? The types are defined by the same document, RFC > 2538bis. Sorry, for clarity, I should have written, "define those CERT types or=20 the protocols using them". This is useful in particular if a protocol=20 emerged after RFC2538 which was assigned such a cert type. You could turn this another way around, and ask "if a user sess this=20 CERT type, where could it find more information on the protocol using=20 the CERT type?" --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-2016890406-1127557193=3D:6255-- -- 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: --1589707168-2016890406-1127557193=:6255-- From owner-namedroppers@ops.ietf.org Sat Sep 24 06:56:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJ7iA-0005FT-PY for dnsext-archive@megatron.ietf.org; Sat, 24 Sep 2005 06:56:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29941 for ; Sat, 24 Sep 2005 06:56:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EJ7f9-0008qY-Fm for namedroppers-data@psg.com; Sat, 24 Sep 2005 10:53:47 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EJ7f6-0008pz-4f for namedroppers@ops.ietf.org; Sat, 24 Sep 2005 10:53:44 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j8OArOqi031090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Sep 2005 12:53:28 +0200 From: Simon Josefsson To: Pekka Savola Cc: namedroppers@ops.ietf.org, =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard References: <6.2.3.4.2.20050923102256.047ba5f0@wheresmymailserver.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050924:pekkas@netcore.fi::CdoYAI4z/UpixSH5:UWH X-Hashcash: 1:21:050924:namedroppers@ops.ietf.org::shXg2htnCJutscOF:vVs X-Hashcash: 1:21:050924:ogud@ogud.com::i/Naycyzwk20/lNP:5tkC Date: Sat, 24 Sep 2005 12:53:22 +0200 In-Reply-To: (Pekka Savola's message of "Sat, 24 Sep 2005 13:19:53 +0300 (EEST)") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA29941 Pekka Savola writes: > On Sat, 24 Sep 2005, Simon Josefsson wrote: >> Pekka Savola writes: >>> On Fri, 23 Sep 2005, =D3lafur Gu=F0mundsson wrote: >>>> 0 reserved >>>> 1 PKIX X.509 as per PKIX >>>> 2 SPKI SPKI certificate >>>> 3 PGP OpenPGP packet >>>> 4 IPKIX The URL of an X.509 data object >>>> 5 ISPKI The URL of an SPKI certificate >>>> 6 IPGP The URL of an OpenPGP packet >>>> 7-252 available for IANA assignment by IETF Standards a= ction >>>> 253 URI URI private >>>> 254 OID OID private >>>> 255-65023 available for IANA assignment by IETF Consensus. >>>> 65024-65534 experimental >>>> 65535 reserved >>> >>> Please also add references here to the documents which define those >>> CERT types. >> >> What do you mean? The types are defined by the same document, RFC >> 2538bis. > > Sorry, for clarity, I should have written, "define those CERT types or=20 > the protocols using them". This is useful in particular if a protocol=20 > emerged after RFC2538 which was assigned such a cert type. > > You could turn this another way around, and ask "if a user sess this=20 > CERT type, where could it find more information on the protocol using=20 > the CERT type?" I see. I have changed the IANA considerations to read as below. If this is a problem for anyone, please speak up. For the entire updated document, see . If someone wants to find out more about the particular format used for a particular CERT type, they have to chase the references in the RFC in the IANA table. The RFC numbers added to the IANA registry should be to the RFC that define the new CERT type. Thanks, Simon IANA needs to create a new registry for CERT RR, certificate types. The initial contents of this registry is: [[RFC Editor: Replace xxxx below with the number of this RFC.]] Decimal Type Meaning Reference ------- ---- ------- --------- 0 Reserved RFC xxxx 1 PKIX X.509 as per PKIX RFC xxxx 2 SPKI SPKI certificate RFC xxxx 3 PGP OpenPGP packet RFC xxxx 4 IPKIX The URL of an X.509 data object RFC xxxx 5 ISPKI The URL of an SPKI certificate RFC xxxx 6 IPGP The URL of an OpenPGP packet RFC xxxx 7-252 Available for IANA assignment by IETF Standards action 253 URI URI private RFC xxxx 254 OID OID private RFC xxxx 255-65023 Available for IANA assignment by IETF Consensus 65024-65534 Experimental RFC xxxx 65535 Reserved RFC xxxx Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can only be assigned by an IETF standards action [7]. This document assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate types 0x0100 through 0xFEFF are assigned through IETF Consensus [7] based on RFC documentation of the certificate type. The availability of private types under 0x00FD and 0x00FE ought to satisfy most requirements for proprietary or private types. The CERT RR reuses the DNS Security Algorithm Numbers registry. In particular, the CERT RR requires that algorithm number 0 remain reserved, as described in Section 2. The IANA is directed to reference the CERT RR as a user of this registry and value 0, in particular. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 26 10:57:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuPk-0000qA-VC for dnsext-archive@megatron.ietf.org; Mon, 26 Sep 2005 10:57:09 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02716 for ; Mon, 26 Sep 2005 10:57:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EJuIz-000Llc-SL for namedroppers-data@psg.com; Mon, 26 Sep 2005 14:50:09 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EJuIw-000Lkv-Fc for namedroppers@ops.ietf.org; Mon, 26 Sep 2005 14:50:06 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EJuIs-0006ey-Oj; Mon, 26 Sep 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dhcid-rr-10.txt Message-Id: Date: Mon, 26 Sep 2005 10:50:02 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : A DNS RR for Encoding DHCP Information (DHCID RR) Author(s) : M. Stapp, et al. Filename : draft-ietf-dnsext-dhcid-rr-10.txt Pages : 10 Date : 2005-9-26 It is possible for multiple DHCP clients to attempt to update the same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, "Resolution of DNS Name Conflicts" [1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct RR type for this purpose for use by DHCP clients and servers, the "DHCID" RR. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dhcid-rr-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-10.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: <2005-9-26104027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dhcid-rr-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-26104027.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From BarbaraBoone@vnrockworld.com Wed Sep 28 06:33:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKZFU-00081p-8i for dnsext-archive@megatron.ietf.org; Wed, 28 Sep 2005 06:33:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27353 for ; Wed, 28 Sep 2005 06:33:13 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKZMq-0000L7-Pu for dnsext-archive@ietf.org; Wed, 28 Sep 2005 06:40:57 -0400 Received: from [220.71.16.235] (helo=65.246.255.50 ident=aczvdiwy) by mx2.foretec.com with smtp (Exim 4.24) id 1EKZFN-0001ML-0D for dnsext-archive@ietf.org; Wed, 28 Sep 2005 06:33:09 -0400 Received: from BCfY@localhost by etd3.int (8.11.6/8.11.6); Wed, 28 Sep 2005 15:43:25 +0400 Message-ID: <9tsLEJQNmC7mG2lYXDpwy@synthking.net> From: "Samantha Fox" Reply-To: "Samantha Fox" To: dnsext-archive@ietf.org Subject: Finally, you can afford software by Win XP Win XP & Macromedia Date: Wed, 28 Sep 2005 04:45:25 -0700 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: BarbaraBoone@vnrockworld.com Content-Type: multipart/mixed; boundary="--eQlzmMRit9e4uRsb" X-Spam-Score: 4.8 (++++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 gk5 ----eQlzmMRit9e4uRsb Content-Type: text/html; Content-Transfer-Encoding: quoted-printable D
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
<= tr>

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Adobe = Photoshop 9.0
 3 Window= s XP Pro
 4 Adobe Acro= bat 7 Pro
 <= font face=3DVerdana size=3D1>5 Flash MX= 2004
 6 Corel Draw 1= 2
 7 Norton Antivirus = 2005
 8 Windows 2003 = Server
 9 Alias Maya = 6 Wavefrt
 <= font face=3DVerdana size=3D1>10 Adobe <= /a> Illustrator 11
&nb= sp; See more by this manufacturer
   Microsoft
   Symantec
   Adobe<= /a>
  Customers also bo= ught
   these other items...

Microsoft Office = Professional Edition *2003*
Microsoft

<= /table>

Choose= :
 
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (86%)

=

Availability: Available for INSTANT download!
Coupo= n Code: IKCIq
 

Sales Rank= : #1
= System requirements  |  Ot= her Versions
Date Coupon Expires:= August 31st, 2005
Average Customer Revie= w:3D"5 Based on 19147 reviews. W= rite a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 

List Price:$599.00
Price:$69.99<= /b>
You Save:$529.01 (90= %)



Availability: A= vailable for INSTANT download!
Coupon Code: c1TGZLWTC
 = ;

Sales Rank: #2
System requirements&nbs= p; |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 1397 = reviews. Write a review.

=

= Microsoft Windows XP Professional or Longhorn Edition<= br> Microsoft

Choose:=
 

List Price:$279.00
Price:$49.99
You Save:= $229.01 (85%)



Availabi= lity: Available for INSTANT download!
Coupon Code: 22BSiXs<= br>  

Sales Rank: #3
System requirement= s  |  Other Versions
Date Coupon Expires: August 31st, 2005=
Average Customer Review:3D"5 Based= on 11914 reviews. Write a review.

Adobe Acrobat Professional V 7.0
= Adobe

=
Choose:
 = ;

=

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (85= %)



Availability: A= vailable for INSTANT download!
Coupon Code: hkXmEN
 

Sales Rank: #4
System requirements  = |  Other Versions
Date Coupon Expires: August 31st, 2005
= Average Customer Review:3D"= Based on 1788 r= eviews. Write a review.

<= /font>

----eQlzmMRit9e4uRsb-- From owner-namedroppers@ops.ietf.org Fri Sep 30 00:02:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELC6t-0008GR-9R for dnsext-archive@megatron.ietf.org; Fri, 30 Sep 2005 00:02:59 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03693 for ; Fri, 30 Sep 2005 00:02:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ELBzO-0005MT-Kh for namedroppers-data@psg.com; Fri, 30 Sep 2005 03:55:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ELBzN-0005LF-IZ for namedroppers@ops.ietf.org; Fri, 30 Sep 2005 03:55:13 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1ELBzL-000Jmz-OF for namedroppers@ops.ietf.org; Thu, 29 Sep 2005 23:55:12 -0400 Received: by internaut.com (Postfix, from userid 1000) id 28D7550259; Thu, 29 Sep 2005 20:55:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 15CD150258 for ; Thu, 29 Sep 2005 20:55:12 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Thu, 29 Sep 2005 20:55:12 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: LLMNR Issue 101: Comments on -43 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The proposed resolution is to accept the proposed changes, and in addition: Change Section 2 to the following: "2. Name Resolution Using LLMNR LLMNR queries are sent to and received on port 5355. The IPv4 link- scope multicast address a given responder listens to, and to which a sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast address a given responder listens to, and to which a sender sends all queries, is FF02:0:0:0:0:0:1:3. Typically a host is configured as both an LLMNR sender and a responder. A host MAY be configured as a sender, but not a responder. However, a host configured as a responder MUST act as a sender, if only to verify the uniqueness of names as described in Section 4. This document does not specify how names are chosen or configured. This may occur via any mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315]. A typical sequence of events for LLMNR usage is as follows: [a] An LLMNR sender sends an LLMNR query to the link-scope multicast address(es), unless a unicast query is indicated, as specified in Section 2.4. [b] A responder responds to this query only if it is authoritative for the name in the query. A responder responds to a multicast query by sending a unicast UDP response to the sender. Unicast queries are responded to as indicated in Section 2.4. [c] Upon reception of the response, the sender processes it. The sections that follow provide further details on sender and responder behavior." In Section 2.5, change: " For UDP queries and responses, the Hop Limit field in the IPv6 header and the TTL field in the IPV4 header MAY be set to any value. However, it is RECOMMENDED that the value 255 be used for compatibility with Apple Bonjour [Bonjour]." to: " For UDP queries and responses, the Hop Limit field in the IPv6 header and the TTL field in the IPV4 header MAY be set to any value. However, it is RECOMMENDED that the value 255 be used for compatibility with early implementations of [RFC3927]." Change Section 3 to the following: "3. Usage Model LLMNR is a peer-to-peer name resolution protocol that is not intended as a replacement for DNS. By default, an LLMNR sender SHOULD send LLMNR queries only for single-label names. In order to reduce unnecessary DNS queries, stub resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS queries for single-label names. An LLMNR sender SHOULD NOT be enabled to send a query for any name, except where security mechanisms (described in Section 5.3) can be utilized. If LLMNR is given higher priority than DNS among the enabled name resolution mechanisms, a denial of service attack on the DNS server would not be necessary in order to poison the LLMNR cache, since LLMNR queries would be sent even when the DNS server is available. In addition, the LLMNR cache, once poisoned, would take precedence over the DNS cache, eliminating the benefits of cache separation. As a result, LLMNR is only used as a name resolution mechanism of last resort, and queries SHOULD NOT be sent unless one of the following conditions are met: [1] No manual or automatic DNS configuration has been performed. If DNS server address(es) have been configured, a host SHOULD attempt to reach DNS servers over all protocols on which DNS server address(es) are configured, prior to sending LLMNR queries. For dual stack hosts configured with DNS server address(es) for one protocol but not another, this implies that DNS queries SHOULD be sent over the protocol configured with a DNS server, prior to sending LLMNR queries. [2] All attempts to resolve the name via DNS on all interfaces have failed after exhausting the searchlist. This can occur because DNS servers did not respond, or because they responded to DNS queries with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. Where a single resolver call generates DNS queries for A and AAAA RRs, an implementation MAY choose not to send LLMNR queries if any of the DNS queries is successful. An LLMNR query SHOULD only be sent for the originally requested name; a searchlist is not used to form additional LLMNR queries. Since LLMNR is a secondary name resolution mechanism, its usage is in part determined by the behavior of DNS implementations. In general, robust DNS resolver implementations are more likely to avoid unnecessary LLMNR queries. As noted in [DNSPerf], even when DNS servers are configured, a significant fraction of DNS queries do not receive a response, or result in negative responses due to missing inverse mappings or NS records that point to nonexistent or inappropriate hosts. This has the potential to result in a large number of unnecessary LLMNR queries. [RFC1536] describes common DNS implementation errors and fixes. If the proposed fixes are implemented, unnecessary LLMNR queries will be reduced substantially, and so implementation of [RFC1536] is recommended. For example, [RFC1536] Section 1 describes issues with retransmission and recommends implementation of a retransmission policy based on round trip estimates, with exponential backoff. [RFC1536] Section 4 describes issues with failover, and recommends that resolvers try another server when they don't receive a response to a query. These policies are likely to avoid unnecessary LLMNR queries. [RFC1536] Section 3 describes zero answer bugs, which if addressed will also reduce unnecessary LLMNR queries. [RFC1536] Section 6 describes name error bugs and recommended searchlist processing that will reduce unnecessary RCODE=3 (authoritative name) errors, thereby also reducing unnecessary LLMNR queries." Change the last paragraph in Section 5.2 to the following: " This vulnerablity can be reduced by limiting use of LLMNR to resolution of single-label names as described in Section 3, or by implementation of authentication (see Section 5.3)." Change Section 5.3 to the following: "5.3. Authentication LLMNR is a peer-to-peer name resolution protocol, and as a result, it is often deployed in situations where no trust model can be assumed. Howeverm where a pre-arranged security configuration is possible, the following security mechanisms may be used: [a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0) [RFC2931] security mechanisms. "DNS Name Service based on Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes the use of TSIG to secure LLMNR, based on group keys. While group keys can be used to demonsrate membership in a group, they do not protect against forgery by an attacker that is a member of the group. [b] IPsec ESP with a null-transform MAY be used to authenticate unicast LLMNR queries and responses or LLMNR responses to multicast queries. In a small network without a certificate authority, this can be most easily accomplished through configuration of a group pre-shared key for trusted hosts. As with TSIG, this does not protect against forgery by an attacker with access to the group pre-shared key. [c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to support DNSSEC, LLMNR implementations MAY be configured with trust anchors, or they MAY make use of keys obtained from DNS queries. Since LLMNR does not support "delegated trust" (CD or AD bits), LLMNR implementations cannot make use of DNSSEC unless they are DNSSEC aware. Unlike approaches [a] or [b], DNSSEC permits a responder to demonstrate ownership of a name, not just membership within a trusted group. As a result, it enables protection against forgery." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 30 03:23:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELFFO-0003o1-MK for dnsext-archive@megatron.ietf.org; Fri, 30 Sep 2005 03:23:59 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26703 for ; Fri, 30 Sep 2005 03:23:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ELFBw-000Oai-9S for namedroppers-data@psg.com; Fri, 30 Sep 2005 07:20:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ELFBu-000OaM-PM for namedroppers@ops.ietf.org; Fri, 30 Sep 2005 07:20:23 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.3/8.13.3) with ESMTP id j8U7KKV7013556 for ; Fri, 30 Sep 2005 09:20:20 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> <9F4030A5-051F-4413-AD5A-076E2ADBBC70@mail-abuse.org> <1126695527.9288.52.camel@bash.adsl-64-142-13-68> <2EBF6065-D013-4338-8FCB-3E8C6FD99F69@mail-abuse.org> <98A6DD22-0DA4-48CF-BC49-183BE8024451@mail-abuse.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Date: Fri, 30 Sep 2005 09:20:18 +0200 To: Namedroppers X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I wrote: > I'd like to ask if we can all consent with the document as is now > (http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis-06.txt). After that version the IANA considerations section was improved by adding a reference field for the CERT types. I plan to notify our ADs that the last-call issues have been addressed and that consensus has been reached on version -08 of the document (while still in the queue it lives on Simons Site: http:// josefsson.org/rfc2538bis/ ). I'll do so early next week. Thanks for your cooperation. - --Olaf - ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDPOcztN/ca3YJIocRAnyAAKCE7DI0SMX/uYnebZyOj0kaCsaCwACg1Vaj IMJxshsSm1HoasavySV9y84= =Y91a -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 30 10:50:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELMDo-0002zV-ME for dnsext-archive@megatron.ietf.org; Fri, 30 Sep 2005 10:50:48 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15361 for ; Fri, 30 Sep 2005 10:50:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ELM8I-000GEb-Ui for namedroppers-data@psg.com; Fri, 30 Sep 2005 14:45:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [203.174.79.138] (helo=zns001-0m9001.yokogawa.co.jp) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ELM8F-000GDx-Tc for namedroppers@ops.ietf.org; Fri, 30 Sep 2005 14:45:04 +0000 Received: from zns001-0m9001.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id j8UEj2CY016565 for ; Fri, 30 Sep 2005 23:45:02 +0900 (JST) Received: from zex001-0m9005.jp.ykgw.net (zex001-0m9005.jp.ykgw.net [10.0.11.15]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id j8UEj2sZ016556 for ; Fri, 30 Sep 2005 23:45:02 +0900 (JST) Received: from [10.0.69.41] ([10.0.69.41]) by zex001-0m9005.jp.ykgw.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Sep 2005 23:45:01 +0900 Message-ID: <433D4F6D.8040904@jp.yokogawa.com> Date: Fri, 30 Sep 2005 23:45:01 +0900 From: Nobumichi Ozoe User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: DNS conformance test Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Sep 2005 14:45:01.0862 (UTC) FILETIME=[89AB9C60:01C5C5CD] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, The TAHI project wants to inform you of advancing the test development though only gradually. We are now writing test specification for DNS. Please see the following URL if you are interested. http://www.tahi.org/dns/ http://www.tahi.org/dns/spec/ Bes regards, PS. ETSI plugtests still accept application:-) -- Nobumichi Ozoe IPv6 Business Network & Software Development Dept. Yokogawa Electric Corporation E-mail: Nobumichi.Ozoe@jp.yokogawa.com URL: http://www.yokogawa.com/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 30 15:55:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQyn-0006xa-Vq for dnsext-archive@megatron.ietf.org; Fri, 30 Sep 2005 15:55:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04116 for ; Fri, 30 Sep 2005 15:55:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ELQtP-000FIc-Hf for namedroppers-data@psg.com; Fri, 30 Sep 2005 19:50:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ELQtO-000FHi-G7 for namedroppers@ops.ietf.org; Fri, 30 Sep 2005 19:50:02 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ELQtN-0007Px-9i; Fri, 30 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2538bis-08.txt Message-Id: Date: Fri, 30 Sep 2005 15:50:01 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Storing Certificates in the Domain Name System (DNS) Author(s) : S. Josefsson Filename : draft-ietf-dnsext-rfc2538bis-08.txt Pages : 16 Date : 2005-9-30 Cryptographic public keys are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). This document obsoletes RFC 2538. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2538bis-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-30125857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2538bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-30125857.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From GertrudeShipman@impureness.com Fri Sep 30 16:41:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELRgz-0003bO-Ju for dnsext-archive@megatron.ietf.org; Fri, 30 Sep 2005 16:41:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17600 for ; Fri, 30 Sep 2005 16:41:15 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELRot-0005bL-Dz for dnsext-archive@ietf.org; Fri, 30 Sep 2005 16:49:29 -0400 Received: from 200165119195.user.veloxzone.com.br ([200.165.119.195]) by mx2.foretec.com with smtp (Exim 4.24) id 1ELRgw-0004dM-05 for dnsext-archive@ietf.org; Fri, 30 Sep 2005 16:41:14 -0400 Received: from quo@localhost by k2F.int (8.11.6/8.11.6); Sat, 01 Oct 2005 02:39:27 +0100 Message-ID: From: "Tina Montano" Reply-To: "Tina Montano" To: dnsext-archive@ietf.org Subject: Acrobat Pro 7.0 $69.95 Office XP Date: Fri, 30 Sep 2005 19:33:27 -0600 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: GertrudeShipman@impureness.com Content-Type: multipart/mixed; boundary="--FkkUude22bHCMWSp9" X-Spam-Score: 4.8 (++++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 qw1 ----FkkUude22bHCMWSp9 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable a
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

TOP 10 NEW TITLES

  

 = ON SALE NOW!

 1 = Office Pro 2003
 2 Ad= obe Photoshop 9.0
 3 Wi= ndows XP Pro
 4 Adobe= Acrobat 7 Pro
 5 Flash= MX 2004
 6 Corel Dr= aw 12
 7 Norton Antiv= irus 2005
 <= font face=3DVerdana size=3D1>8 Windows= 2003 Server
 9 Alias= Maya 6 Wavefrt
 10 = Adobe Illustrator 11
  See more by this manufacturer
   Microsoft
  = Symantec
   Adobe
  Custom= ers also bought
  these other items...

Micro= soft Office Professional Edition *2003*
Microsoft

= <= tr>
Choose:
 

You Save:



Availability: Available for INSTANT down= load!
Coupon Code: RjZahpl
 

Sales Rank: #1
System requirements  |  Other Versions
Date= Coupon Expires: August 31st, 2005
Av= erage Customer Review:3D"5 Based on 167291 reviews. Write a review.

<= table border=3D0 cellpadding=3D0 cellspacing=3D0 style=3D"border-collapse:= collapse" bordercolor=3D#111111 width=3D100% id=3DAutoNumber1 height=3D55= >
List Price:$499.00
Price:$69.99
$429.01 (86%)

Adobe Photoshop CS2 V= 9.0
Adobe<= /a>

Choose:=
 

=
List Price:$599.00
Price:= $69.99
You Save:$529.01 (90%)



Av= ailability: Available for INSTANT download!
Coupon Code: Kj= P7P
 

Sales Rank: #2
<= /span>System requir= ements  |  Other Versions=
Date Coupon Expires: August 31st= , 2005
Average Customer Review:3D"5 Based on 18912 reviews. Write a revi= ew.

Microsoft Windows XP Professional or Lo= nghorn Edition
Microsoft

Choose:
 

=

List Price:$279.00
Price:$49.99
You Save= :$229.01 (85%)



Availability: Available for INSTANT download!
<= b>Coupon Code: n7YqqQsvP
 

Sales Rank: #3
System requirements  |  Other Versions
Date Coupon= Expires: August 31st, 2005
Average C= ustomer Review:3D"5 Based on 1694 reviews. Write a review.

Adobe Acrobat P= rofessional V 7.0
Adobe

Choose:
 

<= a href=3Dhttp://hotoemsale.com/?F>

List Price:<= /b>$499.00
Price:$69.99
You Save:$429.01 (85%)



= Availability: Available for INSTANT download!
Coupon Code:<= /b> B657a
 

Sales Rank: #4=
System = requirements  |  Other Ve= rsions
Date Coupon Expires: Augus= t 31st, 2005
Average Customer Review:= 3D"5 Based on 1843 reviews. Write a= review.

----FkkUude22bHCMWSp9--