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
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
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
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
(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
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
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
...@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
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
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.
, 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
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
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
-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:
@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
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,
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
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
-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
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
].
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
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
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
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
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
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
...
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
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
(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
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
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
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
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
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
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:
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
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.
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
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
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 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
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
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
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
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.
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.
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
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
48 matches
Mail list logo
