Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 04 Jan 2011 16:27:58 -0500

On 09/12/2010 4:30 PM, Olafur Gudmundsson wrote:
>
> Dear colleagues
>
> The chairs have received a request to adopt the following draft as a
> working group document.
> http://tools.ietf.org/html/draft-hoffman-dnssec-ecdsa-04
>
>
> The draft falls within the WG charter because it pertains to DNSSEC
> algorithm maintenance
>
> The rules of the working group require that at least 5 members of the
> working group publicly state that they support adoption. If 5 people
> have not stepped forward by January 15'th the draft will not be adopted.

The draft has reached its threshold for adoption, one issue has been 
brought up that the chairs would like more input on:

+  - IMHO the SHA-384 DS stuff should be put in another document:
+   * there is no reason to mix SHA-384 DS with ECDSA DNSKEY/RRSIG
+   * there is even no text explaining when SHA-384 should be used
+    in this case
+   * it makes easier to address the next item

Please tell us if this item belongs in the draft, in a separate document 
or not at all?

>
> Please read the document and say what changes are needed to get the
> document to be ready for advancement. The plan is to dispose of this
> document in short order.
> Please comment on if this document should be for informational or
> standards track.

We are assuming Standards Track is where the working group wants to 
place this document.

	Olafur & Andrew

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 04 Jan 2011 14:34:09 -0800

> Please tell us if this item belongs in the draft, in a separate document

It belongs in the draft because it makes no sense to have a signature 
that is ECDSA with the P-384 curve and SHA-384 that is pointed to by a 
DS of SHA-256: that gives an attacker a unneeded opening.

> We are assuming Standards Track is where the working group wants to

That would be appropriate.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 05 Jan 2011 10:08:00 -0500

> DS of SHA-256: that gives an attacker a unneeded opening.

Trying to interpret your statement above, is this a fair
generalization?
"DS digest should/must be as strong as the DNSKEY it points to ?"

	Olafur

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 05 Jan 2011 07:12:50 -0800

> "DS digest should/must be as strong as the DNSKEY it points to ?"

With a non-normative slant, yes. Maybe "the DS digest should be able to 
be as strong as the DNSKEY signature that it covers". If someone wants 
to cover a strong signature with a weak hash, or vice versa, that's 
their choice, of course.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 05 Jan 2011 10:24:25 -0500

> to cover a strong signature with a weak hash, or vice versa, that's

Thinking ahead, why not just define SHA-512 DS and skip the 384 ?

	Olafur

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Jan 2011 10:38:33 -0500

At 7:12 -0800 1/5/11, Paul Hoffman wrote:

>With a non-normative slant, yes. Maybe "the DS digest should be able to be
>as strong as the DNSKEY signature that it covers". If someone wants to cover
>a strong signature with a weak hash, or vice versa, that's their choice,
>of course.

I'd like to see this stated in DNS terms - i.e., the notion of 
strength is not one of them.

I would suggest that

  - the authoritative set of the DS record SHOULD include a DS RR for 
each key that is of the same hash algorithm as is used in the key and 
MAY have other hashes (and MAY even have only other hashes[1])

[1] The parenthetical comment is redundant, put it there for emphasis.

  - a validator SHOULD prefer the DS record of the same hash algorithm 
over other hash algorithms for a key.  Prefer means that it SHOULD be 
the first tried and if it fails, the validator MAY declare failure 
without examining the other applicable hash algorithms.  A validator 
MUST NOT require that there be a hash of the same algorithm present, 
with require meaning - if such a hash is absent, failure is not 
automatic.

You may note that I spec "the same hash algorithm" because I don't 
know of any way to say if one hash algorithm is stronger than the 
next.  I.e., bit length might be an indicator but I bet it also isn't 
reliable.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

The 21st Century is 10% complete.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 05 Jan 2011 07:55:54 -0800

> Thinking ahead, why not just define SHA-512 DS and skip the 384 ?

That's two very separate questions.

- I tend not to propose protocol elements that I doubt I could use 
myself. I see no cryptographic purpose to SHA-512 DSs if there are no 
signatures that require that strength hash. I know of no cryptographic 
reason to have signatures whose effective strength is greater than 192 bits.

