Re: [DNSOP] SEARS - Search Engine Address Resolution Service (and Protocol)
Greetings! Is there a more or less complete description of SEARS? Google can't find anything instead this or that trade companies, Wikipedia shows some people and some trade companies too... On Thu, Feb 16, 2012 at 4:30 PM, Todd Glassey wrote: > So SEARS is a method of replacing the DNS roots with a well-known > service portal providing a Google or other SE based access model. The > session can interface with traditional HTTP or DNS-Lookup Ports to > deliver content or addresses to a browser in the form of a HTTP redirection. > > The protocol specification is almost done and is intended to make > threats of attacks against the DNS roots less of an issue. > > Todd > > -- > Todd S. Glassey - CISM CIFI > CTO Certichron Inc > > This message contains information which may be confidential and/or > privileged. Unless you are the intended recipient (or authorized to > receive for the intended recipient), you may not read, use, copy or > disclose to anyone the message or any information contained in the > message. If you have received the message in error, please advise the > sender by reply e-mail and delete the message and any attachment(s) > thereto without retaining any copies. > > Further we have a formal OPT OUT Policy posted on our website pertaining > to the use of any Email Addresses gleaned or taken from any source, web, > mailing lists, previous customer lists etc. In all instances we choose > to formally OPT OUT and this notice constitutes formal disclosure that > you may not collect, buy or sell or provide access to this email address > or any pertaining to our DNS MX Record Publication License posted on the > web at http://www-wp.certichron.com/?page_id=3947. > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-rfc5933-bis-08.txt
Dear colleagues, The updated version of RFC 5933-bis draft is uploaded. The updated version partially resolves the issues raised by Michael StJohns in his thorough review. I hope there will be more interest in the updated version of the draft than it was during the previous WGLC. As I'm not subscribed to dnsop@ nowadays, I kindly ask not to remove me from the recipients list. Many thanks in advance! -- Forwarded message - From: Date: Sun, Jul 10, 2022 at 6:06 PM Subject: New Version Notification for draft-ietf-dnsop-rfc5933-bis-08.txt To: Dmitry Belyavskiy , Vasily Dolmatov < vdolma...@gmail.com> A new version of I-D, draft-ietf-dnsop-rfc5933-bis-08.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-ietf-dnsop-rfc5933-bis Revision: 08 Title: Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC Document date: 2022-07-10 Group: dnsop Pages: 10 URL: https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc5933-bis-08.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5933-bis-08 Abstract: This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). This document obsoletes RFC 5933 and updates RFC 8624. The IETF Secretariat -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: Working Group Last Call for draft-ietf-dnsop-rfc5933-bis
Dear Michael, Sorry for a very long delay, as your review was the only one I thought there was not enough interest in this document. On Wed, Feb 2, 2022 at 12:04 AM Michael StJohns wrote: > On 2/1/2022 3:35 PM, Tim Wicinski wrote: > > All > > We were reviewing the Working Group Last Call for this, and we received no > comments. We know there was interest in at least moving this forward, but > even Warren concurred we can't send this to the IESG unless there are folks > saying they feel it is ready to be published. > > Thanks > > tim > > > Hi Tim - > > Since you ask, I don't think it's ready to go forward. Section 2 is > particularly opaque. > > Section 2.1 - Provide the ASN1 that explains what's going on by adding the > prefix to a 64 byte GOST public key. Ideally identify the various OIDs > that match to the key format, and to the signature format. > Done > Section 2.2 - How does the private key in the first part of the example > get you to the public key in the second? > > The Base 64 in the DNSKEY appears to give you this value: > > 5E 46 7A 4F EA 90 F6 D7 8E 32 C0 3F 60 AF A4 4F > 31 0B 86 E3 0F 4E C6 20 81 DC B6 6F EB 1F CC 9E > AD 1F D7 A7 8B 38 8C 5F 78 23 32 75 19 23 2A E7 > 48 87 21 2E 3B A9 F3 1A 72 F9 45 39 97 51 32 8F > > Which appears to be an unparameterized GOST public key which I assume > matches the private key. That may be a valid key or not, but saying that > explicitly would be useful.Or at least "The following DNSKEY RR > contains the encoded GOST public key paired with this private key - see xxx > for the key pair generation logic" > Done > To fix all this, start from a normal (PEM or PKCS8 or PKCS12 or X509) > representation of an example key pair and work from there to map to/form > DNSKEY, DS and RRSIG records. > > The algorithm number is specified as 23 here and other places, and that's > so that the examples could be calculated, but if the IANA doesn't issue > them 23 as the number (and they probably won't) most of the examples will > have to be redone with the final values. This is a cart/horse problem and > I'd recommend that the IANA do an early assignment of the signature and > digest algorithm values and that the document be redone with the final > values prior to IESG submission to prevent a round trip during RFC > publication. > Yes, this is a possible way forward. > Sections 3.1 and 4.1 - show your work. Show the actual data being hashed > or signed so that someone else coming along can verify that a) you did the > encoding properly, and b) the hashes match or the signatures match. This > is especially important with algorithms which lack broad international > implementation. > It's the most problematic part for me nowadays. So I provided a reference to my fork of LDNS I used for the DNS part of work and a link to a reference implementation of GOST algorithms. If you think it's not enough, I will try to remember what I did and regenerate the examples with intermediate steps. > Section 5 - these should refer to the GOST specification (e.g. "MUST be > 512 bits per [GOSTxxx]"). As stated, this could be something peculiar to > this spec rather than the underlying cryptographic primitive. > Done. > Section 6.1 - huh? In any case, we generally don't have single subheader > sections - move the text up. I think this is supposed to be "The support > of this cryptographic suite in DNSSEC-aware systems is OPTIONAL. Systems > that do not support these algorithms may ignore the RRSIG, DNSKEY and DS > records created with them." > Done. > Section 10: " > Sorry, didn't get :( > I hope this helps - > > Mike > > > -- Forwarded message - > > All > > With draft-ietf-dnsop-dnssec-iana-cons now in AUTH48 state, it's time to > move this document along as well. > > This starts a Working Group Last Call for draft-ietf-dnsop-rfc5933-bis, > "Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource > Records for DNSSEC" > > Current versions of the draft is available here: > https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc5933-bis-07.html > > The Current Intended Status of this document is: Informational > > Please review the draft and offer relevant comments. > If this does not seem appropriate please speak out. > If someone feels the document is *not* ready for publication, please speak > out with your reasons. > > Because of the American holiday, we're going to run the last call process > a few days long. This Working Group Last Call will end on: 10 December > 2021 > > thanks > tim > > ___ > DNSOP mailing listDNSOP@ietf.orghttps://www.ietf.org/mailman/listinfo/dnsop > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-rfc5933-bis-09.txt
Dear colleagues, Here is the updated version of the "Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC" IETF draft. We have a new coauthor, Boris Makarenko, who kindly agreed to continue the development process. -- Forwarded message - From: Date: Thu, Jul 28, 2022 at 2:10 PM Subject: New Version Notification for draft-ietf-dnsop-rfc5933-bis-09.txt To: Boris Makarenko , Dmitry Belyavskiy < beld...@gmail.com>, Vasily Dolmatov A new version of I-D, draft-ietf-dnsop-rfc5933-bis-09.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-ietf-dnsop-rfc5933-bis Revision: 09 Title: Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC Document date: 2022-07-28 Group: dnsop Pages: 10 URL: https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc5933-bis-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5933-bis-09 Abstract: This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). This document obsoletes RFC 5933 and updates RFC 8624. The IETF Secretariat -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-belyavskiy-rfc5933-bis-01.txt
Dear DNSOP mailing list members, Please see the announcement of the draft describing using the GOST 2012 hash and digital signature algorithms for DNSSec. The document pretends to update 2 IANA registries. The 1st one implies the "RFC required" status: https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 so there are no problems with it. The 2nd one, unfortunately for me, requires "Standard action" status https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1 so it makes impossible to pass it via ISE. I kindly ask to review the draft to make possible assigning the IANA codes for the algorithms. The implementation of the draft is also available, see https://github.com/beldmit/ldns/tree/gost2012 for details. Many thanks! -- Forwarded message - From: Date: Sun, Feb 9, 2020 at 1:43 PM Subject: New Version Notification for draft-belyavskiy-rfc5933-bis-01.txt To: Vasily Dolmatov , Dmitry Belyavskiy < beld...@gmail.com> A new version of I-D, draft-belyavskiy-rfc5933-bis-01.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-belyavskiy-rfc5933-bis Revision: 01 Title: Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC Document date: 2020-02-09 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-belyavskiy-rfc5933-bis-01.txt Status: https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ Htmlized: https://tools.ietf.org/html/draft-belyavskiy-rfc5933-bis-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-belyavskiy-rfc5933-bis Diff: https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-rfc5933-bis-01 Abstract: This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-belyavskiy-rfc5933-bis-01.txt
Just a clarification. In contrast to RFC 5933, this document does NOT pretend to make the described algorithms IANA-recommended. On Wed, Feb 12, 2020 at 12:14 AM Warren Kumari wrote: > Dear DNSOP, > > I asked Dmitry to please bring this document to DNSOP for discussion; > DNSOP is where we generally discuss the use of different algorithms in > DNSSEC. > I'd appreciate it if the discussion can be kept to the DNS / DNSSEC > parts of the document (using the algorithms for DNSKEY, RRSIG, and DS > resource records), and not the crypto itself (CFRG / others are the > place for that). > > W > > On Tue, Feb 11, 2020 at 12:06 PM Dmitry Belyavsky > wrote: > > > > Dear DNSOP mailing list members, > > > > Please see the announcement of the draft describing using the > > GOST 2012 hash and digital signature algorithms for DNSSec. > > > > The document pretends to update 2 IANA registries. > > > > The 1st one implies the "RFC required" status: > > > https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 > > so there are no problems with it. > > > > The 2nd one, unfortunately for me, requires "Standard action" status > > > https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1 > > > > so it makes impossible to pass it via ISE. > > > > I kindly ask to review the draft to make possible assigning the IANA > codes for the algorithms. > > The implementation of the draft is also available, see > https://github.com/beldmit/ldns/tree/gost2012 for details. > > > > Many thanks! > > > > -- Forwarded message - > > From: > > Date: Sun, Feb 9, 2020 at 1:43 PM > > Subject: New Version Notification for draft-belyavskiy-rfc5933-bis-01.txt > > To: Vasily Dolmatov , Dmitry Belyavskiy < > beld...@gmail.com> > > > > > > > > A new version of I-D, draft-belyavskiy-rfc5933-bis-01.txt > > has been successfully submitted by Dmitry Belyavskiy and posted to the > > IETF repository. > > > > Name: draft-belyavskiy-rfc5933-bis > > Revision: 01 > > Title: Use of GOST 2012 Signature Algorithms in DNSKEY and > RRSIG Resource Records for DNSSEC > > Document date: 2020-02-09 > > Group: Individual Submission > > Pages: 9 > > URL: > https://www.ietf.org/internet-drafts/draft-belyavskiy-rfc5933-bis-01.txt > > Status: > https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ > > Htmlized: > https://tools.ietf.org/html/draft-belyavskiy-rfc5933-bis-01 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-belyavskiy-rfc5933-bis > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-rfc5933-bis-01 > > > > Abstract: > >This document describes how to produce digital signatures and hash > >functions using the GOST R 34.10-2012 and GOST R 34.11-2012 > >algorithms for DNSKEY, RRSIG, and DS resource records, for use in the > >Domain Name System Security Extensions (DNSSEC). > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > > > > -- > > SY, Dmitry Belyavsky > > ___ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. >---maf > -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Minutes for 23 April 2020 Interim
Dear Paul, On Mon, Apr 27, 2020 at 3:51 AM Paul Wouters wrote: > On Thu, 23 Apr 2020, Tim Wicinski wrote: > > > We've uploaded the minutes from today's session > > Thanks for the minutes. One comment on the GOST comment from Jim: > > > Jim: Supports work > Wants references to old ones to be deprecated > > > Note that RFC-8624 already made algorithm 12 (ECC-GOST) a "MUST NOT" > for signing and a "MAY" for validation. > > I agree that for 8624bis, the MAY should become a MUST NOT. Ideally > after we have the new GOST DNSKEY algorithm. The justification is that > this algorithm has been obsolete for a while now, and there is no real > deployment of it. As far as I know, there were only two domains in .ru > that used it, mostly for testing? Maybe Viktor, Dmitry or Stanislav > could confirm this. > There were more than 2 domains :) I see some elements of a vicious circle there. Lack of support of GOST in DNSSEC software causes a lack of popularity even in Russia. So now the standard and its implementation were done simultaneously. -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis
Hello, On Thu, Jun 4, 2020 at 12:07 AM Tim Wicinski wrote: > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis > > The draft is available here: > https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ > Being a co-author of this draft, I support adoption. -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis
Dear Paul, On Thu, Jun 4, 2020 at 12:17 AM Paul Wouters wrote: > On Wed, 3 Jun 2020, Tim Wicinski wrote: > > > As we stated in the meeting and in our chairs actions, we're going to run > > regular call for adoptions over next few months. > > We are looking for *explicit* support for adoption. > > > > This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis > > I support adoption, willing to review and contribute txt. > > Note, the DS in the example in section 4.1 seems to be using 5 as > the assigned number, but this should probably be a TBA2 for now :) > > Unless, an early code point has already been assigned, and looking > at the iana table the next available value is indeed 5 :) > Thanks for your support! I had to define some values to provide relevant examples, and 5 for digest is mentioned in the "IANA Considerations" section. -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
I support the adoption. On Fri, Jun 12, 2020 at 6:12 PM Tim Wicinski wrote: > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular calls for adoptions over the next few months. We are looking for > *explicit* support for adoption. > > > This starts a Call for Adoption for draft-arends-private-use-tld > > The draft is available here: > https://datatracker.ietf.org/doc/draft-arends-private-use-tld/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 26 June 2020 > > Thanks, > tim wicinski > DNSOP co-chair > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis
Dear Ondřej, As we have different statuses for the algorithm, I don't think the CFRG adoption is required. I don't think there are good or bad time periods to adopt nation-wide crypto profiles. For me, the difference between the GOST profile and hypothetical Korean or German profile is close to zero, and if anybody brings such a profile for standardization, I'd like to support it. As we have different statuses for the algorithms, I don't think the CFRG adoption is required. Speaking about the implementation, I'll have to put on the hat of the GOST engine maintainer. The open-source implementation of the GOST crypto is available in OpenSSL (as engine), LibreSSL (being the part of the core), and GnuTLS. The project activity of the gost-engine is limited by the coordination of the life circles between the Russian Standard body and OpenSSL. The issue you refer to is backdated almost two years ago, and I have some (rather vague, though) plans to make a new release as some improvements worth backporting appeared recently and some more are expected. On Tue, Jun 16, 2020 at 10:53 AM Ondřej Surý wrote: > Hi, > > I do not hold as strong position as Olafur here, but I concur that the > document > needs much better rationale. There’s no rationale for adopting the new GOST > algorithm at the moment and I would especially like to hear why GOST 2012 > should be standardized and EC-KCDSA (Korean) and ECGDSA (German) > should not. > > I specifically think that we should only standardize algorithms recommended > by cfrg such as RFC 7748 or RFC 8439 (just example, not applicable). > > I consider the previous GOST standardization for DNSSEC to be a fiasco. > > I would also ask the WG to require a implementation report before we send > this to WGLC. The support for GOST family of algorithms varies between > the various crypto libraries. I found it problematic for the DNS vendors > that > OpenSSL supports the algs only in form of OpenSSL engine, and that said > engine had last release in 2018. The project activity looks fine, but > issues > like this[1] don’t exactly fill me with trust, but at least there’s an > active maintainer > for the project. > > As of the adoption - I am indifferent, the things I mentioned could be done > with or without WG adopting the document, but I think that the document > should not become a RFC (not even Informational) before the items I > mentioned are cleared. > > 1. https://github.com/gost-engine/engine/issues/91 > > Ondrej > -- > Ondřej Surý > ond...@isc.org > > > On 16 Jun 2020, at 04:42, Olafur Gudmundsson wrote: > > > > > > Thom > > As I have before stated in the past, adding new DNSSEC algorithm is bad > for interoperability, > > I oppose the adoption of this document unless there are better reasons > put forward why this algorithm is better than > > the 4 ECC algorithms that have been standardized so far. > > Better in this case could be stronger, faster, better post-quantum > resistance etc > > > > Also I want to point out this last call did not specify track so my > opposition is against all tracks, at this point. > > > > Olafur > > > > > > > > > >> On Jun 3, 2020, at 5:07 PM, Tim Wicinski wrote: > >> > >> > >> All, > >> > >> As we stated in the meeting and in our chairs actions, we're going to > run > >> regular call for adoptions over next few months. > >> We are looking for *explicit* support for adoption. > >> > >> > >> This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis > >> > >> The draft is available here: > https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ > >> > >> Please review this draft to see if you think it is suitable for adoption > >> by DNSOP, and comments to the list, clearly stating your view. > >> > >> Please also indicate if you are willing to contribute text, review, etc. > >> > >> This call for adoption ends: 15 June 2020 > >> > >> Thanks, > >> tim wicinski > >> DNSOP co-chair > >> > >> > >> > >> ___ > >> 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 mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis
Dear Paul, On Thu, Jun 18, 2020 at 5:48 PM Paul Hoffman wrote: > Why is this WG considering making this document Standards Track instead of > Informational? Also, why is the WG considering putting the document in our > work stream at all? Can the WG can bring much value to the document itself? > We do have lots of other things we are working on. > > There is no procedural need for this document to be part of the DNSOP > working group. In order for this algorithm to get an algorithm number from > IANA, all that is needed is an RFC. National crypto algorithms is one of > the common use cases for the Independent Stream in the RFC Series. > Suggesting that the authors publish it there will take less time for all of > us, will conceivably get it published as an RFC sooner, and fulfills the > requirement for them to get their assignment from IANA. > Unfortunately, Independent Stream is impossible for this document. This document requires updates to 2 IANA registries: Domain Name System Security (DNSSEC) Algorithm Numbers ( https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml ) has the "RFC Required" update policy The 2nd registry Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms ( https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1 ) has the "Standards Action" update policy So it makes impossible to use the Independent Stream process. -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5933-bis-01.txt
Dear Dnsop, The updated version of the draft-ietf-dnsop-rfc5933-bis is published. Many thanks to Tim Wicinski for his comments. If some of them are not processed, it's totally my fault caused by a lack of attention. The question to be clarified is the relation between this draft and RFC 5933. Many thanks to Tim for raising this question! On Tue, Sep 8, 2020 at 7:50 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : Use of GOST 2012 Signature Algorithms in DNSKEY > and RRSIG Resource Records for DNSSEC > Authors : Dmitry Belyavskiy > Vasily Dolmatov > Filename: draft-ietf-dnsop-rfc5933-bis-01.txt > Pages : 8 > Date: 2020-09-08 > > Abstract: >This document describes how to produce digital signatures and hash >functions using the GOST R 34.10-2012 and GOST R 34.11-2012 >algorithms for DNSKEY, RRSIG, and DS resource records, for use in the >Domain Name System Security Extensions (DNSSEC). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-rfc5933-bis-01 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5933-bis-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5933-bis-02.txt
Dear colleagues, Here is the updated version of the draft describing the usage of Russian GOST cryptography for DNSSec. The changes since the previous version of the draft are related to obsoleting the RFC 5933 and corresponding changes in the IANA registries. I kindly ask those who were interested in reviewing this draft to make their reviews. Many thanks in advance! On Mon, Sep 28, 2020 at 12:21 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : Use of GOST 2012 Signature Algorithms in DNSKEY > and RRSIG Resource Records for DNSSEC > Authors : Dmitry Belyavskiy > Vasily Dolmatov > Filename: draft-ietf-dnsop-rfc5933-bis-02.txt > Pages : 8 > Date: 2020-09-28 > > Abstract: >This document describes how to produce digital signatures and hash >functions using the GOST R 34.10-2012 and GOST R 34.11-2012 >algorithms for DNSKEY, RRSIG, and DS resource records, for use in the >Domain Name System Security Extensions (DNSSEC). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-rfc5933-bis-02 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5933-bis-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC
I support the adoption On Wed, Aug 4, 2021 at 5:29 PM Tim Wicinski wrote: > > All > > This starts a Working Group Last Call for draft-ietf-dnsop-dnssec-iana-cons > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/ > > The Current Intended Status of this document is: Standards Track > > Please review the draft and offer relevant comments. > If this does not seem appropriate please speak out. > If someone feels the document is *not* ready for publication, please speak > out with your reasons. > > This starts a two week Working Group Last Call process, and ends on: 18 > August 2021 > > thanks > tim > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC
Sorry, I meant I support the draft On Wed, Aug 11, 2021 at 3:45 PM Dmitry Belyavsky wrote: > I support the adoption > > On Wed, Aug 4, 2021 at 5:29 PM Tim Wicinski wrote: > >> >> All >> >> This starts a Working Group Last Call for >> draft-ietf-dnsop-dnssec-iana-cons >> >> Current versions of the draft is available here: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/ >> >> The Current Intended Status of this document is: Standards Track >> >> Please review the draft and offer relevant comments. >> If this does not seem appropriate please speak out. >> If someone feels the document is *not* ready for publication, please >> speak out with your reasons. >> >> This starts a two week Working Group Last Call process, and ends on: 18 >> August 2021 >> >> thanks >> tim >> ___________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > > -- > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: I-D Action: draft-ietf-dnsop-rfc5933-bis-05.txt
Dear colleagues, The updated version of the draft is posted. The only change is intended status, Informational for now. -- Forwarded message - From: Date: Thu, Nov 11, 2021 at 12:34 PM Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5933-bis-05.txt Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC Authors : Dmitry Belyavskiy Vasily Dolmatov Filename: draft-ietf-dnsop-rfc5933-bis-05.txt Pages : 9 Date: 2021-11-11 Abstract: This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5933-bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: I-D Action: draft-ietf-dnsop-rfc5933-bis-06.txt
Dear colleagues, New version of the draft is uploaded. The only difference from previous is some nits, many thanks Tim Wicinski for the nitpicking. -- Forwarded message - From: Date: Fri, Nov 12, 2021 at 1:57 PM Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5933-bis-06.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC Authors : Dmitry Belyavskiy Vasily Dolmatov Filename: draft-ietf-dnsop-rfc5933-bis-06.txt Pages : 9 Date: 2021-11-12 Abstract: This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). This document obsoletes RFC 5933 and updates RFC 8624. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5933-bis-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: I-D Action: draft-ietf-dnsop-rfc5933-bis-06.txt
Dear Stephane, On Fri, Nov 12, 2021 at 2:46 PM Stephane Bortzmeyer wrote: > On Fri, Nov 12, 2021 at 01:59:52PM +0100, > Dmitry Belyavsky wrote > a message of 153 lines which said: > > > New version of the draft is uploaded. > > I would like to have to additions, if you have time: > > * a section summarizing the changes since RFC 5933. It seems it is > just GOST R 34.10-2001 replaced by GOST R 34.10-2012? > Yes, I will add the corresponding part if it is missing. Both signature and hash are replaced. > * an implementation status section (see RFC 7942) listing the > resolvers that can validate with GOST R 34.10 (Unbound, and BIND, it > seems) but also a few domain names signed with it (I knew caint.su but > it apparently disappeared). > It's a more complicated question. We had to write this document because the former hash and signature algorithms are deprecated both in Russia and by IETF. Then we have a chicken-and-egg problem: we can't sign domains without codepoints for hash and signature algorithms, we can't get the codepoints without RFC. I have an implementation in my private fork of LDNS, BTW. -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: I-D Action: draft-ietf-dnsop-rfc5933-bis-07.txt
Dear colleagues, The updated version of the document is uploaded. Difference with the previous version is a description of changes from RFC 5933. Thanks to Stephane Bortzmeyer. -- Forwarded message - From: Date: Fri, Nov 12, 2021 at 8:33 PM Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5933-bis-07.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC Authors : Dmitry Belyavskiy Vasily Dolmatov Filename: draft-ietf-dnsop-rfc5933-bis-07.txt Pages : 9 Date: 2021-11-12 Abstract: This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). This document obsoletes RFC 5933 and updates RFC 8624. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5933-bis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
