Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

From: Warren Kumari <[email-masked]>
Date: Thu, 3 Mar 2011 14:36:21 -0500

Hi all,

After watching the thread, I'd like to propose this as a strawman:

Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these are all we specify.

My reasoning behind this is:
1: We don't want to support too many algorithms -- it leads to complexity (which leads to weaker security) and opens the door to interoperability issues and fights over why algorithm X was allowed and Y was not.

2: Having more than 1 algorithm forces implementations to understand that there is not just one, and so should help lead towards algorithm agility

3: In order to do DANE, you have to be able to do DNSSEC -- in order to do DNSSEC you should already support the above.

4: (IMO, an important one, even if not technical one) giving people the ability to choose will lead to greater deployment. Some folk will claim that SHA-256 is too short. Some will claim that SHA-384 is excessively long and computationally expensive. Some will claim something completely random. Almost none of them will have any (rational) basis for their claims, but allowing them to use the algorithm they believe is superior will make them more likely to deploy. 

5: 2 algorithms seems like enough. While SHA1 may or may not be suitable (my (and to be completely blunt, your) views don't really matter) -- there are enough strong views on the strength / lifetime that we are likely to get bogged down / splinter over this. If we were already deployed with SHA1 this would be an important decision, but seeing as we're not, I think that avoiding fight (and living to see another day) is best.
Once again, I'm not saying that I think that SHA1 is (or isn't) fine for this, rather that, in order to get deployed, we should avoid the issue.

#4 and #5 might be pandering, but if it doesn't decrease security, and leads to sooner / more deployment it seems like a win....

Does anyone object to this (for any reasons other than "You're running away from the fight, you coward!")? 
Please speak soon, as we'd love to close this out....

<chair hat>
Please don't let this dissolve into a "algorithm X is better than Y, and Z is a pile o' rubble" discussion -- while that may be true, this is not the time or place to have it....
</chair hat>

W

On Feb 25, 2011, at 4:31 PM, Warren Kumari wrote:

> Hi all,
> 
> While we are all ruminating on the other issues, I figured we might as well try address this one:
> 
> Need to specify which crypto algorithms and certificate types are mandatory to implement -- http://trac.tools.ietf.org/wg/dane/trac/ticket/21
> 
> Description:
> Currently, the draft is silent on which crypto algorithms and certificate types must be implemented for interoperability. It should be specific before the document is finished.
> 
> 
> W
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

---

From: Scott Schmit <[email-masked]>
Date: Thu, 3 Mar 2011 15:26:12 -0500

> Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these are all we specify.
<snip>

Seems like a perfectly reasonable compromise to me.

-- 
Scott Schmit

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 Mar 2011 19:29:52 -0500

That works for me

On Thu, Mar 3, 2011 at 2:36 PM, Warren Kumari <[email-masked]> wrote:

> 1: We don't want to support too many algorithms -- it leads to complexity
> (which leads to weaker security) and opens the door to interoperability
> issues and fights over why algorithm X was allowed and Y was not.
>
> 2: Having more than 1 algorithm forces implementations to understand that
> there is not just one, and so should help lead towards algorithm agility
>
> 3: In order to do DANE, you have to be able to do DNSSEC -- in order to do
> DNSSEC you should already support the above.
>
> 4: (IMO, an important one, even if not technical one) giving people the
> ability to choose will lead to greater deployment. Some folk will claim that
> SHA-256 is too short. Some will claim that SHA-384 is excessively long and
> computationally expensive. Some will claim something completely random.
> Almost none of them will have any (rational) basis for their claims, but
> allowing them to use the algorithm they believe is superior will make them
> more likely to deploy.
>
> 5: 2 algorithms seems like enough. While SHA1 may or may not be suitable
> (my (and to be completely blunt, your) views don't really matter) -- there
> are enough strong views on the strength / lifetime that we are likely to get
> bogged down / splinter over this. If we were already deployed with SHA1 this
> would be an important decision, but seeing as we're not, I think that
> avoiding fight (and living to see another day) is best.
> Once again, I'm not saying that I think that SHA1 is (or isn't) fine for
> this, rather that, in order to get deployed, we should avoid the issue.
>
> #4 and #5 might be pandering, but if it doesn't decrease security, and
> leads to sooner / more deployment it seems like a win....
>
> Please don't let this dissolve into a "algorithm X is better than Y, and Z
> is a pile o' rubble" discussion -- while that may be true, this is not the
> time or place to have it....
> </chair hat>
>
> W
>
>
> > Need to specify which crypto algorithms and certificate types are
> mandatory to implement --
> http://trac.tools.ietf.org/wg/dane/trac/ticket/21
> >
> > Description:
> > Currently, the draft is silent on which crypto algorithms and certificate
> types must be implemented for interoperability. It should be specific before
> the document is finished.
> >
> >
> > W

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 03 Mar 2011 17:45:30 -0800

> That works for me

And me as well.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Mar 2011 13:46:17 +0100 (MET)

> there is not just one, and so should help lead towards algorithm agility

I'm OK with defining SHA-256 plus another, stronger hash for use with DANE

I'm OK with mandating SHA-256.

I do NOT buy the assertion that it is necessary to have _two_mandatory_
algorithms for algorithm agility.  For other protocols in the security
area, one single manadatory and additional recommended&optional
algorithms are perfectly sufficient.

SHA-384 also looks like an oddball to me.  For agility and interop tests,
defining SHA-512 should be fine.  I would expect that by the time
we need to move away from SHA-256, there is a SHA-3 available, and
it would be OK for DANE to move from SHA-256 mandatory to SHA-3 manadatory
without ever making SHA-512 mandatory (only recommended).

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 4 Mar 2011 08:57:09 -0500

OK, how about this

Define code points for

SHA2-256
SHA2-512
SHA3-256 (reserved)
SHA3-512 (reserved)

If SHA3 is ready in time (i.e. we are still not ready in 2012) we could
consider making SHA3-256 the required algorithm. If not make SHA2-256 and
SHA2-512 the required algorithms.

I don't see the objective here being 'algorithm agility' like we were
fixated on in the 90s. We are not picking eight algorithms with a similar
level of security in the hope that one of them is going to be secure.

What we are doing here is coping with the fact that at the moment we do not
have an industry standard digest function that we can be completely happy
with and we are currently in the mid point of a transition.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 05 Mar 2011 03:13:26 +1300

>SHA2-512 the required algorithms.

Sounds good, although I'd make 256 a MUST and 512 a MAY, both to keep the
every-bit-is-sacred crowd happy and because in practice there's going to be a
de facto universal default that everyone uses, and my guess is it'll be -256,
in the same way that currently the universal default that everyone uses is
SHA1, no matter what other algorithms the spec allows.

Peter.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 04 Mar 2011 06:39:12 -0800

> SHA3-512 (reserved)

This would only work if we knew today that there will be algorithms with 
those exact names. Those of us following the NIST hash competition have 
seen that there is a good chance that will *not* be the case: NIST is 
explicitly allowing (some would say encouraging) parameters on the 
functions.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 04 Mar 2011 06:58:32 -0800

On 3/4/11 6:13 AM, Peter Gutmann wrote:
> Phillip Hallam-Baker<[email-masked]>  writes:
>
>> OK, how about this
>>
>> Define code points for
>>
>> SHA2-256
>> SHA2-512
>> SHA3-256 (reserved)
>> SHA3-512 (reserved)
>>

While I prefer Warren's original proposal (two mandatory algorithms 
now), I can see a reason to have just one now followed by strong wording 
that we are likely to change this in the foreseeable future to a 
specific code point so implementers need to plan for that now. We don't 
have to be specific about what will go in that code point because we 
won't know until NIST is finished, but we can say that we expect that to 
become mandatory as well.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 4 Mar 2011 11:15:50 -0500

On Fri, Mar 4, 2011 at 9:39 AM, Paul Hoffman <[email-masked]> wrote:

> those exact names. Those of us following the NIST hash competition have seen
> that there is a good chance that will *not* be the case: NIST is explicitly
> allowing (some would say encouraging) parameters on the functions.

All the finalists are designed to be used as a drop in replacement for SHA2,
which is a mandatory requirement.

But I do prefer using a hash that incorporates random data in the hash
mechanism. It provides a lot of protection against attack, in most cases an
attacker has to achieve a first preimage attack rather than a second.

So while we could certainly reserve a slot now, it is likely that there will
be further discussion on the choice of mode. And I would really like us to
be having one IETF conversation at that point and not ten with different
combinations of what is mostly the same people.

Since we are going to be using this with TLS it is probably going to make
most sense to consider what algorithms TLS is going to use.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 4 Mar 2011 08:48:07 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Gutmann
> Sent: Friday, March 04, 2011 6:13 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
> 

If the experience with DKIM (which did MUST for SHA1 and SHOULD for SHA256) is any indication, your guess is right on the money.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 4 Mar 2011 08:49:43 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Thursday, March 03, 2011 5:46 PM
> To: [email-masked]
> Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"
> 

+1

---

From: Ben Laurie <[email-masked]>
Date: Fri, 4 Mar 2011 17:37:18 +0000

> 3: In order to do DANE, you have to be able to do DNSSEC -- in order to do DNSSEC you should already support the above.

Hang on. SHA-384? I don't think that is required by DNSSEC.

---

From: Jakob Schlyter <[email-masked]>
Date: Sat, 5 Mar 2011 10:01:31 +0100

> Hang on. SHA-384? I don't think that is required by DNSSEC.

Correct, in order to require what DNSSEC use we should specify SHA-256 and SHA-512.

	jakob

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 05 Mar 2011 07:59:48 -0800

On 3/5/11 1:01 AM, Jakob Schlyter wrote:
>> On 3 March 2011 19:36, Warren Kumari<[email-masked]>  wrote:
>>> Hi all,
>>>

Not actually correct, and not actually relevant.

It is not correct in that DNSSEC only defines hashes as part of 
signature algorithms, not separately. And, if we are going to go that 
route, the only hash that is mandatory for DNSSEC is SHA-1; it feels 
like this WG doesn't want to go there.

It is also not relevant because we do not demand TLS applications to be 
doing DNSSEC themselves: they simply need to know that DNSSEC was used 
on the data they receive.

This is not an argument against SHA-512, but if we are going to make 
arguments for its use, let's make sensible ones. I don't think there are 
many sensible ones for anything other than SHA-1, so we can just pick 
what we want.

--Paul Hoffman

---

From: "George Barwood" <[email-masked]>
Date: Sat, 5 Mar 2011 16:26:29 -0000

----- Original Message ----- 
From: "Paul Hoffman" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, March 05, 2011 3:59 PM
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

> signature algorithms, not separately. 

Not quite, there are actually three contexts where DNSSEC defines hashes.

Signature algorithms, where RSASHA256 and RSASHA512 are the most modern.

The DigestType for a DS record, where SHA1 and SHA256 are the ones defined.

And finally the NSEC3 hash function, where only SHA1 is defined.

George

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 5 Mar 2011 11:33:01 -0500

We do require TLS however.

VeriSign and Comodo have created roots with SHA2-256 and SHA2-384, the
choice is thus not 'oddball'.

>From a strict security point of view SHA2-512 is more secure than SHA2-384,
there is no attack on 512 that will not also break 384.

However, there is an interesting piece of logic at work here.

First, let me point out that SHA2-384 (m) = trunc (SHA2-512 (m), 384). Its
the same algorithm, just truncated.

The criteria for abandoning an existing digest is not when the work factor
below a certain threshold, it is when the work factor falls significantly
below that advertised.

Thus we started getting worried about SHA1 when attacks were announced that
shaved only about 15 bits off the strength, even though what remained was
sufficient for any purpose. The reason we got worried was that customers
started to ask questions and that starts to cost real money when you have a
lot of customers and a lot of sales people.

So SHA2-384 is to be preferred over SHA2-512 because even though it is
easier to break, it has a much higher safety factor.

If someone comes up with an attack against SHA2-512 with O(2^480/2)
complexity it would reduce the cost of attacking SHA2-512 but not the cost
of attacking SHA2-384. So the 512 bit version would be 'compromised' but the
384 version would not.

On Sat, Mar 5, 2011 at 10:59 AM, Paul Hoffman <[email-masked]> wrote:

>>>> 3: In order to do DANE, you have to be able to do DNSSEC -- in order to
>>>> do DNSSEC you should already support the above.
>>>>
>>>
> It is not correct in that DNSSEC only defines hashes as part of signature
> algorithms, not separately. And, if we are going to go that route, the only
> hash that is mandatory for DNSSEC is SHA-1; it feels like this WG doesn't
> want to go there.
>
> doing DNSSEC themselves: they simply need to know that DNSSEC was used on
> the data they receive.
>
> many sensible ones for anything other than SHA-1, so we can just pick what
> we want.
>
> --Paul Hoffman
>

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 05 Mar 2011 08:35:46 -0800

On 3/5/11 8:26 AM, George Barwood wrote:
> From: "Paul Hoffman"<[email-masked]>
> To:<[email-masked]>

<sigh> Quite right. And, for those of you who want to find these (I 
missed the middle one and purposely ignored the last one), they are at

- Signature algs: <http://www.iana.org/assignments/dns-sec-alg-numbers>

- DigestType for DS: <http://www.iana.org/assignments/ds-rr-types/>

- NSEC3: <http://www.iana.org/assignments/dnssec-nsec3-parameters>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 5 Mar 2011 11:43:02 -0500

On Sat, Mar 5, 2011 at 11:26 AM, George Barwood <
[email-masked]> wrote:

> algorithms and certificate types are mandatory to implement"
>
>

Lets say you live in a house built in 1980, it does not have smoke alarms.
But you want to buy a new house, it has to have smoke alarms and if you
renovate an old house, you have to retrofit.

We can't depend on existing protocols for precedent here. DNSSEC is in the
middle of a deployment phase and the code base is going to be changing for
some time. I do not expect us to have a final code base for verifiers until
long after the algorithm competition concludes in 2012.

At the conclusion of the competition I expect that we will have a complete
suite of symmetric algorithms that there is a broad industry consensus to
support. At that point I would expect that to become a requirement across
the board.

The concern about the security of SHA1 is sufficient to make use in new
protocols inappropriate but does not rise to the level of justifying
emergency action to update existing protocols.

---

From: Jakob Schlyter <[email-masked]>
Date: Sun, 6 Mar 2011 09:41:13 +0100

On 5 mar 2011, at 16.59, Paul Hoffman wrote:

> This is not an argument against SHA-512, but if we are going to make arguments for its use, let's make sensible ones. I don't think there are many sensible ones for anything other than SHA-1, so we can just pick what we want.

I agree and after some more thinking (and reading) about this I do believe we should settle for SHA-256 and SHA-384 as the initial set of, and mandatory to implement, digest algorithms for TLSA (just as Warren proposed).

	jakob

---

From: Martin Rex <[email-masked]>
Date: Mon, 7 Mar 2011 15:25:57 +0100 (MET)

> choice is thus not 'oddball'.

I assume you rather mean the signature algorithms
sha256WithRsaEncryption OID { 1, 2, 840, 113549, 1, 1, 11 }
sha384WithRsaEncryption OID { 1, 2, 840, 113549, 1, 1, 12 }

rather than the hash algorithms.

> below a certain threshold, it is when the work factor falls significantly

Nope, I doesn't have anything to do with advertisements.
The problem is when _assumptions_ about an algorithms strength are
shown to not hold, independent of how "strong" that algorithm is
advertised.

This is why we do worry about md5 when used for digital signatures,
and worry much less when md5 is used as HMAC-MD5 for integrity protection
of online communication protocols.

> of attacking SHA2-384. So the 512 bit version would be 'compromised' but the

That is marketing nonsense.

With that reasoning, we should use SHA-512/256 rather than SHA-256

  http://www.schneier.com/blog/archives/2011/02/nist_defines_ne.html
  http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4

I don't see any value in mandating any algorithm beyond SHA-256
at this point -- anticipating that there is going to be SHA-3
in the not so far future and a desire to support SHA-3 in DANE.

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Mar 2011 16:52:54 +0200

>  http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4

The point of SHA-512/256 is not marketing or even security, but speed.
http://eprint.iacr.org/2010/548.pdf

> in the not so far future and a desire to support SHA-3 in DANE.

I disagree. SHA-512 (and -384) are touted for longevity - we hope that they will be resistant to pre-image and collision attacks for longer than SHA-256. This is important for document signing and somewhat for certificates, but not so much for resource records. If it takes a year from "sha-256 broken" to "exploit in the wild", that's plenty of time to replace all resource records.

So it doesn't make sense to publish SHA-384 resource records now, but we need the consumers of such records to be ready for SHA-384 records. The reason that the transition from MD5 to SHA-1 certificates was so smooth is that all browsers at the time supported SHA-1. 

Yoav

---

From: Chris Palmer <[email-masked]>
Date: Mon, 7 Mar 2011 10:02:31 -0800

Let's end this thread and move to the next important topic.

-- 
Chris Palmer
Technology Director, Electronic Frontier Foundation

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 07 Mar 2011 10:19:03 -0800

> Let's end this thread and move to the next important topic.

The document authors need to hear from the WG chairs what the rough 
consensus on this issue is before we can instantiate it in the next 
draft. Are you saying that the rough consensus is obvious, or that you 
believe there can be none and we should give up, or...?

---

From: Warren Kumari <[email-masked]>
Date: Mon, 7 Mar 2011 18:09:23 -0500

On Mar 7, 2011, at 1:19 PM, Paul Hoffman wrote:

> The document authors need to hear from the WG chairs what the rough consensus on this issue is before we can instantiate it in the next draft.

<chair hat>
The WG chairs (well, this one at least) sees no consensus yet[0]....
</chair hat>

> Are you saying that the rough consensus is obvious, or that you believe there can be none and we should give up, or...?

