Subject: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16

From: Andrew Sullivan <[email-masked]>
Date: Fri, 20 Jan 2012 00:49:39 -0500

Dear colleagues,

This message initiates a three week Working Group Last Call on the
document draft-ietf-dnsext-dnssec-bis-updates-16.  LC will close on
2012-01-11 at 00:00 UTC.

The WG's standard conventions, which require five reviewers who state
that they have read the draft and support its publication as a
necessary but not sufficient determinant of rough consensus, are in
force.  Please review the document and post to the list any comments
you have before the close of LC.  If you cannot meet that deadline,
but are willing to commit to completing a review and can give me a
firm date for it (and that date is within a reasonable horizon), I
will announce an extension of the LC deadline.  I'd appreciate it if
you'd tell me of this need sooner rather than later.  Specific
comments are much better than generic ones, and specific comments with
suggested text (if you find some text wanting) are particularly
encouraged.

Speaking only personally, this draft is the product of several years
of WG work: the -00 of the draft was submitted in 2005.  Moreover, it
is the product of a lot of heated discussion and careful teasing out
of the issues involved.  I would be sad to discover that we could not
find (rather) more than five reviewers for this document.

I will be the shepherd for this document if it is sent to the IESG.

Best regards,

Andrew

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 20 Jan 2012 18:22:44 +1100

5.9.  Always set the CD bit on Queries  

	This is demonstratively *bad* advice.  The discussion to do
	with always setting CD bit on queries centered around
	different sets of trust anchors.

	If you take two validating recursive server in series with
	the *same* trust anchors.  If you always set CD then the
	downstream server is vulnerable to a accidental denial of
	service attack if any of the authoritative servers for the
	zone is returning stale (will fail validation) data.

		C -> VR1 -> VR2 -> {A1, A2, A3 .... AN }

	VR1 should make CD=0 as it has no control over which of A1
	... AN, VR2 queries.  By making a CD=0 query, VR2 will
	filter out responses from the stale server.  If the response
	from VR2 to the CD=0 is SERVFAIL then VR1 it should make a
	CD=1 query in case there is a mis-configured trust anchor
	or bad clock.

	Yes, Andrew it is re-opening this subject.

	Mark
-- 
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: Andrew Sullivan <[email-masked]>
Date: Fri, 20 Jan 2012 09:22:43 -0500

Dear colleagues,

> document draft-ietf-dnsext-dnssec-bis-updates-16.  LC will close on

Sigh.  When we go past the 31 at the end of January, the _month_
counter goes up.  That should, of course, have been 2012-02-11
00:00+00.  (I'm particularly ashamed of this one, since 01-11 is my
father's birthday.)

Sorry, all, and thanks to eagle-eyed Ed Lewis for nudging me.

A

---

From: Edward Lewis <[email-masked]>
Date: Fri, 20 Jan 2012 11:55:22 -0500

Comments.

In 2005 it was too soon to publish, now it is not.  And at this point 
there may be more and more wrinkles in the DNSSEC specs, but we need 
to get out at least this (first) update.

Some comments:

Pressence has a presence in the document.  It shouldn't (the spelling, I mean).

5.9's title is misleading.  The content is good, it's about answering 
from cache in the face of a CD query.  But "always doing CD" only 
applies to elements that will do their own validation.

5.4 could optionally make the point that a validator that expects all 
signatures to be good and/or all chains to work is vulnerable to 
malicious insertions of gibberish-based signatures.  It's harder to 
construct a good chain than a false chain.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Vote for the word of the day:
"Papa"razzi - father that constantly takes photos of the baby
Corpureaucracy - The institution of corporate "red tape"
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 25 Jan 2012 12:46:21 +0100

Hi,

I have reviewed, carefully, and support publication.

Some (additional) comments, they have little substance.

The section and appendix on CD bits are long.  Not wrong, but long.
With the root trust anchor deployed, not having a covering trust anchor
is unlikely.  The last validating resolver is the one that can be
trusted, upstream validating resolvers are connected via some network
transport, and trust may therefore not be advisable.

Section 6.2 is correct.  But its tone is loose.  It is about lenient
acceptance of the SEP flag.  Please say that, or say that the proper
setting of the SEP flag is defined in its RFC.

Thanks to Sam, David and Rob for editing.

Best regards, Wouter

On 01/20/2012 05:55 PM, Edward Lewis wrote:
> there may be more and more wrinkles in the DNSSEC specs, but we need to
> get out at least this (first) update.
> 
> Some comments:
>

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 27 Jan 2012 18:21:35 -0800

I read the draft and support publication of the draft.

Here are a few comments...

- Section 4.4 Insecure Delegation proofs last sentence is very
confusing. An example as to what attack this is describing would be
helpful to the implementer.

- Section 5.7 setting the AD bit on queries. Is CD=0,DO=0 in the query
same as AD=1,DO=0 ? If so, why do we need two ways ? I might have
missed the discussion on this earlier. If there is a valid reason,
that needs to be stated explicitly as to why we are introducing this
new option.

- The "Security Considerations" section says:

     This document adds two cryptographic features to the core DNSSEC protocol.

    Is this referring to the algorithms mentioned in section 2.2 (
which actually lists three)  or something else ?

-mohan

---

From: Mark Andrews <[email-masked]>
Date: Sat, 28 Jan 2012 16:20:29 +1100

In message <[email-masked]>
, Mohan Parthasarathy writes:

> same as AD=1,DO=0 ?

The question doesn't make sense.

AD=0,DO=1 and AD=1,DO=1 produce the same result.
AD=0,DO=0 and AD=1,DO=0 produce different results.
AD=0,DO=0 and AD=0,DO=1 produce different results.
AD=1,DO=0 and AD=0,DO=1 produce different results.

> that needs to be stated explicitly as to why we are introducing this
 
Section 5.7 explains why this option exists.

		This allows a requestor to indicate that it understands
   the AD bit without also requesting DNSSEC data via the DO bit.

Examples of AD=1 vs DO=1.

% dig +adflag soa . +noauth +noadd

; <<>> DiG 9.7.3-P3 <<>> +adflag soa . +noauth +noadd
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41997
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;.				IN	SOA

;; ANSWER SECTION:
.			86382	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2012012701 1800 900 604800 86400

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jan 28 16:03:34 2012
;; MSG SIZE  rcvd: 285

% dig +dnssec soa . +noauth +noadd

; <<>> DiG 9.7.3-P3 <<>> +dnssec soa . +noauth +noadd
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61859
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;.				IN	SOA

;; ANSWER SECTION:
.			86372	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2012012701 1800 900 604800 86400
.			86372	IN	RRSIG	SOA 8 0 86400 20120203000000 20120126230000 51201 . nhFWtVAAdecUyYiGqvYYLprczaXbhsR+XK2S+OPBrBWMAk9fPyNjRH7A rSu7I1qIBNstxAlUJ/ncn+lL5o88wDD2PZW4GXolzFc3LslvmyEcEhVe wHhPETDJEsR9rrpx1yt1o5EqhjzBrQNT4FPbmqse0z+r9v9uPCZlB+KQ OvE=

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jan 28 16:03:44 2012
;; MSG SIZE  rcvd: 612

%

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 27 Jan 2012 22:11:43 -0800

> AD=1,DO=0 and AD=0,DO=1 produce different results.
Thanks for the clarification. I realized after I posted that not
setting CD and DO is pre-DNSSEC.

>   the AD bit without also requesting DNSSEC data via the DO bit.
So, "understands" here means "Please do the validation for me " ?
Then, is  CD=1, AD=1 a invalid option ?

So, there are implementations out there that want to know whether
validation was successful or not but just not want to handle any
DNSSEC records ? My question was more on what prompted the addition of
this new feature ?

-mohan

---

From: Mark Andrews <[email-masked]>
Date: Sun, 29 Jan 2012 00:43:31 +1100

In message <CACU5sD=P-agE2oOqvAiCs=bcX3Off6cCubW-f=[email-masked]>
, Mohan Parthasarathy writes:
> > In message <[email-masked]=
> l.com>
> >> - Section 5.7 setting the AD bit on queries. Is CD=0,DO=0 in the que=
> ry
> >> same as AD=1,DO=0 ?
> >
> >                This allows a requestor to indicate that i=
> t understands

No.  AD will be 1 if the answer + authority sections come from
cached data that has validated as secure.  That said I don't think
there is much use unless you are trying to check if a lookup failure
was due to DNSSEC errors.

> DNSSEC records?

I will put it this way.  I doubt if there is a application that
cares about AD that *wants* the DNSSEC records.  At the moment they
have no choice unless they are using the draft.

> My question was more on what prompted the addition of this new feature ?

1. It reduces the response size.
2. You can apply DNS64, NXDOMAIN redirection, bad site filtering, etc. with
   AD=1 which you can't with DO=1.

Mark

---

From: Mohan Parthasarathy <[email-masked]>
Date: Sun, 29 Jan 2012 18:12:14 -0800

> was due to DNSSEC errors.
Okay.

> have no choice unless they are using the draft.
Agreed that those DNSSEC records are not of much use. For
non-validating resolvers, there is now a choice of setting the DO bit
or AD bit and setting both does not make sense. Perhaps, this should
be explained.

>   AD=1 which you can't with DO=1.
Why does the extra DNSSEC records affect DNS64 ?

If AD=1 seems better for non-validating resolvers, perhaps that should
be recommended in the draft ?

-mohan

---

From: Mark Andrews <[email-masked]>
Date: Mon, 30 Jan 2012 14:29:54 +1100

In message <CACU5sDnuW7hUkYAoyyBY=[email-masked]>
> Why does the extra DNSSEC records affect DNS64 ?

Because, despite what Section 3 of RFC 6147 says, you can't divine
intent from DO and CD and applying DNS64 synthesis to DO=1,CD=0 is
just as bad as applying DNS64 synthesis to DO=1,CD=1.

Mark

---

From: Warren Kumari <[email-masked]>
Date: Mon, 30 Jan 2012 16:08:25 -0500

On Jan 20, 2012, at 12:49 AM, Andrew Sullivan wrote:

> you have before the close of LC.  

I have reviewed the document and support its publication (regardless of the outcome of the Section 5.9 discussions).

Nits: 
Multiple times I read "Section 4 - Security Concerns" as "Security Considerations" (probably because I am conditioned to see "Security Considerations" :-P). I'd personally like it to be reworded ("Considerations Relating to Security"?), but not enough to care (I suspect that I'm the only one who misread this...)

Section 5.11
O: "The pressence of an algorithm in a zone's DS or DNSKEY RRset"
P: "The presence of an algorithm in a zone's DS or DNSKEY RRset"
C: Spello.

Appendix B, Model 1.
O: "This model is so named because the validating resolver sets the CD bit on queries it makes reegardless of whether it has a covering trust anchor for the query."
O: "This model is so named because the validating resolver sets the CD bit on queries it makes regardless of whether it has a covering trust anchor for the query."
C: Spello.

> If you cannot meet that deadline,

As it "is the product of a lot of heated discussion and careful teasing out of the issues involved" perhaps some of that can count towards review (if needed)?

W

---

From: Michael StJohns <[email-masked]>
Date: Tue, 31 Jan 2012 13:57:26 -0500

I support the publication of this document - finally. Any nits are just that - nits - and shouldn't affect the publication.  No changes, no take backs!

Mike