Subject: DS design questions

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 02 Jan 2002 23:55:00 -0500

I'm trying to get a new version of the draft out the door. The changes
agreed to so far bring up few questions that I would like some input
on before selecting one the possible.

1. Should the DS record have a digest identifier ?
Right now SHA-1 is the only one specified, x years down the road
we may need a stronger one. There are two ways to handle this,
	use digest identifier byte in the record
	Use the size of the DS record to signal the algorithm used.

The second one is compatible with the current specified format of the
record, the first one is more explicit.

Q 2. NODS bit needed in NXT ?
Current draft uses this bit to allow resolvers to detect quickly if a
zone is a secure RFC 2535 or insecure DS, new version will outlaw RFC 2535
NULL key reducing the usefulness of this bit.
I think this bit is useful in the near term for debugging and testing.
 From resolver perspective this is nice to have not a show stopper.
We waste a type code on this bit from the precious 1-126 range
(1/3 of the type space has been used so far).

Q 2.5 IF answer to 2 is yes, should the document recommend the use new
type code > 42 for NODS or reuse one of the reserved type codes that
has never been properly used/documented such as: SINK, EID, NIMLOC, ATMA.

Q 3. DS or NXT second RR set in authority section ?
It has been strongly suggested that referral answers have DS and NXT
added to the authority section, this is motivated by the facts:
	that it is sometimes hard to reach the correct servers
	this WILL save lookups.

The cost is larger answers and possibly less or no glue in some referrals.
I personally think that DS is more important thus it should be the
second RR set in the authority section and NXT the third.
NXT is more important to resolvers in the negative case and could be 
suppressed when there is DS, but that is one more special case in servers.

	Olafur

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 02 Jan 2002 23:25:03 -0800

> record, the first one is more explicit.

the second one opens the possibility that we will someday add a pad byte
somewhere just to have a distinguishing length.  that way lies madness.
i strongly recommend the use of an alg-id.

> (1/3 of the type space has been used so far).

if processing it and understanding it becomes optional after the near-term
uses you envision, then put in the crutch.  but if it will add code paths to 
implementations which won't be written until my three-year-old is in college
then by all means leave it out and deal with the near-term inconvenience.

> suppressed when there is DS, but that is one more special case in servers.

size constraints basically just do not matter.  DNSSEC is not deployable
without EDNS, with or without DS RRs in the authority section.  thinwire
clients (i'm thinking wireless PDA's here) are likely to use IPSec toward
a fatpiped proxy for more than just DNSSEC-related reasons.  i'd say put
in the thing that will limit the number of transactions on the wire rather
than the size of the response, since round trip delay is a physical property
and seems unlikely to improve beyond speed-of-light in the near term.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 3 Jan 2002 09:56:14 +0100

On Wed, 02 Jan 2002 23:55:00 -0500

> record, the first one is more explicit.

I enjoy aesthetics so the second option is preferred.
 
> (1/3 of the type space has been used so far).

Q2.5beta

Can we put a flag-date on the use of this bit? i.e. as soon as RFC2535 is
obsolete the bit is obsolete.

> suppressed when there is DS, but that is one more special case in servers.

I think that is a good argument but I am agnostic about this point.

--Olaf

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 3 Jan 2002 14:24:32 +0100

On Thu, 3 Jan 2002 09:56:14 +0100

> I enjoy aesthetics so the second option is preferred.

oops, that should have read first  option... 

--Olaf

---

From: Randy Bush <[email-masked]>
Date: Thu, 03 Jan 2002 05:58:35 -0800

> i strongly recommend the use of an alg-id.

what paul said

randy

---

From: Brian Wellington <[email-masked]>
Date: Thu, 3 Jan 2002 11:09:50 -0800 (PST)

> i strongly recommend the use of an alg-id.

I strongly agree.

> then by all means leave it out and deal with the near-term inconvenience.

If RFC 2535 NULL KEYs are outlawed (and no implementation will need to 
support both NULL KEYs and DS), I don't think the bit is needed.

As for complexity, I don't think it matters too much.  If an 
RFC2535-style response is misinterpreted as a DS response (because there 
is no NODS bit), it will still fail to verify because there will be no NXT 
record in the authority section showing the lack of DS.

> and seems unlikely to improve beyond speed-of-light in the near term.

I think putting these in the authority section is crucial if there is
supposed to be an implementation in the near future.  A lot of extra cost
in the resolver for dealing with state can be removed if the DS/NXT 
records are guaranteed to be in the response packet, as they will be if 
they're in the authority section.

Brian

---

From: Daniel Massey <[email-masked]>
Date: Thu, 03 Jan 2002 14:52:38 -0500

> > i strongly recommend the use of an alg-id.

Add one more strongly agree.

> support both NULL KEYs and DS), I don't think the bit is needed.

I thought the NODS bit was good at first, but on second thought I also
think it should not have a NODS bit.  

The bit doesn't gain anything once NULL keys are gone (at least
as far as I can tell, please correct me if that is wrong)
>From the perspective of someone looking at a new spec, NODS would
just be an extra bit that needs to be set but has no meaning.  
It seems to me like the best thing to do is to make a clean break 
and eliminate the NODS bit.

Dan

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 3 Jan 2002 16:21:31 -0500

If we are going to have a flag day for DNSSEC rollout with DS, then we
should eliminate the NODS bit in the NXT record.  "Vanilla" RFC2535 signed
zones would not be deemed "true DNSSEC secured" anyway.  But consider the
alternative:

zone 'SUB.A' is signed RFC2535 and has a SIG(KEY) record from the parent in
it's zone.
What would happen when a DS-aware resolver gets the delegation from 'A', it
will see that no DS RR is present (in the NXT record bitmap)?  The resolver
contacts 'SUB.A" it gets the KEY and SIG record for the KEY signed by the
parent (zone A).   Should a resolver be assumed to have enough intelligence
to start the validation process the old RFC2535 way (or more difficult - a
mix of DS/RFC2535 chaining)?

Scott

---

From: Brian Wellington <[email-masked]>
Date: Thu, 3 Jan 2002 11:09:50 -0800 (PST)

I strongly agree.

Brian

---

From: Brian Wellington <[email-masked]>
Date: Thu, 3 Jan 2002 21:01:55 -0800 (PST)

> mix of DS/RFC2535 chaining)?

I don't understand this.  If RFC 2535 signed zones are deprecated and not 
considered secure, why would a resolver need to start the validation 
process in the old way?  Shouldn't the lack of DS or provably absent DS be 
enough to make the validation attempt fail?

Brian

---

From: Daniel Massey <[email-masked]>
Date: Fri, 04 Jan 2002 11:03:16 -0500

In my view, the flag day would wipe out the old rules
and would have the following impact on the example:

> 
> zone 'SUB.A' is signed RFC2535 and has a SIG(KEY) record from the 
> parent in it's zone.

After the flag day, both A and SUB.A are doing the wrong thing: 
  -  SIGs generated by A's KEY should be kept local to A's zone
  -  any SIGs in the SUB.A zone should be generated by a SUB.A key
This gets rid of a lot of inter-zone coordination issues, questions
of who is authoritative for what, problems with when things expire,
scaling problems, etc.

> parent (zone A).   

Ignore the SIG from KEY A.   perhaps log a warning that this zone
is operating under obsolete rules.

> Should a resolver be assumed to have enough intelligence

No, definitely not.  The resolver should not be complicated by the 
trying to understand both the old and new styles.  A resolver is
either configured with a trusted key for the zone or uses a DS
record at the parent. 

Dan

---

From: David Blacka <[email-masked]>
Date: Fri, 04 Jan 2002 11:43:35 -0500

>>>>> "Scott" == Scott Rose <[email-masked]> writes:

 Scott> If we are going to have a flag day for DNSSEC rollout with DS,
 Scott> then we should eliminate the NODS bit in the NXT record.
 Scott> "Vanilla" RFC2535 signed zones would not be deemed "true
 Scott> DNSSEC secured" anyway.  But consider the alternative:

 Scott> zone 'SUB.A' is signed RFC2535 and has a SIG(KEY) record from
 Scott> the parent in it's zone.  What would happen when a DS-aware
 Scott> resolver gets the delegation from 'A', it will see that no DS
 Scott> RR is present (in the NXT record bitmap)?  The resolver
 Scott> contacts 'SUB.A" it gets the KEY and SIG record for the KEY
 Scott> signed by the parent (zone A).  Should a resolver be assumed
 Scott> to have enough intelligence to start the validation process
 Scott> the old RFC2535 way (or more difficult - a mix of DS/RFC2535
 Scott> chaining)?

This makes me wonder about the expected behavior of DNSSEC-aware
resolvers.  

My (possibly wrong) conception was that resolvers would only query
with the DNSSEC-OK bit (and EDNS0) if there was a reasonable chance
that server would understand it.  That is, it would query for DNSSEC
records at zones for which it had trusted keys, cached validated keys,
or when following a _secure_ delegation.  When following an insecure
delegation, the resolver would drop EDNS0 (and DNSSEC-OK) on the
assumption that those nameservers are DNSSEC (and probably EDNS0)
unaware.

Since, AFAIK, querying an older DNS server with EDNS0 causes FORMERR
to be returned, this seemed to me to be a logical thing to do.

Under this scheme, however, this alternative scenario would not work
because the resolver would never see SUB.A's keyset (because it didn't
ask for it by turning on the DO bit).

Should resolvers be querying servers with the DO bit without any
indication of whether or not the server will understand it?  Should
DNSSEC server return DNSSEC information without being asked for it?

-- 
David Blacka            <[email-masked]> 
Sr. Research Engineer   Verisign Applied Research

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 4 Jan 2002 11:38:59 -0500 (EST)

> on before selecting one the possible.

Thanks to everyone that has responded to these question either on the
list or in private.

Summary of results.
> 1. Should the DS record have a digest identifier ?

Yes, I will add a field to the DS record and require IETF standards
action (the most difficult step) to create a new digest identifier,
we do not what to many algorithms used.

> Q 2. NODS bit needed in NXT ?

Most answers lets have a clean break, and not include this bit.

> Q 3. DS or NXT second RR set in authority section ?

Fewest people had opinion on this one, but all the answers where
"require both", which was not my question.
In the draft I will require that authority section on referral answer
contain "NS DS SIG(DS) NXT/parent SIG(NXT/parent)" in this order,
DS will only be included if it exists, and NXT/child is not allowed.

thanks again
	Olafur

---

From: Derek Atkins <[email-masked]>
Date: 04 Jan 2002 14:13:16 -0500

> assumption that those nameservers are DNSSEC (and probably EDNS0)

This certainly does not appear to be what BIND does, at least by my
watching it.  It appears to at least try EDNS0 on every (initial)
request.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Brian Wellington <[email-masked]>
Date: Fri, 4 Jan 2002 14:47:17 -0800 (PST)

> assumption that those nameservers are DNSSEC (and probably EDNS0)

I would think that a resolver which understands EDNS and is capable of
verifying DNSSEC records would always query with EDNS0 and the DO bit, 
unless it believes that the remote server will not understand it.  That 
is, when it sees a FORMERR response, it will no longer send EDNS/DO to the 
same server.

> to be returned, this seemed to me to be a logical thing to do.

Right.

> ask for it by turning on the DO bit).

Unless it defaults to enabling the DO bit.

> indication of whether or not the server will understand it?

Yes.  There's no harm in this.

> Should

No.  Otherwise the DO bit is useless.

Brian