Subject: [dnsext] Issues in WGLC of dnssec-bis-updates

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Feb 2012 10:18:20 -0500

Dear colleagues,

We're still in the WGLC on dnssec-bis-updates, but we have some
pending issues to sort out.

At the moment, we have several issues that have been raised in the
WGLC, but not much in the way of proposed resolution.  Sam Weiler says
he is tracking them; and many of the issues have been fairly minor,
but I want to make sure that we don't go back into a long period of
benign neglect of this document, so I'd like to hear some responses.

The following are substantive issues that require more than minor
changes to the document, and for which we need some answers.  I'm
raising them now in the hopes that we can get them closed before WGLC
ends.

A reminder that WGLC ends at the same time (this) Friday ends.

ISSUE 1: Indeterminacy of Indeterminate

In http://www.ietf.org/mail-archive/web/dnsext/current/msg12176.html,
Mohan Parthasarathy argues that RFC 4033 and RFC 4035 have
inconsistent definitions of "Indeterminate".  RFC 4033 says this is
what Indeterminate means, in section 5:

   Indeterminate: There is no trust anchor that would indicate that a
      specific portion of the tree is secure.  This is the default
      operation mode.

RFC 4035 has this definition in section 4.3: 

   Indeterminate: An RRset for which the resolver is not able to
      determine whether the RRset should be signed, as the resolver is
      not able to obtain the necessary DNSSEC RRs.  This can occur when
      the security-aware resolver is not able to contact security-aware
      name servers for the relevant zones.

These two do seem to be inconsistent.  In particular, the latter
apparently can happen when a security-aware resolver with an
appropriate trust anchor can't find an upstream that can handle the DO
bit.  Does anyone have an opinion on what to do about this?  We will
need to come to some very strong agreement quickly, or it will not be
addressed in this document.

    DEFAULT ACTION: none.  Without proposed text that finds strong
    support, this issue will be left out of the document.  

ISSUE 2: Ignoring CNAME signatures

Jiankang Yao has suggested in
http://www.ietf.org/mail-archive/web/dnsext/current/msg12166.html that
language be added to permit ignoring unsigned CNAME records under some
circumstances.  I am already on the record as personally opposing this
change, but surely I'm not the only voice here.  Does anyone have an
opinion about this?

    DEFAULT ACTION: none.  Without proposed text that finds very
    strong support, this proposed change will not be included.  If a
    change is to be added along these lines, it will require a
    separate last call on its own, because it is a major change to the
    protocol.

ISSUE 3: Alter section 5.10

Paul Hoffman requests a change to section 5.10 in
http://www.ietf.org/mail-archive/web/dnsext/current/msg12173.html.
Speaking only personally, I cannot see any objection to the proposed
sentence, "If a site has only a single trust anchor, the information
in this entire section can safely be skipped."  I'm less sure about
the motivational sentences; I'm not even sure they're true.  Does
anyone have any thoughts?

    DEFAULT ACTION: Include the "If a site has only a single trust
    anchor …" sentence, and exclude the other proposed sentences.

ISSUE 4: Request to change the language in 5.6

This is also a request from Paul Hoffman, in the same review.  Is
there any objection to his first formulation?  I believe his second
formulation would actually be a significant change to the protocol,
and as shepherd I cannot accept it without a fairly strong signal from
the WG.

    DEFAULT ACTION: Use the first formulation proposed ("In order to
    interoperate with implementations that ignore this rule on
    sending, resolvers need to allow either the DO bit to be set or
    unset when receiving responses.")

ISSUE 5: The CD bit redux

Mark Andrews argues in
http://www.ietf.org/mail-archive/web/dnsext/current/msg12133.html that
the advice always to set the CD bit is bad advice.  Does anyone else
want to take up his line of argument?  If not, I'll rule that he's in
the rough on this.

Wouter Wijngaards suggests that the discussion around this is too
long, and one of the editors agrees.  To find fault where it belongs,
the long appendix on this is there at my insistence, because several
people previously argued that it was necessary to expose the
consequences of different approaches to setting the CD bit, and yet my
finding was that there was rough consensus in favour of the "always
set" approach.  In the absence of overwhelming support in favour of
removing the discussion, I think it should stay.  If you think it
should be altered, then you need to offer replacement text and not ask
that someone come up with it.  Keep in mind that the text, long as it
is, was the subject of protracted discussion.

    DEFAULT ACTION: none.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 07 Feb 2012 16:34:52 +0100

Hi Andrew,

I support the default actions you describe.  Below are reasons for
things I feel more strongly about.

> ISSUE 1: Indeterminacy of Indeterminate

I feel the first (4033) is a better description.  I personally use a
definition for this as: this portion of the tree does not have a trust
anchor above it (higher up the hierarchy), and therefore is not secure,
insecure, or bogus.  Note that with the root trust anchor the
indeterminate state no longer occurs, since we know everything is
covered by that trust anchor.

> ISSUE 2: Ignoring CNAME signatures

The change requested seems impossible (not compatible with deployed
code, and not future compatible with intended feature too) to me, thus I
support no change.

Best regards,
   Wouter

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Feb 2012 11:23:44 -0500

Hi,

> covered by that trust anchor.

This is extremely interesting and helpful; thanks.  I wonder about
something, though.  What should we call the state you get when you
have a validating resolver that can only speak to upstream resolvers
that all respond NOTIMP (or similar) to the DO bit?  That case appears
to be covered by the 4035 definition and not the 4033 one.  Is this
"unvalidatable" rather than "indeterminate"?

Best regards,

A

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 07 Feb 2012 17:53:57 +0100

Hi Andrew,

> "unvalidatable" rather than "indeterminate"?

This would make data that is not covered by a trust anchor indeterminate
(like it was before, you have no anchor that covers it so can check no
signatures).  Data covered by a trust anchor becomes bogus, because you
cannot get the DNSSEC data for zone of the trust anchor, and its
delegations need to tell you if the data covered by it is secure or
insecure; these signatures are withheld, and this makes the result bogus.

Best regards,
   Wouter

---

From: Edward Lewis <[email-masked]>
Date: Tue, 7 Feb 2012 09:14:53 -0800

>covered by that trust anchor.

I disagree with that.

The Internet that we usually think about as being the only one is 
what I call the "global public Internet".  For the global public 
Internet, the DNS in common use does have a trust anchor for it's 
root zone so the assertion holds for the majority of cases, but then 
again only for recursive servers that have the trust anchor.

There are other inter-networks that use the DNS protocol.  In at 
least one of these, DNSSEC has not been deployed.

And, you can stretch this to the case of a recursive server, on the 
global public Internet, that does not have the root anchor configured 
- and may have another anchor.  To such a server, validating some DNS 
data is impossible (incalculable).

The protocol cannot be defined assuming one particular mode of operation.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Feb 2012 13:08:56 -0500

>    support, this issue will be left out of the document.  

A request to the folks who have done DNSSEC much longer than I have: please do resolve this somehow. It affected the development of DANE, and will probably nail others later.

--Paul Hoffman

---

From: Mohan Parthasarathy <[email-masked]>
Date: Tue, 7 Feb 2012 11:51:28 -0800

On Tue, Feb 7, 2012 at 9:14 AM, Edward Lewis <[email-masked]> wrote:
> The Internet that we usually think about as being the only one is what I
> call the "global public Internet".  For the global public Internet, the DNS
> in common use does have a trust anchor for it's root zone so the assertion
> holds for the majority of cases, but then again only for recursive servers
> that have the trust anchor.
>
> There are other inter-networks that use the DNS protocol.  In at least one
> of these, DNSSEC has not been deployed.
>
> And, you can stretch this to the case of a recursive server, on the global
> public Internet, that does not have the root anchor configured - and may
> have another anchor.  To such a server, validating some DNS data is
> impossible (incalculable).
>
Before getting to define this precisely, we should try to understand
the different cases that can occur and see whether we all agree on the
error status for the different cases.

Some RRSet needs to be validated. The RRSet was fetched with the DO bit set.

- We are able to get the RRSIGs back for the RRset. But unable to
validate completely because we are not able to get the DNSKEY RRSET or
not able to fetch the DS record. Going by 4035, this is Insecure. Two
problems here. First, it is also possible that you talked to the
DNSSEC-unaware server which does not know how to fetch the DS record.
Secondly, this could be a fake signature for which you can never
establish the trust. Do we want to declare Insecure in both these
cases ?

- We are able to get the RRSIGs back for the RRSet. But unable to
validate the signatures because it is expired. This is Bogus as per
4035.

- We are unable to get the RRSIGs back, but we got some response from
the server i.e., the main RRSet itself. Missing signatures. As per
4035, this is Bogus. But then this could be a bad CPE. Do we want to
declare this Bogus ?

We can create more examples, but it looks to me that there are only
two error cases.

1) We get some DNSSEC RRs back but can't validate. Just being able to
partially validate without tracing back to the trust anchor is equally
bad as not being able to validate the signatures.

