Subject: [dnsext] alias algorithm for bname and other new rrtype Fw: I-D Action:draft-yao-dnsext-alias-algorithm-00.txt

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 11 Aug 2010 23:25:08 +0800

nsec3 or bname and more future rrtype have to deal with the dnssec problems.
alias algorithm identifier is necessary.
this document design a univerisial method for all new rrtypes in dnssec.

we will not need to name a individual alias algorithm identifiers to individual rrtype.

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 11, 2010 9:45 PM
Subject: I-D Action:draft-yao-dnsext-alias-algorithm-00.txt 

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> Title           : Alias algorithm identifier assignment mechanism for DNSSEC
> Author(s)       : J. Yao, et al.
> Filename        : draft-yao-dnsext-alias-algorithm-00.txt
> Pages           : 7
> Date            : 2010-08-11
> 
> DNS Security Extensions (DNSSEC) has been developed to provide origin
> authentication and integrity protection for DNS data by using digital
> signatures.  The DNSKEY, RRSIG, and DS RRs use an 8-bit number to
> identify the security algorithm being used.  More and more new
> RRTYPEs will appear in future.  This document defines an alias
> algorithm identifier assignment method for DNSSEC 8-bit algorithm
> numbers.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-yao-dnsext-alias-algorithm-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

--------------------------------------------------------------------------------

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 13 Aug 2010 10:48:23 +0200

On 11.8.2010 17:25, Jiankang YAO wrote:
> nsec3 or bname and more future rrtype have to deal with the dnssec
> problems. alias algorithm identifier is necessary. this document
> design a univerisial method for all new rrtypes in dnssec.
>

Sorry, but that I-D doesn't make any sense at all.

You write:

> Based on the rule of first come first served, the 8-bit algorithm
> allocation pool would soon be exhausted if more and more new RRTYPEs
> and algorithms had appeared in the DNS protocols.

And then you define new "aliases".  But you don't say anything about the
coding the "alias" to the RRSIG/DNSKEY RR types.  The field in those
records are still 8-bit and you cannot create alias-labels from the thin
air.  You need to code it into the wire format - e.g. into the algorithm
field of DNSKEY/RRSIG record.  So the problem you are trying to solve is 
still there.  Or am I missing something?  How will you code the "alias" 
to the wire format.

> The validating resolver following this specification MUST check the
> type covered of the RRSIG before the verification.  Only when the
> validating resolver knows the RRTYPE, it can begin to verify the
> signature of the RRSIG.  Otherwise, the validating resolver MUST
> regard the RRSIG in which the type covered is unknown to the
> resolver as insecure instead of bogus.

Also I am very afraid of this.  I could imagine all sort of "upgrade" 
attacks when attacker will spoof RRTYPE not know to the resolver, but 
known to the client.  Hence I consider this proposal very dangerous to 
the DNSSEC security.

O.
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: "Jiankang YAO" <[email-masked]>
Date: Fri, 13 Aug 2010 23:57:10 +0800

----- Original Message ----- 
From: "Ondřej Surý" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 13, 2010 4:48 PM
Subject: Re: [dnsext] alias algorithm for bname and other new rrtype Fw: I-D Action:draft-yao-dnsext-alias-algorithm-00.txt

> still there.  Or am I missing something?  How will you code the "alias" 

the current resolvers will not know the alias-algorithm.
the new resolvers follow this. this alias-alg may be used for any new rrtypes.
my understanding is the problem disappear.

every alias-alg has the new number from iana.

> known to the client.  Hence I consider this proposal very dangerous to 

this will not increase the possible attack you metioned.

for example, many current resolvers do not support nsec3 and DSA-NSEC3-SHA1,

the attackers can still spoof as the NSEC3 type and  DSA-NSEC3-SHA1,
the  "upgrade"  attacks you mentioned will appear.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 13 Aug 2010 18:23:07 +0200

On 13.8.2010 17:57, Jiankang YAO wrote:
> From: "Ondřej Surý"<[email-masked]>
> To: "Jiankang YAO"<[email-masked]>
> Cc:<[email-masked]>

Sorry, but I still don't get it.  Maybe give me an example of adding two 
consecutive RRTYPEs following the rules you propose:

1. BNAME
2. YNAME

How many new algorithms numbers (and names) will you have and what 
happens if:

1. you introduce BNAME
2. you introduce new algorithm called f.e. DEXTER
3. you introduce YNAME

> every alias-alg has the new number from iana.

So it doesn't solve the 8-bit problem.

> the  "upgrade"  attacks you mentioned will appear.

No it won't because it's secured by DS record in the parent zone.  So 
you are either secure (because the resolver support the algorithm) or 
you are insecure (because your resolver doesn't support the algorithm). 
  But the attacker cannot change that for individual RRTYPEs.

O.