- There are operational advantages of SHA-384 over SHA-512, namely size 
on the wire. Thus, "skipping" SHA-384 would waste bandwidth without 
offering any advantage.

---

From: Basil Dolmatov <[email-masked]>
Date: Wed, 05 Jan 2011 19:13:08 +0300

> reason to have signatures whose effective strength is greater than 192 
No signatures are requiring any "strength of hash".
The implementors are the only persons who can require some strength from 
some elements of security chain.
The obvious reason for implementor to require something is to ensure 
that all elements in this chain are equally reliable. Unfortunately, 
"bits of strength" are not the obvious characteristics of reliability 
which are good for comparison in all cases.

So, the demand of equality of some bits figures looks somewhat artificial.

dol@
>
> - There are operational advantages of SHA-384 over SHA-512, namely 
> size on the wire. Thus, "skipping" SHA-384 would waste bandwidth 
> without offering any advantage.
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 05 Jan 2011 09:42:59 -0800

On 1/5/11 7:38 AM, Edward Lewis wrote:
> I'd like to see this stated in DNS terms - i.e., the notion of strength
> is not one of them.

If this was *DNS*SEC, I would agree. However, this is more DNS*SEC*. In 
security, strength is particularly important.

> I would suggest that
>
> - the authoritative set of the DS record SHOULD include a DS RR for each
> key that is of the same hash algorithm as is used in the key and MAY
> have other hashes (and MAY even have only other hashes[1])
>

That idea (with a bit more careful wording) would work fine for current 
signature schemes. It might fall apart later, but it works fine for all 
the signature schemes under consideration.

> over other hash algorithms for a key. Prefer means that it SHOULD be the
> first tried and if it fails, the validator MAY declare failure without
> examining the other applicable hash algorithms. A validator MUST NOT
> require that there be a hash of the same algorithm present, with require
> meaning - if such a hash is absent, failure is not automatic.

Ditto.

> You may note that I spec "the same hash algorithm" because I don't know
> of any way to say if one hash algorithm is stronger than the next. I.e.,
> bit length might be an indicator but I bet it also isn't reliable.

It is reliable as long as the hash algorithm does not have known 
pre-image weaknesses. None of the hash algorithms under consideration 
do, and in fact there are no practical pre-image attacks even for the 
soon-to-be-deprecated MD5. There is no future guarantee that this will 
be the case, of course.

But, getting back to the cryptography you don't want to discuss, note 
that your use of "the same hash algorithm" assumes that a pre-image 
attack on the contents of something signed will have the same effect as 
a pre-image attack on the DS record. That is extremely unlikely to be 
true, as we have seen in recent collision attacks. Regardless, if you 
are unwilling to talk about strengths, using the same hash algorithm in 
both places is currently the best way around it.

 > No signatures are requiring any "strength of hash".

Signers sign with some assumption of the strength of the signature 
against attack. One significant factor in that strength is the strength 
of the hash against pre-image attacks.

 > some elements of security chain.

True, but irrelevant.

 > which are good for comparison in all cases.

We disagree here. I understand that, given the tight limitations of 
GOST, that might be true in your market. However, in a future world 
where there are multiple hash algorithms (thinking ahead to SHA-3), some 
of which will have the same effective strengths, effective strength is a 
reasonable measurement.

 > So, the demand of equality of some bits figures looks somewhat 
artificial.

In the GOST world, yes; in the less-restricted space of open standards, no.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Jan 2011 13:15:59 -0500

At 9:42 -0800 1/5/11, Paul Hoffman wrote:

>...Regardless, if you are unwilling to talk about strengths, using 
>the same hash algorithm in both places is currently the best way 
>around it.

Exactly why I used that term.  It's one thing to define equivalence, 
it's another to define ordering (in this case, strength).  I don't 
question the notion of strength in the cryptographic sense, I just 
don't see how you can translate that into a DNS document in a way 
that will be helpful to DNS operators.

Out of pure curiosity about the threat of pre-image attacks, are the 
attacks possible within the DNS message format?  I mean, I have heard 
that one can forge a PDF file to match the hash of another, for the 
purposes of changing the meaning of the file.  I assume this takes 
more than a few bits of diddling to do.

