Subject: DNSKEY flags field

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Jun 2004 16:39:22 +0200

Hello.  I think the flags field of DNSKEY could be improved to
facilitate future revisions.  The dnssec-records says in 2.1.1:

   Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
   creation of the DNSKEY RR, and MUST be ignored upon reception.

Always ignoring unknown bits remove the possibility of using the flags
field as an upgrade path in future revisions of DNSSEC.  What do
people think about changing the above to:

   Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
   creation of the DNSKEY RR, and bits 0-6 MUST be ignored upon
   reception, and non-zero values in bits 8-14 MUST cause the DNSKEY
   to be considered invalid for purposes of RRSIG validation.

This would allow DNSSECter to use bits 0-6 for non-critical signaling
of new features, and to use bits 8-14 for critical signaling of new
features.

Of course, if after more consideration, it is realized that using the
flags field is not a reliable way to signal features DNSSECter want to
communicate, then EDNS or some other solution can be used instead.
But adopting the above text would make it possible to have this option
open for DNSSECter.

What do you think?

Thanks,
Simon

PS. This message was reposted here because my post to [email-masked]
appear to have neither arrived, bounced or generated a moderation
notify.  If you receive duplicates, I apologize.

--
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: Edward Lewis <[email-masked]>
Date: Thu, 10 Jun 2004 11:38:08 -0400

>What do you think?

This is more or less what silly state began to try to do.  Define 
looking at the bits that shouldn't matter to see if a "panic because 
it's the future and I don't know what to do" mode is to be entered.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Even the voices inside my head are refusing to talk to me anymore.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Jun 2004 17:56:38 +0200

> it's the future and I don't know what to do" mode is to be entered.

A "panic button" already exists in DNSKEY -- if DNSSECter specify use
of a protocol field != 3, old resolvers will reject those DNSKEYs, for
RRSIG validation purposes.  Using the Flags Field appeared to me like
a cleaner solution, considering the original use of the protocol
field.  With my text this option would be available.

Thanks,
Simon

---

From: Edward Lewis <[email-masked]>
Date: Thu, 10 Jun 2004 12:28:22 -0400

>field.  With my text this option would be available.

What your text is doing is bringing the flags definition in line with 
the protocol field - telling the verifier to ignore keys that don't 
fit the narrowly defined contents they are allowed to have.  It's 
good to see the specifications have commonality across the sections.

The problem is that this is not sufficient to provide a base for a 
migration strategy.  What's missing are instructions on what to do if 
all keys present fail the tests?  Should the verifier log this 
instance as a note to the administrator that perhaps the verifier 
code has fallen behind in version and needs to be replaced?   Should 
the verifier just assume that there is no available DNSSEC 
verification data for the zone and thus treat it as unsigned?

What does a resolver do when it tries to load a trusted key that has 
a protocol field != 3 or flag bits not 0 in the right places?

What if a verifier starts in a zone with acceptable keys, sees a 
(child's) DS set with acceptable algorithms, but finds only a DNSKEY 
set (upon descending into the child) with unacceptable bits?  How is 
that DNSKEY set signed?  Can the signature be validated?  If not, how 
do you know that the DNSKEY set of all unacceptable keys is not a 
malicious insertion?

I think the problem (and I'm off on a tangent now) is that you have 
to make the verifier be able to realize at the DS RR set that the 
child will have no acceptable keys for me - at the point where I can 
verify the "end of understandable security" while still being secure 
enough to trust it.

And the server has to be able to understand that even if I do present 
secure data, a client unable to understand it will fall back to 
assuming the server has no security.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 11 Jun 2004 09:57:44 +0200

On Thu, 10 Jun 2004 12:28:22 -0400
> verify the "end of understandable security" while still being secure 

One of the things you have to take into account is the signature strip
attack (there was a long thread on that under one of the questions,
Weiler started that one if I recall well.).

You have to decide, as soon as you receive the DNSKEY RRset, which
keys the data MUST be signed with in order to not be bogus.

So you have to ordonate something like "If any of the secure entry poin
into the zone (either the DS RRs or trust anchors) points to DNSKEY
RRs in the apex with all zero values in bits 8-14 than any RRset in
the zone MUST have at least one RRSIG generated by an all-zero keys,
RRsets not signed by an RRSIG generated by an all-zero key are to be
treated as bogus."

In addition you have to say that if you find non-zero bit keys you treat
the zone as insecure.

"If none the secure entry point into the zone point to DNSKEY RRs in
the apex with non-zero values in bits 8-14 than the zone may be treated as
insecure."

-- Olaf
   No hats

Playing with bits at this stage is stepping on corner-case ground.

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 Jun 2004 16:07:08 +0200

Edward Lewis <[email-masked]> writes:

> fit the narrowly defined contents they are allowed to have.  It's good
> to see the specifications have commonality across the sections.

The current text says this.  My proposed text split the flag bits into
two parts, one part which can be ignored if unsupported, and one part
which cause the entire DNSKEY to be rejected for RRSIG validation
purposes.  The latter is similar to sending a protocol != 3 value.

> instance as a note to the administrator that perhaps the verifier code
> has fallen behind in version and needs to be replaced?   Should the
> verifier just assume that there is no available DNSSEC verification
> data for the zone and thus treat it as unsigned?
>
> What does a resolver do when it tries to load a trusted key that has a
> protocol field != 3 or flag bits not 0 in the right places?

I was not trying to provide a migration strategy, just to make it
possible to develop one -- one that would be cleaner than using the
protocol field, which is possible with the unmodified current
document.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 Jun 2004 16:48:05 +0200

> the apex with non-zero values in bits 8-14 than the zone may be treated as

I believe none if those discussions are required, or even useful.  By
the same argument, do you also believe that the document describe what
should happen when the protocol field is not 3?  Essentially, I don't
see the difference between when a DNSKEY is invalid because the
protocol field is not 3, and when (with my proposed text) bits 8-14
are non-zero.

If the WG prefer having only the Protocol Field available for use in
future revisions, then fine.  My suggestion was based on the thought
that it would be cleaner to have the Bit Field available for this
purpose too.

If the intention is not to use the Protocol Field for future revision,
then the field serve no purpose and I believe it should be removed.

Thanks,
Simon

---

From: Edward Lewis <[email-masked]>
Date: Fri, 11 Jun 2004 11:42:32 -0400

>Weiler started that one if I recall well.).

I think that's a different issue from my point, but is related.

Validation of the data begins with 1) the data and 2) an expectation 
of what is to be present to come to believe the data.

Let's begin with the topic of on-line signing of dynamically 
generated data denial responses (authenticated denial).  If there's 
to be on-line signing, then there's an on-line key.  Such a key is 
more vulnerable than off-line keys.

So, if we want to continue to rely on off-line signing for safety, we 
need to set expectations about what key is used where.  If we decide 
to propose on-line signing of negative answers, then we will have to 
specify that:

    - If the zone subscribes to this notion
         - The key signing a positive answer (with data) has to be a key that
           is indicated to be off-line
         - The key signing the key set has to be indicated as off-line
         - The key signing the negative answer may be indicated as on-line

If you don't provide the above, then the protocol is vulnerable to an 
exposure of the private key that leads to someone signing a 
long-RRSIG-validation and high TTL version of an illicit key set and 
thus being able to send data around signed by one of the illicit keys.

This relates to signature stripping because the verifier needs to 
determine if it has sufficient data to prove the answer.  What the 
verifier needs to be able to get is a RRSIG for an answer that shows 
the right kind of key was used.

The right kind of key could be "any key if the zone does not have any 
key on-line or an off-line key if the zone has keys on-line."  The 
verifier needs to be able to see that in the data it gets - that's 
the expectation.  If an RRSIG is stripped that would demonstrate 
that, then the verifier is correct to be suspicious and take 
corrective action.

>So you have to ordonate something like "If any of the secure entry poin

I have to admit that "ordonate" is not in my version of the English 
dictionary. ;)  And I can't find a verb that is close to the spelling 
you have.  (I.e., huh?)

>the apex with non-zero values in bits 8-14 than the zone may be treated as

I don't think that's the right "rule."

Let's say that my verifier is able to understand the security of the 
zone example.com.  I.e., I understand the semantics of all the set 
bits in the zone's  DNSKEY's, RRSIG's, NSEC's.

Asking for "www.newzone.example.com." A (assuming it's in a 
sub-delegation), I will see this in the response:

         Answer
         Authority
          newzone.example.com. NS ns1.newzone.example.com.
          newzone.example.com. NS ns2.newzone.example.com.
          newzone.example.com. DS <key 1>
          newzone.example.com. DS <key 2>
          newzone.example.com. RRSIG(DS)
         Additional

I can validate the RRSIG above, proving that there's a DS key.

When I issue the same answer to ns1.newzone.example.com., I get:

         Answer
          www.newzone.example.com A 222.333.444.555
          www.newzone.example.com RRSIG(A)
         Authority
         Additional
          newzone.example.com. DNSKEY <key 1>
          newzone.example.com. DNSKEY <key 2>
          newzone.example.com. RRSIG(DNSKEY)

What' happens when I find that key's 1 and 2 have bits set that I 
can't understand?  Should I be content that these keys match the DS 
hashes, now concluding that there are no acceptable keys and 
therefore I can reasonable continue on assuming there is no security 
to be had?  (Maybe so, maybe not.)

If this is the case, should the resolver know to alert it's operator 
that this happened - i.e., that may it's time for a verifier upgrade? 
I think so because this is significantly different from this referral 
message (which also results in the ending of an expectation of 
security):

         Answer
         Authority
          newzone.example.com. NS ns1.newzone.example.com.
          newzone.example.com. NS ns2.newzone.example.com.
          newzone.example.com. NSEC saying no DS
          newzone.example.com. RRSIG(NSEC)
         Additional

Then there's a mixed case - when some keys are acceptable, some not. 
The zone ought not be treated as unsigned unless the verifier has no 
way to expect otherwise.
...
>Playing with bits at this stage is stepping on corner-case ground.

Yep.

---

From: David Blacka <[email-masked]>
Date: Fri, 11 Jun 2004 14:18:12 -0400

> protocol field is not 3, and when (with my proposed text) bits 8-14

If your intention is to use bits 8-14 -or- the protocol field as a transition 
mechanism, then yes.

> that it would be cleaner to have the Bit Field available for this

I do not think that the protocol field is useful for future revisions as it 
currently stands.

> then the field serve no purpose and I believe it should be removed.

It, in fact, serves no purpose.  The protocol field is there for historical 
reasons only.

For either your proposal or the protocol field to be useful as an indicator of 
a future revision, the resolver behavior wrt keys in unknown protocols has to 
be defined...differently. 

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 Jun 2004 23:35:19 +0200

> If your intention is to use bits 8-14 -or- the protocol field as a transition 

I don't intend to use as a fully elaborated transition mechanism, only
to make it _possible_ to use it in a fully elaborated transition
mechanism.  Much like (I believe) the protocol field can be used for
this.

> I do not think that the protocol field is useful for future revisions as it 

Why not?  The current text says:

   The Protocol Field MUST have value 3 and the DNSKEY RR MUST be
   treated as invalid during signature verification if found to be some
   value other than 3.

Given this, a future revision could depend on DNSSECbis resolvers
following the above text and reject DNSKEY RRs with non-3 protocol
fields.  I don't think the details of how non-3 values are to be used
is important, and they don't need to be described now.  The above text
is a vehicle for future expansion.

> It, in fact, serves no purpose.  The protocol field is there for historical 

As DNSSECbis is not backwards compatible with DNSSEC, this argument
doesn't appear to be very convincing to me.  As DNSKEY is currently
defined, the field can serve a purpose in a revision, which I believe
is good.

If the intention is to never make use of resolver behaviour for the
protocol field, then I fail to understand why the current text places
requirements on DNSSECbis implementations.  Every protocol requirement
in the document leads to interoperability tests, which are expensive.
If the specification did not include a MUST, it will be impossible to
rely on any specific behaviour and it could not be used in a revision.

Thanks,
Simon

---

From: David Blacka <[email-masked]>
Date: Fri, 11 Jun 2004 18:11:34 -0400

On Friday 11 June 2004 5:35 pm, Simon Josefsson wrote:

> > I do not think that the protocol field is useful for future revisions as
> > it currently stands.
>

I will agree that current validators will reject DNSKEY RRs with non-3 
protocol fields.  That is the intent as I see it, anyway.

As far as I can tell, the current result of publishing a signed zone with all 
DNSKEYs of protocol = 4 is that resolvers who think the zone should be 
secured will conclude that every answer from that zone is BOGUS.  That just 
doesn't seem like a good vehicle for future expansion to me.  But maybe we 
are talking about different forms of "expansion".

> > It, in fact, serves no purpose.  The protocol field is there for
> > historical reasons only.
>

I'm not arguing anything.  I'm just stating what I believe to be a fact.

> rely on any specific behaviour and it could not be used in a revision.

If you were to argue for the removal of the protocol field from the DNSKEY 
record on the grounds that it is useless, you would get no argument from me.  
If you were, instead, to argue for language changes to the DNSSECbis docset 
to make the field more useful for something, you would also be quite welcome.  
If you would like to describe how to use the protocol field for a future 
revision with the docs as-is, you would also be quite welcome.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 12 Jun 2004 01:21:50 +0200

> protocol fields.  That is the intent as I see it, anyway.

We agree here.

> secured will conclude that every answer from that zone is BOGUS.

By BOGUS, do you mean that since no valid DNSKEY were found, and
consequently no RRSIGs could be verified, returned data is considered
insecure?  Or are you saying a DNS cache, quering for
(foo.example,IN,SOA) and receiving:

foo.example   SOA ...
foo.example   RRSIG SOA ...
foo.example   NSEC ...
foo.example   DNSKEY ...protocol field 4...

should reject the entire response, and return SEVRFAIL, NOERROR or
something to the client?  I see no ground for that behaviour.
Instead, I believe the resolver should return the requested RR.  It is
this behaviour that I find useful in an extension.  It allow for a
graceful upgrade to a DNSSECter where the failure mode is a
degredation to vanilla DNS, instead of error states.

> That just doesn't seem like a good vehicle for future expansion to
> me.  But maybe we are talking about different forms of "expansion".

Perhaps so, I find the above sufficient to allow future extensions.

> revision with the docs as-is, you would also be quite welcome.

And do you have any thoughts on the actual proposed text change that
started this thread?  I have no wish to change the Protocol Field.  I
have used the Protocol Field, in this thread, as an example of an
already specified extension mechanism, since people appeared to think
that my proposed change wanted to introduce a new extension mechanism.
I want to introduce a cleaner way to specify the extensions, compared
to using the protocol field.

Thanks,
Simon

---

From: Paul Vixie <[email-masked]>
Date: Fri, 11 Jun 2004 22:47:00 +0000

> As far as I can tell, the current result of publishing a signed zone with
> all DNSKEYs of protocol = 4 is that resolvers who think the zone should
> be secured will conclude that every answer from that zone is BOGUS.

that's my reading also.

> That just doesn't seem like a good vehicle for future expansion to me.

agreed.  the whole protocol field is worthless and illconsidered as it is.
however, it can be hardcoded to 3 and left in the spec; we already abandoned
"pretty" about 200,000 miles ago, and this does not even approach "dangerous".

> If you were to argue for the removal of the protocol field from the
> DNSKEY record on the grounds that it is useless, you would get no
> argument from me.

you would get an argument from me, however.  it's doing no harm and there's
already been some early deployment with it.  before we break stiction on that
early deployment we need to prove that something is actively harmful, like
for example, prevents -ter from being even theoretically possible.  this does
not meet that standard.

> If you were, instead, to argue for language changes to the DNSSECbis
> docset to make the field more useful for something, you would also be
> quite welcome.  If you would like to describe how to use the protocol
> field for a future revision with the docs as-is, you would also be
> quite welcome.

or if you'd just like to leave it defined as it is, that would be ok w/ me,
since "useless" != "harmful".

---

From: David Blacka <[email-masked]>
Date: Fri, 11 Jun 2004 22:00:20 -0400

> (foo.example,IN,SOA) and receiving:

I believe, given the current language in the DNSSECbis documents, that 
SERVFAIL would be returned.  I could be wrong.  At best, resolver 
behavior in this situation is ambiguous, I think.

> to using the protocol field.

I think that the WG should discuss the merits of different ways to move 
the protocol beyond DNSSECbis.   Using the protocol field or unused 
flag bits seems like a good avenue to explore.  I don't see a great 
deal of difference between using flags or the protocol field, however.

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

---

From: Paul Vixie <[email-masked]>
Date: Sat, 12 Jun 2004 02:16:23 +0000

> > to using the protocol field.

so did i.  see <draft-vixie-dnssec-ter-01.txt> for one possible alternative.

> I think that the WG should discuss the merits of different ways to move the
> protocol beyond DNSSECbis.   Using the protocol field or unused flag bits
> seems like a good avenue to explore.  I don't see a great deal of
> difference between using flags or the protocol field, however.

the protocol field is essentially useless as specified.  under no
circumstances will a chance to the protocol field of DNSKEY have any
effect on the rdata layout of any RR including DNSKEY, or on the
content of other RRs including NSEC.

ed lewis sometimes talks about "the holy Q-trinity", and his arguments
are directly relevant here.  to get different answers you'll have to
ask different questions.  to get different metadata (authority/additional)
without asking a different question, you'll have to specify different
flags (like "want dnssec" and "want dnssec-ter i mean").

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 12 Jun 2004 20:09:30 +0200

David Blacka <[email-masked]> writes:

> I believe, given the current language in the DNSSECbis documents,
> that SERVFAIL would be returned.  I could be wrong.  At best,
> resolver behavior in this situation is ambiguous, I think.

Which section do base this on?  Records 2.1.2 says:

This is rather specific as to which situations the DNSKEY should be
regarded as invalid.  That imply that it shouldn't be invalid for
other situations, otherwise the qualification is unnecessary.  But I
agree it is ambiguous at best.

Thanks,
Simon

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 14 Jun 2004 11:38:30 +0200

On Sat, 12 Jun 2004 01:21:50 +0200

> > protocol fields.  That is the intent as I see it, anyway.

we all do :-) ...

> degredation to vanilla DNS, instead of error states.

What happens is really dependend on "how" you enter the zone.

If you follow a chain of trust that says "foo.example" is supposed to
be secure in "protocol 3" then, by not having a "protocol 3" key to
verify against you have to treat the zone as bogus.

If you do not have a secure entry point (following a chain of trust of
via a configured trustanchor) into the zone than the keys really are
of no use and it does not matter if they are of proto 3 or 4. And your
data should pass through as not being validated.

IMHO this exactly as specified by the language in "proto". Protocol 4
keys are not to be used for validation: If a DS RR[*] points to a
protocol 4 key than the DS RR tells us foo.example is secure, but
since we have a protocol 4 key we cannot validate. Not being able to
validate in a secure zone implies bogus results.

> to using the protocol field.

IMHO, without degradation attack prevention you cannot use the field,
nor the flag bits.

--Olaf

[*] I assume here that the DS was part of a protocol 3 chain of trust
i.e. signed by a protocol 3 KEY. If the whole chain of trust is
protocol 4 than the behaviour is unspecified.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 14 Jun 2004 12:00:49 +0200

> dictionary. ;)  And I can't find a verb that is close to the spelling 

Oh... it sounded English to me :-). I ment "ordain" ("verordoneren" in
Dutch, both seem to have the same French etymology)

So you have to ordain something like ... "If andy of the secure entry points
> I can validate the RRSIG above, proving that there's a DS key.

Ack..

> to be had?  (Maybe so, maybe not.)

Aha... this is actually a different issue. This is, if I understand
you well, how you handle proto 4 keys if you only know about proto 3
(I was more worried about what happens if you know of both, ie the
effect during transition).

Back to your example.

For argument sake let us say that keys 1 and 2 have their protocol
field set to 4. And that the DS RR was signed with a protocol 3 key.

A DNSSEC-bis validator cannot validate with these keys and since the
zone is supposed to be secure, by virtue of the DS RRs this zone is to
be marked bogus. (I the validator cannot determine the selfsignature
over the keyset the sone should be marked bogus.)

The language I tried to provide was to prevent 'degradation
attacks'. That is, you have both protocol keys in your keyset and an
attacker is stripping DNSSIGs of one of both types.

For algorithm degradation attacks we have spend a lot of time in
preventing this. The fact that there is an algorithm field in DS
helps, I am not sure if it is crucial in preventinon of degradation
attacks.

Although I thought that minor language modifications would help I am
changing my mind...I am starting to get more and more convinced that
trying to modify flags and protocol fields now opens up a whole set of
security considerations that will take far to much time to solve.

I am now in favour of closing this lid and not touching protocol or
the flags in DNSSEC-bis and live with them as is.

-- Olaf
   No hats.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 14 Jun 2004 12:36:42 +0200

> verify against you have to treat the zone as bogus.

Again, what do you mean by "bogus" in this context?  I believe it
should mean "insecure", i.e. downgrade to vanilla DNS.  But Scott Rose
thought SERVFAIL should be returned here.  If there isn't agreement on
the interpretation, perhaps this should be clarified.

> data should pass through as not being validated.

Right.  But I believe they should pass through.  There appear to be
disagreement on that.

> validate in a secure zone implies bogus results.

"Bogus results" is not well defined.  Do you mean resolvers are
permitted to return anything it want?

> IMHO, without degradation attack prevention you cannot use the field,

I believe you can.  Send two DNSKEYs:

foo.example    IN DNSKEY proto=3 ...
foo.example    IN DNSKEY proto=4 ...

Are you saying that a conforming DNSSECbis resolver would reject this
response and return SERVFAIL?  Or should it ignore the unrecognized
second DNSKEY, validate the data using the proto=3 key and (assuming
verification succeed) proceed as normal?

Thanks,
Simon

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Jun 2004 12:42:16 -0400

>So you have to ordain something like ... "If andy of the secure entry points

Ahh - I should have added that m-w.com didn't have a guess as to what 
the word was either.  But, nevertheless...

>effect during transition).

Yeah, I seem them related because:

1) You start validation with data and RRSIGs.  If one RRSIG indicates 
a key I can use and another indicating a key I can't use and we 
assume the first is stripped, the process is hosed.

Relying on signatures to guide the validation is both an assumption 
of the process and danger as there's no guarantee the RRSIG's will 
arrive.

>field set to 4. And that the DS RR was signed with a protocol 3 key.

Hmm, well in this case, the validator can tell that there's a 
problem.  It knows, verifiably, that data in the child is 
unverifiable even though the parent is.  We've definitively hit the 
end of an island of security.

>the flags in DNSSEC-bis and live with them as is.

Closing the lid but you have no hat.  (Pun in there somewhere.) ;)

I'm not so sure this would be a bad way to go.  I'm not sure it has 
promise either, but it needs thinkin' out.

It's not safe to put a DNSSEC version indicator in the RRSIGs - 
because they can get stripped off without notice.  But, if I have 
data and fail to verify it but have a trusted key that is potentially 
"in play."  The next step is to see if the data ought to be secured - 
and maybe there is the place where the protocol number in the key and 
DS can play a role.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.

---

From: David Blacka <[email-masked]>
Date: Mon, 14 Jun 2004 13:54:29 -0400

> the interpretation, perhaps this should be clarified.

The term "bogus" is defined in draft-ietf-dnsext-dnssec-intro-10, section 5, 
and again in -dnssec-protocol-06, section 4.3.  As specified, when a 
validator determines that a responses is bogus, for whatever reason, it 
returns SERVFAIL.

> Right.  But I believe they should pass through.  There appear to be

If there is no trust anchor, then the validator has no reason to expect a the 
answers should be signed, and no way to validate the answer if it is.  This 
is defined as the "Insecure" state.  There is no disagreement about this.

> permitted to return anything it want?

"Bogus" *is* well-defined.  Granted, this term wasn't defined before this 
latest round of documents.  And it hasn't displaced the term "BAD" everywhere 
in the docset.  Maybe -intro or -protocols (or both) should define "BAD" as a 
synonym of "Bogus".

> verification succeed) proceed as normal?

The latter.

In this case, the validator would discard the proto=4 key for validation 
purposes, and thus effectively ignore RRSIGs generated by this key.  If an 
RRset *only* had RRSIGs by the proto=4 key, it would either generate a 
requery for the "missing" RRSIG or consider the response bogus (or BAD, if 
you prefer).

However, I don't know what use this case is for the purposes of DNSSEC 
versioning.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 14 Jun 2004 20:31:15 +0200

> validator determines that a responses is bogus, for whatever reason, it 

Thanks for the pointers.  Where is the requirement to respond with
SERVFAIL described?  Or more generally, where is resolver behaviour
when resolvers receive bogus data discussed?

>> verification succeed) proceed as normal?

Excellent!  Maybe I had simply not understood how "bogus" data was to
be treated.  From the previous discussion I got the impression that
resolvers would treat the above data as bogus.  If the above work, I
believe using proto=4 as a extension mechanism is possible.  Just
define what DNSKEY with proto=4 mean.  Resolvers that do not support
it, will use proto=3 and continue work, whereas resolvers that support
proto=4 might use that key instead.

But this just reinforce my opinion to add the text I suggested
initially.  If the text is adopted, we can use bit field signaling
instead of protocol fields for extensions, which would be cleaner.

Thanks,
Simon

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 14 Jun 2004 21:03:24 +0200

> Hmm, well in this case, the validator can tell that there's a problem. 
>  It knows, verifiably, that data in the child is unverifiable even 
> though the parent is.  We've definitively hit the end of an island of 
> security.
>

I think this is incorrect, let me try to explain,

The validator MUST not use proto=4 keys for validation. So the DNSKEY 
set cannot be validated, hence the self signature cannot be validated 
and the DNSKEY RRset  should be marked as bogus.  (That is how I read 
the scripture, I hope there is no ambiguity)

DS does not have a proto field that could have been used to indicate 
that one is pointing to a proto 'n' key. So we cannot use DS to make 
the transition.

If we allow proto=4 to be used for DNSKEY validation than we are fine 
we could 'hack' around this.

> Closing the lid but you have no hat.  (Pun in there somewhere.) ;)

my pun-o-meter is in the red :-)

--Olaf

---

From: David Blacka <[email-masked]>
Date: Mon, 14 Jun 2004 15:12:35 -0400

> > The term "bogus" is defined in draft-ietf-dnsext-dnssec-intro-10, section
> > 5, and again in -dnssec-protocol-06, section 4.3.  As specified, when a

In -intro-10 this is discussed later in the same section (5):

   This specification only defines how security aware name servers can
   signal non-validating stub resolvers that data was found to be
   bogus (using RCODE=2, "Server Failure" -- see
   [I-D.ietf-dnsext-dnssec-protocol]).

In -protocol-06, this is stated (sort of) in section 5.5.  Although
that language is talking about what happens when RRSIGs do not
validate, specifically.  It is also mentioned briefly in section 3.2.2
in the context of the CD bit.

