Subject: Re: Usefulness of ECC-DSA algorithm for DNSSEC

From: Mike StJohns <[email-masked]>
Date: Sun, 26 Mar 2006 23:36:18 -0500

At 11:57 PM 3/26/2006, Thierry Moreau wrote:

>However, the RSA-SHA1 RRSIGs would still be mandatory in DNSSEC 
>replies in any event, since RSA-SHA1 is mandatory-to-implement.

No.  Mandatory to implement just means the resolvers and the signers 
have to understand the signatures.  The actual zone data can be 
signed by some, all or none of the algorithms and keys that exists 
within the zone.

So, having a zone signed with ECC vs RSA (not ECC *and* RSA) would 
actually reduce the size of replies.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 27 Mar 2006 09:52:39 -0500

Mike, thanks for this reply.

I agree, but only in theory without much practical impact: the freedom 
to drop RSA-SHA1 seems restricted to the islands of security (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 [authoritative] RRset using at 
least one DNSKEY of each algorithm in the zone apex DNSKEY RRset.  The 
apex DNSKEY RRset itself MUST be signed by each algorithm appearing in 
the DS 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 present in the child's apex 
DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed by the 
corresponding private key.  DS RRs that fail to meet these conditions 
are not useful for validation, but because the DS RR and its 
corresponding DNSKEY RR are in different zones, and because the DNS is 
only loosely consistent, temporary mismatches can occur. [...]

[end of citation]

In other words, a DNSSEC signature algorithm present at an island of 
security is recursively mandated (except for temporary mismatches in DNS 
consistency) to secure child zones.

Hence my original question to Ólafur and others who *might* be playing 
with the idea of droping RSA-SHA1 at the DNS root.

Again, thanks in advance for your clarifications.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

Mike StJohns wrote:
> have to understand the signatures.  The actual zone data can be signed 
> by some, all or none of the algorithms and keys that exists within the 
> zone.
>

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 27 Mar 2006 16:46:38 +0200

>
> In other words, a DNSSEC signature algorithm present at an island  
> of security is recursively mandated (except for temporary  
> mismatches in DNS consistency) to secure child zones.
>

No that is a wrong interpretation. The catch is in the "by each  
algorithm appearing in the DS RRset " part. So the algorithm field in  
the DS can point to "new" algorithms and you are not tied to one  
single algorithm recursively down the tree.

As an example consider this:

@origin example.
example     DNSKEY algo=RSASHA1 KSK id=1
example     DNSKEY algo=RSASHA1 ZSK id=2
example     RRSIG id=2

foo.example.  DS algo=CRYPTSAM hash=deadbeef
foo.example. RRSIG id=1

@originin foo.example
foo.example DNSKEY algo=CRYPTSAM KSK id=5
foo.example DNSKEY algo=CRYPTSAM ZSK id=6
foo.example RRSIG id=6

etc etc

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 27 Mar 2006 10:45:27 -0500

Olaf M. Kolkman wrote:
>> security is recursively mandated (except for temporary  mismatches in 
>> DNS consistency) to secure child zones.
>>
> 
> the DS can point to "new" algorithms and you are not tied to one  single 
> algorithm recursively down the tree.
> 

Thanks for helping my education. I.e. I agree with you and I apologize 
for the temporary doubt perhaps caused by my posts to the group.

This takes care of (what I thought was a radical) counter-argument to 
ECC-DSA as a signature algorithm in DNSSEC. Other issues about ECC 
(Elliptic Curve Cryptography) remain, but I'll leave other raise them if 
they se fit.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Mon, 27 Mar 2006 10:04:29 -0500

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
retire RSA.
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 
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. 
As some Validator's have removed
support for RSA/MD5 that zone risks becoming 
viewed as insecure, and its children
are treated insecure because of the parent.

         Olafur

At 09:52 27/03/2006, Thierry Moreau wrote:
>I agree, but only in theory without much 
>practical impact: the freedom to drop RSA-SHA1 
>seems restricted to the islands of security 
>(including the root), by implication of RFC4035 section 2.
>
>[...] There MUST be an RRSIG for each 
>[authoritative] RRset using at least one DNSKEY 
>of each algorithm in the zone apex DNSKEY 
>RRset.  The apex DNSKEY RRset itself MUST be 
>signed by each algorithm appearing in the DS 
>RRset located at the delegating parent (if any).
>
>A DS RR SHOULD point to a DNSKEY RR that is 
>present in the child's apex DNSKEY RRset, and 
>the child's apex DNSKEY RRset SHOULD be signed 
>by the corresponding private key.  DS RRs that 
>fail to meet these conditions are not useful for 
>validation, but because the DS RR and its 
>corresponding DNSKEY RR are in different zones, 
>and because the DNS is only loosely consistent, 
>temporary mismatches can occur. [...]
>
>[end of citation]
>
>In other words, a DNSSEC signature algorithm 
>present at an island of security is recursively 
>mandated (except for temporary mismatches in DNS 
>Hence my original question to Ólafur and others 
>who *might* be playing with the idea of droping RSA-SHA1 at the DNS root.
>
>>>However, the RSA-SHA1 RRSIGs would still be 
>>>mandatory in DNSSEC replies in any event, 
>>>since RSA-SHA1 is mandatory-to-implement.
>>
>>No.  Mandatory to implement just means the 
>>resolvers and the signers have to understand 
>>the signatures.  The actual zone data can be 
>>signed by some, all or none of the algorithms 
>>and keys that exists within the zone.
>>So, having a zone signed with ECC vs RSA (not 
>>ECC *and* RSA) would actually reduce the size of replies.
>

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 27 Mar 2006 07:36:29 -0800 (PST)

On Mon, 27 Mar 2006, Ólafur Guðmundsson /DNSEXT  co-chair wrote:

> To answer your quotes from below, following is perfectly valid from the 
> protocol point.
>        .  signed by RSA/SHA256
>        COM signed by RSA/SHA1

So if I wanted to express that there there are multiple types of signatures,
that would or would not be possible, i.e. what if I have:
  EXAMPLE.com signed by RSA/SHA1
  EXAMPLE.com signed by RSA/SHA256

> first algorithm it does not understand/support. As some Validator's have 
> removed support for RSA/MD5 that zone risks becoming viewed as insecure, 
> and its children are treated insecure because of the parent.

If multiple signatures are possible what needs to be done is to take care
to separate into multiple RRs that can be requested independently. Not sure
how to do it without breaking DNS other then by prefixes.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Ben Laurie <[email-masked]>
Date: Mon, 27 Mar 2006 17:02:47 +0100

> better answer next time someone ask why are you not using ECC.

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

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Mon, 27 Mar 2006 11:14:44 -0500

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

Key size.
         Olafur