Re: [dnsext] DNSSEC, robustness, and several DS records

[Phillip Hallam-Baker <[e-mail]>]

Some points responding to various issues in the thread.

1) No, it is not likely that we will have an issue with SHA-1 with respect
to DNSSEC. The reason for this is that DNSSEC is not used to provide
non-repudiation. Thus it is not necessary to be able to state today that we
are confident that SHA-1 will be acceptably secure in 20 years time.

I have asked Adi Shamir about likely progress on SHA1 and I think we are
good wrt DNSSEC for at least ten years.


2) Despite this, there is a cost to using non-standard or deprecated crypto.
Every single time someone wants to use a deprecated algorithm they have to
produce a justification for doing so. Those costs mount up and the point is
soon reached where the cost of constantly explaining why SHA-1 is safe is
greater than the switching cost.

I regret not proposing to upgrade DIGEST to SHA1 when we had the chance.
Even though it would not add any security to the scheme (any attack on the
digest construction is dominated by brute forcing the password space), it
would have saved time overall.


3) There are real benefits to making exactly one set of cryptographic
algorithms mandatory across all IETF protocols. At this point we don't have
much discussion over whether to make RSA or AES mandatory they are just the
default mandatory algorithms to be used across the board. I expect that the
SHA3 competition will result in a similar situation for Digest and MAC
functions.

That will still leave some niche requirements for RC4 and DSA and once all
the patents are expired there will be a likelihood of adding ECC. But as far
as mandatory to implement is concerned, I think we can limit the set to
RSA2048 + AES + SHA3 + SHA3-MAC.


4) Since SHA3 is being worked on right now, it would seem to me that the
appropriate upgrade path for DNSSEC would be to ignore SHA2 and skip
straight from SHA1 to SHA3.


5) Since RSA1024 is in the process of being deprecated, DNSSEC may well turn
out to be one of the cases where there is an exception to requiring RSA2048.
DSA-SHA3 will be slower than RSA but the signatures created will be 512 bits
as opposed to 2048 and that is likely to make a difference for DNSSEC.


6) If we end up adding a mandatory algorithm we might well want to revisit
some of the other design considerations in DNSSEC. At the time Don made his
original proposals there were several optimizations that could have been
employed that were in patent. Now those patents are expired it may make
sense to re-open them.

One of the biggest hassles in DNSSEC is that the RRSIG records cover
individual record sets of the same type rather than all the records at a
domain. This is a fairly obvious candidate for using Merkle trees. So there
would be one public key signature for all the records in the zone and each
individual RRset would contain the intermediate tree nodes to enable it to
be verified.

The way I would do it would be to define a new Signature algorithm for
DSA+SHA3+Merkle Trees.




So my conclusion is that the group should take no action on SHA1 now but
that it should return to work on this topic after the SHA3 competition is
completed and it should consider a proposal that could start deployment long
before it became essential to make a switch.