Note to the dnssec-editors: I think that we want to make clear that
SERVFAIL is returned not just when RRset fails to validate, but in all
situations where "bogus" applies.  This is clear (to me, anyway) from
the language in -intro-10, but it is not mirrored in -protocol (that I
could find).

> instead of protocol fields for extensions, which would be cleaner.

I do not see how the protocol field can be used for extensions.  Maybe
I just don't understand what you mean by "extensions"?

In my mind, what we are driving towards are mechanisms for
*non-backward-compatible* versions or extensions to DNSSEC.  If the
"extension" is backwards-compatible, then no signalling is needed,
AFAICT.

If the "extension" is not backwards compatible, then having the
proto=3 present will cause DNSSEC-bis compatible resolvers to choke on
the "extension", as it can't tell that this zone isn't DNSSEC-bis.
All it can see is that there are irrelevant DNSKEYs and irrelevant
RRSIGs.

However, lets think about what happens with all zone apex keys are
proto=4, and the zone is part of an island of security.  So, to
sorta-kinda reprise Ed's example:

 example.com has a secure delegation for newzone.example.com:

and newzone.example.com has:

   newzone.example.com. SOA ...
                        RRSIG(SOA)
   newzone.example.com. NS ns1...
                        NS ns2...
                        RRSIG (NS)
   newzone.example.com. DNSKEY key1, proto=4
                        DNSKEY key2, proto=4
                        RRSIG(DNSKEY)

a DNSSEC-bis aware resolver (i.e., unware of what proto=4 means), will
have a very hard time with this, because it will a) expect
newzone.example.com to be secure, and then be unable to validate
anything in it.  It may be able to tell that the DS in example.com
corresponds to key1 in newzone, but it won't be able to validate the
DNSKEY RRset in newzone (or any other RRset, for that matter).  Thus
will have to conclude that every answer coming from this zone is
bogus.

We *could* go further and specify that proto > 3 means that the
DNSKEYs work the same as proto=3, thus allowing the validator to
validate the zone apex DNSKEY RRset, but that, if all DNSKEYs are
proto > 3, then the zone should be considered Insecure.  This might
work, but it requires more thought.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Jun 2004 15:18:23 -0400

At 21:03 +0200 6/14/04, Olaf Kolkman wrote:
>>  Hmm, well in this case, the validator can tell that there's a problem.  It
>>knows, verifiably, that data in the child is unverifiable even though the
>>parent is.  We've definitively hit the end of an island of security.
>>

Before even responding to Olaf, I just went back over the intro 
document and noticed that it defines "island of security" a bit 
differently than I do - but not in a contradictory way.  I've always 
thought of an island as being a subtree  whose members are all linked 
through secure delegations with the root being a secure entry point. 
The docs say only the root of such a subtree is an "island of 
security."

>The validator MUST not use proto=4 keys for validation. So the DNSKEY set
>cannot be validated, hence the self signature cannot be validated and the
>DNSKEY RRset  should be marked as bogus.  (That is how I read the scripture, I
>hope there is no ambiguity)

For DNSSECbis, this is clear.

>DS does not have a proto field that could have been used to indicate that one
>is pointing to a proto 'n' key. So we cannot use DS to make the transition.

If I said otherwise, I was confusing the protocol field with the 
algorithm field.

>If we allow proto=4 to be used for DNSKEY validation than we are fine we could
>'hack' around this.

It wouldn't be so much of a hack if we defined protocol 42 to be 
DNSSECter.  DNSSECbis would simple be unable to deal with these keys, 
letting them fall into the bogus category.

Going back to the assumption that I am dealing with a zone that is 
written in DNSSECbis and DNSSECter, and I only understand DNSSECbis, 
I should still see a DS RRset signed with a key designated as 
DNSSECbis protocol.  I then have hashes that I ought to be able to 
apply to the the set of keys at the child, even if they are written 
in DNSSECter.  I should be able to validate them via the hash, 
therefore concluding what I read is true - that these are all 
DNSSSECter keys.

At that point, I think it's safe to conclude that I've hit the 
boundary of a DNSSECbis island of security (my version), to use the 
-intro, I've fallen from a DNSSECbis island of security through some 
zones, into a zone with no security.

Instead of SERVFAIL, I return this as unsigned data to someone asking 
for verified data.

If this approach can stand up, I'd prefer it than having to deal with 
the bits of the key flags, for the sake of simplicity.  (Lot of if's 
there.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 14 Jun 2004 21:47:20 +0200

> written in DNSSECbis and DNSSECter, and I only understand DNSSECbis, I 
> should still see a DS RRset signed with a key designated as DNSSECbis 
> protocol.  I then have hashes that I ought to be able to apply to the 
> the set of keys at the child, even if they are written in DNSSECter.  
> I should be able to validate them via the hash, therefore concluding 
> what I read is true - that these are all DNSSSECter keys.
>

You are about to convince me but one thing that worries me a crypto 
vulnerability.

Crypto is not my field of expertise and I maybe heading to circular 
reasoning. So to really understand if there is a problem there I would 
appreciate a pointer on how difficult it is to generate a SHA1 hash 
collision if you have
a number of fixed bits and a number of completely random bits that are 
used as an argument.

( What I am trying to understand is how easy it would be for 'the bad 
guys' to create a DNSKEY RR with the appropriate flags, algorithm and 
protocol field (that are all fixed) and a public key field that has no 
restrictions whatsoever.  The only requirement would be that it matches 
the parental DS RR, there would be no need for the key blob to be an 
actual public key which makes the space in which you try to locate the 
hash collision easier to scan.

You would always be able to use such a key  to perform a DOS attack, we 
know that. But you do not want to be able to use such a completely 
random key to go from a secured to a in-secured world. )

Pointers are appreciated off-list.

--Olaf
   No hats

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Jun 2004 15:49:52 -0400

>work, but it requires more thought.

Tossing out this - how safe is it to assume that if the hash in a DS 
RR matches the DNSKEY RR with proto=4, that the DNSKEY RR is genuine? 
Even if the RRSIG over the DNSKEY set indicates keys that are all 
proto=4?

Ahh - we lose the ability to detect signatures out of time.  I know 
we've kicked around the utility of signing the DNSKEY RRset in light 
of the DS RR hash.  The reason the signatures are still relevant is 
because they are the only means the child has to limit the time the 
key set is "validate-able."  (The DS RR is also signed and thus time 
limited, but this time limit is supplied by the parent.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Jun 2004 15:52:21 -0400

>You are about to convince me but one thing that worries me a crypto

The same thing worries me.  And, after reading David's note, I 
recalled that with out the verifiable signature, the child zone has 
no way to state a signature validation period over the key set.

The rest of your note is also a concern of mine...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Rob Austein <[email-masked]>
Date: Mon, 14 Jun 2004 16:03:21 -0400

> Even if the RRSIG over the DNSKEY set indicates keys that are all 

Define "genuine".  Seriously.

Properly signed DS is an attestation by the parent that it believes
that the child has asked to have this signed key hash listed and that
listing this signed key hash doesn't violate the parent's (unknown,
not part of protocol) policies.  Further deponant sayeth not.

---

From: David Blacka <[email-masked]>
Date: Mon, 14 Jun 2004 16:07:20 -0400

> Even if the RRSIG over the DNSKEY set indicates keys that are all

I suppose it is fairly safe.  My thinking is that if it wasn't (if Olaf's 
crypto concerns were actually a concern, then DS is problematic already).

> limited, but this time limit is supplied by the parent.)

This is an issue.  A bigger issue, in my mind, is that a validator would 
*only* trust that key.  You would be unable to chain that trust to a ZSK, for 
example.  Very annoying.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Jun 2004 16:46:10 -0400

Genuine - meaning that the match of the DNSKEY proto=4 and the DS 
hash is not the result of a malicious party's insertion of data.

Let's put the question another way.  This is a question, I'm seeking ideas.

I begin with a trusted key that I do not question, it's "configured." 
I use it to verify, in the DNSSEC sense, down the tree to a DS RR 
(set).  I now pick up a DNSKEY RR and find that it matches the DS's 
RR set.  How much to I gain by finding out that the DNSKEY set also 
matches the signature generated by one of the private keys 
corresponding to the set?  What are the chances it'll fail the 
signature check?

So, by genuine, I mean, the DNSKEY was used to generate the DS RR's 
hash for it, and not some other public key that was crafted to match 
the hash.

(Does this make sense?  I barely makes sense to me.)

---

From: Rob Austein <[email-masked]>
Date: Mon, 14 Jun 2004 17:06:37 -0400

> hash for it, and not some other public key that was crafted to match 

To the extent that I understand the basic criteria for a cryptographic
hash function, if it is possible to find "some other public key
crafted to match the hash", there's something seriously wrong with the
hash algorithm (or someone has broken the hash algorithm, which
amounts to the same thing).

If you want a better answer, ask a cryptographer. :)

---

From: Jelte Jansen <[email-masked]>
Date: Tue, 15 Jun 2004 12:32:50 +0000

> a number of fixed bits and a number of completely random bits that are 

I am replying to the list, since you do not seem to be the only one who 
worries about this.

Note that I am not a mathematician and therefore also not a real 
cryptographer, but I do interest myself in these matters :)

A good hash function has the following properties:

1) The hash value is completely determined by the complete input. I.e. 
all bits in the input are used and there are no external sources.

2) The function distributes the 'uniformly' input values over the 
complete set of possible hash values (the number of collisions for each

3) The function generates very different values for nearly identical 
inputs (avalanche property: if you change 1 bit in the input, about half 
of the output bits should change, and it should not be predictable which 
bits. SHA1 is known to have this property).

Combining 2 and 3, it is at least as hard (if at all possible) to find a 
collision with a number of fixed bits in the input value than it would 
be to completely brute-force towards a collision (your chances of 
finding one are equally reduced as your search space). For a limited 
input size, there might not even be a collision in the set of inputs you 
have left.

Note that I do not have any numbers on it, but I believe they would come 
in handy both as a way to be sure and as a way to come up with nice 
expiration times and ttl's. I could try to make some, but I think there 
are people more suitable to do that than I am.

Assuming that SHA1 is a good hashing algorithm (and I do not know of any 
attacks against it, which is about the only validation you can have in 
crypto, so it probably is), I think that forging collisions is not a 
problem here.

Jelte

---

From: Jim Reid <[email-masked]>
Date: Tue, 15 Jun 2004 12:20:22 +0100

>>>>> "Jelte" == Jelte Jansen <[email-masked]> writes:

    Jelte> Assuming that SHA1 is a good hashing algorithm (and I do
    Jelte> not know of any attacks against it, which is about the only
    Jelte> validation you can have in crypto, so it probably is), I
    Jelte> think that forging collisions is not a problem here.

Once upon a time, the world thought that MD5 collisions were unlikely.
And before that ISTR the same thing being said about a Snefru or some
other Merkle(?) hash algorithm. So it would be prudent to assume that
one day someone will find SHA collisions, however unlikely that seems
to be today. That scenario should however be closed off by allowing
for new hash/crypto algorithms to be introduced for DNSSEC: ie SHA-N
is "stronger" than SHA-(N-1).

Please remember too that just because no attacks have been published,
doesn't mean they don't exist. The inventors of DES said they knew
about differential cryptanalysis (or at least NSA hinted at it) 20-odd
years before Biham and Shamir invented it.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 15 Jun 2004 12:59:59 +0100

> hash collision easier to scan.

The answer is "impossibly hard". The expected number of keys you would 
have to try before you found a collision with a particular existing key 
is 2^159 (10^39).

I'm not sure I understand the argument that the key blob needn't be a 
real public key, but it doesn't matter - 10^39 random blobs is 
sufficient defence.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Jun 2004 09:50:17 -0400

At 12:32 +0000 6/15/04, Jelte Jansen wrote:
>Olaf Kolkman wrote:
>>  Crypto is not my field of expertise and I maybe heading to 
>>circular reasoning. So to really understand if there is a problem 
>>there I would appreciate a pointer on how difficult it is to 
>>generate a SHA1 hash collision if you have
>>  a number of fixed bits and a number of completely random bits that 
>>are used as an argument.
>>
>
>I am replying to the list, since you do not seem to be the only one 
>who worries about this.
>

Crypto, shmipto.  Okay, I'm satisfied that the DS hash of a key is 
about as good as a "proof" of a key's validity as any RRSIG out 
there.  I.e., if the DS hash passes for a DNSKEY RR, checking the 
RRSIG(DNSKEY) doesn't get you that much more "crypto-security."  Yes, 
more checks are better than less checks (usually), but there's a 
point where we are being too perfect.

However, the issue remains that if you don't validate the RRSIG you 
don't get to validate the child zone's signature validation period. 
(This is the only reason why I didn't try *at all* to get us to *not* 
sign the DNSKEY RR set after we studied the DS RR.)

I think the real question still is: if I can validate the DS RR can I 
can conclude an "end of useful" security because the DNSKEY RR's in 
the child are unusable to me?

It's yes, if you are willing to accept the parent's RRSIG validity 
time as important, it's no if you want to hear from the child.

Maybe it is yes.  If the parent has a DS RR set that is now valid, 
and points to bad keys (in the eyes of the resolver), but the child 
has a fresher set that has some good keys - can the resolver ever 
make use of them?  I think not, because there's no reason the 
resolver will get "pointed" to the "good" keys in a verifiable manner.

---

From: David Blacka <[email-masked]>
Date: Tue, 15 Jun 2004 10:52:05 -0400

> the child are unusable to me?

