Subject: [dnsext] resolving IESG comments on draft-ietf-dnsext-dnssec-bis-updates

From: Samuel Weiler <[email-masked]>
Date: Tue, 10 Jul 2012 09:20:40 -0400 (EDT)

I've been churning through the IESG telechat comments and single 
discuss on draft-ietf-dnsext-dnssec-bis-updates.

I have two questions for the WG, and I want to report on several 
textual changes that I plan to adopt, inspired by the IESG's comments.

Q1: (from Stephen Farrell)

> During the "no answer" mega-discussion on the DANE list, [1] I
> seem to recall this comment was made more than once: "you're
> seeing all this because you're maybe the first new
> application that really needs DNSSEC," or words to that
> effect. Should any of that discussion be reflected in this
> document? (I assume its not already there for timing reasons
> if nothing else.)
>
>   [1] http://www.ietf.org/mail-archive/web/dane/current/msg04845.html

Q2: There's been another call to explain why section 3.1 says a 
validator MUST implement a BAD cache.  If nothing better comes up, I 
plan to just cite http://www.potaroo.net/ispcol/2010-02/rollover.html 
Is there anything better?  Or is there a short summary we can just 
copy into this doc?

And the changes I've made in my working copy of the draft.

> -- 2.1 --
>   signal that a zone MAY be using NSEC3, rather than NSEC.
> 
> This MAY and the one in the following paragraph are misused: they should not 
> be 2119 terms.  Describing what a zone "may be using" is simply a descriptive 
> phrase, not anything normative.  Actually, I would say "might be using".

Done.

> 1) Any reason you can't just refer to DNSSECbis as DNSSEC?  I guess does the 
> outside world know DNSSECbis isn't DNSSEC?

This is an artifact of the ages.  We started this doc just after 4034 
et. al. were published, and the WG still referred to them as 
DNSSECbis.  Given today's usage, we should probably make the change.

> 2) General: r/RFCXXXX/[RFCXXXX] throughout except for the abstract. A couple 
> of times I thought the RFC references needed to be included in [] so it's 
> probably better to just do it everywhere.  You also need to add [RFC2308] as 
> a reference.

Added the 2308 reference.  I'll leave the rest to the rfc editor.

> 3) s1 paragraph two: RFC 6410 got rid of Draft Standard so either
> r/Draft/Internet or r/from Proposed Standard to Draft Standard/along the
> Internet Standards track.    Or something like that.

Done.

> 5) s2, s2.1, s2.2: Could you replace the three instances of "should {also} 
> be" with "are"?  If the WG considers them part of the core, then aren't they? 
> It also avoids the whole question about whether it ought to be SHOULD (not 
> that I'm asking to change that).

Sure.  I used "are now" and "is now".

> 9) s5.11: could you just strike "note that"

Sure.  How about "This requirement applies to servers, not validators."?

Lastly, there is one open Discuss on the document, inspired by a 
GenART review.  Andrew Sullivan replied to the GenART review on the 
IETF list.  I'm waiting for a response from Russ Housley, and I'm 
hoping we can resolve that without more textual changes.  Feel free to 
comment on that thread separately.

-- Sam

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Jul 2012 07:50:51 -0700

On Jul 10, 2012, at 6:20 AM, Samuel Weiler wrote:

> I've been churning through the IESG telechat comments and single discuss on draft-ietf-dnsext-dnssec-bis-updates.
> 
> I have two questions for the WG, and I want to report on several textual changes that I plan to adopt, inspired by the IESG's comments.
> 
> 

It would be helpful to DANE and future protocols if "no answer" was discussed more fully. The amount of differing opinions about the four states *even among DNSSEC-knowledgeable people* in that thread and others was significant. The fact that "bogus" is defined differently in different DNSSEC documents didn't help us come to conclusion, either.

> Q2: There's been another call to explain why section 3.1 says a validator MUST implement a BAD cache.  If nothing better comes up, I plan to just cite http://www.potaroo.net/ispcol/2010-02/rollover.html Is there anything better?  Or is there a short summary we can just copy into this doc?

Citing that article works, but a short summary would be better.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Tue, 10 Jul 2012 16:28:13 -0400

On Jul 10, 2012, at 10:50 AM, Paul Hoffman wrote:

> It would be helpful to DANE and future protocols if "no answer" was discussed more fully. The amount of differing opinions about the four states *even among DNSSEC-knowledgeable people*

s/even/especially/

A number of DANE folk (myself included) had an instinctual understanding of various results, including "no answer" and "bogus" -- unfortunately we all seemed to have differnt understandings...

> in that thread and others was significant. The fact that "bogus" is defined differently in different DNSSEC documents didn't help us come to conclusion, either.

Yup!

W

> Citing that article works, but a short summary would be better.

Credo quia absurdum est.

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 11 Jul 2012 09:06:51 +0200

On 10 jul 2012, at 16:50, Paul Hoffman wrote:

> The amount of differing opinions about the four states *even among DNSSEC-knowledgeable people* in that thread and others was significant.

The big difference is between people that do think it is a good thing that people in X.509 world themselves can "click" on "continue anyways" on a validation failure. I think personally it is *feature* that with DNSSEC a validator by default do not return anything if validation fails for some reasons, and the end user can not do anything at all about it (part from running its own resolver etc etc).

But I do understand other people do have other views.

Because of this, for me, a no-response in DANE is the same as failed validation, and such a failure that the end user/application should not continue. At all. No "continue anyway" etc.

Giving the ability "to continue" opens the door for denial of service attacks as a way to circumvent DANE security.

So to me there are three states only.

- No DANE in use
- DANE in use, validation succeeds
- All other cases

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 11 Jul 2012 07:59:43 -0400

No hat.

On Tue, Jul 10, 2012 at 07:50:51AM -0700, Paul Hoffman wrote:

> It would be helpful to DANE and future protocols if "no answer" was
> discussed more fully. The amount of differing opinions about the
> four states *even among DNSSEC-knowledgeable people* in that thread
> and others was significant. The fact that "bogus" is defined
> differently in different DNSSEC documents didn't help us come to
> conclusion, either.

Although I agree with this, I thought the difference between the docs
was explained by the different perspectives the documents were working
from?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Jul 2012 07:41:56 -0700

On Jul 11, 2012, at 12:06 AM, Patrik Fältström wrote:

> The big difference is between people that do think it is a good thing that people in X.509 world themselves can "click" on "continue anyways" on a validation failure.

That is *not* where the difference of opinions about DNSSEC were. The differences were about what specific events constitute bogus versus indeterminate or insecure. There were good reasons for the WG to differentiate between bogus and indeterminate/insecure, but the DNSSEC documents had places of unclarity, including two different definitions of "bogus".

> I think personally it is *feature* that with DNSSEC a validator by default do not return anything if validation fails for some reasons, and the end user can not do anything at all about it (part from running its own resolver etc etc).
> 

Exactly. The "other views" from different people who the community thinks understand DNSSEC made it hard for us to know what to put in our document. Thus, the request for clarity in *this* document.

> Because of this, for me, a no-response in DANE is the same as failed validation, and such a failure that the end user/application should not continue. At all. No "continue anyway" etc.

This view ignores the fact that PKIX has its own protections to which DANE is adding value. It is fine if this WG wants to say in dnssec-bis-updates that other protocols that want to add value with DNSSEC should fail to less than the protocol if DNSSEC does not return "secure", and it is fine if this WG wants to say that "we aren't going to specify what other protocols will do", but the current DNSSEC documents do neither.

> - DANE in use, validation succeeds

If you want to change DANE, please so do in the DANE WG. The thread here is about making the DNSSEC document clearer for other WGs who will want to use DNSSEC. If the DNSSEC spec had been clearer on what bogus means and what the expectation of the IETF is for why there is a difference between insecure and indeterminate, the DANE WG discussion would have gone *much* better.

--Paul Hoffman