Subject: [dnsext] MSIG proposal (on-the-fly sigs for ordinary records) Was: DNSSEC is hard to get right

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 7 Sep 2010 09:17:23 +0200

On Tue, Aug 31, 2010 at 02:55:08PM +0800,
 Jiankang YAO <[email-masked]> wrote 
 a message of 11 lines which said:

> I propose a lightweight DNSSEC.
> 
> http://www.ietf.org/id/draft-yao-dnsext-msig-00.txt

I've just read the draft and I'm not sure of the problem it intends to
solve. There are two parts where DNSSEC could be regarded as "too
heavy":

1) Administrative procedures, key management, resigning, etc.

2) Work for the name servers (loading large zones, sending large
packets, validating, etc).

MSIG addresses only the second. The first one, which was the cause of
the failure for iab.org, is exactly the same as with the current
DNSSEC.

Even for the second, MSIG addresses a problem that we do not feel (for
the signing of .FR, which will be on line next week, the size of the
zone was the smallest problem) and creates a new problem: the
authoritative name server now must generate a signature for every
request! You will eat less RAM but use much more CPU.

Also, if I understood the draft correctly:

* Every authoritative name server, even a slave, will require a copy
of the private key (since it will have to sign the responses
on-the-fly). Bad for manageability and security.

* MSIG secures the link from the authoritative name server to the
resolver but cannot help if there are chained resolvers, or cannot be
used for the last mile. (I'm not sure about this last point, it is not
clear in the draft.)

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 7 Sep 2010 16:03:53 +0800

----- Original Message ----- 
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 07, 2010 3:17 PM
Subject: MSIG proposal (on-the-fly sigs for ordinary records) Was: DNSSECis hard to get right

> request! You will eat less RAM but use much more CPU.

frankly said, I got the inspiration from the DNScurv draft draft-dempsky-dnscurve-01 - DNSCurve,

which uses the similar mechanism, but changed the dns packet format.

The MSIG proposal does not change the basic rules of dns.

MSIG is very useful for the registries or the DNS zone which has the millions of domain names since it will reduce the size of the zone dramatically.

on the other hand, the outgoing DNS packages are too large for the heavy dnssec. sometimes, we have to use the TCP connections to transfer the big package.

MSIG will reduce the dns outgoing package too.

> used for the last mile. (I'm not sure about this last point, it is not

for the last mile problem, 

I also proposed http://tools.ietf.org/html/draft-yao-dnsop-resolverkey-00

thanks a lot for your taking a look at my draft.

Jiankang Yao

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 7 Sep 2010 16:16:03 +0200

On Tue, Sep 07, 2010 at 04:03:53PM +0800,
 Jiankang YAO <[email-masked]> wrote 

> draft-dempsky-dnscurve-01 - DNSCurve,

Indeed, MSIG is in the same league than DNScurve (and TSIG and IPsec),
it protects the channel, not the message. For instance, it does not
protect you against a rogue slave authoritative name server.

> MSIG is very useful for the registries or the DNS zone which has the
> millions of domain names since it will reduce the size of the zone
> dramatically.

NSEC3+opt-out is sufficient for me.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Sep 2010 18:17:01 -0400

The channel approach is definitely not suited for inter-domain trust.

It does have definite advantages for intra-domain trust however. It
allows the resolver to be used as a security proxy, filtering out
known bad domains (e.g. malware infested, run by the mafia), caching
DNSSEC results, using state to establish security context etc.

-- 
Website: http://hallambaker.com/