So... If I (being a security-aware resolver/validator) have:

  * followed a secure delegation (that is, I found and verified one or
    more DS records),

  * then, when I fetch the child's DNSKEY RRset, I am able to match
    *all* of the DS records in hand to DNSKEY RRs,

  * yet none of them are usable (i.e., proto=4).

I am thinking that one could securely conclude that this was the
intent of the zone publisher and thus am comfortable treating this
delegation as an Insecure delegation.

Another way to ask this question: Is there any way for an attacker to
downgrade a zone using this technique?

I am presuming that the childs DNSKEY RRset is unable to be
validated, although that may not matter greatly.

I can see that if, for instance, one did not require that all of the
DS records match proto>3 keys, you would have a problem: the parent
could have one DS record for a proto=4 key and one for a proto=3 key,
and that attacker could have stripped (or altered) the childs proto=3
key, thus downgrading the zone.

> resolver will get "pointed" to the "good" keys in a verifiable

I think that you are correct.

So far, using proto>3 (or Simon's DNSKEY flags) looks somewhat
promising to me as an alternate way to do DNSSEC-ter.  I will note
that this technique might (slightly) increase the complexity of the
validator.  Without this technique, a validator will always be able to
determine the security status of the child just by looking at the
parent's delegation point.  With this technique, it would have to be
able to make this distinction after fetching the child's DNSKEY set.
I cannot tell if this would present a problem.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Jun 2004 11:35:46 -0400

>I cannot tell if this would present a problem.

Referring to the last sentence first, I think it's acceptable because 
going to the child means you are going closer to the authority.  And 
it's no worse that the case of "bad algorithms."

I think we might be able to have no more complexity in the (design of 
the) validator.  This is based on the observation that the case of 
(proto > 3) keys is the same as the case of (proto = 3 && algorithm 
!= ones-I-understand).  Note: This is an uneducated view of someone 
that has not written a validator in eons.

(I know we "require" mandatory to implement, but a validator's code 
will have to deal with the situation that the set has no mandatory to 
implement keys - because "mandatory to implement" does not mean 
"mandatory to use.")

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jun 2004 11:39:29 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "David" == David Blacka <[email-masked]> writes:
    >> I think the real question still is: if I can validate the DS RR
    >> can I can conclude an "end of useful" security because the DNSKEY
    >> RR's in the child are unusable to me?

    David> So... If I (being a security-aware resolver/validator) have:

    David>   * followed a secure delegation (that is, I found and
    David> verified one or more DS records),

    David>   * then, when I fetch the child's DNSKEY RRset, I am able to
    David> match *all* of the DS records in hand to DNSKEY RRs,

  The "in hand" worries me.

  I assume you verified all of the DS records that there were.
  Are there possibly DNSKEY RRs which have no corresponding DS record
left?

    David> I am thinking that one could securely conclude that this was
    David> the intent of the zone publisher and thus am comfortable
    David> treating this delegation as an Insecure delegation.

  I think so too.

    David> Another way to ask this question: Is there any way for an
    David> attacker to downgrade a zone using this technique?

  An attacker can remove one of the DS records, but the DNSSIG(DS) will
catch that. 
  An attacker can remove one of the DNSKEY records, but you said you
matched each DS to a record, so that would be detected. If you found a
KSK, the DNSSIG(DNSKEY) would prove that too.

    David> I am presuming that the childs DNSKEY RRset is unable to be
    David> validated, although that may not matter greatly.

  Depends upon how pathological a situation you want to deal with.

    David> I can see that if, for instance, one did not require that all
    David> of the DS records match proto>3 keys, you would have a
    David> problem: the parent could have one DS record for a proto=4
    David> key and one for a proto=3 key, and that attacker could have
    David> stripped (or altered) the childs proto=3 key, thus
    David> downgrading the zone.

  Won't that fail the DS hash though?
  (I guess I need to review what DS hashes)

    David> technique, a validator will always be able to determine the
    David> security status of the child just by looking at the parent's
    David> delegation point.  With this technique, it would have to be
    David> able to make this distinction after fetching the child's
    David> DNSKEY set.  I cannot tell if this would present a problem.

  If we say this soon, I think we are okay.
  No flag days in upgrading software to be more careful.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Jun 2004 16:13:27 +0000

> validated, although that may not matter greatly.

that's a tautology.  you won't be able to use the keys necessary to
validate the self-signature on the keys.  so in fact, the inability
to validate the dnskey rrset will be the driving issue.

> downgrade a zone using this technique?

i don't think so.

> key, thus downgrading the zone.

that's similar to all forms of "can corrupt the secure part of the zone"
attacks, and isn't new with (proto>3).

> I think that you are correct.

me too.  but it's worth noting that this is a protocol failing, not an
attack vector.

> I cannot tell if this would present a problem.

i think it's a problem, and it leads me to the opposite conclusion.  the
proto field is worthless for -trans, simply because not every metadata rr
has it.  by the time you've gone looking for the information you need to
know to determine whether you should trust what you saw, you already had
to trust it to do the looking, so what you find is a wider source of
possible failures, but not a wider source of possible successes.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Jun 2004 12:09:06 -0400

>   The "in hand" worries me.

For good reason.

>   I assume you verified all of the DS records that there were.

I assume that we begin with: one RRSIG(DS) has verified the DS set, 
and that for each DS RR in the set, a corresponding DNSKEY was found.

(Whether there are other DNSKEYs present or absent(stripped) or not ...)

>   Are there possibly DNSKEY RRs which have no corresponding DS record

They wouldn't do any good.  Members of the DNSKEY set that are not 
referred to by the DS RR set are not acceptable entry points.  What's 
to keep an attacker from adding a DNSKEY I can grok and adding an 
RRSIG(DNSKEY) to "prove it."

...

>   An attacker can remove one of the DS records, but the DNSSIG(DS) will

Most certainly.

>KSK, the DNSSIG(DNSKEY) would prove that too.

Not necessarily, but I think it's an interpretation thing.  E.g., 
Lets say that the DS set as pointers to A, B, C, and the DNSKEY set 
at the authoritative servers has A, B, C, D.  If D is stripped, I 
can't tell without a useable RRSIG(DNSKEY).  If C is stripped, the DS 
is sufficient to detect that.

>   Depends upon how pathological a situation you want to deal with.

That would happen if the validator can't process A, B, C keys, even 
if D is understandable.

>   (I guess I need to review what DS hashes)

The DS hash "points" to a DNSKEY RR.  So, we can line up the "proven" 
by parent keys.

>   No flag days in upgrading software to be more careful.

I beginning to think that this, which I think is merely an extension 
of the problem of mismatched algorithms, is a promising way to go 
forward.  But, note that DNSSECbis era (proto=3) will treat the 
"enhanced" proto=4 zones as unsecured.

But that's the verifier's problem, not the servers'!
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Jun 2004 14:39:35 -0400

>possible failures, but not a wider source of possible successes.

I'm not following your logic.

Let's say I start by getting an answer RR set and the RRSIG(s).  I go 
off and ask for the DNSKEY RR for each RRSIG interatively - let's say 
the retrieval is recursive.  So, when I get a return from the 
function to get the DNSKEY identified by the RRSIG, I get either 
success and then validate the signature, or I get a failure.  (If 
successful, I break the iterations.)  If there are no acceptable 
DNSKEYs to use after all iterations, there's no validation to be done.

(Note that the key specified in the RRSIG need not be in the same 
*domain* as the answer, I might "chase" it if my local policy so 
allows.)

But all is not lost, I perhaps there was no "security to be expected" 
to begin with.  So, I look to my trusted keys, choose the closest 
enclosing one for the query and follow it down the zone cuts to my 
data.  It makes no sense to go to a more general encloser as I 
presumably only configure keys I can make sense of.

(I'm not espousing this to be the way to write the code, it's just an 
algorithm.  The details between algorithm and implementation might 
hold the missing link that prevents me from following the logic 
above.)

What I would expect to find (looking at the closest trusted key to 
the answer) is an island of security "relative to me, my capabilities 
and policy."  There are keys of my chosen algorithms, and of my 
chosen protocol version(s), etc.  As I descend through or from 
(depending on what you consider the island to be) the island via zone 
cuts, I'll either get to the desired zone or find an "end of 
security" relative to me (the verifier).  If I get to the data I 
want, well something fubar'ed earlier and I might be able to do 
validation after all.  If I find the "end of security," I can 
conclude that finding no key for any signature wasn't a problem. 
"End of security" might be running out of protocol={me} or 
algorithm={what I can do} or just a NSEC saying there's no DS set.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 Jun 2004 23:09:14 +0200

>    [I-D.ietf-dnsext-dnssec-protocol]).

Thanks.  This is CD=0, right?  Stub resolvers do not want to validate
DNSKEY's, so if the DNSKEY is proto=3 or proto=4, they wouldn't care.
I'm more interested in how the name server for the stub resolver
behave.

> validate, specifically. It is also mentioned briefly in section
> 3.2.2 in the context of the CD bit.

I think this is getting to the core of the issue.  Can we assume that
name servers will not treat responses with both DNSKEY proto=3 and
proto=4 as BAD?  If so, I believe we have an migration path to a
DNSSECter in proto=4 (or, as I prefer, via bits 8-14).

> the language in -intro-10, but it is not mirrored in -protocol (that I

Just make sure responses with partial bogus and partial good DNSKEYs
will not be regarded as bogus, but instead good.

> I just don't understand what you mean by "extensions"?

Yes, I haven't been clear.  Let me try one idea of what I'm
envisioning.

I'm seeing proto=4 (or "critical bits") as a vehicle for a migration
mechanism to DNSSECter, at end nodes, which can work smoothly with
only DNSSECbis deployed in the infrastructure.

If a DNSSECter use the same RRs, with the same owner names, and
DNSSECbis resolvers will happily ignore proto=4 DNSKEYs as long as
they see working proto=3 DNSKEYs, they will forward the proto=4
DNSKEYs (together with the proto=3 which it itself understand) to any
clients (since it is needed by DNSSECbis client to verify the DNSKEY
RRset RRSIG).  If, eventually, the client understand DNSSECter, it can
validate the response using DNSSECter instead of DNSSECbis, even
though all middle name servers didn't understand DNSSECter.  Is this
any more clear?  I understand I haven't made this point clear, but
this has only been one aspect of things, and not the most important
that I thought of to describe at first.

There may be more modifications required to get this working.  E.g.,
to NSEC.  Perhaps something like this:

alfa.example IN DNSKEY proto=3 ...
alfa.example IN DNSKEY proto=4 ...
alfa.example IN NSEC alfa.example A MX RRSIG NSEC
alfa.example IN NSEC H(beta.example.org A MX RRSIG

A DNSSECbis client would be happy (although negative data can be
spoofed), and DNSSECter clients would be happy (and using the hashed
NSEC approach, could detect negative spoof attempts -- _without_
permitting zone walking).

Thanks,
Simon

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Jun 2004 17:11:59 -0400

At 14:39 -0400 6/15/04, Edward Lewis wrote:
>(Note that the key specified in the RRSIG need not be in the same *domain* as
>the answer, I might "chase" it if my local policy so allows.)

When I wrote that - in the back of my mind is this in the -records
draft:

# 3.1.7  The Signer's Name Field
#
# The Signer's Name field value identifies the owner name of the DNSKEY
# RR which a validator should use to validate this signature.  The
# Signer's Name field MUST contain the name of the zone of the covered
# RRset.  ...

Zeroth - there's a should there, in small letters.  s/should/is supposed to/

First I can't believe that's in the records draft - it seems to be a
restriction on validation, which would be protocol.  (There are other
things that fall into the "why would this be a records consideration"
but aren't all that important.)

Second, aren't validators allowed to be bound by local policy in this
manner?  Can't we have out of domain signers of data?

(I know we've hashed this around before, but if there was a reason to
leave this restriction in, where's the summary text of the previous
rehashing?  Besides the archives, I mean.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: David Blacka <[email-masked]>
Date: Tue, 15 Jun 2004 18:39:06 -0400

> I'm more interested in how the name server for the stub resolver

Right, CD=0.

> will not be regarded as bogus, but instead good.

I do not believe so.  As long as the validator can establish a chain of trust 
using the proto=3 keys, that fact that it throws out the proto=4 keys is not 
an issue (unless you have some RRsets only signed with the proto=4 keys, in 
which case "legacy" validators will consider them bogus).

> permitting zone walking).

An interesting concept.  Until this, I had not envisioned a form of DNSSEC-ter 
that would simultaneously be backwards compatible with DNSSEC-bis.  Although, 
I am not convinced that we can get this to work.  It would be interesting to 
try, however.

What Ed and I have been discussing is, essentially, the possibility of using 
proto=4 to introduce a non-backwards compatible form of DNSSEC-ter, as an 
alternative to doing typecode rollover.  This would require, IMHO, minor 
language changes to the -protocol document.

---

From: Roy Badami <[email-masked]>
Date: Wed, 16 Jun 2004 01:58:13 +0100

Simon> NSEC alfa.example IN NSEC H(beta.example.org A MX RRSIG

    Roy> Is that meant to imply that you're hashing the target name
    Roy> but not the owner name?  It's not immediately obvious to my
    Roy> how that would work either to achieve authenitcated denial or
    Roy> to prevent zone walking...

Oops, sorry, forget I asked that (or at least don't reply on
namedroppers) since that would be dragging this thread into radio
silence territory (sorry, mea culpa)

	-roy

---

From: Roy Badami <[email-masked]>
Date: Wed, 16 Jun 2004 01:50:54 +0100

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

Is that meant to imply that you're hashing the target name but not the
owner name?  It's not immediately obvious to my how that would work
either to achieve authenitcated denial or to prevent zone walking...

       -roy