Subject: Proposal, DSA 2048 with 256 bit subgroup

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Mar 2006 12:23:37 -0800

Ben Laurie asks
 
>> The two reason I'm exploring ECC are the size issue, and to have an
>> better answer next time someone ask why are you not using ECC.

>If size is the problem, what's wrong with DSA?

Until recently the fact that the key size was limited to 512 bits and the
hash function to 160 bits.
 
NIST recently approved a new version that allows a 2048 bit key size and 256
bit (or 224 bit) subgroup. This means the keys are 256 bytes, the signatures
are 64 bytes.
 
This is not quite as good as the best ECC scheme but we can deploy this
today and without the patent hassle that ECC would involve.
 
I propose the folowing:
 
1) Drop DSA-SHA1 from the spec, it is obsolete. 
2) Add DSA-2048-SHA256 as a MUST
3) Relegate the RSA algorithm to SHOULD

Time is getting short if DNSSEC is going to meet the next window of
opportunity for deployment. That is going to come with the deployment of
DKIM. If you want to deploy a security infrastructure you have to meet a
security requirement. The biggest deployment problem today is the fact that
DNS is perceived to work too well to justify the cost of DNSSEC.
 
The other picture change that has to occur here is the mistaken belief that
the protocol must be perfectly secure on day one. Emprically it is much
easier to upgrade a deployed infrastructure than to start deployment. The
opposition to OPT-IN and anti-zone walking technologies is entirely
misguided as is the entire thread on the level of security actually
provided.
 
DNSSEC is never going to be the last line of security defense. The DNS is a
signaling infrastructure, it is not a discovery infrastructure and its
naming capabilities are limited. The user should not expect 'ibm.com' to
resolve to the IBM that they are most familiar with, all they can expect is
that it will resolve consistently (over certain time intervals).
 
What we need from DNSSEC is a good layer of security to protect the
signaling layer infrastructure against attack and to allow the signaling
layer to be leveraged by application level security solutions such as
SenderID and DKIM. It does not have to be perfect for all purposes to do
this. 

People seem to have a 'single break' security model. This is not appropriate
to analysis of DNSSEC except with respect to zone signing keys for large,
valuable domains. I would not be at all worried about deploying based on
DSA-SHA1 causing problems within the next 5 years. The only reason I
strongly urge a change now is that this fix is much easier to do now and has
zero impact on the architecture (its just drop in of a new algorithm).  It
is going to be easier to SELL DNSSEC if the key strength matches
expectations.

WHEN security flaws are discovered in DNSSEC we will fix them. There have
been flaws in every crypto implementation successfully deployed to date -
SSL, WEP, PGP, SSH ... The only protocols that have escaped flaw discovery
are the ones nobody ever used. Despite these well known flaws I am not aware
of a single case where one has been exploited for criminal purposes. Even
flawed crypto is not the weakest link in the system.

What we cannot fix is a protocol that does not meet the deployment
constraints in the field.