If I sign a single A record, how can a forgery be concocted to 
replace the set?  I don't mean 1 for 1 necessarily, maybe it would 
take 10 or so.  Is MD5 really broken within the confines of DNS?  (My 
point is that thie is *DNS*SEC and not DNS*SEC*.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Chris Thompson <[email-masked]>
Date: 05 Jan 2011 18:39:41 +0000

On Jan 5 2011, Edward Lewis wrote:

>over other hash algorithms for a key. 

You mean that a validator should prefer a digest type 1 (SHA-1) DS over
a type 2 (SHA-256) DS if the key to be validated uses algorithm RSASHA1?
This directly contradicts the SHOULD in RFC 4509 section 3, and also
doesn't seem too sensible to me.

>                                       Prefer means that it SHOULD be 

It's perfectly possible for an implementor, or an operator, to have
opinions about this, though.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Basil Dolmatov <[email-masked]>
Date: Wed, 05 Jan 2011 21:52:41 +0300

05.01.2011 20:42, Paul Hoffman пишет:
> where there are multiple hash algorithms (thinking ahead to SHA-3), 
> some of which will have the same effective strengths, effective 
> strength is a reasonable measurement.
>
I did not make any GOST references, moreover I did not imply any GOST 
peculiarities in my comment, it is true for _any_ algorithm (the fact 
that GOST belongs to "space of open standards" too is worth mentioning, 
but irrelevant).

In any space of cryptographic standards the strength of algorithm is 
measured not by "bits of strength" or "bits of key or hash length" but 
by the number of operations which should be performed for given attack.
If one bothers to compare the algorithm strength more accurately then 
the product of (operations)*(memory required) is used.

Other figures have mostly marketing meaning rather than technical one.

dol@

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 05 Jan 2011 10:54:45 -0800

On 1/5/11 10:15 AM, Edward Lewis wrote:
>> ...Regardless, if you are unwilling to talk about strengths, using the
>> same hash algorithm in both places is currently the best way around it.
>
> Exactly why I used that term. It's one thing to define equivalence, it's
> another to define ordering (in this case, strength). I don't question
> the notion of strength in the cryptographic sense, I just don't see how
> you can translate that into a DNS document in a way that will be helpful
> to DNS operators.

Note that the current draft doesn't have anything about strengths in it: 
this came up in a discussion with Olafur about why I didn't bother to 
define a SHA-512 DS record.

> attacks possible within the DNS message format?

No. There are no practical pre-image attacks for any of the hash 
algorithms we are talking about, even MD5. It doesn't matter the format 
of the hashed data: there are none to date for any format until you get 
to the truly ridiculous sizes of messages (billions of petabytes per 
hashed message).

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 05 Jan 2011 10:56:23 -0800

> doesn't seem too sensible to me.

Thank you, Chris. I knew that someone had said something about strengths 
in an RFC, but I could not remember where. You nailed it.

That's not to say that we should have equivalent wording in this 
document, just that the "cannot say anything about strength" is a new 
requirement that is not met by earlier standards-track documents from 
this WG.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 05 Jan 2011 11:01:10 -0800

> that GOST belongs to "space of open standards" too is worth mentioning,

GOST limits which hash algorithm can be used in signatures to one 
choice, so that is indeed relevant.

> the product of (operations)*(memory required) is used.

Both are used as measurements, and the one that is most commonly used in 
discussion is equivalent bit strength.

> Other figures have mostly marketing meaning rather than technical one.

That was not the IETF consensus when we adopted RFC 3766, which was 
heavily reviewed in the IETF's cryptographic community.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Jan 2011 14:10:27 -0500

>No.

Again asking from pure curiosity, why then are we concerned about 
strengths and broken hashes?  Within the confines of DNS again, that 
is.

I can understand not wanting to use MD5 because it has been 
discredited and thus code supporting it might disappear from general 
distribution.  And I am not encouraging using any past the grave 
technology just because we can.  My question arises from what seems 
to be a preoccupation (by others) with attacks via downgrading the 
"strength" of the cryptography used.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Jan 2011 14:21:55 -0500

At 10:56 -0800 1/5/11, Paul Hoffman wrote:
>Thank you, Chris. I knew that someone had said something about strengths in
>an RFC, but I could not remember where. You nailed it.
>
>That's not to say that we should have equivalent wording in this document,
>just that the "cannot say anything about strength" is a new requirement that
>is not met by earlier standards-track documents from this WG.

Looking at 4509, the two places "strength" is mentioned is here:

6.2.  SHA-1 vs. SHA-256 Considerations for DS Records

    Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
    implementations allow for it.  SHA-256 is widely believed to be more
    resilient to attack than SHA-1, and confidence in SHA-1's strength is
    being eroded by recently announced attacks....

My comment about needing references applies to that - "recently 
announced attacks" is unsupported by a reference.

                                     ...It is beyond the scope of this
    document to speculate extensively on the cryptographic strength of
    the SHA-256 digest algorithm.

And here the document says strength is beyond the scope.

In section 3:

    ...Validator implementations SHOULD ignore DS RRs containing SHA-1
    digests if DS RRs with SHA-256 digests are present in the DS RRset.

Looking at this, I don't see why this is a good idea if the key is 
RSA/SHA-1 (algorithm 5 or 7).  Well, not a bad idea, but what is 
gained?  If SHA-1 is questionable, why is it more questionable if 
it's the DS hash than if it is the DNSKEY hash?  Isn't the weakest 
link still SHA-1?  (Ignoring the rest of the chain.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 05 Jan 2011 11:36:35 -0800

On 1/5/11 11:10 AM, Edward Lewis wrote:
> strengths and broken hashes? Within the confines of DNS again, that is.

Strengths matter because, even with no brokenness, some hashes are 
stronger than others with respect to pre-image attacks. SHA-256 is 
inherently stronger than SHA-1 by 96 bits of equivalent strength.

We are currently not concerned about breaking of the pre-image strength 
because we have no idea what such a break would mean. A zillion 
assumptions in all security protocols would come into question if there 
was any practical pre-image reduction in a hash being commonly used.

We should be concerned about reductions in collision strength only if it 
turns out that DNSSEC uses hashes in a way that can be affected by such 
a reduction. To date, no one has shown how that affects DNSSEC, even 
though there have been some pretty creative collision attacks on systems 
that rely on PKIX certificate chaining. A few people might insist that 
some collision attack is important in some corner cases, but that's 
where the hard cryptography ends and the sober world of consensus starts.

> I can understand not wanting to use MD5 because it has been discredited
> and thus code supporting it might disappear from general distribution.
> And I am not encouraging using any past the grave technology just
> because we can. My question arises from what seems to be a preoccupation
> (by others) with attacks via downgrading the "strength" of the
> cryptography used.

Such arguments are in the same category as "the DNS doesn't scale" and 
its ilk. If you don't define your terms carefully, you can make 
arguments about almost anything. When you define your terms carefully, 
others can decide whether or not your argument applies to a significant 
portion of the world.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 5 Jan 2011 16:24:50 -0400

On Wed, Jan 5, 2011 at 2:15 PM, Edward Lewis <[email-masked]> wrote:

> If I sign a single A record, how can a forgery be concocted to replace the
> set?  I don't mean 1 for 1 necessarily, maybe it would take 10 or so.  Is
> MD5 really broken within the confines of DNS?  (My point is that thie is
> *DNS*SEC and not DNS*SEC*.)

I don't think you can for an A record per se, but it might be possible
for other record types.

If you can forge the delegation to the zone containing the A record,
it makes the forging the A signature unnecessary.

Can we (do the latter)?

In order to forge (given what we know of the MD5 weakness), it is
necessary to fit in 128 bytes of arbitrary data, aligned on a 64-byte
boundary.

The math of 2^n works against us here, in terms of the ability to get
things aligned.

The only factors of 2^n are 2^m (for m < n), which means that unless
*both* the RRSIG RDATA (less the signature itself) *and* the canonical
wire-format of the RR of the covered RR type, happen to be of length
2^x and 2^y respectively, it is possible to add more forged RR records
to the set until the RR RDATA is aligned on the 64-byte boundary.

The question then becomes, are any "important" RR types capable of
having arbitrary 128-byte RDATA values?

I don't know offhand, but I suspect that the NS record can, since the
DNS protocol itself allows binary labels long enough. It may boil down
to canonical sort order, on a given NS set (!!!).

This means insecure delegations from zones signed with MD5 might be vulnerable.

Whether corresponding DS records can similarly be "forged" (e.g. by
synthesizing DNSKEY values in the redirected delegated zone) when
SHA-1 is the hash for DS, is beyond my ability to figure out...

If it is, then it would imply that MD5 is fatally broken, since any
delegation signed with MD5, secure or otherwise, could be forged.

But, even insecure delegations being forged is bad enough...

Brian

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Jan 2011 23:32:18 +0100

In your previous mail you wrote:

     - a validator SHOULD prefer the DS record of the same hash algorithm 
   over other hash algorithms for a key.  Prefer means that it SHOULD be 
   the first tried and if it fails, the validator MAY declare failure 
   without examining the other applicable hash algorithms.

=> thanks to have opened the can of worms about the validator behavior
when there are more than more than one DS RR using different digest
algorithm. Today only the case SHA-1 vs. SHA-256 is clear.

Regards

[email-masked]

---

From: Dmitry Burkov <[email-masked]>
Date: Thu, 6 Jan 2011 01:48:18 +0300

Strange discussion for me - if it can be named a discussion :-)
gost belongs to national recommendations with all their typical faults and mistakes
yes, if it was openly described and implemenented in open source - i can't understand what's the issue?
you can use it or not - it's your choice
the choice for russian authourity to issue new recommendations which can be more strength then some alternatives :-) - it is not a problem - i hope - if someone don't like competitors - it doesn't mean that they are dead 

