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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

On 02/07/2012 04:18 PM, Andrew Sullivan wrote:
> 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
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPMUScAAoJEJ9vHC1+BF+N8EoP/0tmCJfE1muvqPaTT1f3fa32
7Fn3/7pBqlV8yPGBk00T+ntDCep/EHk/yU1Yk1nDRLIltufSPFc5LDeU+04p2Nkq
ZOTO3W8uTu8ZQmHM68Ol84zFlog0DFe42V0XOYv9wUI6CNXCiaTyC9q4pjTZw8dR
HnoPRPjdIphQuuDWOWAnO/w/gODKqk//CiAHMHosn2H2yQBBujl14Ard3iQKbz0q
ytoIPua0z4EYrL9gAl0BkOctVzhtmE4mGEan6AOcvGwxxlDVIRDvgLGvN7bvFxe7
3faUVaLH6wGhYmCHoPYd1Kxm/zLUMhXKkYtLuJ/ICZGyh3hqX6hI17fBtKYccKGf
ZPYK/CQ0YLWhKVFl/qTuKXMzcU2A3OmcBcsLWNncIlS2zMjju9Nsvr8qkWXQiP6x
lru874L65DhyFuk2/CJz4vfO2sbZmyJinF5P2TVyKz6mKHH7cWj6r+7E6dnKCrc2
W57L0clDml5koNfzQlsWoMuBZGu5Xk+xbhb35CcaLabfx9H1ESqTVDe9w/cOufPV
w3OJITPd1SyeglSc1zAheF1ydamkGOf40j4YOwzLJ/A8YOTEjxjmIMEbX+Vg6IIV
Gpi5Xrh4WeuJxRBRVyTzg+69dEHdgpqtq+WYVTKgypzZvgO1SWOj+5m3bB+uM0bH
ToMTKFX0K4TuqvOC2UDy
=JvrZ
-----END PGP SIGNATURE-----
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext