This is a discussion on Re: Usefulness of ECC-DSA algorithm for DNSSEC - DNS ; As some of you are aware of I asked an IRTF group on cryptograph CFRG some questions on use of ECC in DNSSEC. This is done to identify any potential research issues related to possible use of ECC in DNSSEC. ...
As some of you are aware of I asked an IRTF group on cryptograph CFRG
some questions on use of ECC in DNSSEC. This is done to identify any
potential research issues related to possible use of ECC in DNSSEC.
Any output from CFRG (or other forums) will be fed into DNSEXT before
any standards actions.
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.
The DNSEXT working group has been considering for some time to add support
for ECC. Any deployment of ECC will be gradual, there are no plans to
It is possible that ECC might replace DSA as mandatory to implement.
Currently ECC is a minefield of IPR claims, FUD etc.
This requires careful consideration of ECC and different curves before
the DNSEXT working group can proceed.
Any zone can sign with any supported algorithm, using a algorithm that
is not as widely supported as RSA has the risk that a zone appears
unsigned to some resolvers. For background on this issue look at
RFC3090, issues locally and globally secure.
To answer your quotes from below, following is=20
perfectly valid from the protocol point.
. signed by RSA/SHA256
COM signed by RSA/SHA1
EXAMPLE.com signed by DSA
child.example.com signed by RSA/MD5
grandchild.example.com signed by DSA
But for a validator the trust chain is broken when it is faced with the
first algorithm it does not understand/support.=20
As some Validator's have removed
support for RSA/MD5 that zone risks becoming=20
viewed as insecure, and its children
are treated insecure because of the parent.
At 09:52 27/03/2006, Thierry Moreau wrote:
>Mike, thanks for this reply.
>I agree, but only in theory without much=20
>practical impact: the freedom to drop RSA-SHA1=20
>seems restricted to the islands of security=20
>(including the root), by implication of RFC4035 section 2.
>Relevant RFC4035 citations:
>2.2. Including RRSIG RRs in a Zone
>[...] There MUST be an RRSIG for each=20
>[authoritative] RRset using at least one DNSKEY=20
>of each algorithm in the zone apex DNSKEY=20
>RRset. The apex DNSKEY RRset itself MUST be=20
>signed by each algorithm appearing in the DS=20
>RRset located at the delegating parent (if any).
>2.4. Including DS RRs in a Zone
>[...] All DS RRsets in a zone MUST be signed, [...]
>A DS RR SHOULD point to a DNSKEY RR that is=20
>present in the child's apex DNSKEY RRset, and=20
>the child's apex DNSKEY RRset SHOULD be signed=20
>by the corresponding private key. DS RRs that=20
>fail to meet these conditions are not useful for=20
>validation, but because the DS RR and its=20
>corresponding DNSKEY RR are in different zones,=20
>and because the DNS is only loosely consistent,=20
>temporary mismatches can occur. [...]
>[end of citation]
>In other words, a DNSSEC signature algorithm=20
>present at an island of security is recursively=20
>mandated (except for temporary mismatches in DNS=20
>consistency) to secure child zones.
>Hence my original question to =D3lafur and others=20
>who *might* be playing with the idea of droping RSA-SHA1 at the DNS root.
>Again, thanks in advance for your clarifications.
>- Thierry Moreau
>CONNOTECH Experts-conseils inc.
>9130 Place de Montgolfier
>Canada H2M 2A1
>web site: http://www.connotech.com
>Mike StJohns wrote:
>>At 11:57 PM 3/26/2006, Thierry Moreau wrote:
>>>However, the RSA-SHA1 RRSIGs would still be=20
>>>mandatory in DNSSEC replies in any event,=20
>>>since RSA-SHA1 is mandatory-to-implement.
>>No. Mandatory to implement just means the=20
>>resolvers and the signers have to understand=20
>>the signatures. The actual zone data can be=20
>>signed by some, all or none of the algorithms=20
>>and keys that exists within the zone.
>>So, having a zone signed with ECC vs RSA (not=20
>>ECC *and* RSA) would actually reduce the size of replies.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.