Or I am wrong and someone is not satisfied that russian authorities simply didn't provided newest algorithms in open source? 

Sent from my iPad

On 05.01.2011, at 22:01, Paul Hoffman <[email-masked]> wrote:

> GOST limits which hash algorithm can be used in signatures to one choice, so that is indeed relevant.
> 
> Both are used as measurements, and the one that is most commonly used in discussion is equivalent bit strength.
> 
> That was not the IETF consensus when we adopted RFC 3766, which was heavily reviewed in the IETF's cryptographic community.

---

From: Florian Weimer <[email-masked]>
Date: Fri, 07 Jan 2011 13:39:24 +0000

* Edward Lewis:

> If I sign a single A record, how can a forgery be concocted to replace
> the set?  I don't mean 1 for 1 necessarily, maybe it would take 10 or
> so.  Is MD5 really broken within the confines of DNS?

As far as I can tell, MD5 is only broken for hashing sufficiently
predictable messages supplied by non-trusted parties, and only for
certain message configurations.

In most cases, when you sign an A RRset, there is a close relationship
between the key holder and the data source, so MD5 would still work.
Signing the DS RRset for a delegation is a different matter, though:
the data is supplied by an untrusted party, and there is much more
wiggle room, too (provided that the signer does not reconstruct the DS
RRs from the DNSKEYs in the delegated zone).

I haven't tried to implement an actual attack, but I suspect that the
attack on MD5-based X.509 certificates could be adapted to
hypothetical MD5-based signatures on DS RRsets.  (The attack would
work by submitting a registration for a previously unregistered domain
with crafted DS RRs which causes the MD5 hash to converge with the
hash of the domain which is being attacked.)

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 7 Jan 2011 09:32:56 -0500

Rather than using the term 'strength' I suggest we use the term 'work factor'.

The term strength tends to be interpreted relative to the algorithm
concerned, 'what strength RSA key', it is not really defined as an
absolute measure.

Work factor using known best attack is much better defined. Although
there is always going to be a degree of slop since many attacks have
memory/CPu tradeoffs.

But all this is really outside the parameters of what DNSEXT should
have to concern itself with. What matters most in choice of
cryptographic algorithm is consistency. The attacker only needs to
break the weakest link in the chain. So if we have SHA3 in the DNSSEC
layer and MD5 in the S/MIME we are still vulnerable.

I would like to propose we change the model here. The IETF should get
out of the business for issuing DNSSEC code points for any algorithm
other than those which are mandatory to implement.

Mandatory to implement algorithms should be specified in RFCs that
apply to a collection of protocols. Working Groups would be free to
decide whether to specify their own algorithms or use the common
mandatory set. The advantage of using a common mandatory set being
that they would be subject to ongoing maintenance and revision.