2) We get no DNSSEC RRs back. This could be a problem in the path or
the zone is not signed. We can't tell the difference without some
extra configuration.

How does it help the application to make this more fine grained ?

-mohan

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Feb 2012 09:21:59 +1100

In message <[email-masked]>, "W.C.A. Wijngaards" writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Andrew,
> 

The delegation is secure or insecure.  The data is secure, bogus
or indeterminate.  When you follow a insecure delegation the data
is no longer under the trust anchor, i.e. there is no chain from a
trust anchor to it.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Feb 2012 10:31:08 +1100

In message <[email-masked]>, Paul Hoffman writes
:
> A request to the folks who have done DNSSEC much longer than I have: please d
> o resolve this somehow. It affected the development of DANE, and will probabl
> y nail others later.

This really is a "how many angels can you fit on a pin head" argument.

You can prove a answer is secure with respect to the trust anchors you have.
You can determine that you can't validate as secure with the trust anchors
you have.
Everything else is indeterminate/insecure as far as the application is
concerned.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Feb 2012 16:55:44 -0800

> This really is a "how many angels can you fit on a pin head" argument.

No, it is not, and please don't try to dissuade people from answering. There are two different definitions in the respective RFCs. You may not care which is right, but the rest of us do.

> Everything else is indeterminate/insecure as far as the application is

Is that proposed text for the dnssec-bis document?

--Paul Hoffman

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 08 Feb 2012 09:30:46 +0100

Hi Mohan,

The definition of indeterminate was wrong in RFC4035, and you now seem
to think DNSSEC is riddled with downgrade.  There is no downgrade,
because the security-states are the outcome of the chain-of-trust
algorithm, not implemented from its definitions in RFC4035.

At any step, if the algorithm, that is validating the chain of trust
from a trust anchor to the data, knows that it must have DNSSEC data,
but this is not available, the result becomes bogus.  Why the data is
not available does not matter.  The algorithm knows if DNSSEC data must
be available, because this is what NSEC and DS records tell at
delegation points.

DNSSEC has the interesting property that it can tell if a zone is signed
or not.  And it can do so securely.  This is very nice for backwards
compatibility.  And it solves all of the things you ask for.

> error status for the different cases.

Why data cannot be fetched is not a factor in the end result.  This
simplifies the cases to: cannot get the proper DNSSEC data, can get
proper DNSSEC data but it's invalid, can get proper DNSSEC data and it's
ok.  And the results are bogus, bogus, secure.  If you find an insecure
delegation it is insecure.  If there is no applicable trust anchor, the
result is indeterminate (that is effectively just like insecure).

> not able to fetch the DS record. Going by 4035, this is Insecure. Two

No, it is bogus.  If you cannot get the DS and DNSKEY records, the
result is bogus.

> establish the trust. Do we want to declare Insecure in both these

It is not important if the upstream server is DNSSEC unaware or if it is
lying.  If you cannot get the proper DNSSEC data the result is bogus.

> validate the signatures because it is expired. This is Bogus as per

Yes, expired is bogus.

> 4035, this is Bogus. But then this could be a bad CPE. Do we want to

Yes it is bogus.

I understand the definition of Indeterminate is wrong in 4035; but no,
downgrade attacks by the removal of DNSSEC data result in bogus.  There
are no excuses (i.e. being a CPE, being old, or being unaware) that
would make the result non-bogus.

> bad as not being able to validate the signatures.

Yes, that is bogus in today's implementations.

> the zone is not signed. We can't tell the difference without some

You can tell the difference because the chain-of-trust is signed itself,
and this extends from the trust anchor to the data you just got, and
thus you know if this zone is signed or not.  And thus in your question,
the unsigned zone is ok(insecure), and the signed-zone-missing-DNSSEC
RRs is not ok(bogus).

> How does it help the application to make this more fine grained ?

No, the application just wants all bogus data to be removed.  Data that
is secure and data that is not DNSSEC signed is what it wants.  Because
of the chain-of-trust the validator knows which parts of the space below
a trust anchor is signed (and must have DNSSEC available) and which part
is unsigned.  This property could be the cause that made insecure and
indeterminate terms exist, as indeterminate is not really processed but
simply the absence of a covering trust anchor, just like in the case
where you had no trust anchors at all.  But then insecure needs
processing: you have to validate the chain of trust from the trust
anchor to the insecure-delegation point, and only then can you conclude
that the data is insecure.  This is something internal to the DNSSEC
validator, and not particularly impressive to the application, that
likely just wants to know if the data was DNSSEC-signed (if so: secure
or bogus) or if the data was not DNSSEC-signed (as determined with the
configured set of trust anchors).

Best regards,
   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Feb 2012 21:08:34 +1100

In message <[email-masked]>, "W.C.A. Wijngaards" writes:
> is unsigned.

More correctly it knows if it should be able to get a signed answer
with signatures it is capable of verifying or not.  A zone can be
insecure, as far as the validator is concerned, even if there are
DS records in the parent zone and the validator treats the parent
zone as secure.

> This property could be the cause that made insecure and
> that the data is insecure.

No, you can conclude that you don't expect to be able to validate
it.  The break point may or may not be at a insecure delegation (no
DS records in parent zone).

In reality the first step of validation is determining if there is
a trust anchor that is could potentially result in the data being
declared secure.  From the application's perspective there is no
difference if the data came from a zone that was not under a
configured trust anchor or from a zone to which there is not a trust
chain supported by the validator.

> This is something internal to the DNSSEC

No, it want to know if it is secure or insecure (insecure data can still
be signed data).
 
Mark

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 08 Feb 2012 11:39:54 +0100

Hi Mark,

> DS records in the parent zone and the validator treats the parent

You are more correct in applying the validation implementation support
rules.

> DS records in parent zone).

Thus the set of trust anchors that is configured, and their chains of
trust, determine a number of zones that the validator can securely
determine that are signed and it has the implementation for to
dnssec-validate it.  If dnssec data needed to securely determine this is
unavailable or invalid then the result is bogus

Best regards,
   Wouter

---

From: [email-masked]
Date: Wed, 8 Feb 2012 12:32:02 +0000

On Tue, Feb 07, 2012 at 04:34:52PM +0100, W.C.A. Wijngaards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1
> Hi Andrew,
> I support the default actions you describe.  Below are reasons forthings I feel more strongly about.
> I feel the first (4033) is a better description.  I personally use adefinition for this as: this portion of the tree does not have a trustanchor above it (higher up the hierarchy), and therefore is not secure,insecure, or bogus.  Note that with the root trust anchor theindeterminate state no longer occurs, since we know everything iscovered by that trust anchor.

	Which root?  The ICANN root?  My corporate root?
	Folks use IP and DNS in networks that may not be connected to the 
	"public" Internet and thus to the ICANN root key.
	So I would say that there is existence proof that you can find 
	the ICANN root trust anchor in an indeterminate state.  I would 
	hope your code is agile enough to cope.

> The change requested seems impossible (not compatible with deployedcode, and not future compatible with intended feature too) to me, thus Isupport no change.
> Best regards,   Wouter

/bill

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 08 Feb 2012 09:47:50 -0500

> 	"public" Internet and thus to the ICANN root key.

Futher, there exists one or more networks connected to the "public"
Internet (non-locally routed prefixes) for which the IANA root zone
does not completely determine the root zone, and for which one or more
zone-restricted trust anchors would be insufficient.

> 	the ICANN root trust anchor in an indeterminate state.

Agree.

Eric

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 8 Feb 2012 10:45:46 -0800

> algorithm, not implemented from its definitions in RFC4035.
Okay, after reading your response and re-reading 4035 and 4033, I
think 4033 definitions for Bogus, Insecure and Indeterminate capture
the discussion below more clearly.

 <snip>

> result is indeterminate (that is effectively just like insecure).

Ok, Bogus, Secure and Insecure applies only when there is an
applicable trust anchor. When it is absent, it is indeterminate. That
simplifies a lot.

 <snip>
> configured set of trust anchors).
That was very useful discussion.

regards
mohan

> Best regards,
>   Wouter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.15 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJPMjK2AAoJEJ9vHC1+BF+NxVUQAIyQ4nPk7Syogn9uh4z890yJ
> kmPxslbpvHru47OxKd0tYvozldnP32z1+JToGSZR8qRU+w9SAQLutnFkqCU28x95
> QUAot8G157kxZT95zhdjVqpbyUYDYwKKUY4jqplq4IuyIm1ewEOcwAS8Sak1o9Gr
> 17Xs4aCpl55QmTCZAlP+r6SwCDY738Py9I51BJhifAB9HdkT6XK1+bsbMSiFhG+o
> koICUhKaLDthmFvBrHBVCiW4xD5uk8ww2jlMNXv2LaRT05tfVjLC0EfboFn3kEkg
> +c39M8Bm4GlkQvB1Wr37AEPn/m0PYbsC2lOEQL/04QRGiAcDTtjo4bzzsKb6yFFi
> cWg8mUsldcSikZB+YFVS0RRLGcKCWhOVHxxMqKlA/IdzBU02JiGaYqZU9SKaakkc
> 8AEFJkQdUYerh4BPeiwlzpy4uS3kiJU7A8hKnQSIuRR1xo7r28NKuvrxLnw5b3es
> kExf4pyb5zitBPx6c0ERQ1SJrw9VU3DipJb6dY/QW5uceHvfJlYQiXN6nGGKUkvw
> FlupnGef8TvHvgnHieiD9t3WRh+7WNKdMCs627U/Ym8VC0gcTXK3WORMdwrAVq7j
> I7wEkXH4ms9sJD09ZGysNjlRylKvMzHlxxIjl3kpFmvGwus//BxMq8GCT+08cJ9Z
> 5AOnYo5AWqWqa8nipilZ
> =dpSm
> -----END PGP SIGNATURE-----

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Feb 2012 13:56:17 -0500

No hat.

On Wed, Feb 08, 2012 at 09:30:46AM +0100, W.C.A. Wijngaards wrote:
> is secure and data that is not DNSSEC signed is what it wants. 

It seems to me that the above is either a matter of policy or a matter
of implementation.  That is, some applications will surely only want
data that they can know for sure is valid, and in particular will not
want any unsigned data no matter what.

This could be implemented in more than one way.  One is to hand the
application everything that is validated and unsigned, and let the
application work out which it wants.  But another would be for the
application to be able to signal this choice to the resolver.  No?

A

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Feb 2012 11:48:57 -0800

> application to be able to signal this choice to the resolver.  No?

In specific, the current proposal for DANE wants to know if it is getting bogus data. It treats bogus data as quite different than "no record received". See the bulleted list in section 5 of draft-ietf-dane-protocol-16.txt.

If the DNSEXT WG thinks that it is going to change dnssec-bis to make the change Wouter suggests, the DANE WG needs to hear about it *very soon*.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Feb 2012 10:05:10 +1100

In message <CACU5sDk8zGPF-w5BpBG21tNW1s0mpCEUP=[email-masked]>,
 Mohan Parthasarathy writes:
> On Wed, Feb 8, 2012 at 12:30 AM, W.C.A. Wijngaards <[email-masked]> wr=
> ote:
> > to think DNSSEC is riddled with downgrade. =A0There is no downgrade,
> >> On Tue, Feb 7, 2012 at 9:14 AM, Edward Lewis <[email-masked]> wrot=
> e:
> >>>> insecure, or bogus. =A0Note that with the root trust anchor the
> >>> call the "global public Internet". =A0For the global public Internet, t=
> he DNS
> >>> in common use does have a trust anchor for it's root zone so the assert=
> ion
> >>> holds for the majority of cases, but then again only for recursive serv=
> ers
> >>> There are other inter-networks that use the DNS protocol. =A0In at leas=
> t one
> >>> And, you can stretch this to the case of a recursive server, on the glo=
> bal
> >>> have another anchor. =A0To such a server, validating some DNS data is
> >>> The protocol cannot be defined assuming one particular mode of operatio=
> n.
> >>>
> > Why data cannot be fetched is not a factor in the end result. =A0This
> > ok. =A0And the results are bogus, bogus, secure. =A0If you find an insecu=
> re
> > delegation it is insecure. =A0If there is no applicable trust anchor, the

Absolutely wrong.

Step 1 of validation.
Is there a potential covering trust anchor?
	Yes.  Goto step 2.
	No.  Mark as insecure.

Step 2 ....

> > thus you know if this zone is signed or not. =A0And thus in your question,
> > No, the application just wants all bogus data to be removed. =A0Data that
> > is secure and data that is not DNSSEC signed is what it wants. =A0Because
> > is unsigned. =A0This property could be the cause that made insecure and
> > where you had no trust anchors at all. =A0But then insecure needs
> > that the data is insecure. =A0This is something internal to the DNSSEC
> > =A0 Wouter
> > =3DdpSm

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 8 Feb 2012 15:27:47 -0800

On Wed, Feb 8, 2012 at 3:05 PM, Mark Andrews <[email-masked]> wrote:
>From RFC 4033:

Insecure: The validating resolver has a trust anchor, a chain of
      trust, and, at some delegation point, signed proof of the
      non-existence of a DS record.  This indicates that subsequent
      branches in the tree are provably insecure.  A validating resolver
      may have a local policy to mark parts of the domain space as
      insecure.

So, I don't understand what you mean.

-mohan

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Feb 2012 17:15:35 -0800

>So, I don't understand what you mean.

What Mark wrote is consistent with that paragraph.  Not complete, but 
consistent.

Look at a path through the namespace:

     o      = root
     |
     o      = tld
     |
     o      = example
     |
     o      = www

Let's say that "tld." is a cut point.

Case 1 - if there are no trust anchors at all, then everything is "insecure."

Case 2 - if there is a root trust anchor and there is provably no DS 
record for tld., then all names in the tld. domain (not just the 
zone) are provably insecure.

Case 3 - (as in case 2 up to the BUT) if there is a root trust anchor 
and there is provably no DS record for tld., BUT there is a trust 
anchor for example.tld. and www is not a cut point.  In this case you 
can validate sets owned by www.example.tld.  "Insecure" is never an 
outcome.  The possible outcomes are "bogus", "valid" (or whatever 
"good" is called), and a service failure if some record cannot be 
retrieved.

Case 4 - trust anchors at root and tld.root and no cutpoints without 
a DS, then you'll never see insecure.

(I hope I have this right.)

And only "Bogus" is bad, no data is returned for Bogus and Service 
Failure.  Data is returned for Insecure and Valid.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Feb 2012 13:22:31 +1100

> Failure.  Data is returned for Insecure and Valid.

Insecure is data that validator *knows* is cannot cryptographically verify.
This may be because:
* there are no suitable trust anchors to attempt to verify with.
* there is a insecure delegation (provable no DS record) in the path.
* there is a secure delegation but no algorithm support in the path.

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 8 Feb 2012 18:41:06 -0800

> * there is a secure delegation but no algorithm support in the path.
Right, but what I wrote was not Absolutely wrong, if you assume that
there will at least be  a root trust anchor configured,  But it might
be worth clarifying the first and third bullet above for Insecure.

-mohan

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 09 Feb 2012 10:25:48 +0100

Hi Paul, Andrew,

On 02/08/2012 08:48 PM, Paul Hoffman wrote:
>>> No, the application just wants all bogus data to be removed.
>>> Data that is secure and data that is not DNSSEC signed is what
>>> it wants.
>> 
>> It seems to me that the above is either a matter of policy or a
>> matter of implementation.  That is, some applications will surely
>> only want data that they can know for sure is valid, and in
>> particular will not want any unsigned data no matter what.
>> 
>> This could be implemented in more than one way.  One is to hand
>> the application everything that is validated and unsigned, and
>> let the application work out which it wants.  But another would
>> be for the application to be able to signal this choice to the
>> resolver.  No?
> 
> 
> In specific, the current proposal for DANE wants to know if it is
> getting bogus data. It treats bogus data as quite different than
> "no record received". See the bulleted list in section 5 of
> draft-ietf-dane-protocol-16.txt.
> 
> If the DNSEXT WG thinks that it is going to change dnssec-bis to
> make the change Wouter suggests, the DANE WG needs to hear about it
> *very soon*.

Let me state that I do not want to make such a change.  For backwards
compatibility DNSSEC has this facility to figure out which zones are
signed and validatable by the validator, and this backwards
compatibility can be used for DANE too.  Thus it wants to know the
precise secure, insecure and bogus validation results.

Best regards,
   Wouter

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Feb 2012 16:43:53 -0500

Dear colleagues,

On 7 Feb I noted some outstanding issues that were pending prior to
the end of WGLC.  I want to go through the results of the discussion I
saw.

>     support, this issue will be left out of the document.  

There was not proposed text and strong support, so the issue is not
taken up.  To my eyes, the discussion mostly revealed that there are
subtle inconsistencies but that it doesn't seem to have a practical
difference.

>     DEFAULT ACTION: none.  

This is the plan.

>     anchor …" sentence, and exclude the other proposed sentences.

This is the plan.  Editors, please make that adjustment.

>     unset when receiving responses.")

This is the plan.  Editors, please make that adjustment.

>     DEFAULT ACTION: none.

There was no follow up discussion on this, and I did not see expressed
support for Mark Andrews's proposed change, so that's the plan.

Sam, as editor you said you'd tracked some other items and were
planning to follow up.  Will you do that as soon as possible on the
list, please?  

Apart from those issues, I believe the document has received enough
review that it can be sent to the IESG. 

Thanks,

A