Re: [keyassure] Opening issue #21: "Need to specify which crypto

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.

On Tue, Mar 8, 2011 at 1:05 PM, <bmanning@vacation.karoshi.com> wrote:

> On Tue, Mar 08, 2011 at 05:57:34PM +0100, Martin Rex wrote:
> >
> > 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.
> >
> >
> > -Martin
>
>        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
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure
>

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