So an implementation that offered DNSSEC with the 2012 crypto set
might specify RFC4043 + RFC 7xxx compliance.

All non-mandatory crypto would use ASN.1 OIDs to declare the algorithm
type. In the case of DNSSEC this would require an approach similar to
the one that the OID based CERT type uses. There would be a code point
reserved for identifying the algorithm by ASN.1 oid and a defined
mechanism for squeezing in the OID as a prefix to the crypto material.

Some people are going to complain about the lack of control here. But
that is worrying about the wrong problem. The only problems we should
be concerned with are interoperability and endorsement.

The only interoperability concern should be that applications that
support a common algorithm be able to use it to communicate. That
means that they all use the same code points to identify the same
algorithm. It is not a big concern to me as people who use non
standard crypto should know what to expect. It is their funeral, we
should not try to stop them attending.

The much bigger concern for me is endorsement. The problem with having
the IETF control the registry is that making an entry into the
registry implies an endorsement. Like it or not, the IETF has
effectively endorsed the use of GOST, a Soviet era crypto algorithm
that is being promoted for specific political reasons that I believe
to be contrary to the principles of an open Internet.

The fact that the OID registry is open and has no gating factor is a
good thing. No gate means no endorsement. If we had used ASN.1 OIDs to
identify algorithms there would be no RFC 5933, there would be no
mention of GOST in RFCs at all unless there was a decision to adopt it
as a mandatory to implement algorithm (which the GRU would not want in
any case since their whole purpose requires use of a different
algorithm).

On Wed, Jan 5, 2011 at 1:39 PM, Chris Thompson <[email-masked]> wrote:
>> I'd like to see this stated in DNS terms - i.e., the notion of strength is
>> not one of them.
>>
>> I would suggest that
>>
>> key that is of the same hash algorithm as is used in the key and MAY have
>> other hashes (and MAY even have only other hashes[1])
>>
>>  - a validator SHOULD prefer the DS record of the same hash algorithm over
>> other hash algorithms for a key.
>
>>                                      Prefer means that it SHOULD be the
>> You may note that I spec "the same hash algorithm" because I don't know of
>> any way to say if one hash algorithm is stronger than the next.  I.e., bit
>> length might be an indicator but I bet it also isn't reliable.
>

-- 
Website: http://hallambaker.com/

---

From: Florian Weimer <[email-masked]>
Date: Fri, 07 Jan 2011 15:14:53 +0000

* Phillip Hallam-Baker:

> Work factor using known best attack is much better defined.

Nope, because attacks tend to be theoretical, and it is hard to tell
if the attacks could actually implemented as described in the
technical reports, given sufficient resources.  Things like
communication overhead in a parallel implementation are difficult to
estimate and often not taken into account.  Even if this is resolved
in some way (but it won't ever happen, I'm pretty sure), you have to
deal with the question of trade-offs: how do you fold sizes and
bandwidths of several types of storage, processing speeds and
communication costs into a single number?

If there are working attacks which you can run on real hardware, it
makes sense to speak of work factors.  But then, you don't want to use
the algorithms anymore, so this isn't an interesting case, either.

> have to concern itself with.

I agree.  If there's a solution for this issue (due to very
significant advances in cryptography, which are rather unlikely, given
past performance), then the DNSSEC standards can use that knowledge.
Right now, there is no such thing, at least in the public literature.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 07 Jan 2011 15:26:11 +0000

> mechanism for squeezing in the OID as a prefix to the crypto material.
...
> algorithm.
...
> any case since their whole purpose requires use of a different

Q: is there sufficient standardisation within the ASN.1 OIDs that if a new
crypto type FOO comes along, then 2 implementations, working solely from
the OID, they can necessarily interoperate? IE will they thoroughly specify
whether FOO options X and Y have to be supported, wire format, etc? To
illustrate what I mean, I include below a section from the OpenSSH-5.7
testing release notes. I know ssh != DNSSEC, but I suspect support for a
new algorithm might not be as simply described as whether a single ID.

-- 
Alex Bligh

 * Implement Elliptic Curve Cryptography modes for key exchange (ECDH)
   and host/user keys (ECDSA) as specified by RFC5656. ECDH and ECDSA
   offer better performance than plain DH and DSA at the same equivalent
   symmetric key length, as well as much shorter keys.

   Only the mandatory sections of RFC5656 are implemented, specifically
   the three REQUIRED curves nistp256, nistp384 and nistp521 and only
   ECDH and ECDSA. Point compression (optional in RFC5656) is NOT
   implemented.

   Certificate host and user keys using the new ECDSA key types are
   supported - an ECDSA key may be certified, and an ECDSA key may act
   as a CA to sign certificates.

   ECDH in a 256 bit curve field is the preferred key agreement
   algorithm when both the client and server support it. ECDSA host
   keys are preferred when learning a host's keys for the first time.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 7 Jan 2011 10:27:59 -0500

Well if the attacks are not theoretical we should not be considering
them at all.

I would ignore communication for calculation of work factor.

Shamir's TWIRL device shows one way of avoiding the communication issue.

We are talking about worst case here and we are always going to have a
significant degree of ambiguity. But even if you assume infinite
memory and infinite communication bandwidth, you can arrive at a lower
bound for the work factor.

We can also impose reasonable memory constraints like limiting the
number of storage locations to the number of atoms in the earth's
crust or whatever.

But the main point is that while everyone in the IETF is welcome to
participate in such a discussion we should be having exactly one
discussion, not one per WG. And we certainly should not be having
different discussions leading to different conclusions.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 07 Jan 2011 07:40:52 -0800

> Rather than using the term 'strength' I suggest we use the term 'work factor'.

I suggest we do neither. This is not the correct WG to be discussing 
this. The proposal at hand adds two signature algorithms and one hash 
algorithm. This current thread started when one of the WG co-chairs 
innocently asked about adding another hash algorithm or replacing the 
one proposed with a new one. I responded with my reasoning (based on 
"strength" and/or "work factor"), but that wording *is not* expected to 
end up in the WG document.

It is sufficient for us to define the use of strong algorithms and let 
operators use whatever input they want to choose which to use.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 7 Jan 2011 10:46:42 -0500

There are two issues here:

1) Different OIDs assigned to the same algorithm with the same parameters.

2) Algorithms that take parameters that lead to different OID assignments.

In the first case we did at one point have an ambiguity where an IETF
WG got the idea that it should ignore the existing OID assignments and
assign OIDs in the IETF arc.

It is now understood that that was a mistake and should not be repeated.

If we moved to the scheme I propose it would make sense for the IETF
to maintain a registry of mandated algorithms and the ASN.1 OIDs
mandated for use in those protocols that use them. But part of the
point of getting the IETF out of the business of registering code
points for non-mandatory crypto would be to discourage use.

In the second case we have frequently ended up with different OIDs for
incompatible variations of the same algorithm. But this is exactly
what we want.

For example, we have had at least three different packaging formats
for RSA signatures over the years. The packaging formats are
incompatible and a verifier can only verify a signature if it supports
the precise packaging format used to create the signature. So even
though the public key algorithm is the same, the implementation is
different and we need to use a different identifier if we are going to
have interoperability.

ECC is a little bit of a unique case since there are parameters and
options and much more complexity than we have had to cope with in the
past.

But even so, I don't see a lot of value in having different protocols
choose different sets of options. At the end of the day consistency is
going to be far more useful than any benefit we might gain from those
options.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 7 Jan 2011 07:58:40 -0800

> certain message configurations.

I think thinking about "degrees of broken" is dangerous. MD5 is
broken, and it shouldn't be considered fit for purpose where security
matters. It may have some use as a cheap integrity check, and in
hash-tables, but not authenticity.

But even IF we take the "supplied by third parties" issue. Imagine
that I'm an evil Certificate Authority, I might give you a certificate
that I know I can produce hash collisions for. (via a prefix attack).
I could then successfully spoof DNS responses for a CERT rrset, by
using your RRSIG, but my evil certificate. That's the really easy way.

It turns out you don't even have to be the issuer though - it's
relatively easy to just create a lot of certificates until you get one
that matches. This is how the RapidSSL cert was successfully forged.

http://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities

-- 
Colm