W
[0]: I'm sure that you already knew that (and that that was your point), but figured I'd make it explicit....

---

From: Chris Palmer <[email-masked]>
Date: Mon, 7 Mar 2011 16:05:39 -0800

> The WG chairs (well, this one at least) sees no consensus yet[0]....

Actually, I thought that people had roughly agreed to specify SHA-256 and -384 and to create a slot for SHA-3. If I'm wrong and that's not what people have roughly agreed, then I apologize and here are my two cents: As long as the minimum is -256 with a plan for SHA-3, I'm happy.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 07 Mar 2011 17:03:32 -0800

On 3/7/11 4:05 PM, Chris Palmer wrote:
> Actually, I thought that people had roughly agreed to specify SHA-256
> and -384 and to create a slot for SHA-3. If I'm wrong and that's not
> what people have roughly agreed, then I apologize and here are my two
> cents: As long as the minimum is -256 with a plan for SHA-3, I'm
> happy.

One specific thing that this author would like to see is what you and 
others specifically mean by "a slot for SHA-3" and "a plan for SHA-3". 
To me, those are quite different. We already have slots for SHA-3, 
SHA-42, and so on; they are not named as such, but they are there.

We do not have a plan for anything that is not currently listed in the 
document: they are just slots. If you or others want "a plan for SHA-3", 
what would that say in specific?

My personal opinion is "SHA-256 and SHA-384 (or 'and SHA-512') and slots 
for others in the future but with no plan for those slots", but a few 
folks here have spoken of plans (which means more words), so I don't 
have words to suggest for plans.

--Paul Hoffman

---

From: Chris Palmer <[email-masked]>
Date: Mon, 7 Mar 2011 17:41:20 -0800

On Mar 7, 2011, at 5:03 PM, Paul Hoffman wrote:

> One specific thing that this author would like to see is what you and others specifically mean by "a slot for SHA-3" and "a plan for SHA-3". To me, those are quite different. We already have slots for SHA-3, SHA-42, and so on; they are not named as such, but they are there.

Change this:

"""
4.3.  TLSA Hash Types

   This document creates a new registry, "Hash Types for TLSA Resource
   Records".  The registry policy is "Specification Required".  The
   initial entries in the registry are:

   Value        Short description       Ref.
   -----------------------------------------------------
   0            No hash used            [This]
   1            SHA-1                   NIST FIPS 180-2
   2            SHA-256                 NIST FIPS 180-2
   3            SHA-384                 NIST FIPS 180-2
   4-254        Unassigned

   Applications to the registry can request specific values that have
   yet to be assigned.
"""

To something like this:

4.3.  TLSA Hash Types

   This document creates a new registry, "Hash Types for TLSA Resource
   Records".  The registry policy is "Specification Required".  The
   initial entries in the registry are:

   Value        Short description       Ref.
   -----------------------------------------------------
   0            No hash used            [This]
   1            SHA-1                   NIST FIPS 180-2
   2            SHA-256                 NIST FIPS 180-2
   3            SHA-384                 NIST FIPS 180-2
   4            Reserved
   5            Reserved
   6-254        Unassigned

   Applications to the registry can request specific values that have
   yet to be assigned. Note that that types 4 and 5 are reserved to
   indicate the SHA-3 algorithm, when it is defined. Future revisions
   to this document SHALL require implementations to support SHA-3, and
   implementors SHOULD prepare for this with a flexible implementation
   strategy.

I don't really speak RFC-ese, but hopefully this makes enough sense. :)

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 08 Mar 2011 17:06:29 +1300

Paul Hoffman <[email-masked]> writes:

>Are you saying that the rough consensus is obvious, or that you believe there
>can be none and we should give up, or...?

I believe we should shoot anyone who doesn't agree that { SHA256 + SHA3 } is
the right solution.  Then we will have consensus and can move on.  But that's
just my opinion...

Peter.

---

From: [email-masked]
Date: Tue, 8 Mar 2011 04:55:08 +0000

> the right solution.  Then we will have consensus and can move on.  But that's

	two to the chest, one to the head...

or in other words

+1

--bill (I beleive also)

---

From: Brian Smith <[email-masked]>
Date: Mon, 7 Mar 2011 22:23:08 -0800 (PST)

> cents: As long as the minimum is -256 with a plan for SHA-3, I'm

It would be better to have both SHA-384 mandatory for clients. Those two algorithms are already practically required because they are both required for a good implementation of TLS 1.2. Making SHA-384 mandatory for clients makes it easier for server administrators to switch from SHA-256 to SHA-384 if that would ever be helpful; that could be a real possibility considering the deployment of SHA-3 on clients is a long way off.

Cheers,
Brian

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 8 Mar 2011 08:20:50 +0100

> It would be better to have both SHA-384 mandatory for clients. Those two algorithms are already practically required because they are both required for a good implementation of TLS 1.2. Making SHA-…

+1 - having two algorithms (although from the same family) from the start is better than just one. And we add SHA-3 and friends later - no need to "reserve" code points for them at this point.

	jakob

---

From: Ben Laurie <[email-masked]>
Date: Tue, 8 Mar 2011 09:06:35 +0000

> the right solution.  Then we will have consensus and can move on.  But that's

+1 :-)

Don't really see the point of SHA-384 myself, but I'm not particularly
opposed to its inclusion.

SHA3 obviously doesn't exist yet, but happy to have it included in the plan.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 8 Mar 2011 09:32:25 +0000

> sha384WithRsaEncryption OID { 1, 2, 840, 113549, 1, 1, 12 }

Yes, and also...

ecdsa-with-SHA384 OID { 1 2 840 10045 4 3 3 }

> > The criteria for abandoning an existing digest is not when the work
> > factor below a certain threshold, it is when the work factor falls
> > significantly below that advertised.
> 
> > complexity it would reduce the cost of attacking SHA2-512 but not the
> > cost of attacking SHA2-384. So the 512 bit version would be
> > 'compromised' but the 384 version would not.
> 

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.

---

From: "George Barwood" <[email-masked]>
Date: Tue, 8 Mar 2011 10:24:02 -0000

----- Original Message ----- 
From: "Ben Laurie" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 08, 2011 9:06 AM
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

> Don't really see the point of SHA-384 myself, but I'm not particularly opposed to its inclusion.

SHA-384 is faster to compute than SHA-256 on 64-bit machines, and has a bigger margin of security.

It's cheap to include it now, and avoids a potential big headache if/when SHA-256 proves to be vulnerable.

That doesn't seem very likely in the near future, but history indicates that we shouldn't be too confident.

By the same argument SHA-512 could also be defined, even if we don't expect to use it any time soon.

There is a reason NIST defined these functions ( even if as non-specialists we may not fully understand ).

---

From: Sean Turner <[email-masked]>
Date: Tue, 08 Mar 2011 10:58:49 -0500

> +1 - having two algorithms (although from the same family) from the start is better than just one. And we add SHA-3 and friends later - no need to "reserve" code points for them at this point.

I think I'm in this camp.  It's hard to use 2119-language for something 
that nobody can claim conformance to.  Somebody is still going to need 
to write a draft that says here's the SHA-3 alg, here's it's reference 
and we're updating the registry regardless so I think the draft could 
just as well do this:

    Value        Short description       Ref.
    -----------------------------------------------------
    0            No hash used            [This]
    1            SHA-1                   NIST FIPS 180-3
    2            SHA-256                 NIST FIPS 180-3
    3            SHA-384                 NIST FIPS 180-3
    4-254        Unassigned

    Applications to the registry can request specific values that have
    yet to be assigned. Note that there is every intent to update this
    registry when [SHA-3] is finalized.  Implementors are strongly
    encouraged to support a flexible implementation strategy in order
    to support an orderly migration to [SHA-3] shortly after this
    registry is updated.

or something like that.

I can already envision the GEN-Art comment/IESG discuss on needing a 
stable reference for SHA-3 if it's a normative reference.  If there's no 
requirements associated with it you'll probably get away with an 
informative reference to [SHA-3]:

[SHA-3] "Cryptographic Hash Algorithm Competition", NIST Computer
         Security Resource Center Cryptographic Hash Project.

There is precedent to using this reference but it was in a draft with an 
intended status of informational and it was an informational reference.

spt

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 8 Mar 2011 08:10:21 -0800

On Mar 8, 2011, at 7:58 AM, Sean Turner wrote:
> I think I'm in this camp.  It's hard to use 2119-language for something that nobody can claim conformance to.  Somebody is still going to need to write a draft that says here's the SHA-3 alg, here's it's reference and we're updating the registry regardless so I think the draft could just as well do this:
> 

I still don't get why SHA-384 instead of SHA-512.  SHA-384 just seems silly to me: its no FASTER than SHA-512, it MUST be less secure than SHA-512, and the "every bit is sacred" zombie-idea in DNS needs its head lopped off: 16B larger hashes does NOT make a difference in DNS, especially for a single signature over a big blob of data.

(Not that I'm saying it should impede this group, I'm happing with the language above or similar, I just want to know why people want to use SHA-384 instead of SHA-512!)

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 08 Mar 2011 08:26:18 -0800

> (Not that I'm saying it should impede this group, I'm happing with the language above or similar, I just want to know why people want to use SHA-384 instead of SHA-512!)

There is some reason to believe that the final SHA-3 spec will have a 
384-bit hash that will be faster to calculate than the 512-bit version, 
and it will be hard to convince people who were using SHA-2-512 that 
going to SHA-3-384 is a good move. They'll claim that it is less safe 
because they didn't realize that they didn't even need the strength in 
SHA-2-256 to start with.

It's all headology, unfortunately.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Mar 2011 17:57:34 +0100 (MET)

Nicholas Weaver wrote:
> 
> I still don't get why SHA-384 instead of SHA-512.
> SHA-384 just seems silly to me: its no FASTER than SHA-512,
> it MUST be less secure than SHA-512.

There is no reason to this (in the sense of reasonable explanation).

It fosters on the premise that SHA-1 is completely and throroughly
broken and SHA-256 impaired by more serious attacks than currently
known for SHA-1 _long_ before a SHA-3 finalist is selected.

The only two situations, where *I* believe that having more than
one mandatory to implement hash algorithms for DANE would make sense:

  1)  when SHA-1 was permitted (which no one seems to be asking for)
  2)  when the SHA-3 winner has been determined (which hasn't happened yet)

Personally, I would strongly prefer the hash algorithm list for
DANE to be

   1)   SHA-256      (FIPS 180-3)    MUST implement
   2)   SHA-512      (FIPS 180-3)    SHOULD implement

Personally, I believe that SHA-384, and more so SHA-224 should have
never been defined by NIST, because they constantly confuse the
crypto-clueless about the purpose of these algorithms and cause
needless discussions.

-Martin

---

From: [email-masked]
Date: Tue, 8 Mar 2011 17:39:24 +0000

On Tue, Mar 08, 2011 at 08:26:18AM -0800, Paul Hoffman wrote:
> >(Not that I'm saying it should impede this group, I'm happing with the 
> >language above or similar, I just want to know why people want to use 
> >SHA-384 instead of SHA-512!)
> 

	and what are those reasons?

--bill

---

From: [email-masked]
Date: Tue, 8 Mar 2011 18:05:16 +0000

> known for SHA-1 _long_ before a SHA-3 finalist is selected.

	my working analog here is that you don't shoot at a moving
	target - you shoot ahead of it.

	given the pace of the IETF processes, I fully expect there will
	be a SHA-3 finalist selected before this spec lands.  (YMMV of course)

--bill

---

From: Yoav Nir <[email-masked]>
Date: Tue, 8 Mar 2011 22:41:30 +0200

> because they didn't realize that they didn't even need the strength in 

That would explain the relatively slow adoption of ECDSA. I want my 2048 bits of security.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 8 Mar 2011 15:47:06 -0500

Quite possibly, but most people know not to wait for IETF process before
deployment.

I don't like the idea of SHA2-512/256 because the new IV is going to require
people to use a different code library to get support and that may be
tricky.

Given that SHA2-512 is fastest on 64 bit machines and given that these are
now the mainstream, would it not make sense to simply go to SHA2-384 or
SHA2-512 as the only mandatory for the time being with the expectation of
adding in some flavor of SHA3 when that is possible?

I think we need to break this down in matrix fashion

1) Attack
    A compromise that could lead an attacker to break DANE.

2) Reputation
   A compromise that falls short of enabling an actual attack against DANE
but will lead to concerns amongst users and pressure for a new algorithm.
(c.f. demands to change HMAC-MD5 despite no evidence this is necessary).

3) Support
   Is the algorithm supported in standard cryptographic toolkits, is
widespread support to be expected in the future.

4) Performance
    Not really a factor for this application but will determine whether it
is used for other purposes.

5) Industry
   Is the algorithm THE industry standard or merely A standard.

SHA-1:  Good for 20 years on attack but unknown as far as reputation. Is the
main target of cryptanalysis at the moment. Support is universal.

SHA2-256: Good for 30+ years on attack and at least 10 for reputation.
Support is near universal.

SHA2-386: Good for 40+ years on attack and probably 30+ for reputation.
Support is near universal

SHA2-512: Good for 50+ years on attack but likely 20+ on reputation due to
the fact that if 512 bits is specified in a protocol it is difficult to
explain why less than 512 bits are necessary.

SHA3-*: Will be THE standard in some strength as far as we can predict.
While it is possible something else will beat SHA3, I can't see that
happening and people being happy with SHA2.

So my recommendation would be

