Subject: RE: rrsig(qtype)

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

On Thu, 17 Jun 2004, Scott Rose wrote:

> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Derek Atkins
> >
> >
> > Roy Arends <[email-masked]> writes:
> >
> > > 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).
> >
>
> 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.

Yes.

> 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

Exactly.

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

Okay

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: 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.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   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.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   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.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   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.

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

   ;; Answer
   ;; (empty)

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

   ;; Additional
   ;; (empty)

---

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 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