Re: draft-ietf-dnsext-dnssec-gost
On 15/02/2010 7:43 PM, Olafur Gudmundsson wrote: On 15/02/2010 6:37 PM, Martin Rex wrote: Mark Andrews wrote: In message201002151420.o1fekcmx024...@fs4113.wdf.sap.corp, Martin Rex writes : OK, I'm sorry. For the DNSsec GOST signature I-D, the default/prefered (?) parameter sets are explicitly listed in last paragraph of section 2 of draft-ietf-dnsext-dnssec-gost-06. However, it does _NOT_ say what to do if GOST R34.10-2001 signatures with other parameter sets are encountered. Since each end adds the parameters and they are NOT transmitted this can never happen. If one end was to change the parameters then nothing would validate. OK. I didn't know anything abouth DNSSEC when I entered the disussion... Having scanned some of the available document (rfc-4034,rfc-4035,rfc-2536 and the expired I-D draft-ietf-dnsext-ecc-key-10.txt) I'm wondering about the following: - the DNS security algorithm tag ought to be GOST R34.10-2001 and not just GOST This is a good point, adding a version label is a possiblity in this case or just in the future cases, but I think slapping one on this is fine. - DSA and the expired ECC draft spell out the entire algorithm parameters in the key RRs, which preclues having to assign additional algorithm identifiers if a necessity comes up to use different algorithm parameters. DSA did not cover the case if the key is 1024 bit. ECC draft was killed due to the fact it was impossible to guarantee that a implementation supporting ECC would be able to handle all the possible curves that the proposal allowed. Wouldn't it be sensible to do the same for GOST R34.10-2001 keys -- i.e. list the parameter set as part of the public key data? Given the procedure of the standardization body that defines GOST the parameter set OID could be used in alternative to spelling out each of the element in the parameter set in full. Implying the paramter set A for the GOST R34.10-2001 algorithm does not seem very agile, given the limited number range for the algorithm field in DNS security. For interoperability reasons we WANT MINIMAL flexibility for implementors/users. Thus we stripped all that out and picked ONE possible GOST/2001 curve. Given the differences between -1994 and -2001 versions, any successor GOST R34.10-201X standard may not be able to reuse the DNSKEY record anyway and need a new algorithm identifier. And at that point, an unqualified label GOST would become ambiguous. see above, Olafur (document shepeard) Martin, Based on your comments and the possible confusion over registering the memonic GOST for DNSSEC, I think it would be wise to change the DNSKEY Memonic to ECC-GOST. Olafur (document shepeard) PS: orignally we registered RSA for RSA/MD5 combination, then we got RSASHA1, RSASH256, RSASHA1NSEC3 .., thus the first registered should not get a special shoter name than later variants :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost [Was: Re: IAB statement on the RPKI. ]
Martin, (Apparently, the subject lines have been messed up entirely on this list these days. I tried to return to the actual subject, GOST signatures for DNSSEC.) I fear you are in danger of drawing the wrong conclusions based on incomplete information. (1) non-protocol issues ... that Zones can carry both, a mandatory to implement signature (algorithm) and interoperable world-wide, and one that might be prefered in particular regions (or legislations) and can be evaluated in those areas by those who care (or which are obliged to care). If I understand correctly, the basic issue of those under GOST-related regulatory restrictions is that they are legally constrained to MUST NOT use other algorithms than GOST to produce digital signatures. That makes your smart proposal moot, AFAICS. :-( I have no idea whether or not geo-diversity of secondary servers and/or anycast server instances providing signatures with a generally accepted signature algorithm on the same zone content could be an option ... -- routing might do the right thing, and the necessary details for the root could be worked out ... (2) protocol issues (are signatures and DNS KEYs in DNSsec really designed to be highlanders, i.e. there can only be one?) No, DNSSEC can use and carry multiple signatures. That's necessary for rekeying and algorithm agility (phased introduction of new signature algorithms) anyway. The drawbacks are twofold: - The protocol does not allow the clients to select what they would like to get; they only can set a flag to say I do understand DNSSEC, please send the DNSSEC records you have with the answer. So the authority or cache needs to send all signatures to every DNSSEC-aware client. - Keys and signatures add significantly to the size of DNS responses, and there (still) are lots of obstacles out there in the wild to proper use the protocol mechanisms standardized long ago to cope with responses longer than 512 octets: EDNS, and DNS transport over TCP. Too many network elements raise sad hurdles, and IP fragmentation is a minefield. Thus, widespread practice of regular double- (or triple-)signing of DNS RRsets would most likely increase the order of magnitude of failures to receive answers that lead to DNSSEC-verifiable results. Hard luck. Sigh! Kind regards, Alfred Hönes. -- +++ | 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 | +++ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Martin Rex пишет: What I don't understand is whether the deprecation applies to GOST R34.10-1994 in general, Yes. or only to GOST R34.10-1994 as a signature algorithm. No. I am somewhat illiterate to crypto math, so I'm wondering whether it is technicall possible to use a GOST R34.10-1994 key agreement (ephemeral keys) in conjunction with GOST R34.10-2001 certssignatures, Never ever interested. ;) and if yes -- whether that is still permitted by russian authorities. No. I should correct myself, the check against relevant documentation showed that it was more prolonged grace period allowed by authorities. The usage of GOST R 34.10-94 is fully prohibited starting 1 of January 2008. With one exception: it is allowed to check signatures under already signed archived documents using this algorithm. As for TLS, using GOST R 34.10-94, this is fully non-compliant to Russian standards and should not be used. Definitely, noone can be obliged to follow this outside the Russia or when using crypto in home environment or something of the kind. Nevertheless, I would consider following this as a strong guideline because of two thoughts: - first of all, I think there was some reason for creating and putting into operation of new standard, spending a lot on its preparation and transition to it (consider GOST 28147-89, which is active for 20 years) - no certified software/hardware will support deprecated algorithm, so there definitely will interoperability problems. I would like to return to topic, which concerns with the document describing the DNSSec extension with GOST algoritm. This document quotes RFC4357 as a reference to the used parameter set. Nothing more. This document uses the only valid set of GOST algorithms for the purpose of usage in the DNSSec . In this document no TLS is used, no key agreement procedures are used, etc. dol@ new topic I think that the representation of GOST algorithms in IETF is relatively poor now. There should be several other documents which makes the structure and usage of these algorithms more clear for those who will be willing to implement it and for those who suddenly found it been implemented in his/her software/hardware already. This work has been already started from publication of standards' translation to English as Informational RFCs to have some basiv reference point. Then, there should be other document, describing implementation of GOST algorithm in detail in the manner to which IETF community is used to (The style of Russian standards is really hard for comprehension). There will be a lot of issues (defining scopes, fixing parameter sets, setting OIDs, ensuring non-controversity with existing implementations, etc.) which have to be solved when preparing this document, some of them were quoted in different GOST-relevant discussions. All of these comments are carefully collected and I hope will help a lot when preparing this document. dol@ -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
No hat. On Tue, Feb 16, 2010 at 01:18:48PM +0300, Basil Dolmatov wrote: Martin Rex пишет: I am somewhat illiterate to crypto math, so I'm wondering whether it is technicall possible to use a GOST R34.10-1994 key agreement (ephemeral keys) in conjunction with GOST R34.10-2001 certssignatures, Never ever interested. ;) To address Martin Rex's point, however, we would not need to know whether the draft's editors were ever interested, but whether it is technically possible. This seems like a good (and so far unanswered) question. The usage of GOST R 34.10-94 is fully prohibited starting 1 of January 2008. Certainly, this prohibition is irrelevant. We are not offering technical interoperation documents _for a particular legal framework_, but technical interoperation documents _for the Internet_. The documents must therefore assume that, if someone can come up with a bad idea that is nevertheless consistent with the document in question, someone will. (If you doubt this, please examine the Internet -- pretty much any part of it you like -- more carefully.) So I think Martin's question is appropriate, and his suggestion up-thread to be a good one. The more specific the document can be made, the better for all concerned. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Andrew Sullivan wrote:
On Tue, Feb 16, 2010 at 01:18:48PM +0300, Basil Dolmatov wrote:
Martin Rex пиÑеÑ:
I am somewhat illiterate to crypto math, so I'm wondering whether
it is technicall possible to use a GOST R34.10-1994 key agreement
(ephemeral keys) in conjunction with GOST R34.10-2001 certssignatures,
Never ever interested. ;)
To address Martin Rex's point, however, we would not need to know
whether the draft's editors were ever interested, but whether it is
technically possible. This seems like a good (and so far unanswered)
question.
I'm sorry for the confusion and off-topic that I created in the discussion.
The dnssec-gost document appears to be OK in being very explicit and
constrained in its usage of GOST, requiring the GOST R34.10-2001
signature algorithm and implying a single parameter set (A) for
the signatures.
The deprecated GOST R34.10-1994 algorithm is a non-issue for dnssec-gost.
Ensuring that no reference to GOST signatures is without R34.10-2001
qualifier in the document should be sufficient to prevent any potential
confusion.
The use of GOST R34.11 for the hash algorithm should probably also be
changed to include the year GOST R34.11 to prevent confusion with
any future hash algorithms in the GOST R34.11 series.
Mandating a particular parameter set for an ECC crypto algorithm
is perfectly OK for interop. Whether or not to include
a parameter set identifier in the DNS KEY RR is up to the DNSext
working group (Implementations of GOST are likely to know
all three GOST R34.10-2001 parameter sets listed in rfc-4357).
The byte order of GOST-related values seems to be confusing:
http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-gost-06#section-3
Quoting RFC 4490:
The signature algorithm GOST R 34.10-2001 generates a digital
signature in the form of two 256-bit numbers, r and s. Its octet
string representation consists of 64 octets, where the first 32
octets contain the big-endian representation of s and the second 32
octets contain the big-endian representation of r.
http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-gost-06#section-4
4. DS Resource Records
GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest
type {TBA2}.The wire format of a digest value is compatible with
RFC4490 [RFC4490], that is digest is in little-endian representation.
Since there are already RFCs out there using GOST (CMS) and there
are implementations based on drafts (TLS) and maybe some under
evaluation (XMLsec) it seems a little late to ask for pure
ordering at this point in time. Re-using the format/ordering
that is used in existing documents/protocols and implementations
appear to be OK to _me_. IETF protocols provide more flexibility
at this point than e.g. ASN.1. To me, it looks like there is
a little mess in GOST byte ordering in various usage scenarios,
so _I_ would not expect interop without interop testing, no matter
what ordering DNSsec defines. :-/
I really appreciate the mentioning of key and hash sizes in the
dnssec-gost document in section 5, because one can not easily
look it up in rfc-4357. (It's in there, but not easy to determine).
-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
All, hHere are at least 2 issues under discussion within this thread. I'd like to address them separately, but in the same note. (1) Quality of GOST specification While I'm very happy to see any algorithm publicly documented in an I-D or RFC, I agree with Martin Rex that the current RFC-4357 on GOST 3410-2001 is not sufficiently clear and complete to easily lead to entirely-independent interoperable implementations. It ought to be possible for a non-Russian, non-certified, implementation to interoperate with any other implementation of the same algorithm -- from an implementer reading the RFC alone. Martin Rex's notes to the IETF list: A) http://www.ietf.org/mail-archive/web/ietf/current/msg60250.html B) http://www.ietf.org/mail-archive/web/ietf/current/msg60253.html I share Martin Rex's desire for some clarifications to that fundamental document, and I also share his concern that the RFC specifying GOST does not specify what an implementation ought to do when it encounters signatures with other parameter sets. Such a revision ought to make more clear, perhaps in Security Considerations as Martin Rex earlier suggested, that GOST-3410-2001 is entirely separate from GOST 3410-94. That fact is NOT obvious from reading RFC-4357 and is quite relevant to implementers (of either version) of GOST 3410. In that revision to RFC-4357, I'd love to see an Appendix with some test vectors for GOST, as well. Documenting a wide range of suitable test vectors can be extremely helpful in verifying that a particular implementation of some algorithm is operating correctly, which in turn is fundamental to protocol interoperability. (RFC-4231 provides an example of test vectors for some other openly specified algorithms.) (2) DNSsec use of GOST specification For the several reasons various folks have already expressed on the IETF list, and also for the reasons above in (1), I share the view that GOST should be MAY rather than SHOULD for use in DNS Security. Yours, R. Atkinson ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Perhaps it would help elucidate matters if we knew the precise criteria In particular, is the requirement to support Gost or is it that all the algs used be approved If the second case 1) what would be the root zone criteria and 2) would these regulation issues disappear if the root zone were differently managed? Sent from my iPhone On Feb 15, 2010, at 10:09 AM, Rex, Martin martin@sap.com wrote: -Original Message- This document: http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08 says section 1.1: 4. GOST R 34.10-2001 replaces GOST R 34.10-94. section 1,2: GOST R 34.10-2001 is developed to replace GOST R 34.10-94. Both statement are right. :-) Both statements are completely useless. AES is a replacement/successor to DES. SHA-2 is a replacement to SHA-1. So what? Getting rfc-4357 published without the slightest indication that the acceptibility of GOST R34.10-1994 had already expired 2 years before is a serious problem in that document. What really confuses me is that software that there are GOST toolkits shipped even today that support GOST R34.10-1994. OpenSSL also contains an implementation of GOST R34.10-1994 and the GOST TLS ciphersuites draft also contains a ciphersuite with a GOST R34.10-1994 signaturer algorithm. In effect, whether and how much GOST R34.10-1994 is deprecated remains a complete mystery. 2. GOST R 34.10-2001 was accepted and activated by the Act 380-st of 12.09.2001 issued by the Russian federal committee for standards. ... 4. GOST R 34.10-2001 replaces GOST R 34.10-94. So, GOST -1994 for digital signature _is_ deprecated and replaced from 12.09.2001. The transition period is not stated explicitly because it is obvious from standard procedure of certification in Russia. I would like to remind you that we are the IETF here, and that implementations of DNS-SEC must remain possible without an official certification in Russia. DNS-SEC would not make much sense if it could not be used by implementations that are _not_ certified in Russia. That information OUGHT to have been added to rfc-4357 and it ought to be added to draft-dolmatov-cryptocom-gost34102001-08. Why? Now is 2010, and all implementations of -1994 standard have been completely phased out more than 5 years ago. There seems to be a disagreement between this statement and reality. The GOST crypto toolkit shipped by the Company CryptoPro (author behind rfc-4357 and draft-chudov-cryptopro-cptls-04) still implements GOST R34.10-1994, and both documents list GOST R34.10-1994 in a fashion that does _NOT_ suggest that this algorithm may no longer be used. The GOST implementation in OpenSSL, provided by a different russian company, also implements/provides GOST R34.10-1994. This statement was inserted following the advice of Russ Housley. The main reason for that was that this text is a _translation_ of the text of official Russian state standard. At the moment of its creation this text was thoroughly checked with authors of original standard for consistency. Any editorial changes/corrections could diverge the translation from the original, which is undesirable. I agreed with this Russ's reasoning. I agree to the intent. The words that were used are very inadequate and misleading. This is not the first RFC that represents a republication of a standard controlled by a different standardization body or private entity. Just use something like your explanation instead, and it will likely have the desired effect on the comments you receive for this document. Random other example for how other RFCs have done this: RFC-2986 (PKCS-10) http://tools.ietf.org/html/rfc2986 Abstract This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. I do understand that the structure and the style of these documents are unfamiliar to the significant part of community, but this is because of the fact it is _a_translation_ of official standard text. It is not a retelliing or compilation, it is a _translation_. And it is intended to exist as a reference to the origin, when creating further IETF documents, which will be pure IETF documents and will be commented and edited when necessary. A republication only makes sense if it is sufficient to understand and implement the technology. If you respond to a request for clarification with because it is obvious from standard procedure of certification in Russia. then there may be a significant misunderstanding about the purpose of informational RFC documents. That only makes sense if it is sufficiently complete and clear to allow for independent interoperable implementations of IETF
Re: draft-ietf-dnsext-dnssec-gost
One point that seems to be ambiguous here is what the role of an rfc is with respect to defacto standards status In theory informational rfc do not establish or modify standards. In practice the broken process that stops anything being a standard and makes those we do have obsolete means that this is not obvious In my view a should or must in an informational rfc only has scope to the document itself. So the gost draft should use MUST or Should in my view But I can see how this could confuse Sent from my iPhone On Feb 15, 2010, at 9:52 AM, Spencer Dawkins spen...@wonderhamster.org wrote: On one point in this discussion... I'm not saying that everyone will SEE it, but there actually is an errata process for RFCs, and the omission of the year-version suffix in RFC 4357 seems like something that would be really helpful to submit an errata for. Submission page is at http://www.rfc-editor.org/errata.php. The errata link does show up on many hyperlinked versions of RFCs, so things aren't as bleak as they were ten years ago, to pick an interval. Thanks, Spencer - Original Message - From: Martin Rex m...@sap.com To: Basil Dolmatov d...@cryptocom.ru Cc: ietf@ietf.org Sent: Monday, February 15, 2010 8:20 AM Subject: Re: draft-ietf-dnsext-dnssec-gost IMHO, rfc4357 should have been completely stripped from GOST R34.10-1994 before publication if what you describes really applies to this algorithm. I think that is a question to authors of RFC4357 and I think that corrections should be issued. There is no correction process for RFCs. Preferably the new document about GOST R34.10 signature algorithms should be merged with rfc4357 into rfc4357bis, and this time the GOST R34.10-1994 algorithm should only be mentioned in the Security Considerations as having been completely retired/phased out in 2004. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
On 15/02/2010 7:43 PM, Olafur Gudmundsson wrote: On 15/02/2010 6:37 PM, Martin Rex wrote: Mark Andrews wrote: In message201002151420.o1fekcmx024...@fs4113.wdf.sap.corp, Martin Rex writes : OK, I'm sorry. For the DNSsec GOST signature I-D, the default/prefered (?) parameter sets are explicitly listed in last paragraph of section 2 of draft-ietf-dnsext-dnssec-gost-06. However, it does _NOT_ say what to do if GOST R34.10-2001 signatures with other parameter sets are encountered. Since each end adds the parameters and they are NOT transmitted this can never happen. If one end was to change the parameters then nothing would validate. OK. I didn't know anything abouth DNSSEC when I entered the disussion... Having scanned some of the available document (rfc-4034,rfc-4035,rfc-2536 and the expired I-D draft-ietf-dnsext-ecc-key-10.txt) I'm wondering about the following: - the DNS security algorithm tag ought to be GOST R34.10-2001 and not just GOST This is a good point, adding a version label is a possiblity in this case or just in the future cases, but I think slapping one on this is fine. - DSA and the expired ECC draft spell out the entire algorithm parameters in the key RRs, which preclues having to assign additional algorithm identifiers if a necessity comes up to use different algorithm parameters. DSA did not cover the case if the key is 1024 bit. ECC draft was killed due to the fact it was impossible to guarantee that a implementation supporting ECC would be able to handle all the possible curves that the proposal allowed. To clarify ECC draft killed == draft-ietf-dnsext-ecc-key Olafur ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost [Was: Re: IAB statement on the RPKI. ]
Alfred =?hp-roman8?B?SM5uZXM=?= wrote: (Apparently, the subject lines have been messed up entirely on this list these days. I tried to return to the actual subject, GOST signatures for DNSSEC.) I fear you are in danger of drawing the wrong conclusions based on incomplete information. (1) non-protocol issues ... that Zones can carry both, a mandatory to implement signature (algorithm) and interoperable world-wide, and one that might be prefered in particular regions (or legislations) and can be evaluated in those areas by those who care (or which are obliged to care). If I understand correctly, the basic issue of those under GOST-related regulatory restrictions is that they are legally constrained to MUST NOT use other algorithms than GOST to produce digital signatures. That makes your smart proposal moot, AFAICS. :-( But they don't need to create digital signatures! They only need to provide RRSIG RRs with MACs that the rest of the world can use to perform integrity checks and data origin authentication based on a common asymmetric crypto algorithm for the purpose of interoperability when validating DNS records. None of registries in Russia needs to provide official digital signatures (in any legally binding sense) in order to make DNSsec work at the technical level. The GOST-signed RRSIG RRs can be the officially signed records, the other is just a provision for technical interop of the MAC scheme with DNSsec for the rest of the internet. Any other approach just doesn't scale. IIRC, IPsec decided somewhere around 1995 that sacrificing interop to accomodate crypto export regulation was a dead-end road and not appropriate for an international standardization body. Although, I might have missed that the IETF reverted its attitude and is today catering everone and his dog's personal crypto preferences in their protocols, dropping the burden on the implementors of the technology, I think it would be the wrong approach. What is the situation in IPsec with regards to GOST these days? (2) protocol issues (are signatures and DNS KEYs in DNSsec really designed to be highlanders, i.e. there can only be one?) No, DNSSEC can use and carry multiple signatures. That's necessary for rekeying and algorithm agility (phased introduction of new signature algorithms) anyway. That's what I assumed (and I found it in rfc-4033 3.1). The drawbacks are twofold: - The protocol does not allow the clients to select what they would like to get; they only can set a flag to say I do understand DNSSEC, please send the DNSSEC records you have with the answer. So the authority or cache needs to send all signatures to every DNSSEC-aware client. That looks like a defect in the protocol. - Keys and signatures add significantly to the size of DNS responses, and there (still) are lots of obstacles out there in the wild to proper use the protocol mechanisms standardized long ago to cope with responses longer than 512 octets: EDNS, and DNS transport over TCP. Too many network elements raise sad hurdles, and IP fragmentation is a minefield. Thus, widespread practice of regular double- (or triple-)signing of DNS RRsets would most likely increase the order of magnitude of failures to receive answers that lead to DNSSEC-verifiable results. Hard luck. Sigh! Probably the biggest mistake in DNSsec was to describe the data that is used to verify RRs as digital signatures instead of simply MACs based on asymmetric crypto algorithms. All of the politics and flawed assumptions around PKI have prevented the existing DNS registries to add RRSIGs to their zones many many years ago -- which otherwise would have helped to iron out the problems around the size of the DNS responses over the last decade. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Basil Dolmatov wrote: Martin Rex пиÑеÑ: I'm still quite confused. All references to GOST signature algorithms of the kind [GOST3410] ought to be fixed to say [GOST3410-2001]. I think that can de done, despite the fact that there is no other algorithm coded as GOST 3410, except GOST 34.10-2001. The problem is that there are IETF documents like rfc-4357 and like the (currently expired) GOST TLS ciphersuites draft that still list GOST R34.10-1994 as a valid algorithm. It seems it mixed up the (deprecated) signature Algorithm GOST R34.10-1994 and the hash/digest algorith GOST R34.11-1994 that is still being used for signatures with GOST R34.10-2001. It seems that no mixture takes place. Signature standard has number 34.10, hash standard has number 34.11. I cannot see how they can be mixed up. I'm sorry for the typo. I meant to say that *I* mixed them up because of their inconsistent naming throughout the GOST-related documents that have been publshed as I-Ds and RFC. That comes mainly from the goof-up in rfc4357 that leaves out the -1994 appendix to the hash algorithm in the section header/contents and tag name. IMHO, rfc4357 should have been completely stripped from GOST R34.10-1994 before publication if what you describes really applies to this algorithm. I think that is a question to authors of RFC4357 and I think that corrections should be issued. There is no correction process for RFCs. Preferably the new document about GOST R34.10 signature algorithms should be merged with rfc4357 into rfc4357bis, and this time the GOST R34.10-1994 algorithm should only be mentioned in the Security Considerations as having been completely retired/phased out in 2004. Which is not really helpful. Any specification referencing rfc-4357 will now have to declare which kind of parameter sets (as defined in rfc-4357) should be used/accepted for which purpose and which parameter set is the default. Yes. And this is done in the draft text. Read it. OK, I'm sorry. For the DNSsec GOST signature I-D, the default/prefered (?) parameter sets are explicitly listed in last paragraph of section 2 of draft-ietf-dnsext-dnssec-gost-06. However, it does _NOT_ say what to do if GOST R34.10-2001 signatures with other parameter sets are encountered. I was confused by the I-D about the GOST R34.10-2001 digital signature algorithm, where the possible parameters sets and their meaning are specified to be pretty unspecified (page 7): GOST R 34.10-2001 does not determine the process of generating parameters needed for digital signature scheme. Possible sets of these parameters are defined for example in [RFC4357]. Document - draft-ietf-dnsext-dnssec-gost-06 does not use any test parameters from RFC 4357 and does not reference any of them. The dnssec document references rfc4357 for the definition of the parameter sets, but fails to define what to do if signatures with other parameter sets than the default/preferred one are received. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
At 2:18 PM -0500 2/12/10, Edward Lewis wrote: At 10:57 -0500 2/12/10, Stephen Kent wrote: If we look at what the CP developed in the SIDR WG for the RPKI says, the answer is the IESG (going forward, after an initial set of algs are adopted based on the SIDR WG process). In the IPSEC, TLS, and SMIME contexts, the WGs themselves have made the decisions, which the IESG then approves by virtue of the usual standards track RFC approval process. I do not believe that the criteria have been documented uniformly across these WGs. What is CP? Sorry for the acronym ambiguity. the CP is the certificate policy (for the RPKI). Every major PKI has a CP. These documents follow the outline provided in RFC 3647. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
At 8:50 AM -0800 2/12/10, David Conrad wrote: On Feb 12, 2010, at 7:57 AM, Stephen Kent wrote: Who gets to decide on what algorithms get first class status and based on what criteria? If we look at what the CP developed in the SIDR WG for the RPKI says, the answer is the IESG So, they're going to flip a coin or what? Who is largely irrelevant. The criteria is the interesting bit. Both issues are relevant. Most of the other WGs dealing with this issue have been in the secruity area and feel comfortable making these decisions. The IESG has been comfortable with their decisions. Note that change have been made, for other than technical reasons, e.g., initially TLS had DH 7 DSA as MUST and RSA as SHOULD, because of patent issues. When the RSA patent expired, the roles were reversed. So the IESG has been an active participant in these decisions in the past. Steve brought up national algorithm, but we have also personal algorithms such as curve25519 or threefish. WGs like IPsec, TLS, and SMIME have been able to say no to personal algs for a long time. IPsec, TLS, and SMIME are all one-to-one. DNSSEC (in this context) is one-to-many. Your observation is applicable to IPsec, not to S/MIME, and, for practical purposes, not for TLS. An S/MIME message may be sent to multiple recipients, so it is not literally one-to-one. S/MIME accommodates algorithm diversity best for the public key algorithms used to encrypt the content encryption key. It also can accommodate diversity for the algorithm used to sign the message, but at a higher cost. It does poorly if different recipients make use of different content encryption algorithms. TLS is nominally 1-1, but in reality, the vast majority of TLS use is for access to web sites that have a very diverse set of clients. That requires a small set of mandatory algorithms, to ensure interoperability. Finally, the question posed was about how have decisions on which algorithms are mandatory to implement have been decided in the IETF in the past. My reply addressed that question. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-ietf-dnsext-dnssec-gost
-Original Message- This document: http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08 says section 1.1: 4. GOST R 34.10-2001 replaces GOST R 34.10-94. section 1,2: GOST R 34.10-2001 is developed to replace GOST R 34.10-94. Both statement are right. :-) Both statements are completely useless. AES is a replacement/successor to DES. SHA-2 is a replacement to SHA-1. So what? Getting rfc-4357 published without the slightest indication that the acceptibility of GOST R34.10-1994 had already expired 2 years before is a serious problem in that document. What really confuses me is that software that there are GOST toolkits shipped even today that support GOST R34.10-1994. OpenSSL also contains an implementation of GOST R34.10-1994 and the GOST TLS ciphersuites draft also contains a ciphersuite with a GOST R34.10-1994 signaturer algorithm. In effect, whether and how much GOST R34.10-1994 is deprecated remains a complete mystery. 2. GOST R 34.10-2001 was accepted and activated by the Act 380-st of 12.09.2001 issued by the Russian federal committee for standards. ... 4. GOST R 34.10-2001 replaces GOST R 34.10-94. So, GOST -1994 for digital signature _is_ deprecated and replaced from 12.09.2001. The transition period is not stated explicitly because it is obvious from standard procedure of certification in Russia. I would like to remind you that we are the IETF here, and that implementations of DNS-SEC must remain possible without an official certification in Russia. DNS-SEC would not make much sense if it could not be used by implementations that are _not_ certified in Russia. That information OUGHT to have been added to rfc-4357 and it ought to be added to draft-dolmatov-cryptocom-gost34102001-08. Why? Now is 2010, and all implementations of -1994 standard have been completely phased out more than 5 years ago. There seems to be a disagreement between this statement and reality. The GOST crypto toolkit shipped by the Company CryptoPro (author behind rfc-4357 and draft-chudov-cryptopro-cptls-04) still implements GOST R34.10-1994, and both documents list GOST R34.10-1994 in a fashion that does _NOT_ suggest that this algorithm may no longer be used. The GOST implementation in OpenSSL, provided by a different russian company, also implements/provides GOST R34.10-1994. This statement was inserted following the advice of Russ Housley. The main reason for that was that this text is a _translation_ of the text of official Russian state standard. At the moment of its creation this text was thoroughly checked with authors of original standard for consistency. Any editorial changes/corrections could diverge the translation from the original, which is undesirable. I agreed with this Russ's reasoning. I agree to the intent. The words that were used are very inadequate and misleading. This is not the first RFC that represents a republication of a standard controlled by a different standardization body or private entity. Just use something like your explanation instead, and it will likely have the desired effect on the comments you receive for this document. Random other example for how other RFCs have done this: RFC-2986 (PKCS-10) http://tools.ietf.org/html/rfc2986 Abstract This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. I do understand that the structure and the style of these documents are unfamiliar to the significant part of community, but this is because of the fact it is _a_translation_ of official standard text. It is not a retelliing or compilation, it is a _translation_. And it is intended to exist as a reference to the origin, when creating further IETF documents, which will be pure IETF documents and will be commented and edited when necessary. A republication only makes sense if it is sufficient to understand and implement the technology. If you respond to a request for clarification with because it is obvious from standard procedure of certification in Russia. then there may be a significant misunderstanding about the purpose of informational RFC documents. That only makes sense if it is sufficiently complete and clear to allow for independent interoperable implementations of IETF protocols. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
On one point in this discussion... I'm not saying that everyone will SEE it, but there actually is an errata process for RFCs, and the omission of the year-version suffix in RFC 4357 seems like something that would be really helpful to submit an errata for. Submission page is at http://www.rfc-editor.org/errata.php. The errata link does show up on many hyperlinked versions of RFCs, so things aren't as bleak as they were ten years ago, to pick an interval. Thanks, Spencer - Original Message - From: Martin Rex m...@sap.com To: Basil Dolmatov d...@cryptocom.ru Cc: ietf@ietf.org Sent: Monday, February 15, 2010 8:20 AM Subject: Re: draft-ietf-dnsext-dnssec-gost IMHO, rfc4357 should have been completely stripped from GOST R34.10-1994 before publication if what you describes really applies to this algorithm. I think that is a question to authors of RFC4357 and I think that corrections should be issued. There is no correction process for RFCs. Preferably the new document about GOST R34.10 signature algorithms should be merged with rfc4357 into rfc4357bis, and this time the GOST R34.10-1994 algorithm should only be mentioned in the Security Considerations as having been completely retired/phased out in 2004. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Basil Dolmatov wrote: Martin Rex пиÑеÑ: I'm still quite confused. All references to GOST signature algorithms of the kind [GOST3410] ought to be fixed to say [GOST3410-2001]. I think that can de done, despite the fact that there is no other algorithm coded as GOST 3410, except GOST 34.10-2001. Slightly OT: There some more confusing aspect abouth GOST R34.10- The math behind GOST bears some similarities with Diffie Helman (DH). RFC-4357 describes VKO GOST R34.10-94 and VKO GOST R34.10-2001 under a section called Key Derivation Algorithms, and defines parameter sets for these algorithms. To me, it looks like the GOST algorithms in RFC4357 would be better described as Key agreement instead of Key Derivation algorithms (consistent with the X.509v3 use of the terminology). In detail, the key exchange algorithm for GOST in TLS seems to significantly differ from DH key agreement. What I don't understand is whether the deprecation applies to GOST R34.10-1994 in general, or only to GOST R34.10-1994 as a signature algorithm. I am somewhat illiterate to crypto math, so I'm wondering whether it is technicall possible to use a GOST R34.10-1994 key agreement (ephemeral keys) in conjunction with GOST R34.10-2001 certssignatures, and if yes -- whether that is still permitted by russian authorities. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
In message 201002151420.o1fekcmx024...@fs4113.wdf.sap.corp, Martin Rex writes : OK, I'm sorry. For the DNSsec GOST signature I-D, the default/prefered (?) parameter sets are explicitly listed in last paragraph of section 2 of draft-ietf-dnsext-dnssec-gost-06. However, it does _NOT_ say what to do if GOST R34.10-2001 signatures with other parameter sets are encountered. Since each end adds the parameters and they are NOT transmitted this can never happen. If one end was to change the parameters then nothing would validate. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Mark Andrews wrote: In message 201002151420.o1fekcmx024...@fs4113.wdf.sap.corp, Martin Rex writes : OK, I'm sorry. For the DNSsec GOST signature I-D, the default/prefered (?) parameter sets are explicitly listed in last paragraph of section 2 of draft-ietf-dnsext-dnssec-gost-06. However, it does _NOT_ say what to do if GOST R34.10-2001 signatures with other parameter sets are encountered. Since each end adds the parameters and they are NOT transmitted this can never happen. If one end was to change the parameters then nothing would validate. OK. I didn't know anything abouth DNSSEC when I entered the disussion... Having scanned some of the available document (rfc-4034,rfc-4035,rfc-2536 and the expired I-D draft-ietf-dnsext-ecc-key-10.txt) I'm wondering about the following: - the DNS security algorithm tag ought to be GOST R34.10-2001 and not just GOST - DSA and the expired ECC draft spell out the entire algorithm parameters in the key RRs, which preclues having to assign additional algorithm identifiers if a necessity comes up to use different algorithm parameters. Wouldn't it be sensible to do the same for GOST R34.10-2001 keys -- i.e. list the parameter set as part of the public key data? Given the procedure of the standardization body that defines GOST the parameter set OID could be used in alternative to spelling out each of the element in the parameter set in full. Implying the paramter set A for the GOST R34.10-2001 algorithm does not seem very agile, given the limited number range for the algorithm field in DNS security. Given the differences between -1994 and -2001 versions, any successor GOST R34.10-201X standard may not be able to reuse the DNSKEY record anyway and need a new algorithm identifier. And at that point, an unqualified label GOST would become ambiguous. As previously mentioned, current uses of GOST R34.11 should be changed to GOST R34.11-1994 as well (prevent ambiguity with a future/updated hash algorithm for GOST). -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
On 15/02/2010 6:37 PM, Martin Rex wrote: Mark Andrews wrote: In message201002151420.o1fekcmx024...@fs4113.wdf.sap.corp, Martin Rex writes : OK, I'm sorry. For the DNSsec GOST signature I-D, the default/prefered (?) parameter sets are explicitly listed in last paragraph of section 2 of draft-ietf-dnsext-dnssec-gost-06. However, it does _NOT_ say what to do if GOST R34.10-2001 signatures with other parameter sets are encountered. Since each end adds the parameters and they are NOT transmitted this can never happen. If one end was to change the parameters then nothing would validate. OK. I didn't know anything abouth DNSSEC when I entered the disussion... Having scanned some of the available document (rfc-4034,rfc-4035,rfc-2536 and the expired I-D draft-ietf-dnsext-ecc-key-10.txt) I'm wondering about the following: - the DNS security algorithm tag ought to be GOST R34.10-2001 and not just GOST This is a good point, adding a version label is a possiblity in this case or just in the future cases, but I think slapping one on this is fine. - DSA and the expired ECC draft spell out the entire algorithm parameters in the key RRs, which preclues having to assign additional algorithm identifiers if a necessity comes up to use different algorithm parameters. DSA did not cover the case if the key is 1024 bit. ECC draft was killed due to the fact it was impossible to guarantee that a implementation supporting ECC would be able to handle all the possible curves that the proposal allowed. Wouldn't it be sensible to do the same for GOST R34.10-2001 keys -- i.e. list the parameter set as part of the public key data? Given the procedure of the standardization body that defines GOST the parameter set OID could be used in alternative to spelling out each of the element in the parameter set in full. Implying the paramter set A for the GOST R34.10-2001 algorithm does not seem very agile, given the limited number range for the algorithm field in DNS security. For interoperability reasons we WANT MINIMAL flexibility for implementors/users. Thus we stripped all that out and picked ONE possible GOST/2001 curve. Given the differences between -1994 and -2001 versions, any successor GOST R34.10-201X standard may not be able to reuse the DNSKEY record anyway and need a new algorithm identifier. And at that point, an unqualified label GOST would become ambiguous. see above, Olafur (document shepeard) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Martin Rex : Basil Dolmatov wrote: Martin Rex : Whether and how much the -1994 version is deprecated is also a complete mystery. It is written in the text of GOST -2001 Which document are you refering to when you say "text of GOST -2001" ? This document: http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08 says section 1.1: 4. GOST R 34.10-2001 replaces GOST R 34.10-94. section 1,2: GOST R 34.10-2001 is developed to replace GOST R 34.10-94. Both statement are right. 2. GOST R 34.10-2001 was accepted and activated by the Act 380-st of 12.09.2001 issued by the Russian federal committee for standards. ... 4. GOST R 34.10-2001 replaces GOST R 34.10-94. So, GOST -1994 for digital signature _is_ deprecated and replaced from 12.09.2001. The transition period is not stated explicitly because it is obvious from standard procedure of certification in Russia. No certificate can be issued for any hardware/software using -1994 algorithm after 12.09.2001 and the certification period is 3 years. So, after 12.09.2004 there can be no operating hardware/software using -1994 algorithm. That information OUGHT to have been added to rfc-4357 and it ought to be added to draft-dolmatov-cryptocom-gost34102001-08. Why? Now is 2010, and all implementations of -1994 standard have been completely phased out more than 5 years ago. I just found the following paragraph in the Copyright Notice of http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08 on the title page which irritates me: This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English. Is there a new trend to have the IETF rubber stamp documents as is? To me, this statement precludes editorial changes/corrections, which doesn't sound right. I boldly assumed the original name of the IETF documents "RFC" mean "Request For Comment", in the form that the community was asked for feedback (request for clarifications, correction or changes) before document was published. At least this is how I understand "The Tao of the IETF" http://tools.ietf.org/html/rfc4677#section-8.1 Although the IETF may not have "change control" for the technical contents described in informational document, a complete absence of change control of document structure, clarity, detail of explanation and editorial issues would come as a suprise to me... This statement was inserted following the advice of Russ Housley. The main reason for that was that this text is a _translation_ of the text of official Russian state standard. At the moment of its creation this text was thoroughly checked with authors of original standard for consistency. Any editorial changes/corrections could diverge the translation from the original, which is undesirable. I agreed with this Russ's reasoning. I do understand that the structure and the style of these documents are unfamiliar to the significant part of community, but this is because of the fact it is _a_translation_ of official standard text. It is not a retelliing or compilation, it is a _translation_. And it is intended to exist as a reference to the origin, when creating further IETF documents, which will be pure IETF documents and will be commented and edited when necessary. -Martin dol@ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Martin Rex пишет: I'm still quite confused. All references to GOST signature algorithms of the kind [GOST3410] ought to be fixed to say [GOST3410-2001]. I think that can de done, despite the fact that there is no other algorithm coded as GOST 3410, except GOST 34.10-2001. It seems it mixed up the (deprecated) signature Algorithm GOST R34.10-1994 and the hash/digest algorith GOST R34.11-1994 that is still being used for signatures with GOST R34.10-2001. It seems that no mixture takes place. Signature standard has number 34.10, hash standard has number 34.11. I cannot see how they can be mixed up. RFC-4357 was published in January 2006, i.e. after GOST signature algorithm R34.10-1994 algorithm was deprecated (12.09.2001) and after which is must no longer be used (12.09.2004) according to your description. The GOST TLS ciphersuite document still defines and uses the deprecated signature algorithm... IMHO, rfc4357 should have been completely stripped from GOST R34.10-1994 before publication if what you describes really applies to this algorithm. I think that is a question to authors of RFC4357 and I think that corrections should be issued. Which is not really helpful. Any specification referencing rfc-4357 will now have to declare which kind of parameter sets (as defined in rfc-4357) should be used/accepted for which purpose and which parameter set is the default. Yes. And this is done in the draft text. Read it. Corresponding public key parameters are those identified by id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357 http://tools.ietf.org/html/rfc4357], and the digest parameters are those identified by id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357 http://tools.ietf.org/html/rfc4357]. No confusions, no ambiguity. The purpose, existance and semantics of the test algorithm parameter sets are particularly confusing. Document - draft-ietf-dnsext-dnssec-gost-06 does not use any test parameters from RFC 4357 and does not reference any of them. HTH, dol@ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
I agree with Steve and others saying that MAY is appropriate for this. This looks like the right approach to me as well. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Martin Rex пишет: Admittedly, I know very little about the cryptographic details, but there are two GOST signature algorithms (GOST R34.10-1994 and GOST R34.10-2001). The earlier appears to bear some similarity with DH, the newer appears to bear similarity with ECDH. Whether and how much the -1994 version is deprecated is also a complete mystery. It is written in the text of GOST -2001 2. GOST R 34.10-2001 was accepted and activated by the Act 380-st of 12.09.2001 issued by the Russian federal committee for standards. ... 4. GOST R 34.10-2001 replaces GOST R 34.10-94. So, GOST -1994 for digital signature _is_ deprecated and replaced from 12.09.2001. The transition period is not stated explicitly because it is obvious from standard procedure of certification in Russia. No certificate can be issued for any hardware/software using -1994 algorithm after 12.09.2001 and the certification period is 3 years. So, after 12.09.2004 there can be no operating hardware/software using -1994 algorithm. Just that simple. ;) dol@ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Paul Hoffman пишет: For example, there is already a published attack on the GOST hash function that does not exist in SHA-256 and SHA-512. That attack lessens the complexity of building of the collision from 2**128 operations to 2**109 operations (infinitesimal part of overall complexity) and demands padding the meaningful message with several kilobytes of additional binary data, which is impossible for any message with fixed format. The GOST algorithms have had much less cryptographic review than other algorithms. ...have had much less _published_ cryptographic review... I would say. ;) These algorithms were thoroughly and intensively reviewed by specialists throughout the world during all years of their existence. The fact that these algorithms are used without changes for 20, 15 and 10 years respectively shows that these reviews were not successful. If that attack becomes practical, an attacker can create signatures using GOST that he/she could not create in RSA/SHA-256 or RSA/SHA-512. That attack cannot become practical and you know that as well as everyone who works with cryptography. dol@ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
I agree with Steve and others saying that MAY is appropriate for this. S. Stephen Kent wrote: I recommend that the document not be approved by the IESG in its current form. Section 6.1 states: 6.1. Support for GOST signatures DNSSEC aware implementations SHOULD be able to support RRSIG and DNSKEY resource records created with the GOST algorithms as defined in this document. There has been considerable discussion on the security area directorate list about this aspect of the document. All of the SECDIR members who participated in the discussion argued that the text in 6.1 needs to be changed to MAY from SHOULD. The general principle cited in the discussion has been that national crypto algorithms like GOST ought not be cited as MUST or SHOULD in standards like DNESEC. I refer interested individuals to the SECDIR archive for details of the discussion. (http://www.ietf.org/mail-archive/web/secdir/current/maillist.html) Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
On Fri, Feb 12, 2010 at 03:12:30PM +0300, Basil Dolmatov wrote: ...have had much less _published_ cryptographic review... I would say. ;) I am not a security expert, but I've never met one who thought that unpublished cryptographic review was worth a dime. Moreover, for the purposes of the IETF, if something isn't published it might as well not exist: we have no way of knowing one way or the other. If you mean published to a limited and vetted community of NDA-covered experts, that might yield different conclusions about the value of the review (depending I guess on how free those experts think they are to disagree). But it would have no effect on the value of those reviews for IETF purposes, which just depends on the publication (and, actually, publication in a language the community can understand). I have no feelings about the merits of the algorithm. But there are too many side issues in this discussion already without us getting into a battle of whether the review is adequate: the reviews aren't apparently available as far as this community is concerned, unfortunately, even if they've been done A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
... As a document shepeard I have made note that this is desired, but at the same time this is a topic that was outside the scope of the working group. This is on the other hand a topic that belongs in the IETF review. So my questions to the IETF (paraphrashing George Orwell) Are all crypto algorithms equal, but some are more equal than others? not all are equal, from a purely cryptanalytic perspective. Among those that may be equivalent from that perspective, there are other meaningful differences, e.g., how widely are the algs implemented and used. Who gets to decide on what algorithms get first class status and based on what criteria? If we look at what the CP developed in the SIDR WG for the RPKI says, the answer is the IESG (going forward, after an initial set of algs are adopted based on the SIDR WG process). In the IPSEC, TLS, and SMIME contexts, the WGs themselves have made the decisions, which the IESG then approves by virtue of the usual standards track RFC approval process. I do not believe that the criteria have been documented uniformly across these WGs. Steve brought up national algorithm, but we have also personal algorithms such as curve25519 or threefish. WGs like IPsec, TLS, and SMIME have been able to say no to personal algs for a long time. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Basil Dolmatov wrote: Martin Rex пиÑеÑ: Admittedly, I know very little about the cryptographic details, but there are two GOST signature algorithms (GOST R34.10-1994 and GOST R34.10-2001). The earlier appears to bear some similarity with DH, the newer appears to bear similarity with ECDH. Whether and how much the -1994 version is deprecated is also a complete mystery. It is written in the text of GOST -2001 2. GOST R 34.10-2001 was accepted and activated by the Act 380-st of 12.09.2001 issued by the Russian federal committee for standards. ... 4. GOST R 34.10-2001 replaces GOST R 34.10-94. So, GOST -1994 for digital signature _is_ deprecated and replaced from 12.09.2001. The transition period is not stated explicitly because it is obvious from standard procedure of certification in Russia. No certificate can be issued for any hardware/software using -1994 algorithm after 12.09.2001 and the certification period is 3 years. So, after 12.09.2004 there can be no operating hardware/software using -1994 algorithm. Just that simple. ;) I'm still quite confused. All references to GOST signature algorithms of the kind [GOST3410] ought to be fixed to say [GOST3410-2001]. It seems it mixed up the (deprecated) signature Algorithm GOST R34.10-1994 and the hash/digest algorith GOST R34.11-1994 that is still being used for signatures with GOST R34.10-2001. RFC-4357 was published in January 2006, i.e. after GOST signature algorithm R34.10-1994 algorithm was deprecated (12.09.2001) and after which is must no longer be used (12.09.2004) according to your description. The GOST TLS ciphersuite document still defines and uses the deprecated signature algorithm... IMHO, rfc4357 should have been completely stripped from GOST R34.10-1994 before publication if what you describes really applies to this algorithm. Unfortunately, rfc-4357 does _not_even_mention_ that GOST R34.10-1994 is deprecated and must no longer be used, and is at the same time abiguous about the name of the Hash algorithm. The table of contents and section heading call it only GOSTR3411. Regarding key size confusion of the old signature algorithm in rfc-4357: GOST R34.10-94: non givenRFC-4357 5.1. VKO GOST R 34.10-94 512 or 1024 RFC-4357 8.3. GOST R 34.10-94 Public Key Algorithm Parameters GOST R34.10-2001: 512 RFC-4357 5.2. VKO GOST R 34.10-2001 none given RFC-4357 8.4. GOST R 34.10-2001 Public Key Algorithm Parameters RFC-4357 Security Considerations says the following about the parameters sets (for signature and the hash algorithm): Use of the test parameter sets or parameter sets not described herein is NOT RECOMMENDED. When different parameters are used, it is RECOMMENDED that they be subjected to examination by an authorized agency with approved methods of cryptographic analysis. Which is not really helpful. Any specification referencing rfc-4357 will now have to declare which kind of parameter sets (as defined in rfc-4357) should be used/accepted for which purpose and which parameter set is the default. The purpose, existance and semantics of the test algorithm parameter sets are particularly confusing. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsext-dnssec-gost (...) to Proposed Standard
(1) There's a serious issue deeply buried in this draft, draft-ietf-dnsext-dnssec-gost-06. Let's start from a general PoV: The signature algorithm used by this document targeted for PS is an elliptical curve cryptography (ECC) algorithm. Most international and national standards, including Standards Track RFCs, have adopted the generic presentation formats for the parameters to be passed in and out of the (software/hardware) 'black boxes' implementing ECC originally specified in the SEC-1 Standard. What matters for DNSSEC is the representation of ECC public keys. These are points on an elliptic curve over a finite field. In DNSEXT I had requested that this draft also make use of the basic ECpoint format commonly used in other protocols and most standards for the representation of its public keys in DNSSEC resource records. This should further modularity and thus likely increase software quality and hence security. However, the authors have harshly rejected this call for uniformity, based on a few specialized implementations where the implementers apparently have not been aware of more than a decade of standardization efforts for ECC. I did not keep this discussion on namedroppers because IMHO this is a question at the architectural level that needs to be dealt with in the IETF at large. I therefore repeat here my request to replace the ad-hoc representation of the EC public keys in the draft with the ECpoint format described in the SEC-1 standard; in particular, Algorithms 2.3.3 and 2.3.4 of SEC-1 describe the conversion of an abstract EC point into an octet string and vice versa, respectively. These algorithms should be used to encode/decode the wire format of the EC points used as publik keys. The abstraction provided by these algorithms allows implementations to use any internal representation of EC points they seem fit but make use of an interface that is not different from that for other EC algorithms. Admittedly, the IETF had been lulled some time ago and missed putting emphasis on homogenous interfaces when RFCs 4490 and 4491 have been adopted, and these two RFCs suffer from a similar deficiency. I have filed defect reports as Technical Errata against these RFCs (EID=1884 and 1885, respectively) to raise awareness of this issue. I expect that a document that seeks adoption on the Standards Track does not violate current IETF Full Standards. STD 13, RFC 1035 specifies the byte order of all numeric quantities used on the wire in the DNS. The last paragraph of Section 2.3.2 is rather explicit in specifying network byte order: Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first. The document in LC, as it stands, introduces mixed endian-ness into the DNS wire protocol. This is not explicit in the draft because it for this purpose refers to another RFC that suffers from a similar defect. I strongly oppose to this violation of architectural principles and request a change of the wire format specification in the draft. (2) I also concur with Steve and Paul that it is premature to have a SHOULD implementation requirement for a combination of cryptographic algorithms that arguably are less strong than the state-of-the-art assumes, and that only recently have seen starting in-depth discussion in the scientific cryptanalytical community. We should wait until the translations of the old specifications of the basic GOST algorithms into English have been published on the Independent Submission stream (all three documents have already advanced to RFC-EDITOR state this week) and then for the world-wide international cryptanalytical community having had sufficient time to scrutinize the fundamental algorithms (or find [more] weeknesses therein) before we ever consider making SHOULD or MUST implement requirements for such algorithms' support in fundamental Internet protocols (like the DNS). Reportedly there are serious concerns regarding the small block size used in the GOST hash algorithm. It sounds strange in the age of announced dawn of SHA-1 for digital signatures to step back now that a global open effort is on its way (under the auspices of NIST) for the development and adoption of a state-of-the-art, next-generation hash standard (dubbed preliminarily SHA-3). This is not a concern of practical cryptanalytical threats against (rather short-lived) DNSSEC, but of a general desire to get rid of weaker algorithms in crypto-toolkits, in order to avoid their accidental use (e.g. by misguided poor configuration or as a result of downgrading attacks) in circumstances where it _does_ matter. (3) I also concur with Andrew that having different requirement levels in a fundamental protocol that does not allow negotiation of crypto-algorithms also causes severe deployability concerns. This 'inability to negotiate
Re: draft-ietf-dnsext-dnssec-gost
On Feb 12, 2010, at 7:57 AM, Stephen Kent wrote: Who gets to decide on what algorithms get first class status and based on what criteria? If we look at what the CP developed in the SIDR WG for the RPKI says, the answer is the IESG So, they're going to flip a coin or what? Who is largely irrelevant. The criteria is the interesting bit. Steve brought up national algorithm, but we have also personal algorithms such as curve25519 or threefish. WGs like IPsec, TLS, and SMIME have been able to say no to personal algs for a long time. IPsec, TLS, and SMIME are all one-to-one. DNSSEC (in this context) is one-to-many. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
A clarification of what I said (was Re: Last Call: draft-ietf-dnsext-dnssec-gost . . . )
On Fri, Feb 12, 2010 at 12:29:00AM +0100, Alfred Hönes wrote: (3) I also concur with Andrew that having different requirement levels in a fundamental protocol that does not allow negotiation of crypto-algorithms also causes severe deployability concerns. I want to be perfectly clear: I did not say that; neither did I imply it. I don't know that I believe it. The statement to which I think you are referring was merely an attempt to focus the discussion opened by my esteemed co-Chair, thereby to make sure that we stick to the question of picking algorithm support levels _for DNSSEC_, and not in general. So I was pointing out a feature of DNSSEC that is different from at least some other contexts. For the record, I refuse to have a personal opinion one way or the other on what the IESG should do with the draft in question. I believe the WG decided to support its publication, and in my capacity as Chair I feel duty-bound to promote that support. I am not the shepherd for this document, however, and I have no stake in the outcome. Best, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
At 10:57 -0500 2/12/10, Stephen Kent wrote: If we look at what the CP developed in the SIDR WG for the RPKI says, the answer is the IESG (going forward, after an initial set of algs are adopted based on the SIDR WG process). In the IPSEC, TLS, and SMIME contexts, the WGs themselves have made the decisions, which the IESG then approves by virtue of the usual standards track RFC approval process. I do not believe that the criteria have been documented uniformly across these WGs. What is CP? At 15:11 -0500 2/11/10, Olafur Gudmundsson wrote: Steve brought up national algorithm, but we have also personal algorithms such as curve25519 or threefish. WGs like IPsec, TLS, and SMIME have been able to say no to personal algs for a long time. I've asked this before (see http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg03057.html): what is a national algorithm? I asked that in the DNSEXT WG and didn't get a response. There's a definition in http://www.ietf.org/mail-archive/web/secdir/current/msg01343.html but from that I can't distinguish between Skipjack (in that it is labeled as national) and DES (not-national but published by [US] NIST as FIPS). But in the bigger picture, for different reasons, I think the SHOULD in question be removed/changed. I think it is up to an implementor to choose whether they implement something or not, support RFC wxyz or not. And it is up to the RFP write to require it or not. I don't think any RFC can MUST itself into existence. PS - I think Olafur meant private algorithms not personal algorithms. See http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml, registrations for 253 and 254. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Edward Lewis wrote: At 10:57 -0500 2/12/10, Stephen Kent wrote: If we look at what the CP developed in the SIDR WG for the RPKI says, the answer is the IESG (going forward, after an initial set of algs are adopted based on the SIDR WG process). In the IPSEC, TLS, and SMIME contexts, the WGs themselves have made the decisions, which the IESG then approves by virtue of the usual standards track RFC approval process. I do not believe that the criteria have been documented uniformly across these WGs. What is CP? Certificate Policy: http://www.ietf.org/id/draft-ietf-sidr-cp-08.txt spt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
On 12/02/2010 2:18 PM, Edward Lewis wrote: At 10:57 -0500 2/12/10, Stephen Kent wrote: PS - I think Olafur meant private algorithms not personal algorithms. See http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml, registrations for 253 and 254. No I meant exaclty what I wrote. Personal algorithm is an algorithm develeoped by a person or a group of people that are not state sponsored thus the examples I provided. Olafur ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Basil Dolmatov wrote: Martin Rex пиÑеÑ: Whether and how much the -1994 version is deprecated is also a complete mystery. It is written in the text of GOST -2001 Which document are you refering to when you say text of GOST -2001 ? This document: http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08 says section 1.1: 4. GOST R 34.10-2001 replaces GOST R 34.10-94. section 1,2: GOST R 34.10-2001 is developed to replace GOST R 34.10-94. 2. GOST R 34.10-2001 was accepted and activated by the Act 380-st of 12.09.2001 issued by the Russian federal committee for standards. ... 4. GOST R 34.10-2001 replaces GOST R 34.10-94. So, GOST -1994 for digital signature _is_ deprecated and replaced from 12.09.2001. The transition period is not stated explicitly because it is obvious from standard procedure of certification in Russia. No certificate can be issued for any hardware/software using -1994 algorithm after 12.09.2001 and the certification period is 3 years. So, after 12.09.2004 there can be no operating hardware/software using -1994 algorithm. That information OUGHT to have been added to rfc-4357 and it ought to be added to draft-dolmatov-cryptocom-gost34102001-08. I just found the following paragraph in the Copyright Notice of http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08 on the title page which irritates me: This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English. Is there a new trend to have the IETF rubber stamp documents as is? To me, this statement precludes editorial changes/corrections, which doesn't sound right. I boldly assumed the original name of the IETF documents RFC mean Request For Comment, in the form that the community was asked for feedback (request for clarifications, correction or changes) before document was published. At least this is how I understand The Tao of the IETF http://tools.ietf.org/html/rfc4677#section-8.1 Although the IETF may not have change control for the technical contents described in informational document, a complete absence of change control of document structure, clarity, detail of explanation and editorial issues would come as a suprise to me... -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsext-dnssec-gost (Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC) to Proposed Standard
Dear colleagues, We, RiNet ISP, being one of the middle-sized providers in Moscow RU, would like to support the proposed document due to constantly increasing both needs for securing (here, in terms of being verifiable) communications and legal issues with implementing cryptography in Russian Federation. Thank you. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-ietf-dnsext-dnssec-gost
I recommend that the document not be approved by the IESG in its current form. Section 6.1 states: 6.1. Support for GOST signatures DNSSEC aware implementations SHOULD be able to support RRSIG and DNSKEY resource records created with the GOST algorithms as defined in this document. There has been considerable discussion on the security area directorate list about this aspect of the document. All of the SECDIR members who participated in the discussion argued that the text in 6.1 needs to be changed to MAY from SHOULD. The general principle cited in the discussion has been that national crypto algorithms like GOST ought not be cited as MUST or SHOULD in standards like DNESEC. I refer interested individuals to the SECDIR archive for details of the discussion. (http://www.ietf.org/mail-archive/web/secdir/current/maillist.html) Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
At 12:57 PM -0500 2/11/10, Stephen Kent wrote: I recommend that the document not be approved by the IESG in its current form. Section 6.1 states: 6.1. Support for GOST signatures DNSSEC aware implementations SHOULD be able to support RRSIG and DNSKEY resource records created with the GOST algorithms as defined in this document. There has been considerable discussion on the security area directorate list about this aspect of the document. All of the SECDIR members who participated in the discussion argued that the text in 6.1 needs to be changed to MAY from SHOULD. The general principle cited in the discussion has been that national crypto algorithms like GOST ought not be cited as MUST or SHOULD in standards like DNESEC. I refer interested individuals to the SECDIR archive for details of the discussion. (http://www.ietf.org/mail-archive/web/secdir/current/maillist.html) As usual, I agree completely with Steve Kent. Further, I note that while there was consensus in the DNSEXT WG to put this document on standards track, there was no such consensus for making every DNSSEC implementation come under a new SHOULD-level requirement. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
On 11/02/2010 12:57 PM, Stephen Kent wrote: I recommend that the document not be approved by the IESG in its current form. Section 6.1 states: 6.1. Support for GOST signatures DNSSEC aware implementations SHOULD be able to support RRSIG and DNSKEY resource records created with the GOST algorithms as defined in this document. There has been considerable discussion on the security area directorate list about this aspect of the document. All of the SECDIR members who participated in the discussion argued that the text in 6.1 needs to be changed to MAY from SHOULD. The general principle cited in the discussion has been that national crypto algorithms like GOST ought not be cited as MUST or SHOULD in standards like DNESEC. I refer interested individuals to the SECDIR archive for details of the discussion. (http://www.ietf.org/mail-archive/web/secdir/current/maillist.html) Steve As a document shepeard I have made note that this is desired, but at the same time this is a topic that was outside the scope of the working group. This is on the other hand a topic that belongs in the IETF review. So my questions to the IETF (paraphrashing George Orwell) Are all crypto algorithms equal, but some are more equal than others? Who gets to decide on what algorithms get first class status and based on what criteria? Steve brought up national algorithm, but we have also personal algorithms such as curve25519 or threefish. Olafur ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
On Thu, Feb 11, 2010 at 03:11:27PM -0500, Olafur Gudmundsson wrote: Who gets to decide on what algorithms get first class status and based on what criteria? Without wanting to put words in Olafur's mouth, it seems to me that a couple details are needed as background to focus this debate. At the moment, the only way to add a new algorithm to DNSSEC is standards action. So in order to add GOST, we have to have a standards-track document. We also have the problem that DNS clients cannot negotiate their algorithms with the other end of the communication. Moreover, the natural fallback -- use a MAY algorithm by preference, but include a MUST algorithm so that everyone can verify your signatures -- will increase the size of DNS responses. Alternatively, one can use a MAY algorithm only, but with the knowledge that a substantial number of people might not be able to validate (so they'll treat the answer as unsecured, and not get the benefit of DNSSEC). So the question here is not what algorithms get first class status in general, but whether we want to have different classes of support for DNSSEC, given the current conditions. Thanks and best regards, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
At 4:04 PM -0500 2/11/10, Andrew Sullivan wrote: So the question here is not what algorithms get first class status in general, but whether we want to have different classes of support for DNSSEC, given the current conditions. First off, thank you for better stating the question. There are a plethora of signing algorithms. Note that a signing algorithm consists of a public key algorithm *and* a hash algorithm. The question here is whether they also have SHOULD-level requirements to process every signing algorithm that is in the IANA registry. Having such a requirement gives attackers a much wider target: in order to spoof a signature, they can pick the weakest of a large collection of algorithms. For example, there is already a published attack on the GOST hash function that does not exist in SHA-256 and SHA-512. The GOST algorithms have had much less cryptographic review than other algorithms. If that attack becomes practical, an attacker can create signatures using GOST that he/she could not create in RSA/SHA-256 or RSA/SHA-512. Given this, the answer to the question should be no, not all algorithms automatically get SHOULD-level requirements. The IETF can, on a case-by-case basis, decide if they want to update the base DNSSEC spec to include a SHOULD-level or MUST-level requirement for a new signature algorithm. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
I agree with Steve's and Paul's analyses. In addition, it's not clear to me how this SHOULD-level requirement squares with the IANA registration of this algorithm as OPTIONAL (in Section 8), since in RFC 2119 OPTIONAL == MAY. The document that defines that registry (draft-ietf-dnsext-dnssec-registry-fixes) does not allow algorithms to be RECOMMENDED, so it seems like the requirement for support has to be either a MUST or a MAY to be consistent with the registry. --Richard On Feb 11, 2010, at 4:24 PM, Paul Hoffman wrote: At 4:04 PM -0500 2/11/10, Andrew Sullivan wrote: So the question here is not what algorithms get first class status in general, but whether we want to have different classes of support for DNSSEC, given the current conditions. First off, thank you for better stating the question. There are a plethora of signing algorithms. Note that a signing algorithm consists of a public key algorithm *and* a hash algorithm. The question here is whether they also have SHOULD-level requirements to process every signing algorithm that is in the IANA registry. Having such a requirement gives attackers a much wider target: in order to spoof a signature, they can pick the weakest of a large collection of algorithms. For example, there is already a published attack on the GOST hash function that does not exist in SHA-256 and SHA-512. The GOST algorithms have had much less cryptographic review than other algorithms. If that attack becomes practical, an attacker can create signatures using GOST that he/she could not create in RSA/SHA-256 or RSA/SHA-512. Given this, the answer to the question should be no, not all algorithms automatically get SHOULD-level requirements. The IETF can, on a case-by-case basis, decide if they want to update the base DNSSEC spec to include a SHOULD-level or MUST-level requirement for a new signature algorithm. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Stephen Kent wrote: I recommend that the document not be approved by the IESG in its current form. Section 6.1 states: 6.1. Support for GOST signatures DNSSEC aware implementations SHOULD be able to support RRSIG and DNSKEY resource records created with the GOST algorithms as defined in this document. There has been considerable discussion on the security area directorate list about this aspect of the document. All of the SECDIR members who participated in the discussion argued that the text in 6.1 needs to be changed to MAY from SHOULD. The general principle cited in the discussion has been that national crypto algorithms like GOST ought not be cited as MUST or SHOULD in standards like DNESEC. I refer interested individuals to the SECDIR archive for details of the discussion. I agree with Stephen Kent. That needs to be a MAY. GOST is IMHO _not_ mature enough and not sufficiently understood and availble to justify a SHOULD or RECOMMENDED for its support/use in a core internet protocol. Over the past year we had our SSL/TLS supplier add support for GOST TLS ciphersuites to add OEM SSL/TLS implementation (in form of a third-party crypto plugin that can be certified by the relevant russian authorities). One of the problems with GOST is its lack of availability of documentation/specification and the meaning, purpose and characteristics of algorithm parameters. Admittedly, I know very little about the cryptographic details, but there are two GOST signature algorithms (GOST R34.10-1994 and GOST R34.10-2001). The earlier appears to bear some similarity with DH, the newer appears to bear similarity with ECDH. Whether and how much the -1994 version is deprecated is also a complete mystery. There are IETF documents listing specific algorithm Identifier parameters (sets), referenced by OIDs, and those OIDs are issued by one particular company. I haven't seen any documentation about the characteristics, purpose of these algorithm parameters sets and the means/process to define other parameter (sets). -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
One of the problems with GOST is its lack of availability of documentation/specification and the meaning, purpose and characteristics of algorithm parameters. A bit of Googling turned up this http://vsegost.com/Catalog/96/9658.shtml with scanned GIFs of ГОСТ Р34.10-1994. There is a link to the other one, ГОСТ Р34.10-2001 on that page as well. This does seem to document the parameters. Is the real problem the lack of English language documentation? If so, I'm sure that the people who would like to use these algorithms could arrange for translations of the two documents, and perhaps even make that an individual submission as an Internet draft. Whether and how much the -1994 version is deprecated is also a complete mystery. That may be explained by its use in card payment systems. As you may know if you follow the news, a Cambridge team has just found a HUGE hole in the UK's chip and pin payment system, but a subtext of that announcement is that other weaknesses documented in previous years still have not been fixed. Signature algorithms used in payment systems get embedded in all kinds of devices, and software systems, making it hard to deprecate stuff fast. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Michael Dillon wrote: One of the problems with GOST is its lack of availability of documentation/specification and the meaning, purpose and characteristics of algorithm parameters. A bit of Googling turned up this http://vsegost.com/Catalog/96/9658.shtml with scanned GIFs of ГОСТ Р34.10-1994. There is a link to the other one, ГОСТ Р34.10-2001 on that page as well. This does seem to document the parameters. Is the real problem the lack of English language documentation? If so, I'm sure that the people who would like to use these algorithms could arrange for translations of the two documents, and perhaps even make that an individual submission as an Internet draft. English translation, I don't believe, is the problem. The following drafts are the English translations of the [GOST3410] and [GOST3411] references: http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost341194-07 http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08 http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost2814789-06 Whether and how much the -1994 version is deprecated is also a complete mystery. That may be explained by its use in card payment systems. As you may know if you follow the news, a Cambridge team has just found a HUGE hole in the UK's chip and pin payment system, but a subtext of that announcement is that other weaknesses documented in previous years still have not been fixed. Signature algorithms used in payment systems get embedded in all kinds of devices, and software systems, making it hard to deprecate stuff fast. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Sean Turner wrote: Is the real problem the lack of English language documentation? If so, I'm sure that the people who would like to use these algorithms could arrange for translations of the two documents, and perhaps even make that an individual submission as an Internet draft. English translation, I don't believe, is the problem. The following drafts are the English translations of the [GOST3410] and [GOST3411] references: http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost341194-07 http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08 http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost2814789-06 I'm having difficulties to find answers to relatively simple questions: - for which key sizes are the algorithms defined? - which parameter of the algorithms (-94, -2001) is used to characterize the key size? -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
Martin Rex wrote: Sean Turner wrote: Is the real problem the lack of English language documentation? If so, I'm sure that the people who would like to use these algorithms could arrange for translations of the two documents, and perhaps even make that an individual submission as an Internet draft. English translation, I don't believe, is the problem. The following drafts are the English translations of the [GOST3410] and [GOST3411] references: http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost341194-07 http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08 http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost2814789-06 I'm having difficulties to find answers to relatively simple questions: - for which key sizes are the algorithms defined? - which parameter of the algorithms (-94, -2001) is used to characterize the key size? Disclaimer: I'm not an expert on GOST. Section 5 of http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-gost-06 says the GOST public key size is 512 bits. spt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-dnsext-dnssec-gost (Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC) to Proposed Standard
The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC ' draft-ietf-dnsext-dnssec-gost-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-02-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-gost-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=19070rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
