Re: [dane] Digest Algorithm Agility discussion

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Viktor Dukhovni writ
es:
> 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.

If you don't trust a algorithm you should not be using it.  Period.
This fall back to this untrusted/broken algorithm is bad engingeering
and bad security practice.

If the site you want to email only has broken TLSA records, get
them on the phone to fix the problem.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]