1) Do not define any code point for SHA1.

2) Define code point for SHA2-384

3) Expect to support SHA3 in the future via some mechanism. Add it to the
draft if the competition schedule makes this practical.

As a general rule I would prefer to only define IANA code points for
algorithms that the IETF REQUIRES.

I would support all other crypto by reserving one code point for specifying
algorithms by means of ASN.1 OID prefix.

The reason for doing that is that it means that the group does not need to
consider the inevitable requests to support other algorithms or deal with
the damage caused when a refusal is ignored.

We cannot stop the Russian federation from using GOST but we can stop them
getting a reserved code point.

---

From: Chris Palmer <[email-masked]>
Date: Tue, 08 Mar 2011 15:21:58 -0800

On 03/08/2011 12:47 PM, Phillip Hallam-Baker wrote:

> Given that SHA2-512 is fastest on 64 bit machines and given that these
> are now the mainstream,

Not necessarily. For normal servers, yes of course; but having spiffy
machines means that the previous generation of spiffy machines is now
available for use in cheap appliances. Lots of people want those, too,
and want them to perform well.

I personally wouldn't mind having SHA-512 be the only mandatory hash,
but reasonable people will bring up this "why penalize cheap servers"
argument.

https://www.eff.org/code

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 09 Mar 2011 12:42:56 +1300

Phillip Hallam-Baker <[email-masked]> writes:

>now the mainstream, 

Really?  When did smart phones and the like switch to 64-bit processors? I must 
have missed the announcement.

(The platforms where performance is irrelevant because the CPU is just sitting 
there twiddling its thumbs waiting for the next job, desktop PCs and the like, 
are 64-bit, although even there most are running in 32-bit mode.  The platforms 
where performance is critical because of lack of CPU power and lack of battery 
power to drive it, are all 32 bit).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 09 Mar 2011 12:48:47 +1300

Martin Rex <[email-masked]> writes:

>The only two situations, where *I* believe that having more than one 
>mandatory to implement hash algorithms for DANE would make sense:
>
>Personally, I would strongly prefer the hash algorithm list for DANE to be
>

+1.

>Personally, I believe that SHA-384, and more so SHA-224 should have never 
>been defined by NIST, because they constantly confuse the crypto-clueless 
>about the purpose of these algorithms and cause needless discussions.

Even more so.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 09 Mar 2011 12:51:55 +1300

[email-masked] writes:

>given the pace of the IETF processes, I fully expect there will be a SHA-3 
>finalist selected before this spec lands. (YMMV of course)

That was my feeling as well, which is why I've been pushing for slots for
SHA3 (specifically, SHA3-256 MUST, SHA3-512 MAY).

Peter.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 08 Mar 2011 16:18:00 -0800

On 3/8/11 3:48 PM, Peter Gutmann wrote:
>
> Martin Rex<[email-masked]>  writes:
>

FWIW, I have been saying that I support two MUSTs, but I think most of 
the milage of that is gotten by one MUST and one SHOULD.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 11 Mar 2011 13:45:54 -0500

Ok, 

We are calling (rough) consensus as:

SHA-256 MUST be implemented.
SHA-512 SHOULD be implemented.

We fully expect to support SHA-3 once it is finalized, but we are not currently reserving code-points for it. 
We can re-visit code-points for SHA-3 as we know more about it, how many code-points it should have, etc. 

W

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Mar 2011 10:57:43 -0800

> We can re-visit code-points for SHA-3 as we know more about it, how many code-points it should have, etc.

Jakob and I will put out a new draft on Monday with this plus some 
different wording on trust anchors (the latter being still confusing to 
some folks).

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Fri, 11 Mar 2011 14:00:10 -0500

On Mar 11, 2011, at 1:57 PM, Paul Hoffman wrote:

> Jakob and I will put out a new draft on Monday with this plus some different wording on trust anchors (the latter being still confusing to some folks).

The chairs would like to thank our authors for being on top of things, quickly integrating WG consensus and writing such a readable doc....

W

---

From: Tony Hansen <[email-masked]>
Date: Fri, 11 Mar 2011 16:18:24 -0500

On 3/8/2011 11:26 AM, Paul Hoffman wrote:
>> (Not that I'm saying it should impede this group, I'm happing with 
>> the language above or similar, I just want to know why people want to 
>> use SHA-384 instead of SHA-512!)
>

Given what NIST is doing with FIPS-180-4-draft and defining SHA-512/t, 
I'd be surprised if that were true. But it will be interesting to see 
what comes out of SHA3.

> It's all headology, unfortunately.

     Tony Hansen
     [email-masked]