Re: [DNSOP] [dnsext] New Version Notification for draft-mcgrew-tss-02 (fwd)
I've got one. I modified an implementation of Shoup by Steve Weis which does raw RSA sigs to do PKCS1-v1.5 RSA signatures and from those to do DNSSEC signing. It allows the generation and wrapping of shares under remotely generated public keys - e.g. share holder public keys. When signatures are required, the data to be signed is sent to the share holders who decrypt their share with their private key, do a partial signature and return the signature share to the central location (or post it to a mailing list :-) ). The zone manager combines the partial signatures into a DNSSEC formatted RRSIG, verifies the signature is correct across the RRSet and then publishes it. Let me see if I can get permission to distribute it. Hmm.. looks like he's posted the underlying libraries. See http://code.google.com/p/threshsig/updates/list Mike At 10:49 PM 3/10/2009, bmann...@vacation.karoshi.com wrote: I really like the Shoup paper. But I've not seen too many implementations in the wild. :) --bill On Tue, Mar 10, 2009 at 12:49:55PM -0400, Michael StJohns wrote: Hi Alfred - A better scheme for threshold signing for the root might be the Shoup paper: Practical Threshold Signatures, Victor Shoup (s...@zurich.ibm.com), IBM Research Paper RZ3121, 4/30/99 The major difference between the two is that the Shamir system (which you describe) requires the base secret (private key) be reconstituted (by a trusted entity) before it can be used, where the Shoup system allows partial signatures with a public gather function. E.g. In a 3 of 5 system, each of the 3 key share holders partial-sign the data using their share of the private key and send it (as public data) to a central location where a gather function is used to form the actual signature. Shamir is nice in that it can be used for any set of key bits. But the reconstitution requirement is a point of weakness where the actual private key may be compromised. The Shoup system is only specified for RSA as far as I know. Mike At 10:48 PM 3/9/2009, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: This tools might be of interest for implementors of DNSSEC, e.g. the folks wanting to distibute control over the future Root Zone primary Key Signing Keys between the RIRs and ICANN/IANA. The new version should hopefully be ready for implementation. - Forwarded message from IETF I-D Submission Tool - From: IETF I-D Submission Tool idsubmiss...@ietf.org Message-Id: 20090309204424.ad5f73a6...@core3.amsl.com Date: Mon, 9 Mar 2009 13:44:24 -0700 (PDT) Subject: New Version Notification for draft-mcgrew-tss-02 A new version of I-D, draft-mcgrew-tss-02.txt has been successfuly submitted by David McGrew and posted to the IETF repository. Filename: draft-mcgrew-tss Revision: 02 Title: Threshold Secret Sharing Creation_date: 2009-03-09 WG ID: Independent Submission Number_of_pages: 26 Abstract: Threshold secret sharing (TSS) provides a way to generate N shares from a value, so that any M of those shares can be used to reconstruct the original value, but any M-1 shares provide no information about that value. This method can provide shared access control on key material and other secrets that must be strongly protected. This note defines a threshold secret sharing method based on polynomial interpolation in GF(256) and a format for the storage and transmission of shares. It also provides usage guidance, describes how to test an implementation, and supplies test cases. The IETF Secretariat. - End of forwarded message from IETF I-D Submission Tool - Kind regards, Alfred. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ -- to unsubscribe send a message to namedroppers-requ...@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: http://ops.ietf.org/lists/namedroppers/ -- to unsubscribe send a message to namedroppers-requ...@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: http://ops.ietf.org/lists/namedroppers/ -- to unsubscribe send a message to namedroppers-requ...@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: http://ops.ietf.org/lists/namedroppers/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt
On Tue, Mar 10, 2009 at 10:27:21AM +0100, Stephane Bortzmeyer wrote: recollection of one specific person. The alphabetic-only rule in RFC 1123 is just a side note, never detailed, and presented as a fact (which it was at this time), not as a mandatory restriction. I don't know whether I agree that it's just a side note. It seems to be a clarifying discussion used to explain why an innovation is safe. As we have seen in the current discussion, there is possibly more than one interpretation of that safety. I think that's what we have to consider. There are no *TECHNICAL* reasons to limit TLD to alphabetic characters. I think this is what's up for dispute. If people have interpreted the text in 1123 as normative and built resolvers using the logic there, then that is a technical reason to limit TLD characters. Even if we think those resolvers were mistaken in their implementation, they're deployed. Interoperation is one of our more important values, and that includes interoperation with reasonable interpretations of RFCs that we nevertheless think are mistaken. Best, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt
On Sat, 07 Mar 2009, Patrik Fltstrm wrote: Will there also be a problem with digits within a label? Probably not, but I rather see a generic good definition of the gray area and who is responsible for arguing (I an not saying proving here) whether something is ok to delegate or not, and I think it should be the applicant that argue it is ok. Not the other way around. Patrik, are you suggesting that a TLD label with interior digits (but not beginning or ending the TLD label) should be disallowed? Or are you suggesting that anyone proposing a such a TLD with an interior digit should prove no harm? Or something else? Could someone please give a concrete example of why a digit within a TLD label would be a problem? I grudgingly accept that the idea of digits starting or ending a TLD label needs further discussion, but I cannot be convinced about a prohibition against digits within a TLD label without some justification. Matt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt
By the same logic, the whole IDN would be pointless because RFC 1035 restrict labels to alphabetic letter only. IDNA transform IDN labels into punycode so that it become transparent to the resolvers who made those assumption. -James Seng I think this is what's up for dispute. If people have interpreted the text in 1123 as normative and built resolvers using the logic there, then that is a technical reason to limit TLD characters. Even if we think those resolvers were mistaken in their implementation, they're deployed. Interoperation is one of our more important values, and that includes interoperation with reasonable interpretations of RFCs that we nevertheless think are mistaken. Best, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DS vs DNSKEY trust anchors, was Re: Truncation...
At 8:19 +1100 3/11/09, Mark Andrews wrote: In message a06240804c5dc2ddef...@[10.31.200.116], Edward Lewis writes: record involves less typing than a DNSKEY, I'd want to work with a DS record. Has anyone on this list ever typed in a DNSKEY or DS as a trust anchor? I would presume that most (99.%) people work with != type in At 10:40 +1100 3/11/09, Mark Andrews wrote: I have a new key I want to introduce. I add the DS to the parent zone at least the ttl(ds) before I start using that key in the zone. After the DS has been published for ttl(ds) I can then replace the DNSKEY referred to by the old DS with that of the new DS and re-sign the DNSKEY RRset. Once the ttl(dnskey) has expired I can remove the old DS from the parent zone. I wish to be able to do something similar with trust anchors. Publishing DS prevents me from doing so. There is more than one way to do a key supersession. I'll describe one assuming DS records are installed as trust anchors. DS(KEY1) is in my validator. The owner of KEY1 distributes DS(KEY2) with a note that it should be installed by the 15th. On the 15th, DNSKEY(KEY2) is placed in the zone and KEY2 only is used to sign the keyset. With a 1 week TTL on the key set's RRSIG RR, a week later DNSKEY(KEY1) is removed from the set. At some point after that I can remove DS(KEY1) from my validator. Perhaps the special case here is that the keyset is unique in that the signatures for SEP/KSK's are tied to the where the key data is. I.e., if you have something signed by KEY1, then you have KEY1 because that something has to be the key set. If the zone is not run with a KSK/ZSK split, then the removal of KEY1 is triggered by signing the last RR set by KEY2 and then the TTL. The principle here is that there is no error if for a DS record there is no corresponding DNSKEY and vice versa. All that is needed for validation is one chain of trust. Accepting dangling references is not optimal but provides robustness. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt
On Wed, Mar 11, 2009 at 10:56:10PM +0800, James Seng ja...@seng.sg wrote a message of 4 lines which said: By the same logic, the whole IDN would be pointless because RFC 1035restrict labels to alphabetic letter only. I assume you're playing the devil's advocate? Because I believe that all dnsop members know that the reason why we need IDN is not the inability of the DNS to handle 8-bits characters... ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt
On Wed, Mar 11, 2009 at 10:56:10PM +0800, James Seng wrote: By the same logic, the whole IDN would be pointless because RFC 1035 restrict labels to alphabetic letter only. I'd like the reference to where 1035 says that, please. In particular, the following passage in §3.1 of RFC 1035 seems to say something different: Although labels can contain any 8 bit values in octets that make up a label, it is strongly recommended that labels follow the preferred syntax described elsewhere in this memo, which is compatible with existing host naming conventions. In addition, IDNA transform IDN labels into punycode so that it become transparent to the resolvers who made those assumption. you seem to be making my argument for me. The reason IDNA is preferable to some of the alternatives is that some resolver software indeed understood 1034 and 1035 to mean that the preferred syntax ought to be enforced (in what seems to me a plain violation of those RFCs). We have to live with those widely-deployed resolvers, and therefore we need to design other protocols as though the additional restrictions that are _not_ part of the DNS protocol are in fact part of it. Designing the protocols for the actually existing conditions in the network is what makes the design activity engineering rather than research, I think. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt
On Wed, Mar 11, 2009 at 11:36 PM, Andrew Sullivan a...@shinkuro.com wrote: On Wed, Mar 11, 2009 at 10:56:10PM +0800, James Seng wrote: By the same logic, the whole IDN would be pointless because RFC 1035 restrict labels to alphabetic letter only. I'd like the reference to where 1035 says that, please. In particular, the following passage in §3.1 of RFC 1035 seems to say something different: label ::= letter [ [ ldh-str ] let-dig ] ... letter ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case you seem to be making my argument for me. The reason IDNA is preferable to some of the alternatives is that some resolver software indeed understood 1034 and 1035 to mean that the preferred syntax ought to be enforced (in what seems to me a plain violation of those RFCs). We have to live with those widely-deployed resolvers, and therefore we need to design other protocols as though the additional restrictions that are _not_ part of the DNS protocol are in fact part of it. Designing the protocols for the actually existing conditions in the network is what makes the design activity engineering rather than research, I think. Preciesly. Punycode instead of UTF-8 was selected because widely deployed implementation despite theortically DNS should be 8-bit clean. My point is that RFC 1123 statement on alphabetic requirement a) is highly debatable because it is not an explicit requirement since it is mention in a section called DISCUSSION in a passing that since at least the highest-level component label will be alphabetic, in the context that TLD is alphabetic only as a matter of fact at that time, not as a matter of technical requirement b) even it is an explicit requirement, it should be taken in context in the spirit as much as RFC 1035 forbid non-alphabetic characters in labels. -James Seng ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC1035 and permitted characters in labels
Agreed :) DNS is suppose to be 8-bit clean as according to RFC 1035. But taken in context with that recommended section in RFC 1035, together with RFC 952, many legacy implementation already assumed DNS must be LDH. By the time RFC 2181 comes along, it was too late. This was one of the reasons why Punycode was chosen and not UTF-8 for IDN. -James Seng Er, that's in Section 2.3.1: Preferred Name Syntax which says before the BNF: The following syntax will result in fewer problems with many applications that use domain names RFC1035 does not say that labels can only be composed of ASCII letters and digits. RFC1123 imposes limitations on the characters permissible in a host name. But that's not the same as a domain name. PS Apologies for changing the Subject: header into something appropriate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt
On Wed, Mar 11, 2009 at 11:44:54PM +0800, James Seng wrote: label ::= letter [ [ ldh-str ] let-dig ] ... letter ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case Selective quoting can prove anything. Immediately prior to that section, RFC 1035 says The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET). a) is highly debatable because it is not an explicit requirement since it is mention in a section called DISCUSSION in a passing that since at least the highest-level component label will be alphabetic, in the context that TLD is alphabetic only as a matter of fact at that time, not as a matter of technical requirement I just responded to that exact argument up-thread, but since that wasn't apparently convincing, let's do it in more detail. The beginning of 2.1 relaxes a requirement of RFC 952 that host names may never start with a digit. 1123 says that host software MUST support the more liberal syntax. Moreover, the host SHOULD check a candidate string syntacitcally for dotted-decimal number before looking it up in the Domain Name System. As Mark Andrews has argued elsewhere on this list, the single label 666 could be interpreted as an IP address. Various hex representations may also be interpreted as an IP address. These may therefore pass the check for being a dotted-decimal number. The DISCUSSION portion of 2.1 is explaining why relaxing RFC 952's restriction is safe. The safety flows exclusively from the premise that the highest-level component label of a domain name will be alphabetic; this guarantees that a syntactic check for an IP address will fail due to at least one label being made up only of letters. It may be, therefore, that the alphabetic restriction is in fact policy, and is not strictly a protocol issue. The problem is that it is policy on which other technical decisions rest. Change the policy, and the justification for those other technical decisions is undermined. In this sense, the claim in the DISCUSSION portion of 2.1 is not just a policy: it is also the foundation of other protocol issues, and is therefore normative on the protocol even if it _is_ a policy matter. Finally, it is well-known that there are many implementations of software -- particularly with respect to the DNS -- where people with a less-than-nuanced reading of various RFCs have based what they will allow on that reading of the RFC. The 7 bit DNS implementations are an excellent example of this: RFC 1035 was clear that the DNS itself allowed other characters, but implementations checked for the preferred syntax anyway because that was the safest bet. We know empirically that there were lots of checks (and in some cases still are) for valid TLD labels that looked for things no longer than three letters. The 2001 introduction of a number of new TLDs was rockier than necessary partly because of those checks, even though there was never an RFC that suggested such was a good check. 1123 _does_ suggest that it is reasonable to check for top-level labels being alphabetic, and I'd bet a pretty good lunch that we can find implementations that decide whether something is a domain name based on whether the top label starts with a letter. Therefore, even if we don't think that 1123 does in fact restrict the top-level label to letters only, it is prudent to treat such a restriction as a _de facto_ part of the protocol. To the extent we want to change that de facto part of the protocol, we want to do as little damage as possible. An argument in favour of John Klensin's suggestion to make an explicit exception for IDNA2008 A-labels is that it is the smallest change that can be made that still accommodates the new feature we want. Best regards, Andrew -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some second-hand remarks on draft-liman-tld-names-00.txt
The DISCUSSION portion of 2.1 is explaining why relaxing RFC 952's restriction is safe. The safety flows exclusively from the premise that the highest-level component label of a domain name will be alphabetic; this guarantees that a syntactic check for an IP address will fail due to at least one label being made up only of letters. It may be, therefore, that the alphabetic restriction is in fact policy, and is not strictly a protocol issue. The problem is that it is policy on which other technical decisions rest. Change the policy, and the justification for those other technical decisions is undermined. In this sense, the claim in the DISCUSSION portion of 2.1 is not just a policy: it is also the foundation of other protocol issues, and is therefore normative on the protocol even if it _is_ a policy matter. Okay, I agree with this line of logic. 1. We agreed that the TLD restriction is therefore a policy one, and we derive other technical specification (e.g. allowing digits label at 2LD) based on the assumption of the policy one. 2. However, IDNA does not change that technical assumption, since A-label will never be all digit, or start with a digit or end with one. The 2001 introduction of a number of new TLDs was rockier than necessary partly because of those checks, even though there was never an RFC that suggested such was a good check. Agreed 1123 _does_ suggest that it is reasonable to check for top-level labels being alphabetic, and I'd bet a pretty good lunch that we can find implementations that decide whether something is a domain name based on whether the top label starts with a letter. Therefore, even if we don't think that 1123 does in fact restrict the top-level label to letters only, it is prudent to treat such a restriction as a _de facto_ part of the protocol. This is where we differ. 1. RFC 1123 do not suggest that top-level labels be check for alphabetic. RFC 1123 assumed TLD is alphabetic and therefore made certain technical assumption of what is considered valid or not. But I agree with you that there will be implementation that decide what TLD should be but it is a problem with the implementation, not with RFC 1123 or RFC 952, esp on what it did not say. 2. IDNA do not change it either again, since A-label is always LDH, or at least valid according to RFC 1123. To the extent we want to change that de facto part of the protocol, we want to do as little damage as possible. An argument in favour of John Klensin's suggestion to make an explicit exception for IDNA2008 A-labels is that it is the smallest change that can be made that still accommodates the new feature we want. What I failed to see is why we need an update to RFC1123...but I can accept the small change as proposed by John if thats what the group think it is best moving forward. -James Seng ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt
internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Top Level Domain Name Specification Author(s) : L. Liman Filename: draft-liman-tld-names-00.txt Pages : 9 Date: 2009-03-03 RFC 1123 is ambiguous regarding the specification for top level domain (TLD) labels used in the domain name system. This document clarifies the specification, and aligns it with current praxis, including the use of Internationalized Domain Name (IDN) Labels in TLD names. Lars-Johan, Updating 1123, and 1122, is a good idea, and a lot of work went into them, not just by the editor, Bob Braden, but by dozens of people. So my first comment is a meta-comment to the effect that 1123 is not ambiguous regarding the specification for top level domain (TLD) labels used in the domain name system. We didn't attempt to rigorously specify rlogin, telnet, ftp, smtp, or the dns, see the language in section 7 This section lists the primary references with which every implementer must be thoroughly familiar, the absence of this obsoletes language, and the stated purpose -- incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. What we attempted was to make some corrections, known to some of us, circa 1989. We did not exhaust the space of possible ambiguities in existing specifications, though none known were omitted to my knowledge by intent (and I don't have notes from that period anyway, so this is all personal memory), nor did we consider the possibility that the dns would ever cease to be policied by some public trust body, or that names would become trademarks (though we were all fond of memorable landmarks like sri-arpa), and many other fine, and not so fine things that would emerge in the next 20 years. So either the text in section 2.1 of 1123 is low hanging fruit which is opportunistically picked in the momentary context of the third round of new gTLD activities by the Current New Entity (ICANN), or 1123 is perfect except for this one little bit which needs a little bit of editorial review and as a mater of convenience, is intended to be published as a separate RFC rather than as a revised version of 1123. Restated more briefly, I suggest that rather than assert 1123 is ambiguous and you're going to fix it, a technically neutral act, you simply state what it is you're advocating, possibly in a disinterested fashion. Next, it is a convention, which Donald, Bill, and I observed in 2929, that [t]ext labels can, in fact, include any octet value including zero octets but most current uses involve only [US-ASCII]. The nuances I recall that Donald and I exchanged notes over during the drafting was that labels could indeed be one octet, or more, and could be any value, though the practice at the time was the printable range of 7-bit ASCII, and the LDH subset of that range. So the statement in your section 2 would be that you'd like to assert a policy for a registry, the IANA root as it happens, and there's nothing wrong with writing registry policy, its something of a cottage industry in the ICANN g- and cc-playpens, but it isn't a protocol specification. So you'd like two (or more) ASCII alphas, which the iso3166-1 MA may be comforted by, with the possibility of an infix digit or hyphen or sequence of infix digits (but not a sequence of infix hyphens) as the number of octets in the label increases to three or more. That's fine registry policy. As reasonable, as registry policy, as the Arab League's insistence that domain names be real words, or the .cn registry's policy (circa 2001, it may have changed) not to allow the names of current or former prominent persons in the Chinese Communist Party to be allocated, or the .us registry's policy that authoritative nameservers be located in the United States. But it isn't a protocol specification. There is no technical necessity to use only 7-bit ASCII. We (IDN-pre-A) could have chosen to make the lives of the 7-bit mailers, and others, harder. Whether the better possible choice was made was opinion then, and now, of a community of engineers with differing skills, and agendas, but the ASCII encoding form initially (and unilaterally deployed) by Verisign is what was chosen, but not because of any constraint integral to the DNS. My suggestion is that you re-write this as a proposed registry policy to bind on the United States, and its contractors, in particular, Verisign and ICANN, and their subcontractors, the current and potential TLD operators, and of course, the root server operators. I don't think it is particularly good policy, but it is policy and if its what you want, write it as proposed policy and then sell the hell out of it. At last I see why Andrew has been asking if anything when punycoded can end
Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt
Sure. Vint Cerf wrote: Eric, et al, I think it wise to move the discussion to dnsops and to remove from idna-update, please, as has been suggested earlier. IDNAbis does not deal with labels in a way that distinguishes TLDs from any other label position in a domain name. Vint Vint Cerf Google 1818 Library Street, Suite 400 Reston, VA 20190 202-370-5637 v...@google.com On Mar 11, 2009, at 1:13 PM, Eric Brunner-Williams wrote: internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Top Level Domain Name Specification Author(s) : L. Liman Filename: draft-liman-tld-names-00.txt Pages : 9 Date: 2009-03-03 RFC 1123 is ambiguous regarding the specification for top level domain (TLD) labels used in the domain name system. This document clarifies the specification, and aligns it with current praxis, including the use of Internationalized Domain Name (IDN) Labels in TLD names. Lars-Johan, Updating 1123, and 1122, is a good idea, and a lot of work went into them, not just by the editor, Bob Braden, but by dozens of people. So my first comment is a meta-comment to the effect that 1123 is not ambiguous regarding the specification for top level domain (TLD) labels used in the domain name system. We didn't attempt to rigorously specify rlogin, telnet, ftp, smtp, or the dns, see the language in section 7 This section lists the primary references with which every implementer must be thoroughly familiar, the absence of this obsoletes language, and the stated purpose -- incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. What we attempted was to make some corrections, known to some of us, circa 1989. We did not exhaust the space of possible ambiguities in existing specifications, though none known were omitted to my knowledge by intent (and I don't have notes from that period anyway, so this is all personal memory), nor did we consider the possibility that the dns would ever cease to be policied by some public trust body, or that names would become trademarks (though we were all fond of memorable landmarks like sri-arpa), and many other fine, and not so fine things that would emerge in the next 20 years. So either the text in section 2.1 of 1123 is low hanging fruit which is opportunistically picked in the momentary context of the third round of new gTLD activities by the Current New Entity (ICANN), or 1123 is perfect except for this one little bit which needs a little bit of editorial review and as a mater of convenience, is intended to be published as a separate RFC rather than as a revised version of 1123. Restated more briefly, I suggest that rather than assert 1123 is ambiguous and you're going to fix it, a technically neutral act, you simply state what it is you're advocating, possibly in a disinterested fashion. Next, it is a convention, which Donald, Bill, and I observed in 2929, that [t]ext labels can, in fact, include any octet value including zero octets but most current uses involve only [US-ASCII]. The nuances I recall that Donald and I exchanged notes over during the drafting was that labels could indeed be one octet, or more, and could be any value, though the practice at the time was the printable range of 7-bit ASCII, and the LDH subset of that range. So the statement in your section 2 would be that you'd like to assert a policy for a registry, the IANA root as it happens, and there's nothing wrong with writing registry policy, its something of a cottage industry in the ICANN g- and cc-playpens, but it isn't a protocol specification. So you'd like two (or more) ASCII alphas, which the iso3166-1 MA may be comforted by, with the possibility of an infix digit or hyphen or sequence of infix digits (but not a sequence of infix hyphens) as the number of octets in the label increases to three or more. That's fine registry policy. As reasonable, as registry policy, as the Arab League's insistence that domain names be real words, or the .cn registry's policy (circa 2001, it may have changed) not to allow the names of current or former prominent persons in the Chinese Communist Party to be allocated, or the .us registry's policy that authoritative nameservers be located in the United States. But it isn't a protocol specification. There is no technical necessity to use only 7-bit ASCII. We (IDN-pre- A) could have chosen to make the lives of the 7-bit mailers, and others, harder. Whether the better possible choice was made was opinion then, and now, of a community of engineers with differing skills, and agendas, but the ASCII encoding form initially (and unilaterally deployed) by Verisign is what was chosen, but not because of any constraint integral to the DNS. My suggestion is that you re-write this
Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt
Eric, et al, I think it wise to move the discussion to dnsops and to remove from idna-update, please, as has been suggested earlier. IDNAbis does not deal with labels in a way that distinguishes TLDs from any other label position in a domain name. Vint Vint Cerf Google 1818 Library Street, Suite 400 Reston, VA 20190 202-370-5637 v...@google.com On Mar 11, 2009, at 1:13 PM, Eric Brunner-Williams wrote: internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Top Level Domain Name Specification Author(s) : L. Liman Filename: draft-liman-tld-names-00.txt Pages : 9 Date: 2009-03-03 RFC 1123 is ambiguous regarding the specification for top level domain (TLD) labels used in the domain name system. This document clarifies the specification, and aligns it with current praxis, including the use of Internationalized Domain Name (IDN) Labels in TLD names. Lars-Johan, Updating 1123, and 1122, is a good idea, and a lot of work went into them, not just by the editor, Bob Braden, but by dozens of people. So my first comment is a meta-comment to the effect that 1123 is not ambiguous regarding the specification for top level domain (TLD) labels used in the domain name system. We didn't attempt to rigorously specify rlogin, telnet, ftp, smtp, or the dns, see the language in section 7 This section lists the primary references with which every implementer must be thoroughly familiar, the absence of this obsoletes language, and the stated purpose -- incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. What we attempted was to make some corrections, known to some of us, circa 1989. We did not exhaust the space of possible ambiguities in existing specifications, though none known were omitted to my knowledge by intent (and I don't have notes from that period anyway, so this is all personal memory), nor did we consider the possibility that the dns would ever cease to be policied by some public trust body, or that names would become trademarks (though we were all fond of memorable landmarks like sri-arpa), and many other fine, and not so fine things that would emerge in the next 20 years. So either the text in section 2.1 of 1123 is low hanging fruit which is opportunistically picked in the momentary context of the third round of new gTLD activities by the Current New Entity (ICANN), or 1123 is perfect except for this one little bit which needs a little bit of editorial review and as a mater of convenience, is intended to be published as a separate RFC rather than as a revised version of 1123. Restated more briefly, I suggest that rather than assert 1123 is ambiguous and you're going to fix it, a technically neutral act, you simply state what it is you're advocating, possibly in a disinterested fashion. Next, it is a convention, which Donald, Bill, and I observed in 2929, that [t]ext labels can, in fact, include any octet value including zero octets but most current uses involve only [US-ASCII]. The nuances I recall that Donald and I exchanged notes over during the drafting was that labels could indeed be one octet, or more, and could be any value, though the practice at the time was the printable range of 7-bit ASCII, and the LDH subset of that range. So the statement in your section 2 would be that you'd like to assert a policy for a registry, the IANA root as it happens, and there's nothing wrong with writing registry policy, its something of a cottage industry in the ICANN g- and cc-playpens, but it isn't a protocol specification. So you'd like two (or more) ASCII alphas, which the iso3166-1 MA may be comforted by, with the possibility of an infix digit or hyphen or sequence of infix digits (but not a sequence of infix hyphens) as the number of octets in the label increases to three or more. That's fine registry policy. As reasonable, as registry policy, as the Arab League's insistence that domain names be real words, or the .cn registry's policy (circa 2001, it may have changed) not to allow the names of current or former prominent persons in the Chinese Communist Party to be allocated, or the .us registry's policy that authoritative nameservers be located in the United States. But it isn't a protocol specification. There is no technical necessity to use only 7-bit ASCII. We (IDN-pre- A) could have chosen to make the lives of the 7-bit mailers, and others, harder. Whether the better possible choice was made was opinion then, and now, of a community of engineers with differing skills, and agendas, but the ASCII encoding form initially (and unilaterally deployed) by Verisign is what was chosen, but not because of any constraint integral to the DNS. My suggestion is that you re-write this as a proposed registry policy to bind
Re: [DNSOP] [dnsext] New Version Notification for draft-mcgrew-tss-02 (fwd)
At 06:27 PM 3/11/2009, David McGrew wrote: Hi Mike, Hi Alfred - A better scheme for threshold signing for the root might be the Shoup paper: Practical Threshold Signatures, Victor Shoup (s...@zurich.ibm.com ), IBM Research Paper RZ3121, 4/30/99 The major difference between the two is that the Shamir system (which you describe) requires the base secret (private key) be reconstituted (by a trusted entity) before it can be used, where the Shoup system allows partial signatures with a public gather function. E.g. In a 3 of 5 system, each of the 3 key share holders partial-sign the data using their share of the private key and send it (as public data) to a central location where a gather function is used to form the actual signature. I agree that threshold signatures have nice security properties, and that Shoup's PTS method looks good, especially because its signature- share generation step does not require any interaction between the signers. As you say, the TSS draft lacks the partial-signature capability, but TSS does have the benefit of simplicity. Shamir is nice in that it can be used for any set of key bits. But the reconstitution requirement is a point of weakness where the actual private key may be compromised. The Shoup system is only specified for RSA as far as I know. Shoup's PTS method requires the use of a trusted dealer to generate the private keys of all of the signers. So while it eliminates the need for a trusted dealer during the signing step, it does not eliminate that need entirely. (At least this is the case for the paper that you cited above; if there is work that eliminates the trusted dealer, I would be very interested to see it.) best regards, David Hi David - What I would recommend doing here is build a computer and set it up with no connections to the outside world. Load it with the generation software and the public keys of the N share holders. Connect it to a printer. Run the generation software and then print out the 5 public key wrapped shares armored as HEX ascii in an OCR font. Destroy the hard drive. Melt, burn, magnetize, disassemble, etc. Send the wrapped shares off to the various share holders. Have them OCR them into the encrypted key shares they'll use later to do the signing. The ceremony for doing the generation in a reasonably trusted manner and ensuring that information doesn't leak is manageable.. :-) But it would be nice if we didn't need a trusted dealer Mike ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] New Version Notification for draft-mcgrew-tss-02 (fwd)
Hi Mike, Hi Alfred - A better scheme for threshold signing for the root might be the Shoup paper: Practical Threshold Signatures, Victor Shoup (s...@zurich.ibm.com ), IBM Research Paper RZ3121, 4/30/99 The major difference between the two is that the Shamir system (which you describe) requires the base secret (private key) be reconstituted (by a trusted entity) before it can be used, where the Shoup system allows partial signatures with a public gather function. E.g. In a 3 of 5 system, each of the 3 key share holders partial-sign the data using their share of the private key and send it (as public data) to a central location where a gather function is used to form the actual signature. I agree that threshold signatures have nice security properties, and that Shoup's PTS method looks good, especially because its signature- share generation step does not require any interaction between the signers. As you say, the TSS draft lacks the partial-signature capability, but TSS does have the benefit of simplicity. Shamir is nice in that it can be used for any set of key bits. But the reconstitution requirement is a point of weakness where the actual private key may be compromised. The Shoup system is only specified for RSA as far as I know. Shoup's PTS method requires the use of a trusted dealer to generate the private keys of all of the signers. So while it eliminates the need for a trusted dealer during the signing step, it does not eliminate that need entirely. (At least this is the case for the paper that you cited above; if there is work that eliminates the trusted dealer, I would be very interested to see it.) best regards, David ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DS vs DNSKEY trust anchors, was Re: Truncation...
In message a06240800c5dd7e5f2...@[10.31.200.116], Edward Lewis writes: At 8:19 +1100 3/11/09, Mark Andrews wrote: In message a06240804c5dc2ddef...@[10.31.200.116], Edward Lewis writes: record involves less typing than a DNSKEY, I'd want to work with a DS record. Has anyone on this list ever typed in a DNSKEY or DS as a trust anchor? I would presume that most (99.%) people work with != type in At 10:40 +1100 3/11/09, Mark Andrews wrote: I have a new key I want to introduce. I add the DS to the parent zone at least the ttl(ds) before I start using that key in the zone. After the DS has been published for ttl(ds) I can then replace the DNSKEY referred to by the old DS with that of the new DS and re-sign the DNSKEY RRset. Once the ttl(dnskey) has expired I can remove the old DS from the parent zone. I wish to be able to do something similar with trust anchors. Publishing DS prevents me from doing so. There is more than one way to do a key supersession. I'll describe one assuming DS records are installed as trust anchors. DS(KEY1) is in my validator. The owner of KEY1 distributes DS(KEY2) with a note that it should be installed by the 15th. On the 15th, DNSKEY(KEY2) is placed in the zone and KEY2 only is used to sign the keyset. With a 1 week TTL on the key set's RRSIG RR, a week later DNSKEY(KEY1) is removed from the set. At some point after that I can remove DS(KEY1) from my validator. Perhaps the special case here is that the keyset is unique in that the signatures for SEP/KSK's are tied to the where the key data is. I.e., if you have something signed by KEY1, then you have KEY1 because that something has to be the key set. If the zone is not run with a KSK/ZSK split, then the removal of KEY1 is triggered by signing the last RR set by KEY2 and then the TTL. The principle here is that there is no error if for a DS record there is no corresponding DNSKEY and vice versa. All that is needed for validation is one chain of trust. Accepting dangling references is not optimal but provides robustness. Ed, I'm aware there are multiple ways to do this. However publishing DS records only precludes some methods. Publishing DNSKEY records does not preclude any methods as one can *ALWAYS* generate a DS from a DNSKEY. The reverse requires you to look up a key which matches which means it must be available to be available to be looked up. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DS vs DNSKEY trust anchors, was Re: Truncation...
You poor souls. The DNSSEC monster is vast and complex. So much easier just to fix the problem instead of this endless gibberish. It's so complex it's funny when you consider a simple solution like DNSCURVE - http://dnscurve.org/ - and so much more secure. No man in the middle issues. Oh well - sorry for the interruption - and carry on. cheers joe baptista On Wed, Mar 11, 2009 at 10:57 AM, Edward Lewis ed.le...@neustar.biz wrote: At 8:19 +1100 3/11/09, Mark Andrews wrote: In message a06240804c5dc2ddef...@[10.31.200.116], Edward Lewis writes: record involves less typing than a DNSKEY, I'd want to work with a DS record. Has anyone on this list ever typed in a DNSKEY or DS as a trust anchor? I would presume that most (99.%) people work with != type in At 10:40 +1100 3/11/09, Mark Andrews wrote: I have a new key I want to introduce. I add the DS to the parent zone at least the ttl(ds) before I start using that key in the zone. After the DS has been published for ttl(ds) I can then replace the DNSKEY referred to by the old DS with that of the new DS and re-sign the DNSKEY RRset. Once the ttl(dnskey) has expired I can remove the old DS from the parent zone. I wish to be able to do something similar with trust anchors. Publishing DS prevents me from doing so. There is more than one way to do a key supersession. I'll describe one assuming DS records are installed as trust anchors. DS(KEY1) is in my validator. The owner of KEY1 distributes DS(KEY2) with a note that it should be installed by the 15th. On the 15th, DNSKEY(KEY2) is placed in the zone and KEY2 only is used to sign the keyset. With a 1 week TTL on the key set's RRSIG RR, a week later DNSKEY(KEY1) is removed from the set. At some point after that I can remove DS(KEY1) from my validator. Perhaps the special case here is that the keyset is unique in that the signatures for SEP/KSK's are tied to the where the key data is. I.e., if you have something signed by KEY1, then you have KEY1 because that something has to be the key set. If the zone is not run with a KSK/ZSK split, then the removal of KEY1 is triggered by signing the last RR set by KEY2 and then the TTL. The principle here is that there is no error if for a DS record there is no corresponding DNSKEY and vice versa. All that is needed for validation is one chain of trust. Accepting dangling references is not optimal but provides robustness. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC1035 and permitted characters in labels
In message 558a39a60903110907i6edad88dye59293cbac951...@mail.gmail.com, James Seng writes: Agreed :) DNS is suppose to be 8-bit clean as according to RFC 1035. No it is supposed to be nearly 8 bit clean. :-) But taken in context with that recommended section in RFC 1035, together with RFC 952, many legacy implementation already assumed DNS must be LDH. By the time RFC 2181 comes along, it was too late. This was one of the reasons why Punycode was chosen and not UTF-8 for IDN. -James Seng RFC 952 is for HOST NAMES RFC 1035 is for DOMAIN NAMES. Host names and domain names are DIFFERENT things and are often confused in the RFC's. Punycode was choosen because the hostname lookup components of resolvers and other components in applications enforce LDH for HOST NAME lookups (forward and reverse) and for MX lookups. Other sorts of lookups were not constrained. Host names and mail domains restrictions come from outside of the DNS. IDNA sits on top of RFC 952 (modified by RFC 1123) which sits on top of the DNS. Er, that's in Section 2.3.1: Preferred Name Syntax which says before the BNF: The following syntax will result in fewer problems with many applications that use domain names RFC1035 does not say that labels can only be composed of ASCII letters and digits. RFC1123 imposes limitations on the characters permissible in a host name. But that's not the same as a domain name. PS Apologies for changing the Subject: header into something appropriate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DS vs DNSKEY trust anchors, was Re: Truncation...
Moin! On 12.03.2009, at 01:10, Joe Baptista wrote: You poor souls. The DNSSEC monster is vast and complex. So much easier just to fix the problem instead of this endless gibberish. It's so complex it's funny when you consider a simple solution like DNSCURVE -http://dnscurve.org/ - and so much more secure. No man in the middle issues. DNSCurve solves a different problem. It's about encryption of DNS data, while DNSSEC looks on authentication of DNS data. DNSSEC and DNSCurve are complementary solutions not contradicting solutions. Oh well - sorry for the interruption - and carry on. Ahem could I ask why you are carrying my companies logo on your webpage? If there is an contractual relationship please send me the details off list, otherwise please remove it. On the topic DNSKEY or DS keys as trust anchors I would opt for DNSKEYS as there may be publication of trust anchors that may have hash/digest algorithms that my resolver/validator doesn't understand. This already happened to me :-(. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: r...@colt.net http://www.colt.net/ Data | Voice | Managed Services Schütze Deine Umwelt | Erst denken, dann drucken * COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 * Geschäftsführer: Dr. Jürgen Hernichel (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
