Subject: rrsig(qtype)

From: Roy Arends <[email-masked]>
Date: Thu, 17 Jun 2004 09:28:32 +0200 (CEST)

This is an alternative online signing proposal:

Deny existence for QTYPE,QNAME,QCLASS by responding with empty answer
section and RRSIG in authority section, which is dynamically generated and
has signature field value: sign(RRSIG_RDATA).

example:

Dynamic No Data Error

   A "NODATA" response.  The RRSIG proves that the requested RR type does
   not exist.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   mail.example.     IN MX

   ;; Answer
   ;; (empty)

   ;; Authority
   mail.example. 600 IN RRSIG  MX 5 1 600 20040609183619 (
                               20040609183019 37223 example.
                               ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
                               ..
                               jV7j86HyQgM5e7+miRAz8V01b0I= )

   ;; Additional
   ;; (empty)

Roy

--
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: Derek Atkins <[email-masked]>
Date: Thu, 17 Jun 2004 10:33:17 -0400

Can you be more explicit about what's actually signed in this
proposal?  You clearly need to make the signature bound to the actual
asked question.  But "sign(RRSIG_RDATA)" is not sufficient in my mind
to explain what's included in the signature in this response, nor
sufficient to bind the RRSIG to this particular question.

I do like this approach....

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Roy Arends <[email-masked]>
Date: Thu, 17 Jun 2004 17:06:45 +0200 (CEST)

> sufficient to bind the RRSIG to this particular question.

Sign(RRSIG_RDATA) assumed that owner name was a field in RRSIG_RDATA,
which is not the case.  I should have said sign(RRSIG_RDATA | QNAME |
QCLASS) where RRSIG_RDATA is the wire format of the RRSIG RDATA fields
with the Signer's Name field in canonical form and the Signature field
excluded. This RRSIG RDATA has QTYPE in the type covered field.

Presented as said in my previous mail (empty answer, rrsig in auth), it
can then be interpreted as an authenticated denial for
QNAME,QTYPE,QCLASS.

Roy

---

From: Derek Atkins <[email-masked]>
Date: Thu, 17 Jun 2004 11:21:53 -0400

> can then be interpreted as an authenticated denial for

Thank you.  I believe that sign(RRSIG_RDATA | QNAME | QCLASS) does
provide an authenticated denial for QNAME/QTYPE/QCLASS because it'll
be a sig over empty data, but still depend on the name/type/class.

I'm certainly in favor of this proposal.

-derek

---

From: Roy Arends <[email-masked]>
Date: Thu, 17 Jun 2004 17:32:26 +0200 (CEST)

On Thu, 17 Jun 2004, Derek Atkins wrote:

> I'm certainly in favor of this proposal

Okay, d'you think it is appropriate for -trans ?

Roy

---

From: Derek Atkins <[email-masked]>
Date: Thu, 17 Jun 2004 11:55:34 -0400

> Okay, d'you think it is appropriate for -trans ?

If -trans is suggesting real-time signatures for people who don't want
NSEC, then yes I think it's appropriate for -trans.  Does it require
any changes to bis for proper resolver interpretation of this answer?
(I believe the answer to this question is "no", but it's something
that needs to be asked).

-derek

---

From: Roy Arends <[email-masked]>
Date: Thu, 17 Jun 2004 18:21:47 +0200 (CEST)

On Thu, 17 Jun 2004, Derek Atkins wrote:

> NSEC, then yes I think it's appropriate for -trans.

Yes. -trans is suggesting real-time signatures as a measure against
zone-traversal until dnssec-ter has arrived. For the rest, there is
dnssec-ter, or the DoNothing option.

> Does it require any changes to bis for proper resolver interpretation of
> this answer? (I believe the answer to this question is "no", but it's
> something that needs to be asked).

Well, hmmm,  it is a response-type that dnssec-bis resolvers do not yet
swallow. I think the changes to -bis are minimal to allow this.

Roy

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 17 Jun 2004 12:31:36 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Derek Atkins
>
>

I believe it does require some spec change.  Now RRSIGs are being used to
provide non-existent responses, instead of just providing origin
authentication and data integrity.   Not major overhauls, but changes.

And signaling non-signed delegations might need some clarification (if this
scheme is used).  It would look something like this (if I am not mistaken):

Question:  www.example.com

Ans:

Auth:
	example.com.    NS  somehost
	example.com   RRSIG(DS)  signer-.com
Add:
	somehost  	A	10.10.10.1

It sounds like an possibly viable option.  One that could be added to the
DNSSECbis->DNSSECter draft.

Scott

---

From: Roy Arends <[email-masked]>
Date: Thu, 17 Jun 2004 19:43:36 +0200 (CEST)

> authentication and data integrity.   Not major overhauls, but changes.

Yes.

> 	example.com   RRSIG(DS)  signer-.com

Exactly.

> DNSSECbis->DNSSECter draft.

Okay

Roy

---

From: Rob Austein <[email-masked]>
Date: Thu, 17 Jun 2004 14:10:44 -0400

General issue with sign-on-the-fly, not limited to Roy's proposal.

What happens to the data-producer to data-consumer end-to-end trust
model with these online signing models?  Is the response cachable?  Is
this the thin edge of a conversion of DNSSEC from object security into
channel security?

Color me concerned about depth of water and strength of undertow.

Note that while DNSSEC combined with dynamic update shared some of
these properties, the conceptual model in that case is that the data
producer for DNSSEC purposes is what RFC 2136 calls the "primary
master server".  That is, in the dynamic update case there are (at
least) two separate trust relationships: one is between the update
client and the primary master server for the dynamic update protocol;
the other is between the dynamic update engine (which has been
configured to act on behalf of the zone admin) and the DNSSEC
validator.

I do not (yet?) understand what the trust relationships look like in
these sign-on-the-fly-to-avoid-real-NSEC proposals.

Who is trusting whom to do what?

---

From: Roy Arends <[email-masked]>
Date: Thu, 17 Jun 2004 21:03:17 +0200 (CEST)

> this the thin edge of a conversion of DNSSEC from object security into

Since the response would be a negative response in all aspects, its just
as cachable as any other negative response. This is undoubtedly object
security, not channel security. The proposal is to sign a non-existent
object. A none existent object is logically an object with name type
class, neg-ttl, no rdata. That is what is signed.

> Who is trusting whom to do what?

A primary master trusts(1) the update client to update zone.
A DNSSEC validator trusts(2) the master-in-zone-mode-B to update zone.
A DNSSEC validator trusts(3) the signing oracle at the master to sign
empty objects.

(1) The trust is established by message authentication (rfc3007) using
    either TSIG or SIG(0)
(2) Since a DNSSEC validator is oblivious that a zone is subject to secure
    dynamic update, trust is established by standard DNSSEC operation.
    The trust between the primary master and the 'dynamic update engine'
    is done oob, or might be converged to a single elephant.
(3) The trust is established by DNSSEC operation (if DNSSEC-bis is
    ammended to trust signed epty objects)

Since (2) and (3) have different properties (signed objects with data vs
signed objects without data) different keys could be used (not required).

Roy

---

From: Roy Arends <[email-masked]>
Date: Thu, 17 Jun 2004 21:07:41 +0200 (CEST)

> > 	example.com   RRSIG(DS)  signer-.com

Here is the full list of response types. Note that RRSIG(any) is
introduced here, signalling no type exist for name to imply existence of
empty non-terminals, where with NSEC you'd think in 'closest match'.

Name Error

   An authoritative name error.  The special RRSIG RRs prove that the name
   does not exist and that no covering wildcard exists.

   ;; Header: QR AA DO RCODE=3
   ;;
   ;; Question
   ml.example.         IN A

   ;; Answer
   ;; (empty)

   ;; Authority
   example.       3600 IN SOA ...
   example.       3600 RRSIG  SOA ...
   ml.example.     600 RRSIG  ANY ...
   *.example.      600 RRSIG  ANY ...

   ;; Additional
   ;; (empty)

No Data Error

   A "NODATA" response.  The special RRSIG RR proves that the name exists
   and that the requested RR type does not.

   ns1.example.        IN MX

   ;; Answer
   ;; (empty)

   ;; Authority
   example.       3600 IN SOA ...
   example.       3600 RRSIG  SOA ...
   ns1.example.    600 RRSIG  MX ...

   ;; Additional
   ;; (empty)

Referral to Unsigned Zone

   Referral to an unsigned zone.  The special RRSIG RR proves that no DS
   RR for this delegation exists in the parent zone.

   ;; Header: QR DO RCODE=0
   ;;
   ;; Question
   mc.b.example.       IN MX

   ;; Answer
   ;; (empty)

   ;; Authority
   b.example.     3600 IN NS  ns1.b.example.
   b.example.     3600 IN NS  ns2.b.example.
   b.example.      600 RRSIG  DS ..

   ;; Additional
   ns1.b.example. 3600 IN A   192.0.2.7
   ns2.b.example. 3600 IN A   192.0.2.8

Wildcard Expansion

   A successful query which was answered via wildcard expansion.  The
   label count in the answer's RRSIG RR indicates that a wildcard RRset
   was expanded to produce this response, and the special RRSIG RR proves
   that no closer match exists in the zone.

   a.z.w.example.      IN MX

   ;; Answer
   a.z.w.example. 3600 IN MX  1 ai.example.
   a.z.w.example. 3600 RRSIG  MX 5 2 ...

   ;; Authority
   example.       3600 NS     ns1.example.
   example.       3600 NS     ns2.example.
   example.       3600 RRSIG  NS ..
   z.w.example.    600 RRSIG  ANY ..
   a.z.w.example.  600 RRSIG  ANY ..

   ;; Additional
   ai.example.    3600 IN A   ...
   ai.example.    3600 RRSIG  A ...
   ai.example.    3600 AAAA   ...
   ai.example.    3600 RRSIG  AAAA ...

Wildcard No Data Error

   A "NODATA" response for a name covered by a wildcard.  The special
   RRSIG RRs prove that the matching wildcard name does not have any RRs
   of the requested type and that no closer match exists in the zone.

   a.z.w.example.      IN AAAA

   ;; Answer
   ;; (empty)

   ;; Authority
   example.       3600 IN SOA ...
   example.       3600 RRSIG  SOA ...
   z.w.example.    600 RRSIG  ANY ...
   *.w.example.    600 RRSIG  AAAA ...

   ;; Additional
   ;; (empty)

DS Child Zone No Data Error

   A "NODATA" response for a QTYPE=DS query which was mistakenly sent to
   a name server for the child zone.

   example.            IN DS

   ;; Answer
   ;; (empty)

   ;; Authority
   example.       3600 IN SOA ...
   example.       3600 RRSIG  SOA ...
   example.        600 RRSIG  DS ...

   ;; Additional
   ;; (empty)

---

From: Paul Vixie <[email-masked]>
Date: Thu, 17 Jun 2004 19:10:25 +0000

> can then be interpreted as an authenticated denial for QNAME,QTYPE,QCLASS.

but not for <qname,qclass> as in authenticated rcode=3?  would that become
possible if we used qtype=NULL or qtype=ANY as a special case?

(note that i'm very concerned about another aspect of this, but i want to
answer that part separately.)

---

From: Paul Vixie <[email-masked]>
Date: Thu, 17 Jun 2004 19:15:15 +0000

> dnssec-ter, or the DoNothing option.

do you mean you intend to modify -bis to require that initiators be able
to recognize this form of on-the-fly denial of existence if responders
wish to avoid the precomputed-NSEC method?

things that would require changes to the entire installed based in order
to be effective belong in -bis rather than in -trans.

(and it doesn't even belong in -trans unless it also provides an way to
encode authenticated nonexistence of <qname,qclass> not just <...,qtype>.)

> swallow. I think the changes to -bis are minimal to allow this.

i think you're wrong, and that the changes would have to go through
considerable review, analysis, modelling, and testing before i'd feel
comfortable approving them.

---

From: Roy Arends <[email-masked]>
Date: Thu, 17 Jun 2004 21:28:03 +0200 (CEST)

> possible if we used qtype=NULL or qtype=ANY as a special case?

qtype=any

Roy

---

From: Rob Austein <[email-masked]>
Date: Thu, 17 Jun 2004 15:39:36 -0400

At Thu, 17 Jun 2004 21:03:17 +0200 (CEST), Roy Arends wrote:
> ...
>...

The point (which no doubt I expressed badly) is that yes, indeed, this
looks just like object security to the DNSSEC validator, but the trust
relationship is significantly different, since the "signing oracle"
might be any of the authoritative name server for the zone (which
isn't the case for dynamic update).

Perhaps it will turn out to be the case that the folks most likely to
use a sign-on-the-fly hack also operate all of the authoritative name
servers for their zones, in which case the distinction between
trusting the zone admin and trusting the authoritative server admin is
moot, because they're the same entity.  But at the very least we need
to document what sign-on-the-fly does to the trust model so that
people tempted to use it will understand the issue.

---

From: Roy Arends <[email-masked]>
Date: Thu, 17 Jun 2004 21:40:06 +0200 (CEST)

> wish to avoid the precomputed-NSEC method?

Not entirely. If the change would be minimal (and it seems that is not the
case), I would recommend to change -bis. But if it would delay -bis for
more then the currently expected editorial/clarification delay it would
not be worth it.

> to be effective belong in -bis rather than in -trans.

I agree.

> encode authenticated nonexistence of <qname,qclass> not just <...,qtype>.)

rrsig(any).

> comfortable approving them.

I understand your concern. I've been through all the response types
containing NSECs, and it is indeed not trivial, though much less complex,
since the denial is explicit instead of implicit. In any case, it is a
protocol change.

The whole rrsig(qtype) is imho a working concept as a defense against
zone-traversal, but it is too late for -bis and too early for -ter.

I won't stuff it in -trans and bring it up after -ter.

Roy

---

From: Roy Arends <[email-masked]>
Date: Thu, 17 Jun 2004 22:03:40 +0200 (CEST)

> isn't the case for dynamic update).

Yes, don't compare it to dynupdate. I do understand the comparison to
transaction signatures and indeed, the thick wall in between deteriorates
to a thin line. Especially since in practise, zone-admin will use a
zone-key _per_server_ which makes trust relationship really vague.

> moot, because they're the same entity.

Yes.

> But at the very least we need to document what sign-on-the-fly does to
> the trust model so that people tempted to use it will understand the
> issue.

Yes.

One side-note. There have been several interim solutions as a defense
against zone-enumeration. Online signing of malformed nsec is just one. I
really start to like Alex Bligh' do nothing option as an interim. All
other interim proposals seem hacky.

Roy

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 18 Jun 2004 10:31:13 +0200

On Thu, 17 Jun 2004 09:28:32 +0200 (CEST)

> This is an alternative online signing proposal:

Please move this to [email-masked] and report back to namedroppers
when the idea has been cooked and the changes in the security model
are ironed out.

Please concentrate on DNSSEC-bis and the possible minor changes that
are needed in the light of allowing _a_ viable transition. 

Even though this alternative is related to trans we should try not to
widen the discussion by introducing new ideas that need in depth
analysis.

The question on the table is can DNSSEC-bis be shipped without
closing the door &c &c &c

-- Olaf
   DNSSEXT Co-Chair

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC