Subject: [dnsext] Suggested update to RFC 4035 section 4.9.2 Handling of the CD Bit

From: Mark Andrews <[email-masked]>
Date: Fri, 07 Oct 2011 10:02:30 +1100

Old: 4.9.2.  Handling of the CD Bit

   A non-validating security-aware stub resolver SHOULD NOT set the CD
   bit when sending queries unless it is requested by the application
   layer, as by definition, a non-validating stub resolver depends on
   the security-aware recursive name server to perform validation on its
   behalf.

   A validating security-aware stub resolver SHOULD set the CD bit,
   because otherwise the security-aware recursive name server will
   answer the query using the name server's local policy, which may
   prevent the stub resolver from receiving data that would be
   acceptable to the stub resolver's local policy.

New: 4.9.2.  Handling of the CD Bit

   A non-validating security-aware stub resolver SHOULD NOT set the CD
   bit when sending queries unless it is requested by the application
   layer, as by definition, a non-validating stub resolver depends on
   the security-aware recursive name server to perform validation on its
   behalf.

   A validating security-aware stub resolver SHOULD NOT set the CD
   bit on initial queries as this will allow upstream validating
   resolvers to reject answer which fail to validate and to try
   other sources.  If the validating security-aware stub resolver
   receives a SERVFAIL response to the initial query it should
   requery with CD bit set in case the SERVFAIL was due to a bad
   clock or stale trust anchors in a upstream validating resolver.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]

---

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 6 Oct 2011 19:15:44 -0700

Mark,

Thanks for bringing this up on a separate thread.

>   A validating security-aware stub resolver SHOULD NOT set the CD

There are two problems with this:

1) Validation happens in two places which is really a waste of resources

2) CD bit is being overloaded (see below). As noted in the other
thread, it is a misconfiguration. I guess you need a different bit or
perhaps clarify the DO bit to mean that "I understand DNSSEC records,
don't stop when the first authoritative server does not return the
signature, try hard till no servers return any signatures".

>   other sources.

Why does setting/not-setting the CD bit influence the recursive server
to not-try/try other sources ? Why can't the DO bit be used for that
as explained above ?

-mohan

> If the validating security-aware stub resolver
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 07 Oct 2011 14:48:58 +1100

In message <CACU5sD=[email-masked]>
, Mohan Parthasarathy writes:
> > Old: 4.9.2. =A0Handling of the CD Bit
> >
> > =A0 A non-validating security-aware stub resolver SHOULD NOT set the CD
> > =A0 bit when sending queries unless it is requested by the application
> > =A0 layer, as by definition, a non-validating stub resolver depends on
> > =A0 the security-aware recursive name server to perform validation on its
> > =A0 behalf.
> >
> > =A0 A validating security-aware stub resolver SHOULD set the CD bit,
> > =A0 because otherwise the security-aware recursive name server will
> > =A0 answer the query using the name server's local policy, which may
> > =A0 prevent the stub resolver from receiving data that would be
> > =A0 acceptable to the stub resolver's local policy.
> >
> >
> > New: 4.9.2. =A0Handling of the CD Bit
> >
> > =A0 A non-validating security-aware stub resolver SHOULD NOT set the CD
> > =A0 bit when sending queries unless it is requested by the application
> > =A0 layer, as by definition, a non-validating stub resolver depends on
> > =A0 the security-aware recursive name server to perform validation on its
> > =A0 behalf.
> >
> > =A0 A validating security-aware stub resolver SHOULD NOT set the CD
> 

It is unavoidable unless you want to back and forwards lists of
upstream servers that have been tried.  Also a validating recursive
server will most probably validate CD=1 queries anyway as part of
adding the answers to its own cache.  All this does is move when
that validation occurs.

You seem to be under the impression that caches don't need to
validate if the end systems validate.  This is a fallacy.  For a
cache to not be a DoS source it needs to protect itself from bad
data.

> 2) CD bit is being overloaded (see below).

No it isn't.  CD=0 already requires the recursive server to retry
if it is validating.  If you want to force validation from a
non-validating recursive server we need to be able to pass trust
anchors to it.

> As noted in the other

Which just generates lots of unnecessary queries.  Crypto is still
much quicker than asking more upstream queries.  99.999% of the
time the answer you get back does validate.

> > =A0 bit on initial queries as this will allow upstream validating
> > =A0 resolvers to reject answer which fail to validate and to try
> > =A0 other sources.
> 
> to not-try/try other sources?

CD=0 tells the upstream to only pass what it believe is good.  A
recursive server is supposed to treat any answer that doesn't
validate as if it had never arrived.  You then have a lost transaction
and the resolver will retry the query.

CD=1 tells the upstream to pass through what it got.  Repeated CD=1
queries are not required to ask different authoritative servers.

> Why can't the DO bit be used for that as explained above ?
> 
> -mohan
> 
> >=A0If the validating security-aware stub resolver
> > =A0 receives a SERVFAIL response to the initial query it should
> > =A0 requery with CD bit set in case the SERVFAIL was due to a bad
> > =A0 clock or stale trust anchors in a upstream validating resolver.
> >
> > --
> > Mark Andrews, ISC
> > PHONE: =A0+61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
>  INTERNET: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 7 Oct 2011 10:14:50 -0400

Dear colleagues,

This is a procedural matter about decisions we have already made.

On Fri, Oct 07, 2011 at 10:02:30AM +1100, Mark Andrews wrote:
>    layer

We had a huge discussion about this some time ago, and even had a
design team meeting about it.  We came to a conclusion which was
confirmed in face to face meetings and on the list.  Despite the fact
that dnssec-bis-updates has not made it out the door yet, I condiser
this issue closed unless someone has some new argument to make about
why the decision was the wrong one.  I urge anyone who wants to make
those arguments to refer to the previous discussions on this topic.
If you raise something that was already addressed, I will point that
out.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 7 Oct 2011 15:27:52 -0400

Dear colleagues,

On Fri, Oct 07, 2011 at 10:14:50AM -0400, Andrew Sullivan wrote:
> design team meeting about it.

A kind participant whom I shall call 'Dew Isle' pointed out to me that
it's not very friendly to say "read the previous discussion" without
even pointing out where that discussion was.  Dew Isle is right, and
apologies to all.  Here's the beginning of the thread in the archive:

http://www.ietf.org/mail-archive/web/dnsext/current/msg08864.html

Note that while the discussion was on the namedroppers list, it
appears that the old-time archives have been removed, so you'll have
to use the IETF archive.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 08 Oct 2011 09:49:37 +1100

> > design team meeting about it.

I know that.

A non-stub validating resolver has access to multiple athoritative
data sources.  A validating stub resolver does NOT have *direct*
access to multiple authoritative data sources.  This can lead to
accidental denials of service if the upstream learns data from a
bad source and passes it on to the stub.

Setting CD=0 on the initial query lets to upstream filter out what
it believes to be bad then the stub resolver validates what is
passed through.  This may or may not validate but has a much higher
probability of doing so.  If the upstream doesn't pass through a
answer that is possible to validate because it can't find one itself
the stub then asks with CD=1 to avoid the upstreams validator.

This is still not perfect as there may be cases where the stub
resolver has TA to a island of trust that the upstream doesn't so
the upstream can't help the stub by filtering out obviously bogus
responses.

The way to fix that is to have the stub pass the TA set it intends
to use to the recursive server and have it use that TA set when it
filters responses on the stub's behalf.  Note this is still CD=0
as the upstream is validating.

---

From: David Conrad <[email-masked]>
Date: Fri, 7 Oct 2011 16:09:58 -0700

Mark,

>>> design team meeting about it.

For those of us not finely attuned to the CD bit, can you summarize what has changed since the huge discussion and the design team meeting to cause you to raise the issue?

Thanks,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Sat, 08 Oct 2011 23:26:53 +1100

In message <[email-masked]>, David Conrad
 writes:
> > In message <[email-masked]>, Andrew Sullivan =
> writes:
> >=20
> For those of us not finely attuned to the CD bit, can you summarize what =
> has changed since the huge discussion and the design team meeting to =
> cause you to raise the issue?

More correctly I know there was a huge discussion about forwarder
behaviour and CD and whether there is a covering trust anchor or
not.  No where in that discussion was there any discussion of the
best behaviour for a stub resolver.

Nor has there every been any discussion of the denial of service
risks of just sending CD=1 queries to the recursive server from a
stub resolver.  Sending CD=0 is documented in RFC 4035.

Now if you can find any real discussion anywhere of how a validating
stub resolvers should set CD and the risks related to both setting
please point it out.  My recollections is we have only ever really
thought about setting CD=1 and no proper analysis has ever been done.

There are risks with both CD=0 and CD=1 for a stub resolver which
is why I am recommending CD=0, then CD=1, as it provides the best
mitigation strategy.

Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 8 Oct 2011 17:24:32 -0400

No hat.

> stub resolver.  Sending CD=0 is documented in RFC 4035.

[. . .]
 
> is why I am recommending CD=0, then CD=1, as it provides the best

That seems to me like an operational or policy decision, and not a
protocol matter.  That is, your SHOULD NOT in your paragraph 2 is not
the SHOULD NOT of RFC 2119, but a SHOULD NOT that means "I think this
is the best idea."  RFC 2119 SHOULD NOT is about interoperability,
which is why it has the unusual meaning as defined in that RFC.  There
are different possible policies here, and I don't believe one of them
ought to be enshrined as the protocol, because I can think of reasons
why one might prefer the DoS risk (like, for instance, that you don't
have a secure connection to upstream and you know it isn't validating
anyway).

I can see reasons to write a document (perhaps for DNSOP) on how to
operate your validating (stub) resolver.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sun, 09 Oct 2011 09:38:20 +1100

> have a secure connection to upstream and you know it isn't validating

By that logic we should strike paragraph 2 of 4.9.2 (Handling of the CD Bit)

That SHOULD is not required for interoperability.

Now do we give good advice or do we give no advice?

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 9 Oct 2011 10:04:04 -0400

No hat.

> That SHOULD is not required for interoperability.

True, although it appears to me to be a consequence of the definition
of validating security-aware stub resolver.  But anyway,

> Now do we give good advice or do we give no advice?

as I argued before, the advice you are proposing is not in fact always
good advice.  It's a trade-off.

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Mon, 10 Oct 2011 08:34:31 +1100

> good advice.  It's a trade-off.

It's *never* bad advice as it get you to do both CD=0 and then CD=1.
Advising to do *just* CD=0 or CD=1 is bad advice.  If the upstream
doesn't have trust anchors then CD=0 or CD=1 is a moot question.
If the upstream has trust anchors using just CD=1 is leaving the
stub resolver open to a denial of service due to spoofing /
misconfiguration of the parent especially if there is CD=1 cache.
Similarly just CD=0 is leaving you exposed to bad clocks / stale
trust anchors in the recursive server.  With CD=0 then CD=1 you
mitigate both failure modes.

---

From: Mohan Parthasarathy <[email-masked]>
Date: Sun, 9 Oct 2011 18:41:39 -0700

> It's *never* bad advice as it get you to do both CD=0 and then CD=1.

It would be a bad advice if it increases the complexity without real benefits.

> misconfiguration of the parent especially if there is CD=1 cache.

You seem to be implying a "CD=1 cache" and "CD=0 cache" i.e, a cache
maintained differently for CD =1 or CD = 0. If the recursive sever
populates the cache in the same way for both CD=0 and CD=1, then this
issue does not arise. This seems to be much simpler to me rather than
treating it differently.

-mohan

---

From: Mark Andrews <[email-masked]>
Date: Mon, 10 Oct 2011 16:17:25 +1100

In message <CACU5sD=-pJUVKG1QmwBX9d-MZJp6_AYkXWDxh_CTAXO=[email-masked]>
, Mohan Parthasarathy writes:
> >> > By that logic we should strike paragraph 2 of 4.9.2 (Handling of the C=
> D Bit
> >> )
> >> >
> >> > =A0 =A0A validating security-aware stub resolver SHOULD set the CD bit=
> ,
> >> > =A0 =A0because otherwise the security-aware recursive name server will
> >> > =A0 =A0answer the query using the name server's local policy, which ma=
> y
> >> > =A0 =A0prevent the stub resolver from receiving data that would be
> >> > =A0 =A0acceptable to the stub resolver's local policy.
> >> >
> >> of validating security-aware stub resolver. =A0But anyway,
> >>
> >> good advice. =A0It's a trade-off.
> >
> It would be a bad advice if it increases the complexity without real benefi=
> ts.

The complexity of checking for SERVFAIL and reissuing the query
with CD=1 is trivial compared to the complexity of validating a
answer.  This is no more complex that existing TC=1 checks and
retrying with TCP.

> > Advising to do *just* CD=0 or CD=1 is bad advice. =A0If the upstream

Even if server doesn't have a CD=1 cache there is no guarantee that
a second query (with CD=1) will talk to a different authoritative
server.  CD=0 queries are guarantee to talk to multiple authoritative
servers provided there is a trusted path from the servers TA if the
first authoritative server tried is broken.

Given I've seen signed zone configured with servers that don't speak
DNSSEC and I've also seen repeated CD=1 queries fail to get answers
with signature from such a configuration this is not idle speculation
that avoidable validation failures will occur with CD=1 only queries.

I'd argue that misconfigured authoritative servers are more common
than misconfigured TAs as the latter affects ordinary queries and
will result in complaints leading to the TA being fixed where as
the former is hidden as validating recursive servers reject the
answers from the bad server and only return those from the good
servers.

Mark

> > trust anchors in the recursive server. =A0With CD=0 then CD=1 you
> > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is=
> c.org

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 10 Oct 2011 11:10:53 -0700

> answer.  This is no more complex that existing TC=1 checks and
I agree that for the sub itself, this is very similar to TC=1 retry
with TCP. But I was not speaking with respect to the stub alone. See
below.

> first authoritative server tried is broken.
As per dnssec-bis updates section 5.9, the validating resolver always
sets the CD bit irrespective of what is in the incoming query. It
means that there is just one cache. Do implementation really have a
separate cache ? If it always sets CD=1 (which does not alter with
your proposal), then it needs to handle this case because there could
be a bunch of queries (with CD=1 or CD=0) blocked on waiting for this
resolution to complete ?

Isn't the case you are talking about "no" signatures rather than
invalid signatures ? Why is "CD=0" query making it talk to a different
authoritative server and not "CD=1" query in this case ? Let us say
that there are two authoritative servers G (Good) and the B (Bad) for
some signed zone. G speaks DNSSEC whereas B does not. I have two stubs
one of which sets the CD bit.

1) A recursive server receives a query with CD = 0/DOK = 1. It talks
to B first and as it cannot validate without signatures, it talks to
G, validates the result and inserts into the cache.

2) A recursive server receives a query with CD = 1/DOK = 1. Assuming
that there is a single cache, then it returns the response from the
cache.

Now if (2) happens first i.e., it receives a query with CD=1/DOK=1,
you are arguing that it would talk to B first, it does not receive any
signatures and it would just return without trying G. And on receiving
query with CD=0, it would retry with G ? Is there anything in RFC 4035
that describes this behavior explicitly ?

I would expect that setting DO=1 (which might have happened because
the stub might have a priori knowledge that a given zone is signed)
means that it relies on the recursive server to return "some"
signature at least.

So, the concern is that if someone spoofs an answer, the recursive
server returns the response without any signatures while there was
valid signatures. This spoof did not make the stub accept the answer,
just "discard" it. It is a DoS, but it happens due to misconfiguration
which should not be that common.

> that avoidable validation failures will occur with CD=1 only queries.

Do we know how often this happens ? I know it is hard to predict the
future, but if this is very common, does it not make sense  for the
recursive servers handle this case ?

-mohan

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 Oct 2011 05:44:46 +0900

> mitigate both failure modes.

Such arguments are meaningful, only if clients are forced to
broken servers.

So, my question has been:

	How can a client know an address of an HTTP server?

Along with another unanswered question:

	How can a client know secure time?

I can't see any realistic use case defined in enough details.

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Oct 2011 09:00:27 +1100

In message <[email-masked]>
, Mohan Parthasarathy writes:
> > In message <CACU5sD=-pJUVKG1QmwBX9d-MZJp6_AYkXWDxh_CTAXO=x7+Juw@mail.=
> gmail.com>
> >> > In message <[email-masked]>, Andrew Sullivan writ=
> es:
> >> >> No hat.
> >> >>
> >> >> > By that logic we should strike paragraph 2 of 4.9.2 (Handling of th=
> e C=
> >> D Bit
> >> >> )
> >> >> >
> >> >> > =A0 =A0A validating security-aware stub resolver SHOULD set the=
>  CD bit=
> >> ,
> >> >> > =A0 =A0because otherwise the security-aware recursive name serv=
> er will
> >> >> > =A0 =A0answer the query using the name server's local policy, w=
> hich ma=
> >> y
> >> >> > =A0 =A0prevent the stub resolver from receiving data that would=
>  be
> >> >> as I argued before, the advice you are proposing is not in fact alway=
> s
> >> > It's *never* bad advice as it get you to do both CD=0 and then CD==
> 1.
> >>
> >> It would be a bad advice if it increases the complexity without real ben=
> efi=
> >> ts.
> >
> > answer. =A0This is no more complex that existing TC=1 checks and
> > retrying with TCP.
> >
> >> > Advising to do *just* CD=0 or CD=1 is bad advice. =A0If the upst=
> ream
> >> populates the cache in the same way for both CD=0 and CD=1, then thi=
> s
> > server. =A0CD=0 queries are guarantee to talk to multiple authoritative

Validating recusive servers are NOT required to cache the responses
to CD=1 queries.  The MAY validate them and cache them.  If they
don't cache them then the next query for the same tuple may go to
the same authoritative server creating a effectively unvalidatd
cache.  There is no requirement to randomise authoritative server
selection and even if there was there is no guarantee that same
server will not be reselected.

> invalid signatures ?

No.  It's anything which causes a validation failure.  No signatures
is just one example.

> Why is "CD=0" query making it talk to a different authoritative server
> and not "CD=1" query in this case ?

CD=0 responses are validated *before* being returned and if they
fail validation are treated as if they didn't occur (the response
was lost) and the recursive server moves on to the next server for
that zone and tries again.

CD=1 responses, to queries that are not in the cache, are passed back
UNVALIDATED.

> Let us say
  
> signatures and it would just return without trying G.

Yes.

> And on receiving query with CD=0, it would retry with G ?

Yes. 

> Is there anything in RFC 4035 that describes this behavior explicitly ?

Explicity to retry multiple servers, no.  Which is yet another thing
that has been overlooked in RFC 4035.  That said you will find the
validating recursive servers do try multiple authoritative sources
on validation failures.  If you don't you will get bug reports about
unnessary SERVFAILs being returned.  RFC 4035 mainly deals with how
to validate individual response and how react to individual queries.
It says nothing about how to recover from validation failures.  The
word "retry" does not appear.

> means that it relies on the recursive server to return "some"

No.  That is not required.  The a priori knowledge is that there
is a trust anchor at or above the zone that contains the answer.
There may or may not be a insecure delegation between the trust
anchor and the zone that contains the answer.

> which should not be that common.

We have plenty of evidence that DNSSEC misconfigurations happen.  Some
of these are recoverable by trying multiple upstream services.

> >> > trust anchors in the recursive server. =A0With CD=0 then CD=1 yo=
> u
> >> > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
>  INTERNET: marka@is=
> >> c.org

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 10 Oct 2011 18:59:17 -0700

<snip>
> to CD=1 queries.  The MAY validate them and cache them.  If they

Again this is not mentioned anywhere in RFC 4035. It does have
references to BAD cache and it is a SHOULD now. It would be odd to
have a BAD cache and not a GOOD cache.

> server will not be reselected.

Validating resolver always sets CD=1 as per dnssec-bis updates
document and any reasonable recursive server would implement caching.
If so, how can it work if it does not try multiple auth servers ?

The design meeting notes "Always set" policy applied to all validating
resolvers but you are only requiring change for stub resolvers. But
based on your argument, don't you require that this applies to any
validating resolver as it is possible to have multiple recursive
resolvers between the stub and the authoritative server ?

> No.  It's anything which causes a validation failure.  No signatures
Ok.

> CD=1 responses, to queries that are not in the cache, are passed back

This is also under specified in RFC 4035.

Yes.

> of these are recoverable by trying multiple upstream services.

We are not disagreeing about this itself. But what triggers this in
the recursive server ?

-mohan

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Oct 2011 13:31:12 +1100

In message <CACU5sD=jfD-mahyNQDZC+usdrnvhG8gD=[email-masked]>
, Mohan Parthasarathy writes:
> <snip>
> >> >> > Advising to do *just* CD=0 or CD=1 is bad advice.  If the u=
> pst=
> >> ream
> >> >> > doesn't have trust anchors then CD=0 or CD=1 is a moot question=
> .
> >> >> You seem to be implying a "CD=1 cache" and "CD=0 cache" i.e, a ca=
> che
> >> >> maintained differently for CD =1 or CD = 0. If the recursive seve=
> r
> >> >> populates the cache in the same way for both CD=0 and CD=1, then =
> thi=
> >> s
> >> > server.  CD=0 queries are guarantee to talk to multiple authorit=
> ative
> >> be a bunch of queries (with CD=1 or CD=0) blocked on waiting for thi=
> s
> >> resolution to complete ?
> >

It may well be useful but that would be re-opening the topic.

At the moment I'm talking about stub behaviour and I'm looking to
make "validating stub" <-> "validating recursive server" <->
"authoritative server" work reliably in the face of common errors.

> We are not disagreeing about this itself. But what triggers this in

Please re-read my comments above.  RFC 4035 does not specify how
to recover from validation failures.  It expects developers to
something "sensible". 

Mark

> >> > that avoidable validation failures will occur with CD=1 only queries=
> .
> >> >
> >>
> >> >> > trust anchors in the recursive server.  With CD=0 then CD=1=
>  yo=
> >> u
> >> >> > PHONE: +61 2 9871 4742               =
>  =
> >> > PHONE: +61 2 9871 4742                =
> > PHONE: +61 2 9871 4742                 INTERNET: marka@is=
> c.org
> >

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 17 Oct 2011 14:48:19 +0200

Hi Mark, Mohan,

> CD=1 responses, to queries that are not in the cache, are passed back

No, CD=1 responses are "not withheld" if they fail validation.

Thus you can cache it, you can validate it and retry.

Best regards,
   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Oct 2011 00:46:50 +1100

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

And when the stub retries there is no state to prevent the recursive
server asking the same broken upstream again and again and again
....

There is no requirement for a recursive server to attempt to validate
a response to a CD=1 query from downstream or if it attempts to
validate the response to retry a different upstream if the validation
fails.

> Best regards,
>    Wouter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> 
> iQIcBAEBAgAGBQJOnCQTAAoJEJ9vHC1+BF+NT4EQAIiflA8jI4jrWBdWfV+rDtkc
> yLfU+fy5XOHCyRWlViL13nXilav66AJX50r2mbWxxaZ7ouSJnpabcwa5srHPET1+
> ZK3cQQliX3ypLXzAiTFUi78apwLKSeELEvMOKX9qii9GVk/ewnnV096ykCcB8iyf
> yWii2mLtRFcABApSgA8dJfAwB306GMnCZFOnfluEyB+Gltzc5aruhm2/RhaNyO0d
> sRKwuJn5YR/E3tyzvY+kZgcrpqdzokrbGgbtIlvZhaF8ZASLDVBXG/1/kwW/BKGy
> 9BnBy+M487Yz2Lewu31fp9V61V4C/pcnkY+1zewAyJF/G/jayzo/vT0lZV5dRyxq
> 0if2dKjVVU962A/xDHKD59ERDVfyDd1LBT9pZNctxva6Dnjx21Ma+0cT10Y+BXb+
> 2mPz94GIUSyg8iosL2hezBtQz27tL4Qndq/0DHE63SKD1Gi29kMGeSqAQRtXpqYU
> PRavs6sQeLkHPx22G4Q66K9zzhEBsLaG/GTuRTxxn0KNzWx1YoKvDTZmzUM8OBtC
> ts6VA9ZKHcOTE0tCM/12jjlPkQRlTBAQfl7lSJL/K1q1dNiclKVl4lX1I9GfXMRm
> RR/rMi1H/hTB8loh3+ZBCydzCFeRIRi3NSyVFk3oHYzHXOAg37nbizbYXExtz1LP
> jHpwm3oOPzSETtEHmzNC
> =NfTi
> -----END PGP SIGNATURE-----

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 17 Oct 2011 10:04:38 -0400

No hat

> server asking the same broken upstream again and again and again

This is true of any breakage.  If the authoritative servers are under
DoS, you have the same problem, no?  DoS on authoritative servers is
at least as common as DNSSEC misconfiguration.

The plain fact is that DNSSEC makes the DNS more fragile.  Why is this
news, and why do you think that your recommendation is the only
sensible response to this?  I still don't understand that.
 
> validate the response to retry a different upstream if the validation

Of course not. 

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 17 Oct 2011 16:07:07 +0200

Hi Mark,

Mohan failed to tell you and I seem to fail, but I'll give it a retry.

>> On 10/17/2011 03:46 PM, Mark Andrews wrote:

Well there is, because you can cache the final answer?  Of course.

>> validate the response to retry a different upstream if the validation

There is no requirement, but you seem to want to protect your cache from
unwanted dos due to configuration mistakes so that downstream validators
get signatures?  Then, you can validate it anyway, even though /this/
requestor is not interested in blocking bogus, it is interested in the
validation retries, because DO=1 (it wants signatures).

Best regards,
   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Oct 2011 12:31:44 +1100

> validation retries, because DO=1 (it wants signatures).

No. I want to protect the stub from DoS and misconconfigurations.
The stub is one step removed from the source of the bad data so it
can't take *effective* corrective measures itself as it is required
to talk to the world through the recursive server.  It needs to get
the recursive server to take the corrective measures on its behalf,
by setting CD=1, then validate the answer returned to detect any
attacks on the reply packets from the recursive server.

Setup 10 servers for a zone with ameservers in a different zone to
stop the recursive server validating answers from the zone as a
side effect.  Make 9 of them have out of date signatures (old key).
The ask a validating recursive server for a answers using CD=1 and
see how many responses have a signatures with the correct key tag.

Repeat with CD=0.

> iQIcBAEBAgAGBQJOnDaLAAoJEJ9vHC1+BF+NBK4P/20NgUhLGjCv1ngPeFpe6+EK
> oDEUbyZ8O4MmGJd+PsTaRrtgSgMtglXVvTp6FbevNYYbha/tiLxdr9FJi3oHBtJR
> rV8oxoOmw0lyfiubO3S46OC+2GcE/mm4FIIvA1A3cd7YditSp9zFRAWV0pITdbSd
> TMHvRiCFp6Z8b4s7OzNg23WJ182YWoFQWuWYRl0Xomja+vr+bKNHYvNaTo9urIoj
> 1ZOftl/fPNNsDq5v1/LMTYONamy0b9y1PAQr9t3teB30NZ0thJaEuK+G++OnYqlF
> OS8ImpsMqFGIugZLEvV7bM2wGAYlF1nlII5GcQRBIYhZyxvPDiSX8tvgNkAsB/Xn
> QhE4Zp2JPAOTEHbKXuEKw8SKfhWHDOb3NXrKzN7SLVur7v/fHSW2nWldksUqUHs3
> TuFFCfWQIZ6rHJZSarKStZbzESJUo6dAWapw5yqeU7aHrG2+hLMtTqLdn87hzoR5
> JOzzr9cPRdiZWKbEs3+7fZKRE/caD/0HPNLH8hIpueNudhsvkiHUp9lp6tRftQSC
> bMYKdnNg+N0XugLdTq35FZwkbP+GjqEhZzspF6tlLggF8/u3O021yU+jlaK1QTft
> Cp2wXK3lTPnjcu16gb9oRQd+tbwOOjVYkgtO6u9h+0Ho9kBli0qWqqNiC88k9MmB
> RKjSOby2ojhWQvafFb9S
> =ikYp

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Oct 2011 12:42:21 +1100

> sensible response to this?  I still don't understand that.

  10 server A0-A8 out of date, A9 up to date.

  Auth Servers <- breakage ->  Recusive Server <- clean -> Stub
					<- example/a/cd=1,do=1
  	<- example/a/cd=1,do=1
  A0
  	example/a/cd=1,do=1(bad) ->
				example/a/cd=1,do=1(bad) ->
					<- example/a/cd=1,do=1
	<- example/a/cd=1,do=1
  A1
  	example/a/cd=1,do=1(bad) ->
				example/a/cd=1,do=1(bad) ->
					<- example/a/cd=1,do=1
	<- example/a/cd=1,do=1
  A2
  	example/a/cd=1,do=1(bad) ->
				example/a/cd=1,do=1(bad) ->

		Give up.

  Auth Servers <- breakage ->  Recusive Server <- clean -> Stub
					<- example/a/cd=0,do=1
  	<- example/a/cd=1,do=1
  A0
  	example/a/cd=1,do=1(bad) ->
	<- example/a/cd=1,do=1
  A1
  	example/a/cd=1,do=1(bad) ->
	<- example/a/cd=1,do=1
  A2
  	example/a/cd=1,do=1(bad) ->
	
	...

  A9
  	example/a/cd=0,do=1(good) ->
				example/a/cd=0,do=1(good) ->

		Succeed.

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 17 Oct 2011 19:35:31 -0700

>                                example/a/cd=1,do=1(bad) ->

This is confusing. Why did it stop at A2 ? Why didn't it return after
trying A0 or A5 ? If this is arbitrary then the recursive server is
broken. If the recursive server wants to cache the response and avoid
DoS, then stopping here seems broken to me.

-mohan

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Oct 2011 13:52:57 +1100

In message <[email-masked]>, Mohan Parthasarathy writes:
>    <- example/a/cd=3D1,do=3D1
> >        <- example/a/cd=3D1,do=3D1
> >  A0
> >        example/a/cd=3D1,do=3D1(bad) ->
> >                                example/a/=
> cd=3D1,do=3D1(bad) ->
> >                                     =
>    <- example/a/cd=3D1,do=3D1
> >        <- example/a/cd=3D1,do=3D1
> >  A1
> >        example/a/cd=3D1,do=3D1(bad) ->
> >                                example/a/=
> cd=3D1,do=3D1(bad) ->
> >                                     =
>    <- example/a/cd=3D1,do=3D1
> >        <- example/a/cd=3D1,do=3D1
> >  A2
> >        example/a/cd=3D1,do=3D1(bad) ->
> >                                example/a/=
> cd=3D1,do=3D1(bad) ->
> >
> >                Give up.
> 

At some stage the stub has to give up.  Remember the recursive server
doesn't have to cycle through the authoritative servers.  It can
just ask A0 forever with CD=1 queries and *never* talk to A9.

With CD=0 queries the recursive server knows which authoritative
servers it has tried and which ones it hasn't.

CD=1 has stateless retries.
CD=0 has stateful retries.

Mark

>    <- example/a/cd=3D0,do=3D1
> >        <- example/a/cd=3D1,do=3D1
> >  A0
> >        example/a/cd=3D1,do=3D1(bad) ->
> >        <- example/a/cd=3D1,do=3D1
> >  A1
> >        example/a/cd=3D1,do=3D1(bad) ->
> >        <- example/a/cd=3D1,do=3D1
> >  A2
> >        example/a/cd=3D1,do=3D1(bad) ->
> >
> >        ...
> >
> >  A9
> >        example/a/cd=3D0,do=3D1(good) ->
> >                                example/a/=
> cd=3D0,do=3D1(good) ->
> >
> >                Succeed.
> >
> >
> >
> >> > a response to a CD=3D1 query from downstream or if it attempts to

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 17 Oct 2011 20:16:28 -0700

> CD=0 has stateful retries.

See "5.9.  Always set the CD bit on Queries" in dnssec-bis updates.
Recursive server setting the CD bit on upstream queries is not
dependent on the incoming query.

-mohan

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Oct 2011 14:43:06 +1100

In message <CACU5sD=x0d-_+j-eb4TuojdkqZsy+LR=[email-masked]>, Mohan Parthasarathy writes:
> > In message <[email-masked]=
> l.com>, Mohan Parthasarathy writes:
> >> > In message <[email-masked]>, Andrew Sullivan write=
> s:
> >> >> No hat
> >> >>
> >> >> > And when the stub retries there is no state to prevent the recursiv=
> e
> >> >> This is true of any breakage.  If the authoritative servers are und=
> er
> >> >> DoS, you have the same problem, no?  DoS on authoritative servers i=
> s
> >> >> The plain fact is that DNSSEC makes the DNS more fragile.  Why is t=
> his
> >> >                                example=
> /a/=
> >> cd=1,do=1(bad) ->
> >> >                                example=
> /a/=
> >> cd=1,do=1(bad) ->
> >> >                                example=
> /a/=
> >> cd=1,do=1(bad) ->
 
And what does that have to do with my statements?  The examples
*had* CD=1 upstream queries.

CD=1 queries, from the stub, has stateless retries.
CD=0 queries, from the stub, has stateful retries.

Mark

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 17 Oct 2011 21:02:51 -0700

> CD=0 queries, from the stub, has stateful retries.
If the recursive always sets CD=1 on its upstream queries irrespective
of what the stub set in its query, then it is much easier, less
complex to just implement one behavior i.e try the authoritative
servers, validate the signatures, cache the response. Why should it be
stateless in one case and stateful in another case ? Nothing in the
spec talks about stateful vs stateless.

-mohan

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 18 Oct 2011 00:04:29 -0400

Hi,

This is a hat-doffing post.  With my hat on, I say that this thread in
no way seems to be an argument about the previously-closed issues; so
they remain closed.  With my hat partway off, I have to say that I'm
ever less convinced that there's something new here, but I'm open to
argument (possibly from someone who can make the argument I think
might be underlying Mark's view, but that hasn't been made yet).  With
my hat fully off, see below.

>   Auth Servers <- breakage ->  Recusive Server <- clean -> Stub

. . .

> 				example/a/cd=1,do=1(bad) ->

Ok.  So what?  Why is this wrong?  I get it that the client didn't get
an answer.  Well, tough.  Don't mess up your zone maintenance.  But
moreover,

>   Auth Servers <- breakage ->  Recusive Server <- clean -> Stub

. . .your answer here is that the stub sends with cd=0 and therefore
blindly assumes the upstream is safe.  Either that, or it sends
everything _twice_: once with CD=0 and the second time with CD=1 in
order to see whether it's in contact with a "safe" upstream.  I can't
see how this is the only obvious right policy.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 18 Oct 2011 00:18:34 -0400

Dear colleagues,

> CD=0 has stateful retries.

Because I have a feeble (not to say febrile) brain, I fail to
understand the argument implicit above.  As near as I can tell, Mark
is arguing from the position that a particular implementation choice
is what the protocol demands.  I'm not seeing this demand -- neither
in the original RFCs nor in the existing dnssec-bis-updates draft; but
I'm fully prepared to admit that I'm missing something, since I'm
usually missing something.  

As co-chair, I hereby ask others to weigh in on this discussion if
they have a view.  If I don't hear anything from others than those who
have participated, I will take that (as shepherd of
dnssec-bis-updates) to be evidence that people do not think the
proposed additions to the dnssec-bis-updates draft should be added,
and will direct the editors of that draft to ignore this discussion
for their purposes.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian Dickson <[email-masked]>
Date: Tue, 18 Oct 2011 01:35:27 -0400

Okay, glad to comment without previously being active in the conversation...

> usually missing something.

I'll try to summarize, not what Mark has said, or what anyone else has
said, but what needs to be said. Kind of.

Basically, what CD=0 says, and what CD=1 says, are unfortunately
neither diametrically opposed, nor orthogonal, at least when combined
with the following other bits:
RD=1 (I'm a stub)
DO=1 (I'm asking for DNSSEC too)

If the combo was (CD=0, validate for me, and DO=0, I'm not
validating), the behavior requested is well-defined, IMHO.
Or, if RD=0, well, why are we talking to a recursive server?

So, the problem is, that the desired behavior doesn't appear to be
signaled or signal-able, by use of the CD bit. Or rather, the use of
the CD bit is somewhat ambiguous.

And this appears to be the case only when RD=1 and DO=1.

Mark's logic is correct. I looked through 4035, and followed the
various branches (3.2, et al) to see if anything is contradicted or
contraindicated.

He is also correct that the current 4035 use of RFC2119 language, in
respect to stubs and CD bit, is off the mark. The proscribed behavior
is not based on interoperability, and based on presumptions about the
uniformity of validation succeeding.

The choice of CD=0 first should only fail to return good data
(i.e.return data to the stub, which will pass the stub's validation)
if there is a discrepancy between TAs, or if the recursive resolver
has failed to validate all responses or has no responses.
Following this up with CD=1 will disambiguate the reasons if CD=0 does
not give good data, at which point the stub should have reliable
success-or-failure - which does not depend on the implementation
choices on the recursive server.

Doing CD=1 first may lead the stub down the wrong path, and whether it
does is dependent on implementation choices.
CD=0 is much more well-defined, and thus unlikely to be
mis-implemented or in any way dependent on implementers' choices.
IMHO.

So, I'd suggest finding suitable language to encode what Mark says,
and adding it to -bis.

> and will direct the editors of that draft to ignore this discussion

Okay, hopefully I have been able to provide useful input into this.

My strong preference is to find places where DNS (or DNSSEC) have need
for improvement, and improving them.
IMHO, this is one such place, and a low-hanging fruit at that.

Sincerely,
Brian

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Oct 2011 16:42:52 +1100

> an answer.  Well, tough.  Don't mess up your zone maintenance.  But

The current spec only works reliably if *all* the answers the
recursive server gets are *good*.  I'm trying to make it work with
real world senarios.

> blindly assumes the upstream is safe.

No.  CD=0 says nothing, nada, diddly squat about whether the client
is going to validate or not.  All that is required for the client
to validate is that DO=1 so that it will get the signature in the
response.

You keep making this logic error that because CD=1 indicates that
the client intends to validate, that CD=0 indicates that it doesn't
intend to validate.  This is incorrect logic.  DNS64 has this logic
error in it.

	A => B does not mean that !A => !B.

The only assumption I am making is that the recursive server has
some trust anchors.  If it doesn't then CD=0 is no different to
CD=1.

If we want to solve the case where the recursive server has no trust
anchors, I have a solution (below) but that is a whole new RFC and
possibly a bump in EDNS version numbers.  It also solves the different
trust achors problem and different time problem, that the current
CD=1 query is trying to solve, and you never send CD=1 queries
unless the recursive server doesn't understand the extension.  If
the recursive server doesn't undertand the extension (detectably
with a EDNS version bump) the stub would fallback to the behaviour
I am recommending here so this exercise is not a waste of time but
it maybe not enough.

The stub selects its closest trust anchors (as DS's) and sends it
in a EDNS1 messager to the recursive server along with its idea of
the current time.

   <CODE><LEN><NAME><TIME><DS-RDATA-LEN><DS-RDATA>[<DS-RDATA-LEN><DS-RDATA>]*

The recursive server then uses this to validate responses on behalf
of the stub.  The recursive server would cache or not based on its
own trust policy.

Mark

>  Either that, or it sends

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 18 Oct 2011 15:41:38 +0900

> recursive server gets are *good*.  I'm trying to make it work with

As for the real world scenarios, how can you make client time
securely synchronized to that of the root?

						Masataka Ohta

---

From: Danny Mayer <[email-masked]>
Date: Tue, 18 Oct 2011 08:06:04 -0400

> securely synchronized to that of the root?

You can't. The best you can do is to run NTP with autokey from a bunch
of NTP Servers or use a refclock on all involved servers and even that's
not guaranteed. Clocks don't need to be that precise for dnssec but it's
always good to keep good time for other reasons.

Danny

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 18 Oct 2011 22:51:21 +0900

Danny Mayer wrote:

> You can't.

OK.

> The best you can do is to run NTP with autokey from a bunch
> not guaranteed.

With the assumption that DNS traffic is, often intentionally,
blocked, you can't expect NTP work.

That is, there is little use cases, among which, the largest
use cases of the proposal should to retrieve clients' location
privacy from proxy information in HTTP headers.

> Clocks don't need to be that precise for dnssec but it's

The problem is that a host, almost always, has just a clock, not
clocks, one of which is dedicated to secure DNS, which means the
only clock needs to be a lot more precise than required by secure
DNS, which is the real world scenarios.

						Masataka Ohta

---

From: Derek Atkins <[email-masked]>
Date: Tue, 18 Oct 2011 10:16:24 -0400

> DNS, which is the real world scenarios.

My laptop clock is pretty accurate, even after I've been offline for
several days.  It would certainly be accurate enough to test DNS for
long enough to get myself online and then contact either HTTP or NTP
hosts.

You don't need sub-second synchronization here.

The only times there would be an issue is at first startup at
manufacturing time, or if you have a bad clock or bad CMOS battery.
However in the latter case you have much more to worry about than just
your clock.

> 						Masataka Ohta

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Edward Lewis <[email-masked]>
Date: Tue, 18 Oct 2011 10:19:46 -0400

I haven't been reading, but responding to Brian's message, if this is 
really about the CD/RD/DO bit setting, let's try to find the 
troublesome combination and state the goal.

CD = 0 => I want good data; CD = 1 => I want unchecked data
RD = 0 => I want what's in memory; RD=1 => I want recursion
DO = 0 => Don't want DNSSEC records; DO=1 => send any DNSSEC records

(DO = 0 includes no EDNS0...)

Eight possibilities
CD RD DO
  0  0  0 - legacy without recursion, give what's good
  0  0  1 - give what's good locally and send DNSSEC records
  0  1  0 - legacy with recursion, give what's good from the world
  0  1  1 - usual DNSSEC recursive query
  1  0  0 - local inspection of whatever is available
  1  0  1 - local inspection of whatever is available plus DNSSEC records
  1  1  0 - find for me but don't try to check
  1  1  1 - find for me but don't check and send DNSSEC records

The goal is to avoid a recursive server asking the same question in 
less than the TTL (of the answer, the zone minimum, and some other 
TTL for a validation failure).

Is the sticking point that a failed response has no reliable TTL? 
Any TTL guessed by the recursive server would be a WAG and could be 
higher than the true TTL.  IMHO, a rugged validator would pick some 
TTL for this situation, maybe an hour or so (or base this timer on 
the average length of attacks) meanwhile still listening for the true 
response - if it is forthcoming.

If the problem (a stub repeatedly asking for data that fails checks 
repeatedly) is due to a configuration error somewhere, the TTL choice 
isn't the problem.  If the problem is due to a DOS taking out the 
authoritative servers, the TTL isn't the primary issue.  If the 
problem is die to message insertion, then the real answer might also 
arrive later on.

I haven't read the specs on this, it's not what I'm working on at the moment.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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"

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 18 Oct 2011 10:45:24 -0400

No hat.  I think we're no longer moving ahead on this topic, so this
is my last no-hat remark on it.

> recursive server gets are *good*.  I'm trying to make it work with

I get what you're trying to do (Brian Dickson's summary also agreed
with my interpretation of what I thought you were saying).  I have no
difficulty saying, "This might be a good policy for a stub resolver to
adopt."  But what you are trying to do is require this behaviour as
part of the protocol.  I don't see why that's the right answer, since
you are thereby going to require more lookups.  Given that some people
today aren't willing to wait for DNS responses -- i.e. they want
either a positive or negative answer more than they want the right
answer -- I do not believe that doubling the number of queries at
initial lookup is a realistic plan.

You haven't answered the question of why this ought to be protocol
rather than a resolver policy recommendation.  You say you think it's
making things work in "real world scenarios".  I think it might work
with some real world scenarios, and not work in others (like impatient
eyeballs), and therefore I don't see the argument for a protocol
change.  It's certainly true that at least in the short term, zone
operators are going to mess up their signatures and cause breakage.
But you are arguing that every stub resolver will, for all time, have
to send two queries instead of one in order to protect people from
zone operators who screw up their zone operation.  I'm not convinced
your trade-off is obviously the only right one, and your only argument
so far is to say "real world scenarios" over and over again.
 
> is going to validate or not.

Right, but you cannot rely on every answer you get so you have to
re-send your query with CD=1 also.

RFC 4035 effectively tells you this in section 4.9.2:

> 	A => B does not mean that !A => !B.

Gee, I didn't know the rules of entailment before.  Thanks.  I note
that you cut out of the quote you replied to the part of the message
where I discussed the other open course of action, and which
contradicts your claim that I'm denying the antecedent.  That is, I
didn't say "CD=0 and blindly trust the response", but "CD=0 and
blindly trust or send another query".

It is clearly true that "if CD=1 then client will validate" does not
mean anything about what CD=0 means.  We don't have a bit that says
what the querier's policy about validation is.  But because server
policy gets to determine, at least to some extent, what happens with
CD=0, CD=1 is effectively required to signal the state "will valiate".
Apart from that, all bets are off.  DNS64 doesn't have the logic error
you ascribe to it; instead, it's a hack that has to make do with the
bits available to it in the already-deployed world (remember, the
whole point of DNS64 was that you could deploy a NAT64/DNS64 without
touching any clients.  The CD-based signalling was as close as we
could get).

> anchors, I have a solution (below) 

Feel free to write the draft.  I don't find that case especially
compelling, but others might.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian Dickson <[email-masked]>
Date: Tue, 18 Oct 2011 11:45:12 -0400

> the stub then asks with CD=1 to avoid the upstreams validator.

So, to paraphrase, the CD=1 query is subsequently sent, ONLY IF there
is a problem with the response when CD=0.

The does not normally result in more than one query.

And only if CD=0 fails, does a second query get sent - and necessarily so.

In both cases, if an answer is received, it is also processed to see
if the answer is DNSSEC-valid.

> initial lookup is a realistic plan.

Please see above - Mark's recommendations do not double the number of
queries, or at least not most of the time.

> so far is to say "real world scenarios" over and over again.

See above - no double queries.

I agree that improving DNS resolution time is something we should address.
I hope to be able to provide some suggestions along those lines in the
near future.
Unfortunately, doing so is dependent on the "aliasing requirements"
draft, and until
that shows up again, I'm "blocked"...

>   acceptable to the stub resolver's local policy.

It is important to understand *how* that can happen.

As far as I can determine, there are two situations.
The name server's policy validates the answer, but the stub's does not.
The name server's policy does not validate an answer which the stub's
would, and thus the stub never gets the answer.

In the first case, repeating with CD=1 won't change the outcome.

In the second case, repeating with CD=1 might change the outcome, but
only if the name server gets the same answer itself (or has cached the
"BAD" answer).

However, when CD=1, it is also the case that the name server could
receive answer(s) that neither the name server nor the stub will
succeed in validating.

I think perhaps a better way of breaking the problem down might be,
instead, to recommend the following:

"The same 'local policy' SHOULD be applied on a validating
security-aware stub resolver as on its recursive resolver. If a
different policy is required, a different recursive resolver should be
used which uses that other policy. If neither of these is feasible,
implementing a conditional 'CD=0' followed, if needed by 'CD=1'
re-query, SHOULD be done by the stub resolver."

>> intend to validate.

I don't think it is necessarily the case that anything can be inferred
about the validation intent of a stub, from what it sets CD and/or DO
to.
While it may be silly to do so, there is nothing to stop a stub from
asking for DNSSEC records it will ignore.

On the other hand, the idea of a stub asking a recursive resolver to
send DNSSEC records without validating them seems... unreliable.
Probably to be recommended against. See the above recommendation.

Brian

---

From: Michael StJohns <[email-masked]>
Date: Tue, 18 Oct 2011 12:29:55 -0400

This is just plain strange.   

If I have a configured trust anchor, I generally want to do my own validation (CD=1, D0=1, RD=1) - why should I trust anyone else?  (and more importantly, why should I contribute to the load on the recursive resolver by requiring them to validate stuff I'm going to also validate?)  (And if one more person utters "suspenders and belt" ...)

If I don't have a configured trust anchor, I either want no security (CD=1, D0=0, RD=1) or I want my local recursive server to be secure on my behalf (CD=0, D0=0, RD=1).   

As I understand it, the first and the last of these three are the way most stub resolvers get configured.

(Ed's table is useful, but the other 5 possibilities are pretty much only used by geeks and operators :-) and special cases where the local resolver isn't really just a stub )

This is a policy configuration issue - period.  There is no need for Mark's somewhat convoluted "tell me twice" scheme.

If you want to configure your own personal local resolver to do a tell-me-twice, have at it.  But this should (MUST?) not be the required default. I agree with Andrew that there is no protocol issue here. I see no problem with the current language in the document and recommend no change.

Mike

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 18 Oct 2011 09:47:20 -0700

On Oct 18, 2011, at 9:29 AM, Michael StJohns wrote:

> If I have a configured trust anchor, I generally want to do my own validation (CD=1, D0=1, RD=1) - why should I trust anyone else?  (and more importantly, why should I contribute to the load on the recursive resolver by requiring them to validate stuff I'm going to also validate?)  (And if one more person utters "suspenders and belt" …)

The recursive resolver still needs to validate if anything is going to get into the cache. [1]

So you aren't reducing load on the recursive resolver by always sending with CD=1.

> If you want to configure your own personal local resolver to do a tell-me-twice, have at it.  But this should (MUST?) not be the required default. I agree with Andrew that there is no protocol issu…

However, I do agree with this:  Tell me twice vs tell me once with CD=1 is pretty much a non-issue:  Under almost all cases, the load will be the same on the resolver, and the load on the network will be the same.

[1]  I now stand corrected due to some other issues, and now believe that having the recursive resolver validate does have some value.  I still believe it should be the client that validates, as the recursive resolver itself is a threat, but there is actual benefit in the recursive resolver always validating.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 18 Oct 2011 13:09:12 -0400

>The recursive resolver still needs to validate if anything is going to get into the cache. [1]

Not quite.  It can defer validation until (and if) someone asks for the validated data (CD=0 query).    In an "ideal" (well, my ideal) world,  ALL validation is done ONLY by the stubs and this validation in the middle hack goes away.

>So you aren't reducing load on the recursive resolver by always sending with CD=1.

Implementation decision.  Not part of the protocol.  The last time (admittedly this was 5+ years ago) I tried this, at least a few versions of recursive resolvers did not validate CD=1 response data so the load *was* lower.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 18 Oct 2011 13:13:42 -0400

> If I have a configured trust anchor, I generally want to do my own validation (CD=1, D0=1, RD=1) - why should I trust anyone else?  (and more importantly, why should I contribute to the load on the…

If you have DO=1, you are doing validation.

That is constant, regardless of the state of CD.

When CD=0, you want the recursive resolver to validate. Put another
way, you are asking the recursive resolver to do what it would do if
it were looking up the same query for itself, instead of on behalf of
you.

If you were to operate your own recursive resolver (internally on the
"stub" machine), it would behave exactly as if CD=0. It validates
using local policy (trivially true). It does not terminate when it
gets an answer, it terminates when it gets an answer that validates,
or when it exhausts all possible paths for trying to find an answer.

BTW - You (the stub) are validating the response, so you aren't
"trusting" the response.

The only dependency between stub and recursive resolver when CD=0, is
that the stub's policy must be a stricter policy that the resolver's.

This means that the resolver must have a superset of the stub's TAs,
or an identical set.

If this is not the case, then the recursive resolver might block
answers that the stub would otherwise validate.

The recursive resolver (with a superset of TAs) might validate and
return some answers that might fail the stub's validation.

However, in that corner case, having CD=1 would not change the outcome.

> This is a policy configuration issue - period.  There is no need for Mark's somewhat convoluted "tell me twice" scheme.

Please read my response in the other thread. It is not "tell me twice".

OTOH, CD=1 is much more fragile, with no clear benefit *to the stub*.

As  Nicholas Weaver observes, the resolver will generally want to
validate anyway, so there is no extra cost to doing CD=0.

Brian

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 18 Oct 2011 10:15:42 -0700

> Not quite.  It can defer validation until (and if) someone asks for the validated data (CD=0 query).    In an "ideal" (well, my ideal) world,  ALL validation is done ONLY by the stubs and this vali…

True, but I have a bad feeling the ideal world will never happen, so in practice, almost everything that gets cached will need to be validated by the recursive resolver.

> Implementation decision.  Not part of the protocol.  The last time (admittedly this was 5+ years ago) I tried this, at least a few versions of recursive resolvers did not validate CD=1 response dat…

It seems the ONLY reason this debate is coming up is about performance and load:

CD=0 then CD=1 MAY load the recursive resolver more and WILL result in a extra query IFF the recursive resolver does not have a valid root of trust for the name but the client does.

Otherwise, its identical semantics.

Which means, frankly, I don' think it matters either way, since I don't see it, in practice, either reducing the load on the recursive resolver nor commonly causing clients to have to retry.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 19 Oct 2011 09:04:29 +0900

Derek Atkins wrote:

> My laptop clock is pretty accurate,

You miss the point.

The problem is that there will be devices which synchronize
its clock to external sources insecurely, regardless of
whether the devices have accurate clock or not.

> You don't need sub-second synchronization here.

Most people mind clocks of their devices have minutes of
errors.

Most people do not mind clocks of their devices are synchronized
to external sources insecurely.

> manufacturing time, or if you have a bad clock or bad CMOS battery.

No devices have two clocks, one of which is dedicated to
secure DNS.

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Oct 2011 12:54:10 +1100

Getting secure time is not a protocol issue for DNSSEC.  It is
a operations issue.

Apple, for example, sets ntp.conf to "server time.asia.apple.com"
with MacOS based on the default location for this machine.  They
could set autokey and distribute public keys for their timeservers
if they wish.  They may already do so in Lion. 

Other OS vendors could do similar.

Note for many machines mis-set clocks will get noticed as they are
looked at every day and ntp take ages to slew a clock enough to be
a security issue for DNSSEC.

Similarly Kerberos fails with a 5 minute drift.  When that happens
you work out which clocks are wrong and correct them.

Note time is only significant for DNSSEC to protect against replay
attacks or to stop someone continuing to use a compromised key.

Mark

---

From: Rob Austein <[email-masked]>
Date: Tue, 18 Oct 2011 18:40:40 -0400

At Tue, 18 Oct 2011 12:29:55 -0400, Michael StJohns wrote:
> 
> If I have a configured trust anchor, I generally want to do my own
> validation (CD=1, D0=1, RD=1) - why should I trust anyone else?
> (and more importantly, why should I contribute to the load on the
> recursive resolver by requiring them to validate stuff I'm going to
> also validate?)  (And if one more person utters "suspenders and
> belt" ...)
> 
> If I don't have a configured trust anchor, I either want no security
> (CD=1, D0=0, RD=1) or I want my local recursive server to be secure
> on my behalf (CD=0, D0=0, RD=1).
> 
> (Ed's table is useful, but the other 5 possibilities are pretty much
> only used by geeks and operators :-) and special cases where the
> local resolver isn't really just a stub )

I have not really been following this thread, both because I'm working
on other things these days and also because, as one of the primary
authors of the text Mark is unhappy about, I pretty much have to
recuse on whether the text is clear.

With that said, though: I think Mike has nailed it here.  The
recursive name server's implementation issues and efficiency
considerations are not the stub resolver's problem.  When the stub
resolver sets <CD=1, DO=1, RD=1> it is saying "give me the freaking
DNSSEC data and stay the [bleep] out of my way"; at least, that was my
intent back when we were writing the DNSSECbis specifications, and
that was the point about which I made a stinking nuisance of myself
when other WG participants tried to deprecate the CD bit.

I suspect that at least some of the differences of opinion on this
list stem from whether one is looking at all this from the point of
view of the stub resolver or the point of view of the recursive name
server.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Oct 2011 14:08:14 +1100

> recuse on whether the text is clear.

The text is clear.  The requested behaviour however is BAD as it
leaves the stub resolver open to accidental denial of service caused
by the resolver as a direct result of the way CD is being set.

The working group did not explore all the failure modes inherent
with a stub/recursive server/authoritative server configuration.
The text highlights one of those failure modes (incorrect validation
failures in the recursive server) but fails to address the other
failure modes that result from the stub not being in direct
communication with the authoritative servers.

> when other WG participants tried to deprecate the CD bit.

Nobody is arguing that.  In fact the suggested revised text still
depends on that behaviour.

The argument is "Can a stub validator, reliably, get a successfully
answer in the presence of common, partial, misconfigurations of the
authoritative servers if it only makes CD=1 queries?" as per the
current spec.  I contend the answer to that question is "no" and
suggested revised behaviour which addresses some of the failures
that can happen with the current spec.

All CD=0 queries from the stub is BAD.
All CD=1 queries from the stub is BAD.

For the system to work reliably there needs to be a mixture of CD=0
and CD=1 queries with the stub retrying with the other type when
the first type fails.

Now one can argue about "CD=0 then CD=1" or "CD=1 then CD=0" but a
stub which doesn't switch is broken.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 19 Oct 2011 23:25:39 +0900

> Getting secure time is not a protocol issue for DNSSEC.  It is

The problem of DNS over HTTP is that there is no meaningful
use case.

Though it is an operational issue, protocol modification
proposals are meaningless if the proposals have no use cases,
which means that it is a protocol issue, too.

> with MacOS based on the default location for this machine.

Can you expect NTP work, even though plain DNS over IP is not
expected to work?

> looked at every day

And most users blindly acknowledge the notices without knowing
their relevance to secure DNS.

> you work out which clocks are wrong and correct them.

AFAIK, shared key cryptography does not need secure clocks,
because shared keys should be invalidated in time, but,
even if some implementation needs them, it does not make
secure DNS with insecure clock secure.

> attacks or to stop someone continuing to use a compromised key.

Wrong.

After some private keys are compromised, MITM can supply forged
data to a client through secure DNS by forging a clock of the
client, which is why the clock of the client must be secure.

						Masataka Ohta

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 19 Oct 2011 10:27:27 -0700

Andrew,

> understand the argument implicit above.  As near as I can tell, Mark

The discussion that followed this somehow did not answer the specific
question that was raised above. I thought that there was a separate
thread for discussing Mark's proposal out of which this one came
about. My interpretation of the question is a little different. Can
you clarify ?

At least in my mind, the above question was :

What should a recursive server do when it is not able to validate a
response due to the mis-configuration of the authoritative servers ?
Should it retry multiple authoritative servers based on whether the CD
bit is set in the query or not ?

There were two possibilities:

1) What Mark said above: CD =1 implies stateless i.e.,  If the
recursive server encounters a mis-configured server and hence cannot
validate the response, it would return the response if CD=1 was set in
the query. If CD=0, it would try multiple servers and finally validate
the response successfully if there is at least one "good" server.

2) The recursive server always tries multiple authoritative servers
irrespective of the CD bit setting in the query. The DNSSEC bis
updates has the "Always set CD bit policy" which means the recursive
server always sets the CD bit irrespective of what is set in the
incoming query. To make sure that it's cache does not become a DoS
source, it would always try multiple authoritative servers.

Currently this behavior is not defined anywhere in RFC 4035.

-mohan

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 Oct 2011 14:02:32 -0400

>bit is set in the query or not ?

I start with this kind of question, because DNSSEC is not supposed to 
change the nature of DNS:

What happens today, i.e., without DNSSEC, when a recursive server 
reaches a "broken" authoritative server?

Answer: It tries others.  (I'll avoid using the word mis-configured 
here because that's open to too many interpretations.)

Ok, the situation here is different.  In pre-DNSSEC, it was "did I 
get an answer" and in DNSSEC it is "is the answer good enough."  Good 
enough is what, exactly?  What if the first source has a response 
that is syntactically valid but won't validate and the second source 
does.  With CD=1, should the recursor go to the second one?

My thought is - the decision is a matter of local policy.  It's not 
vital to interoperability although the choices lead to different 
results.

>1) ...
>2) ...

That's true and the situation wasn't considered.  My assumption was 
that the recursor would just take the first source and hand that 
back.  If I were writing the prototype code again I would have then 
tried to validate, failed, and cached the failure.  I probably 
eventually would have followed that up with a look at the second 
source, validated the answer, cached that and dumped the 
failed-validation cache.  If the requestor came back again with CD=1, 
I'd answer from cache even though I already did the check.

The base protocol lacked a "get me a fresh answer" bit.  The CD could 
be thought of as the DNSSEC version of "get me a fresh answer."  But 
I wouldn't go there, the protocol, since the beginning, limits the 
requestor's power to push the server around.

None of this is clear.  It wasn't discussed.  It certainly wasn't 
documented.  We can argue about this all day if we want.  What I have 
here is just my opinion - and one I generated sitting in this chair. 
The WG can try to come to a consensus but a 100 messages saying "yes" 
and "no" isn't constructive.

DNSSEC and DNS never considered the ruggedness of it's elements. 
Recursion can be done lightly, falling to SERVFAIL, or it can try 
hard to get an answer.  That "quality" isn't captured in the protocol 
specifications and I don't think we've seriously tried.

I think, maybe it's an implementation choice.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 24 Oct 2011 18:40:45 +0900

http://www.ietf.org/id/draft-ohta-practically-secure-dns-00.txt

						Masataka Ohta

---

From: Joe Abley <[email-masked]>
Date: Mon, 24 Oct 2011 13:12:33 +0000

> 	http://www.ietf.org/id/draft-ohta-practically-secure-dns-00.txt

You characterise the possible reasons why successive responses to the same query, sent close together with different query IDs, might be different. I think the set of possible reasons is simpler than you suggest, namely

(a) the responses are legitimately different (e.g. your possible cases 1, 2 and 3)

(b) the responses are different for a malicious, undesirable reason (your case 4)

I don't understand from your draft how I distinguish between (a) and (b), except in the corner case where I happen to be intimately aware of what the originator of the DNS data (the maintainer of the corresponding zone) intends. The text that provides the necessary guidance in identifying your case (4) is not clear to me.

Your draft also doesn't seem to address the threat that a man in the middle receives both queries from the client and replies to them with bogus data, in such a way that a client following your direction believes the answer to be secure.

I presume that your proposal addresses a particular subset of existing threats, and that you view mitigation of that subset to be sufficient to declare the result "practically secure". It would help me understand the proposal if you outlined what those threats were.

As I read it, the guidance in your draft would cause some legitimate responses to be discarded and at the same time provides a recipe which would allow anybody with malicious intent to feed lies to a client and have them accepted as secure.

Either my understanding is faulty (in which case perhaps the draft would benefit from clarification) or the proposal seems to have limited applicability.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Mon, 24 Oct 2011 09:44:39 -0400 (EDT)

> 	http://www.ietf.org/id/draft-ohta-practically-secure-dns-00.txt

Isn't all of this already proposed in http://tools.ietf.org/html/draft-wijngaards-dnsext-resolver-side-mitigation-01
and implemented in unbound?

It also totally ignores the fact that if all involved name servers are "secure" (definition unknown) but
the traffic path is not, the "secure" client is still going to take rewritten replies. Eg this draft
does not even handle the "starbucks wifi" scenario or any transparent DNS proxy scenario.

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 24 Oct 2011 07:55:07 -0700

> 	http://www.ietf.org/id/draft-ohta-practically-secure-dns-00.txt

This draft only addresses out of path adversaries, those which may trigger a request but can not see the actual packets.  There exists several critical in-path adversaries (including, in practice, the resolvers themselves) that are active in the wild that this can not address, and thus saying "Secure" is a misnomer, it is secure against out-of-path attackers/blind injection attacks only.

The probability of performing blind injection is already vastly reduced by a combination of source port randomization and 0x20 encoding, and the damage DONE by blind injection can be mitigated by better glue policies of which you've advocated in the past.  To my knowledge, Unbound implements all of these: source port randomization + 0x20 to reduce the probability, and glue policy to reduce the damage. [1]  I think 0x20 is off by default but not sure.

Also, There exists an easier approach for fallback under conflict: retry using TCP rather than UDP.  

TCP, with its much larger state space (32b sequence number on each side plus 16b transaction ID) is effectively immune to blind injection attacks.

[1] Glue policy is essential, as otherwise deliberately synthetic names (e.g. 12314515125125125.com) can be used to corrupt glue records yet don't benefit from the increased entropy of 0x20.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 24 Oct 2011 12:21:43 -0400 (EDT)

On Mon, 24 Oct 2011, Nicholas Weaver wrote:

> 0x20 to reduce the probability, and glue policy to reduce the damage. [1]  I think 0x20 is off by default but not sure.

When GoDaddy broke their servers a few months ago, 0x20 basically died. You will be failing thousands of domains
if you enable 0x20 :(

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 24 Oct 2011 09:23:47 -0700

> When GoDaddy broke their servers a few months ago, 0x20 basically died. You will be failing thousands of domains

No, you'll be slowing down resolution, not failing, since you treat 0x20 like you do EDNS: timeout means retry without, and memoize that information.

Better yet, make the "Memoize the information" be "always use TCP", and force them to fix their resolver under the load.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 24 Oct 2011 12:32:40 -0400 (EDT)

> will be failing thousands of domains

Just to clarify. godaddy.com itself is fine, since it is using a different (better!)
nameserver implementation then their customers' nameservers:

$ dig StoneKeep.cOm @ns45.domaincontrol.com.

; <<>> DiG 9.7.4b1-RedHat-9.7.4-0.3.b1.fc14 <<>> StoneKeep.cOm @ns45.domaincontrol.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61049
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;stonekeep.com.			IN	A

;; ANSWER SECTION:
stonekeep.com.		1800	IN	A	96.39.62.68

;; AUTHORITY SECTION:
stonekeep.com.		3600	IN	NS	ns45.domaincontrol.com.
stonekeep.com.		3600	IN	NS	ns46.domaincontrol.com.

;; Query time: 24 msec
;; SERVER: 216.69.185.23#53(216.69.185.23)
;; WHEN: Mon Oct 24 12:29:10 2011
;; MSG SIZE  rcvd: 99

$ dig  GoDaddy.cOm @cns1.secureserver.net.

; <<>> DiG 9.7.4b1-RedHat-9.7.4-0.3.b1.fc14 <<>> GoDaddy.cOm @cns1.secureserver.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22167
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;GoDaddy.cOm.			IN	A

;; ANSWER SECTION:
GoDaddy.cOm.		300	IN	A	97.74.104.201

;; AUTHORITY SECTION:
GoDaddy.cOm.		3600	IN	NS	cns3.secureserver.net.
GoDaddy.cOm.		3600	IN	NS	cns1.secureserver.net.
GoDaddy.cOm.		3600	IN	NS	cns2.secureserver.net.

;; ADDITIONAL SECTION:
cns1.secureserver.net.	3600	IN	A	208.109.255.100
cns2.secureserver.net.	3600	IN	A	216.69.185.100
cns3.secureserver.net.	3600	IN	A	64.202.167.31

;; Query time: 25 msec
;; SERVER: 208.109.255.100#53(208.109.255.100)
;; WHEN: Mon Oct 24 12:30:20 2011
;; MSG SIZE  rcvd: 166

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 24 Oct 2011 09:35:19 -0700

> nameserver implementation then their customers' nameservers:

Oh, thats even easier.  You get the downcased response back the first time, and you treat it as "Use TCP for this server".

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 25 Oct 2011 08:49:00 +0900

Joe Abley wrote:

> You characterise the possible reasons why successive responses to
> the same query, sent close together with different query IDs,
> might be different.

My intention is to have exhaustive list of reasons.

> I think the set of possible reasons is simpler than you suggest, namely
> 

That's useless classification.

The important difference of 3) from 1) and 2) is that lack of identical
replies are persistent over up to 4 queries, during which 4) is
identified to be occurring.

> I don't understand from your draft how I distinguish between (a)
> and (b),

because it is meaningless to distinguish (a) and (b).

> Your draft also doesn't seem to address the threat that a man in the

Why can't you wrap lines properly?

SDNS with automatic servers for clients to modify domain
information with password confirmation is not secure from
a men in the middle attacks, either.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 25 Oct 2011 08:56:45 +0900

Paul Wouters wrote:

> Isn't all of this already proposed in 
> http://tools.ietf.org/html/draft-wijngaards-dnsext-resolver-side-mitigation-01 

Which one?

> "secure" (definition unknown) but

SDNS also totally ignores the fact that SDNS with automatic servers
for clients to modify domain information is not secure if related
servers are not secure.

> the traffic path is not,

SDNS with automatic servers for clients to modify domain
information with password confirmation is not secure if the
traffic path is not secure.

> the "secure" client is still going to take
> rewritten replies. Eg this draft

SDNS also ignores the fact that secure time is practically
impossible to obtain within certain private networks.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 25 Oct 2011 09:04:37 +0900

Nicholas Weaver wrote:

> The probability of performing blind injection is already vastly reduced by a combination of source port

See the abstract of the draft.

> Also, There exists an easier approach for fallback under conflict: retry using TCP

TCP is not always supported.

> [1] Glue policy is essential,

That's a solved problem.

							Masataka Ohta

---

From: Joe Abley <[email-masked]>
Date: Tue, 25 Oct 2011 09:39:03 +0000

> My intention is to have exhaustive list of reasons.

I don't think you are there, yet.

> That's useless classification.

Right, that was my point.

> because it is meaningless to distinguish (a) and (b).

It's a coarse classification, but distinguishing between (a) and (b) is surely the entire point of your proposal.

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 25 Oct 2011 20:26:49 +0900

> I don't think you are there, yet.

Which case, do you think, is missing?

> Right, that was my point.

That's your classification, which means your, not my, problem
is your point.

> It's a coarse classification,

Yes.

> but distinguishing between (a) and
> (b) is surely the entire point of your proposal.

Not at all.

					Masataka Ohta

---

From: Joe Abley <[email-masked]>
Date: Tue, 25 Oct 2011 12:05:07 +0000

> Which case, do you think, is missing?

Your cases are (I am paraphrasing)

(1) responses are different because the zone changed between them

(2) responses are different because they come from different caches

(3) responses are different for some other reason

So I agree it's exhaustive, but only because case (3) is so general.

Since enumerating all possible specific reasons for (3) is not
possible, your recipe for distinguishing between (3) and (4) can
only ever hope to work some of the time -- it's a pragmatic choice
presumably intended to be good enough, most of the time.

To benefit from the approach you propose the recipe needs to do
more good than harm.  Without empirical analysis it's not obvious
that this is the case for today's use of the DNS. Without a time
machine, it's not obvious that this is the case for tomorrow's use
of the DNS (unless the intention is to constrain future use of the
DNS).

Joe

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 25 Oct 2011 10:45:53 -0700

> Why can't you wrap lines properly?

Why do you deliberately misconfigure Thunderbird?  Thunderbird reflows text unless you deliberately mangle the text by eliminating spaces.

> See the abstract of the draft.

You exclude 0x20 in the abstract.

You neglect that the notion of "secure" for the separate recursive resolver is an absolute joke: you gain far more security by just bypassing the recursive resolver completely without even bothering with port randomization if you use a non-kaminskiable glue policy.

> TCP is not always supported.

Fallback to TCP first, before trying anything else on disagreement, because otherwise you are in a world of hurt.

Look at how Facebook handles IP addresses:

The following is 10 queries to glb2.facebook.com for "www.facebook.com"

66.220.147.33
69.171.224.12
69.171.224.11
69.171.228.39
66.220.149.25
66.220.149.66
66.220.149.25
69.171.229.16
69.171.228.40
66.220.147.11

It took 7! tries before a single IP was in agreement.  

Another test:

66.220.149.67
69.171.228.11
66.220.149.11
69.171.229.15
69.171.224.14
66.220.149.67
69.171.228.39
69.171.224.11
69.171.229.12
69.171.224.11

Now it took 10 tries!

Also, blind injectors can't remove the real packet, so with high probability: If you get two responses to the same transaction ID within ~100ms, discard both: the probability of injected packet is high.  While looking for unmatched IDs can produce false positives/malicious false positives.

>>  essential,

Not if you are running bind.  

Most resolvers in the wild still use Kaminskiable Glue Policies: they enable "race until win" attacks, and attacks that get auth information, rather than "one race per TTL".

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 26 Oct 2011 07:43:24 +0900

> Your cases are (I am paraphrasing)

Don't do that.

> (3) responses are different for some other reason

The draft says:

      3) the server is actively randomizing answers for load balancing
      and other purposes; or

and the point is "actively randomizing".

> possible,

Sorry, I'm not interested in discussions why  YOUR, not my,
definitions are useless.

So far, you failed to show an example which is not covered
by my cases.

> more good than harm.

So, where is an example that the proposal is harmful?

> Without empirical analysis it's not obvious
> that this is the case for today's use of the DNS.

That's not a valid argument against proposals to be a
proposed standards for the empirical analysis.

> Without a time

We are solving today's problems.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 26 Oct 2011 07:55:21 +0900

Nicholas Weaver wrote:

> Why do you deliberately misconfigure Thunderbird?

OK. I ignore lengthy lines of your mails.

> You exclude 0x20 in the abstract.

It does not address my case 3) nor exponential growths and
is not practical enough.

> It took 7! tries before a single IP was in agreement.

It has nothing to do with my proposal:

   Otherwise, it should be case 3) and, unless case 4) is identified to
   be simultaneously occurring, one of the replies should be practically
   secure, though it is less secure.

						Masataka Ohta

---

From: Brian Dickson <[email-masked]>
Date: Tue, 25 Oct 2011 19:48:55 -0400

The proposal does not in any way define "secure", which I believe is
going to be problematic for it to be considered by the WG,
let alone the IETF.

Could you please elaborate on what you mean by "secure"?

> for clients to modify domain information is not secure if related

SDNS considers the modification of domain information out-of-scope.

However, DNS registry operators, registrars, and DNS hosting operators
do not ignore this, and generally employ
whatever they consider best practice in securing their servers, and in
limiting the extent of problems if a server
which by necessity is exposed to the Internet, gets compromised.

> traffic path is not secure.

By negating the conclusion, we in turn infer the negation of the preposition.
If the traffic path is secure, SDNS ... is secure.

Current best (and common) practice is to submit domain information
over secure channels.
This includes encrypted email (2048 RSA), physical devices (flash
memory), out-of-band (fax),
and SSL-protected or IPsec-protected connections (e.g. https).

> impossible to obtain within certain private networks.

SDNS does not require secure time, only "pretty good" time to prevent
replay and never-expired data usage.
Wall-clock time from a reasonably reputable source, such as WWV, the
TV, or the USNO web site, are all good enough.
Set once, and check every 6 months by comparing to another reasonably
okay source, is more than enough for SDNS.

SDNS addresses man-in-the-middle (providing modified-but-consistent
results). That meets my definition of "secure".

How does not addressing man-in-the-middle (which your proposal does
not) in any way meet the definition of "pretty secure"?

Brian

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 26 Oct 2011 10:36:31 +0900

> Could you please elaborate on what you mean by "secure"?

"secure" against ID guessing attacks. I'll clarify it with
the next version.

> SDNS considers the modification of domain information out-of-scope.

That's not very practical.

> > "secure" (definition unknown) but

where "secure", here, means all the aspects of security.

> This includes encrypted email (2048 RSA),

It needs yet another secure channel to securely tell one's
public key to its peer.

> physical devices (flash memory), out-of-band (fax),

They are not secure.

> and SSL-protected or IPsec-protected connections (e.g. https).

Same as encrypted email.

Worse, https with so many root CAs is practically not secure.

> replay and never-expired data usage.

Wrong. Without secure time, once a zone is compromised, newly
forged data can be injected with expired certificates.

> TV, or the USNO web site, are all good enough.

Not at all. It's trivially easy to fake radio waves. You don't
even have to tap a wire.

> results). That meets my definition of "secure".

SDNS does not address man-in-the-middle to obtain secure time.

> not) in any way meet the definition of "pretty secure"?

The draft is titled "practically secure" DNS.

						Masataka Ohta