Re: [dane] Digest Algorithm Agility discussion

[Viktor Dukhovni <[e-mail]>]

On Mon, Mar 24, 2014 at 04:42:05AM +1100, Mark Andrews wrote:

> Truly, we do not know which of SHA256 and SHA512 will be broken
> first.  Both are more than strong enough for this job at this point
> in time.

Agree with this 100%.

> When one is broken it will no longer be strong enough.
> Neither will be broken by brute force.  They will be broken by
> discoveries of flaws in the algorithms.  We support multiple
> algorithms so that when/if one is broken we do not end up in a
> situation of having no trusted algorithms supported.

I assume that once the SHA3 (aka Keccac) specification is finally
published by NIST, there will be a DANE-related draft registering
at least two new matching type algorithms for TLSA records:

    3	SHA3-256
    4	SHA3-512

At that point, a client evaluating a TLSA RRset will have a real
choice, for example: SHA2-256 vs. SHA3-256.

The reason the SHA3 competition was held and the Keccac sponge
construction was selected, is that with MD5 and SHA1 looking broken
and vulnerable respectively, there was a desire to find new hash
primitives that are based on new ideas.

So SHA3 is essentially our insurance policy on further progress
against the similar SHA1 and SHA2 designs.  While for now progress
along these lines appears to be stalled, it is not unreasonable to
admit the *possibility* that it might resume again.

Initially, clients may be configured to prefer SHA2-256 (which is
both mandatory to implement and has stood the test of time).  However,
later if there is any trouble on the SHA2 front, the client can be
updated to prefer SHA3 (when published by the server) to SHA2.

The proposed specification provides a transition mechanism with no
flag day, algorithms can be deprecated (relative to more preferred
algorithms) without being disabled.

If a server publishes:

	SHA2-256
	SHA2-512
	SHA3-256

And the client's preference order is (best to worst):

    SHA3-256,
    SHA2-512,
    SHA2-256,

then the client will only evaluate the TLSA records with SHA3-256 digests
and if none match, authentication fails.  Today the client can prefer:

	SHA2-256,
	SHA2-512

And, since both are currently believed well out of reach of even
state-funded adversaries, save itself the wasted cycles of computing
SHA2-512 when both are published.

The point of Wes's choice "B" is that clients don't have to impose
a flag on themselves and drop weakened algorithms entirely, given
that many servers may not be publishing anything stronger.  Instead
with "B", the client uses the strongest mutually available option.

-- 
	Viktor.