headers
Olaf Kolkman | 1 Feb 2004 08:35
Picon
Favicon

DNSEXT list policy


- List Purpose

  namedroppers <at> ops.ietf.org is the mailing list for the IETF DNSEXT
  working group.  

  See <http://www.ietf.org/html.charters/dnsext-charter.html> for the
  wg charter.  Messages should be on topics appropriate to the dnsext
  wg, which are various discussion of the DNS protocols or
  administrivia of the WG itself.

- Specific items that are not not appropriate for posting

  Calls for papers, announcements of events not directly relevant to
  the DNS protocols, etc. are not appropriate.  

  Discussion of problems with particular implementations,
  announcements of releases, sites' misconfigurations, pleas for help
  with specific implementations, etc.  should be done on mailing lists
  for the particular implementations.

  There is a working group for dns operational practice, DNSOP, whose
  charter can be found at
  <http://www.ietf.org/html.charters/dnsop-charter.html>. Items
  relevant to the DNSOP charter are to be discussed on the DNSOP
  mailinglist.

  Discussion about the quality of implementations is outside the scope
  of this list.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Olaf Kolkman | 3 Feb 2004 14:07
Picon
Favicon

Q-28 Clarification of the scope of the document set.

Q-28 Clarification of the scope of the document set.

This is not a protocol issue, but also more than an editorial nit,
hence a question to the WG.

It is about language to be added to several parts of the document set;
During recent discussions it has became clear that some of the
architectural considerations where too implicit.

This is a first go at a draft of text that is to be added to the intro 
document. It
needs some work on the details. It has been sitting on my disk for a 
bit but I
have not been able to concentrate on it for the last few days
(the reason is on www.geerthe,org :-) ).

Note that I think that definitions of new RCODEs or EDNS0 extensions or 
other
solutions to 'solve' the last mile communications is out of scope.

--Olaf

<proposed intro text>

In the DNSSEC architecture the security aware resolver determines if
DNS deta is in one of three states "unsecure", "validated" or
"bogus". The specification in these document set is designed to make
sure these 3 states can unambiguously be determined from the answers
that are returned from security aware servers.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Scott Rose | 3 Feb 2004 18:47
Favicon

Q-29: Resolver Handling of expired RRSIGs

Q-29  Resolver handling of expired RRSIGs

From an earlier thread and individual comments:

What, if any, should be the default resolver behavior
when expired RRSIGs are contained in a response?  For example,
The one or more RRSIGs covering a RRset in the answer section
has  an expiration date in the past.

Currently, the text in the Records and Protocol document
state that they MUST be rejected (they are to be considered
"bogus", using the newly defined terminology).  Some have
suggested that is too harsh, and the default should be something
similar to the following:

"SHOULD be rejected, but MAY use RRSIGs if other security
checks were successful, depending on local policy".

That way, a resolver may be able to pass on success, and the
data could be marked "unsecure" and passed back to a security
aware stub resolver, or passed up to the application.  However,
if the application or stub resolvers are not security aware, this
could lead to a vulnerability.

Is there consensus to relax the "MUST reject expired RRSIGs" and
make it less restrictive?  Please suggest text if the above is
not sufficient.

This formal question is mainly for closure on a discussion thread that has
died down.
(Continue reading)

Permalink | Reply | 1 comment |
headers
bill | 3 Feb 2004 19:16

Re: Q-29: Resolver Handling of expired RRSIGs

> 
> Q-29  Resolver handling of expired RRSIGs
> 
> >From an earlier thread and individual comments:
> 
> suggested that is too harsh, and the default should be something
> similar to the following:
> 
> "SHOULD be rejected, but MAY use RRSIGs if other security
> checks were successful, depending on local policy".

	better language, imho.

> Is there consensus to relax the "MUST reject expired RRSIGs" and
> make it less restrictive?  Please suggest text if the above is
> not sufficient.

--bill

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 0 comments |
headers
bill | 3 Feb 2004 19:32

Re: Q-28 Clarification of the scope of the document set.


	changes sprinkled throughout, mainly changing "bogus" to "indeterminant",
	

> In the DNSSEC architecture the security aware resolver determines if
> DNS deta is in one of three states "unsecure", "validated" or
> "bogus". The specification in these document set is designed to make
> sure these 3 states can unambiguously be determined from the answers
> that are returned from security aware servers.

	I'm unconvinced that the resolver makes this choice.
	a design we are working on/with has the validator as
	an independent module that the resolver talks to and
	it is the validator that determines the "state of the data"
	and tells the resolver.  So, alternate text:

 In the DNSSEC architecture a security enabled resolver receives data
 in one of three states, "unsecure", "validated", or "indeterminant".
 The specification in this document set is designed to make sure these
 three states can unambigiously be determined from answers received
 from security aware and enabled servers or caches.

> Validated: Data is "validated" if one of possibly multiple
>          authentication chains from a trust anchor to the data itself
>          can be established. Multiple authentication chains can exist
>          when there are multiple DS RRs at a delegation point or when
>          data is covered by multiple RRSIGs.  A security aware resolver
>          may not have all possible authorization chains at its
>          disposal, either because an authorization chain is based on an
>          algorithm that has not been implemented or because there is no
(Continue reading)

Permalink | Reply | 8 comments |
headers
Mike StJohns | 3 Feb 2004 20:02

Re: Q-28 Clarification of the scope of the document set.

I think you're heading down the wrong direction here.  There are actually 4 
states.  And bogus is definitely a different state than indeterminate and 
can get handled quite differently by a resolver.

1) Secure.  I have a trust anchor, a chain of trust and I'm able to verify 
the signatures on all the data.

2) Unsecure.  I have a trust anchor, a chain of trust, and, at the 
delegation point I have a signed proof of the non-existence of the DS 
record which makes subsequent branches in the tree provably 
unsecure.  Resolver policy could also declare a portion of the tree 
unsecure from a branch point.

3) Bogus.  I have a trust anchor which is giving me an expectation that 
subsidiary data will be signed (e.g. foo.com trust anchor implies that 
bar.foo.com will be signed unless its explicitly unsecure as above),  but 
the data I'm handed fails to validate due to one or more of: missing 
signatures, invalid signatures (both for expiration and for the sig 
algorithm verification), missing data where the NXT (or what ever we're 
call them) say there should be data, etc.

4) Indeterminate.  I have no trust anchor which would indicate that a 
specific portion of the tree is secure.  This is the default case.

Indeterminate and unsecure data should be handled more or less identically 
- e.g. accepted at face value if the policy allows it.   Secure data should 
generally be accepted.  Bogus data - well.... ideally this would depend on 
what the application cares about, but in practice it will be whatever the 
policy is at the caching/recursive resolver.
(Continue reading)

Permalink | Reply | 7 comments |
headers
bill | 3 Feb 2004 20:15

Re: Q-28 Clarification of the scope of the document set.


	perhaps, but it may just be a desire to keep things "simple". 
	for now, lets presume your four states.  What else is a distingishing
	characteristic?  I see these.

	the bogus lable is primarily driven by temporal events, e.g.
	routing anomolies, head space/timing syncronization, clocking errors,
	etc.

	secure/unsecure presume routing stability, accurate clocks and 
	alert/aware operators.

	indeterminant is todays status quo.

	or do I have this wrong also?

--bill

> 
> I think you're heading down the wrong direction here.  There are actually 4 
> states.  And bogus is definitely a different state than indeterminate and 
> can get handled quite differently by a resolver.
> 
> 
> 1) Secure.  I have a trust anchor, a chain of trust and I'm able to verify 
> the signatures on all the data.
> 
> 2) Unsecure.  I have a trust anchor, a chain of trust, and, at the 
> delegation point I have a signed proof of the non-existence of the DS 
> record which makes subsequent branches in the tree provably
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ted Hardie | 3 Feb 2004 21:05

Re: Q-28 Clarification of the scope of the document set.

At 2:02 PM -0500 02/03/2004, Mike StJohns wrote:
>Bogus data - well.... ideally this would depend on what the 
>application cares about, but in practice it will be whatever the 
>policy is at the caching/recursive resolver.

I think I'm confused here.  What do you think the role of the 
application would be?
Are you thinking that on getting an error message back from the DNS, it might
engage in some activity (like throwing an error in a popup or syslog)?  Or
are  you thinking an application policy might actually cause it to accept
bogus data?
			regards,
				Ted Hardie

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 2 comments |
headers
Matt Larson | 3 Feb 2004 21:38
Picon
Favicon

Re: Q-28 Clarification of the scope of the document set.

Mike,

I think this is on the right track.  A question and a comment:

On Tue, 03 Feb 2004, Mike StJohns wrote:
> I think you're heading down the wrong direction here.  There are actually 4 
> states.  And bogus is definitely a different state than indeterminate and 
> can get handled quite differently by a resolver.
> 
> 
> 1) Secure.  I have a trust anchor, a chain of trust and I'm able to verify 
> the signatures on all the data.
> 
> 2) Unsecure.  I have a trust anchor, a chain of trust, and, at the 
> delegation point I have a signed proof of the non-existence of the DS 
> record which makes subsequent branches in the tree provably 
> unsecure.  Resolver policy could also declare a portion of the tree 
> unsecure from a branch point.

I'm assuming your "branch point" is a delegation point.  By your last
sentence, are you envisioning the ability to configure a resolver with
the notion thay, say, "Always treat foo.com and its descendants as
unsecure regardless of what security records you receive that might
state otherwise"?  I can see this being a handy feature when a zone is
known to have something wrong DNSSEC-wise but one needs to communicate
with it anyway.  Realistically these scenarios are going to occur.

> 3) Bogus.  I have a trust anchor which is giving me an expectation that 
> subsidiary data will be signed (e.g. foo.com trust anchor implies that 
> bar.foo.com will be signed unless its explicitly unsecure as above),  but
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rob Austein | 3 Feb 2004 21:43
Favicon

Re: Q-28 Clarification of the scope of the document set.

At Tue, 3 Feb 2004 12:05:35 -0800, Ted Hardie wrote:
> 
> I think I'm confused here.  What do you think the role of the 
> application would be?
> Are you thinking that on getting an error message back from the DNS, it might
> engage in some activity (like throwing an error in a popup or syslog)?  Or
> are  you thinking an application policy might actually cause it to accept
> bogus data?

Given that only the application really knows what the application's
"security" requirements are, final decision on how to handle the bad
states pretty much has to be up to the application.  All the nasty
stuff with the AD bit, etc, is just an attempt to extend -some-
protection to all the legacy DNS software that's already out there.

As I've mumbled before, sig validation is an end-to-end thing between
the DNS data producer (zone admin) and the DNS data consumer (app).

And yeah, sure, an application might have a policy like "the admin of
this zone is known to be an incompetent bozo, and I'm doing a strong
authentication check with known keys at the app layer anyway, so I
don't care whether the DNSSEC sigs check out or not".  Shouldn't be
the default policy, but you can bet that somebody's going to need to
implement something like it sooner or later for some application.

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane