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

[Andrew Sullivan <[e-mail]>]

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
[e-mail]
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext