Subject: Proposed DNSSEC Plenary Experiment for IETF 74

From: Russ Housley <[email-masked]>
Date: Wed, 26 Nov 2008 10:50:56 -0500

I have been approached about a plenary experiment regarding 
DNSSEC.  The idea is for everyone to try using DNSSEC-enabled clients 
during the plenary session.  I like the idea.  What do others think?

Russ

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

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Nov 2008 13:05:17 -0500

--On Wednesday, 26 November, 2008 10:50 -0500 Russ Housley
<[email-masked]> wrote:

> DNSSEC.  The idea is for everyone to try using DNSSEC-enabled
> clients during the plenary session.  I like the idea.  What do
> others think?

I think it is a wonderful idea.

I must have a DNSSEC-enabled client for WinXP floating around
here somewhere (not a browser extension, but something my email
and Jabber clients can call and that has a well-sorted-out UI to
deal with verification failures).

I also assume those clients will be performing validation
against a signed root zone, signed ORG, COM, and several
national ccTLD zones, signed IETF.ORG, IAB.ORG, RFC-EDITOR.ORG,
and IANA.ORG zones, etc.

Do you have a plan about who is going to supply the low-velocity
flying pigs for this meeting?   Perhaps we could get them to
listen for DNS queries and cache and transport responses.

Sorry for the sarcasm, but some operational reality would be a
good idea for ideas like this.

    john

---

From: Bill Manning <[email-masked]>
Date: Wed, 26 Nov 2008 11:21:31 -0800

> during the plenary session.  I like the idea.  What do others think?

nifty!  jck shares my concerns.  as far as I can determine, the only
way this would work at all is if everyone ran their own copy of a 
validating resolver on their own machines, each with a manually configured
suite of Trust Anchors.  Now what would be a truely interesting test is
to have multiple, independent implementations of RFC 5011 and agreement
by the TA owners to roll their keys during the IETF...  and see how the
various implementations fo RFC 5011 break - or not.

or - we can all run pre-beta versions of windows-7 and statically point to 
either of the two third-party trust anchors in the Internet, the ISC DLV registry
or the ICANN-ITAR.  either of which is one minor step removed from simple
static configuration.

then there is the tiny problem of the lack of a standard DNSSEC API - it can
be as simple as a single bit (validated or not) or can have a range of options.

i don't think there is consensus on what to do here.  and I am dubious that
there will be significant change before IETF 74.

but I could be wrong and may have to show up just to see how well the IETF
recreates Interop!

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Ron Bonica <[email-masked]>
Date: Wed, 26 Nov 2008 17:06:14 -0500

+1

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Nov 2008 10:08:36 +1100

> during the plenary session.  I like the idea.  What do others think?

	The first thing we should address is the lack of signed
	zones under the control of the IETF.

; <<>> DiG 9.3.5-P2 <<>> dnskey ietf.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29574
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ietf.org.			IN	DNSKEY

;; AUTHORITY SECTION:
ietf.org.		7200	IN	SOA	ns0.ietf.org. glen.amsl.com. 1200000073 1800 1800 604800 7200

;; Query time: 344 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Nov 27 10:06:43 2008
;; MSG SIZE  rcvd: 79

	Secondly we should just turn on DNSSEC validation on the
	recursive servers offered by DHCP and RAs.  This should be
	on for the entire week.  This is what we are asking ISP's
	to do and I see no reason why we shouldn't do the same.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: David Conrad <[email-masked]>
Date: Wed, 26 Nov 2008 15:14:15 -0800

On Nov 26, 2008, at 10:05 AM, John C Klensin wrote:
> against a signed root zone,

Sure, if they configure their trust anchor according to https://ns.iana.org/dnssec/status.html

(There are other testbeds too, but I don't recall where to dig up  
their trust anchors)

> signed ORG,

Might be in limited testing by the next IETF -- I don't remember  
offhand the schedule of when ORG was going to be signed...

> COM,

Won't be ready by the next IETF so I understand.

> and several national ccTLD zones,

Yep: SE, BR, PR, BG, & CZ at this point.  And, of course: MUSEUM and  
the test IDN TLDs.  Might be more by the next IETF.  Also, if you're  
using the ns.iana.org IANA testbed, you'll also get INT, ARPA, and  
ARPA children.

> listen for DNS queries and cache and transport responses.

Unnecessary.  All it would take would be for the folks who set up the  
caching servers to configure the appropriate root (or TLD) trust  
anchors.  It isn't really that hard.  I've been doing it on my laptop  
now for over a year.

Of course, the real issue is whether or not anyone would actually  
notice.  The vast majority of folks (the ones who get the IP addresses  
for their caching servers via DHCP) would see absolutely no change  
unless there is a validation failure, in which case they'll get back a  
SERVFAIL response which will likely be interpreted as 'host not found'.

> good idea for ideas like this.

The operational reality is that folks are deploying DNSSEC and there  
are even folks who are validating responses with it.  Turning on  
DNSSEC in the IETF-supplied caching servers should probably be the  
default.  Any reason not to?

Regards,
-drc

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Nov 2008 13:08:52 -0500

>>>>> "Russ" == Russ Housley <[email-masked]> writes:
    Russ> I have been approached about a plenary experiment regarding
    Russ> DNSSEC.  The idea is for everyone to try using DNSSEC-enabled
    Russ> clients during the plenary session.  I like the idea.  What do
    Russ> others think?

  In this case, it's really not about the clients, I think.

  It's about making the IETF DNS servers (the recursive ones), have
DNSSEC processing on. They would authenticate the answers, and discard
responses which should have been signed, but were not.
  An appropriate set of trust anchors would need to be agreed upon, and
a decision whether or not to enable DLV or not would need to be made.

  I will point out that (unless we close port-53 outgoing), that anyone 
who wants to run their own recursive name server (a requirement if you
run windows and the room is IPv6 only...), or who points their
/etc/resolv.conf to their own name server, will not really be affected.
  I do not suggest we close port 53 :-)

  I am in favour (and hope to be there).
  I would also volunteer to help set it up.

-- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Peter Koch <[email-masked]>
Date: Thu, 27 Nov 2008 17:47:32 +0100

> during the plenary session.  I like the idea.  What do others think?

I agree with others' views that validation alone is not very helpful and
some frequently queried for domains' zones should be signed as part of that
experiment.  By IETF74, the IANA (I)TAR might also be available as one
source of TLD trust anchors.
Still that date might be too early to encourage end system validation, so
adding validation and an "interesting" set of TAs to the meeting's recursive
name servers is another option, even if on the WLAN we can't trust the path
between stub and recursive resolver.  However, I'd hope the limited time
did not imply the proponent(s) offered a demonstration during the plenary ...

Central resolvers would also provide for "easy" access to raw data for
statistics purposes.

-Peter

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 27 Nov 2008 10:03:57 -0800

> did not imply the proponent(s) offered a demonstration during the plenary ...

If I understand the thread, so far, there is a current reality that suffers from 
missing too many pieces of necessary DNSSec infrastructure, documentation, maybe 
software, and definitely training.  Without all of these additional pieces, it's 
not reasonable to expect any sort of casual use -- even for "testing".  However 
it might be possible to put enough pieces in place to exercise some interesting 
scenarios.

If the above is anywhere in the vicinity of correct, it would probably be 
helpful to formulate an actual project plan for this, complete with web-site, 
collaboration tools, etc. Absent something organized like this, the likelihood 
of producing anything useful at test-time would, apparently, be at risk.

Or am I misunderstand the disparity between current reality and necessary 
enhancements?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 Nov 2008 14:21:53 -0500

>>>>> "Dave" == Dave CROCKER <[email-masked]> writes:
    Dave> Or am I misunderstand the disparity between current reality
    Dave> and necessary enhancements?

  You are. It's all ready.

  DNSSEC can be done in the plenary by changing the recursive servers.
It's pretty close to being completely apt-get/yum/pkg_add able as being
on.   What's missing is someone to decide what are the set of TAs to
use...

  Go read: http://www.dnssec-deployment.org/

---

From: David Conrad <[email-masked]>
Date: Thu, 27 Nov 2008 11:36:18 -0800

Dave,

On Nov 27, 2008, at 10:03 AM, Dave CROCKER wrote:
> If I understand the thread, so far, there is a current reality that  
> suffers from missing too many pieces of necessary DNSSec  
> infrastructure, documentation, maybe software, and definitely  
> training.  Without all of these additional pieces, it's not  
> reasonable to expect any sort of casual use -- even for "testing".

No.  DNSSEC is in production use today in various places.  It's more  
that no one would notice.  The IETF NOC folks could trivially set up a  
set of DNSSEC-validating caching name servers that would validate any/ 
all signed zones that are covered under the existing trust anchor(s).   
The NOC folks could then configure DHCP/RA to hand out the IP  
addresses for those validating caching name servers to folks who use  
the IETF network.

The problem is that, like most plumbing, this would be entirely  
transparent to the folks using that network.  One of the problems with  
deploying DNSSEC is that there are no standardized APIs that allow  
applications to determine whether or not a name has been validated.   
What's worse, with the standardized APIs, the typical indication of  
validation failure to applications is essentially indistinguishable  
from authoritative server misconfiguration.  Also, since attacks  
DNSSEC protect against are exceedingly rare, it is unlikely there  
would be any actual behavior beyond normal DNS resolution for anyone  
to observe.

However, with that said, I personally believe the IETF network should  
turn on DNSSEC validation in their caching servers and the IETF  
secretariat should sign the IETF-related zones. I can't think of any  
reason why this should not occur at this point.

Regards,
-drc

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Nov 2008 14:52:08 -0500 (EST)

> on.   What's missing is someone to decide what are the set of TAs to

Even that is done with autotrust and dnssec-keys packages. The only
thing that needs to happen is for someone at the distribution to flip
the switch. (dnssec-keys package allows that for Fedora/RHEL machine by
using a simple dnssec-configure command, including DLV support)[*]

The problem is really that there are not many signed zones out there that
are reachable. As I talked at IETF-73 with people such as Roy and Sam, there
is not really any benchmarking one can do. One can benchmark DNS and one
can benchmark crypto, but benchmarking DNSSEC is not the sum of those two.

Without the additional signed zones, the IETF Plenary testing really just
becomes a much smaller version of a bind/unbound test at a large ISP. We'd
be better of asking COMCAST to give a presentation about their experience
enabling DNSSEC on their resolvers.

And I think testing key rollover during the Plenary might be too disturbing
for the plenary itself if it breaks.

Paul
[*] That and hardware crypto acceleration is basically our DNSX Secure
    Resolver appliance due Q1 2009.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Nov 2008 14:54:35 -0500 (EST)

On Thu, 27 Nov 2008, David Conrad wrote:

> However, with that said, I personally believe the IETF network should turn on
> DNSSEC validation in their caching servers and the IETF secretariat should
> sign the IETF-related zones. I can't think of any reason why this should not
> occur at this point.

I agree. And they should push their keys into the ISC DLV, and at IETF enable DLV.

But in general, everyone at IETF to should do this, not just the IETF secretariat.

Paul

---

From: Matthew Ford <[email-masked]>
Date: Thu, 27 Nov 2008 19:49:13 +0000

On 27/11/08 19:36, David Conrad wrote:
>  It's more that no one would notice.

After all the years of FUD surrounding DNSSEC deployment, I feel quite 
strongly that having the IETF do as you suggested and then be able to 
point to 'no discernible impact' on the network would be a significant 
milestone.

Mat

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 27 Nov 2008 21:20:11 +0100

On Nov 27, 2008, at 8:49 PM, Matthew Ford wrote:

>
> After all the years of FUD surrounding DNSSEC deployment, I feel  
> quite strongly that having the IETF do as you suggested and then be  
> able to point to 'no discernible impact' on the network would be a  
> significant milestone.

Data point: IETF65 (Dallas) had a DNSSEC enabled recursive nameserver  
(and, if I recall well, signed reverse zones). No impact noticed  
whatsoever. I wonder how many people actually knew.

--Olaf

---

From: Steve Crocker <[email-masked]>
Date: Thu, 27 Nov 2008 15:52:50 -0500

[As entertainment for the audience, I am sure everyone will enjoy  
seeing my brother and I take opposite sides in this discussion.   
Enjoy ;) ]

I too have been watching this thread but from the vantage of having  
been deeply involved in DNSSEC deployment and, more specifically, as  
one of the people urging deploying DNSSEC at the IETF meetings.  This  

> clients during the plenary session.  I like the idea.  What do  

There was actually considerably more context behind this note, and  
it's perhaps unfortunate the thread has lurched off in a negative  
direction.

I can't speak for the IAOC or others involved in the mechanics, so  
the following is my best understanding -- and also what I recommend  
-- of what's intended.

There are three distinct elements of what's being planned.

1. Signing of the ietf.org zone

2. Providing a DNSSEC-compliant recursive resolver as part of the  
IETF net at the next IETF meeting.

3. An experiment during the plenary.

Russ's note initiated discussion of this last piece without setting  
the context with the first two pieces.  Let me say a few words about  
each piece.

1. Signing ietf.org

Quite a few zones are already signed, and some top level domains,  
Sweden (.SE), Bulgaria (.BG), Peurto Rico (.PR), Brazil (.BR), The  
Czech Republic (.CZ), and .MUSEUM, are in full DNSSEC operation.   
Many of us are running signed zones below the top level, and there is  
already a decision and commitment for the key zones related to the  
IETF to be signed.

Based on the discussions I heard during the last IETF, the plan is to  
sign ietf.org immediately after the parent zone, .ORG, is signed.  I  
would prefer for the signing of ietf.org to be independent of whether  
the parent zone is signed, but that's a separate discussion.  In any  
case, it's my understanding that the people in charge of running  
ietf.org have been tasked with getting it signed.  Once signed, I  
would expect it will stay in operation.  That is, the timing and  
operation of the signed zone don't depend on the IETF meeting and  
have no direct relationship to the meeting's network.

2. Providing a DNSSEC-compliant recursive resolver as part of the  
IETF net at the next IETF meeting.

The other side of the DNSSEC equation is having software that checks  
the signatures.  This is done by a validating resolver, either a  
recursive resolver or the stub resolver.  A handful of organizations,  
notably Telia in Sweden, Comcast, University of California Berkeley,  
and OARC are running DNSSEC-compliant recursive resolvers.  I believe  
the ISPs, Telia and Comcast, are providing these resolvers as  
optional alternatives to the resolvers they regularly run and they  
are not including the addresses of these resolvers in the DHCP  
configuration parameters.  Presumably they will become part of the  
standard DHCP configuration at some future time.

The proposed action for the next IETF meeting is to do the same  
thing.  That is, the IETF network will include a DNSSEC-compliant  
recursive resolver as an additional service which is not included in  
the list of DNS servers returned during the DHCP process.

All of the above should invisible unless the end system explicitly  
invokes the DNSSEC-compliant recursive resolver AND asks for a signed  
response.

3. An experiment during the plenary

I have not been involved in a discussion of this third piece, but I  
presume the intent is to simply include the DNSSEC-compliant  
recursive resolver in the standard DHCP configuration during the  
plenary.  That is, during the plenary, DHCP responses will include  
the DNSSEC-compliant recursive resolver.  Even though the normal DNS  
requests will thus go through the DNSSEC-compliant recursive  
resolver, the end system will see no difference unless the end system  
asks for a a signed response.  I believe Russ was essentially asking  
what people think about this third piece of the plan.  (Apologies,  
Russ, if I have incorrectly channeled you.)

In line with David's note, there are indeed a lot of details to  
cover, including explanatory notes on how end systems need to be  
configured to ask for signed responses. measurements, etc., etc.  All  
normal stuff and all part of what we are more than capable of doing  
all the time.

Steve

On Nov 27, 2008, at 1:03 PM, Dave CROCKER wrote:

> However it might be possible to put enough pieces in place to  
> exercise some interesting scenarios.
>
> If the above is anywhere in the vicinity of correct, it would  
> probably be helpful to formulate an actual project plan for this,  
> complete with web-site, collaboration tools, etc. Absent something  
> organized like this, the likelihood of producing anything useful at  
> test-time would, apparently, be at risk.
>
> Or am I misunderstand the disparity between current reality and  
> necessary enhancements?
>
> d/
> -- 
>
>   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 27 Nov 2008 13:13:20 -0800

Steve Crocker wrote:
> [As entertainment for the audience, I am sure everyone will enjoy seeing 
> my brother and I take opposite sides in this discussion.  Enjoy ;) ]
...
> There are three distinct elements of what's being planned.
...
> Russ's note initiated discussion of this last piece without setting the 
> context with the first two pieces.  Let me say a few words about each 
> piece.
...
> In line with David's note, there are indeed a lot of details to cover, 
> including explanatory notes on how end systems need to be configured to 
> ask for signed responses. measurements, etc., etc.  All normal stuff and 
> all part of what we are more than capable of doing all the time.

Steve, et al,

Damn.  Given your opening, I was hoping for something a little more 
entertaining.  Especially since the only "side" my note was intended to take was 
to observe the stated objections and suggest moving into a project-planning 
mode, so that debate was about concrete details.

What you've done is to agree that there are quite a few details.  As you note, 
the mailing list didn't yet have the context to be aware that, apparently, many 
are already in place.

So I'd class your note as a follow-through of mine, rather than opposing it...

Reference to signing ietf.org suggests that the intent is to limit the 
experiment to operation within the ietf.org domain name.  But since you and 
others have refereed to other branches that are signed, I assume more elaborate 
scenarios are intended to work.

That is, since we know that the full DNS tree isn't signed, I assume that there 
are constraints on the scenarios that can be tested.

What are they?

And in line with your final paragraph, we do need details for the many client 
platforms: linices, windows, and mac platforms... and maybe some of the mobile 
ones, such as WM7, Android, ...?

A quick google for windows dnssec produces no useful points high in the sequence.

d/

-- 

   Dave Crocker

---

From: Lucy Lynch <[email-masked]>
Date: Thu, 27 Nov 2008 13:17:56 -0800 (PST)

As I remember it, the flood in the NOC was much more exciting then
the DNSSEC bits.

- Lucy

--Olaf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 28 Nov 2008 10:44:55 +0100

On Thu, Nov 27, 2008 at 07:49:13PM +0000,
 Matthew Ford <[email-masked]> wrote 

> able to point to 'no discernible impact' on the network would be a

That would prove nothing: failures will DNSSEC do not happen every
day. Signatures expire, people stop signing without telling the parent
zone, keys rolls over, but it may not happen during these few days.

You see the actual problems with DNSSEC (which are *not* FUD) when you
run it every day, for several months. 

<flame>Read the pro-DNSSEC responses to US govermnent's survey
<http://www.ntia.doc.gov/dns/dnssec.html> and see how many of these
people who tell Obama to sign, signed themselves their zone.</flame>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 28 Nov 2008 10:40:44 +0100

On Thu, Nov 27, 2008 at 03:52:50PM -0500,
 Steve Crocker <[email-masked]> wrote 
 a message of 161 lines which said:

> the intent is to simply include the DNSSEC-compliant recursive
> resolver in the standard DHCP configuration during the plenary.
> That is, during the plenary, DHCP responses will include the
> DNSSEC-compliant recursive resolver.  Even though the normal DNS
> resolver, the end system will see no difference unless the end
> system asks for a a signed response.

Hold on, you mean the recursive resolver will NOT validate by default?
If so, this is not an experiment, this is MUCH LESS than what many
people on this list already do every day (having a recursive resolver
which validates even without any specific request).

% dig A futuredate-A.newzsk-ns.test.dnssec-tools.org

; <<>> DiG 9.5.0-P2 <<>> A futuredate-A.newzsk-ns.test.dnssec-tools.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57934

---

From: Bill Manning <[email-masked]>
Date: Fri, 28 Nov 2008 01:48:17 -0800

> invokes the DNSSEC-compliant recursive resolver AND asks for a signed  

	for me, this statement is the crux of the issue.
	it is crucial for there to be signed infrastructure.
	no question about that.  but for what purpose?

	as noted elsewhere in this thread, the IETF network
	has already implemented signed zones in the past (Dallas)
	and actually had an application under test (FreeSwan).

	for those of us who already run DNSSEC validators on our
	local machines, I welcome the idea of a persistent signed
	IETF infrastructure. (e.g. there will not be "the" DNSSEC
	compliant recursive resolver... there will be many of them.

	but that is not the subject of an experiment.

	i beleive that some clarity would be helpful here.
	if the folks in charge would clearly state what the experiment
	is, expected outcome, how the community will be able to 
	gauge the success or failure of the experiment, and future
	actions...  then much of the discussion would disipate or
	shift.

	back to my question - to what purpose?  if all this is 
	invisible to the end-system, of what purpose is the exercise
	of creating signed data?  I think that there should be some
	nod to end-system awareness/impact. And the primary point
	of visability (under the IETF control) is key roll.  at least
	imho.  others will no doubt have their own points. 

	I look forward to more clarification on this proposed experiment.

--bill

---

From: Matthew Ford <[email-masked]>
Date: Fri, 28 Nov 2008 14:28:41 +0000

> run it every day, for several months. 

I said it would be a milestone. I didn't say it was the end of the road.

Mat

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Nov 2008 10:09:16 -0500

Steve,

While I very much appreciate the background, I think the
fundamental point I was trying to make remains unchanged and
part of your response further muddies the waters.

Russ's note suggests DNS-enabled clients.  There is a serious
shortage of those clients for what I believe is still the
most-used operating system platform among IETF participants.

Your note seems to suggest concentrating on caching servers and
full-service resolvers.  I think there are differences in how
various of us have done and interpreted the risk analysis but,
from what I've seen, well-known caching servers (such as ISP
ones) are the most likely targets of attacks.  If they are, then
having DNSSEC verification only to those servers, with client
machines trusting the nearby caching servers without DNSSEC
protection, provides very little protection at all.  Put
differently, if we cannot extend DNSSEC protection and
verification to the desktop, DNSSEC provides very little
marginal security advantage.

As several people have pointed out, effective use of DNSSEC to
the desktop requires sufficient work on APIs and UIs that an
application, or the user, can distinguish between "signed and
validated", "signed but does not validate", and "unsigned".   As
long as verification is performed on the desktop machine (or on
a completely trusted, protected, and user-controlled local-LAN
caching server), it is reasonable for us to take the position
that those interfaces are a problem outside the IETF's scope.
But, as soon as we shift the verification problem to an external
caching server --whether an IETF one or one belonging to an
ISP-- and even if those are trusted, then one needs, not just
APIs but actual pieces of protocol to communicate that
information in an appropriate way.  Without such pieces of
protocol, we put the DNS into the middle of the very worst of
the middlebox problem, with servers not under the user's control
making decisions about whether or not particular strings are
resolved or reported to the user machine as non-existent.   I
have not been following the DNSSEC protocol work closely enough
to be sure, but my impression is that such protocol work has not
even been started, much less concluded and standardized.

With regard to the transparency of all of this to client
machines that don't do their own validation, it rather reminds
me of the distinction made in the stages of drug testing between
"safe" and "effective".  Running DNSSEC-capable caching servers
--whether the ietf.org zone is signed or not-- should be
transparent to non-DNSSEC-aware clients unless there has been a
really major failure in protocol design or implementation.
That would demonstrate "safe", but not "effective".   Perhaps
that is worthwhile, but I think it is a modest goal indeed and
one that has been accomplished many times already.  To
demonstrate "effective", one not only needs signed zones (and,
IMO, zones signed from the root down, not locally-configured
look-aside arrangements which could prove something rather
different), but also needs enough carefully-seeded failure cases
to demonstrate actual protection of client machines from invalid
or hostile DNS records.  

If one were to depend on look-aside mechanisms, then an
experiment to demonstrate effectiveness (and even some aspects
of safety) would need to test interoperability among look-aside
databases, different sequences of testing such databases, etc.  

Any of those things would require very serious experimental
design.  Some would require protocol or other work.  For
example, if some zones are signed via one look-aside database,
others via another, and a few with the relevant keys stored in
several of them, do we need search rules for look-aside
databases and are we confident that the databases themselves,
and the paths to and from them, can be validated or are they
just another potential attack vector?

If all we have in front of us is a general proposal to turn
DNSSEC on during the plenary, plus or minus your note, I think
we might have the potential for a demonstration of "safe", but,
unlike, e.g., the IPv6 experiment, we are no where near showing
"effective".   I'd really like to see a plan that brings us a
lot closer to "effective" and preferably one that more strongly
identifies some of the loose ends that this discussion has
brought out and is used as the basis of initiating IETF work to
get those loose ends tied up.

    john

--On Thursday, 27 November, 2008 15:52 -0500 Steve Crocker
<[email-masked]> wrote:

> [As entertainment for the audience, I am sure everyone will
> enjoy seeing my brother and I take opposite sides in this
> discussion.  Enjoy ;) ]
> 
> I too have been watching this thread but from the vantage of
> having been deeply involved in DNSSEC deployment and, more
> specifically, as one of the people urging deploying DNSSEC at
> the IETF meetings.  This thread began with Russ Housley
> sending a brief message yesterday:
>...

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 28 Nov 2008 10:58:59 -0500

> marginal security advantage.

This doesn't actually follow, because there could be another way to
validate the link between the end host and the validating recursive
resolver.  For instance, we could use TSIG between a non-validating
stub resolver and a validating recursive resolver in order to ensure
that attacks between those two points aren't successful.  If I know I
have the right node doing the validation for me, then attacks against
the ISP's validating recursive resolver require complete takeover of
that machine: by no means impossible, for sure, but a bigger deal than
just spoofing answers to a stub resolver.

That said, I don't want to make light of the end-point problem, since
TSIG between a stub and a recursor isn't a trivial problem today
either.  Moreover, since end nodes in many environments get their
recursor's address(es) via DHCP, and since that path is pretty easy to
compromise, the whole edifice rests on a sandy foundation.
Nevertheless, I just want to be clear that having every end node in
the world doing RFC 4035-and-friends validation is not the only path
to useful DNSSEC.

> validated", "signed but does not validate", and "unsigned".   

Why?  It seems to me that acceptable definitions of "works" and
"doesn't work" in a security-aware context could include "validated or
insecure delegation" and "bogus delegation" respectively.  In my
opinion, any plans that involve users making sensible security
trade-offs due to validation failures will get us right back where we
are with self-signed or expired (or both) certificates for https.  It
seems a perfectly good idea to me that "bogus" means exactly the same
thing as "site off the air".

As a DNS geek, I'd _prefer_ more-intelligent end points with respect
to the DNS.  But I don't buy the argument that they're a necessary
condition for DNSSEC deployment.

> even been started, much less concluded and standardized.

You have exactly two options: allow the recursive server to make the
decisions you seem to dislike -- and I think people who like that
approach think it's a feature, not a bug -- or else to do validation
out at the end nodes.  The end node gets a bit to tell upstream
validators that it is going to do all validation itself, and those
upstream systems are required to pass along all the data necessary for
such validation.  So it's still possible to do everything at the end
node.

This is quite independent of the question of whether applications have
the ability to understand the results from the validator.  I agree
that OS APIs seem to be missing.  I'm not sure that's something the
IETF ought to be solving, but I'd happily entertain arguments either way.

> databases 

My personal reading of the current specifications is that, if you have
at least one path to validation, then validation is supposed to work.
So search rules ought not to be needed.  What the implementations
actually do is currently at variance with my interpretation, however.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Bill Manning <[email-masked]>
Date: Fri, 28 Nov 2008 08:58:19 -0800

> condition for DNSSEC deployment.

	apparently you and john (and me too) do not share a 
	common POV on what is ment by the term, "DNSSEC deployment".

	if I may borrow some phrasing from Steve and put words 
	in your mouth....

	a linked suite of signed zones with the DNSKEY/DS records
	imbedded in the parents zones, all the way to the root zone,
	and or a look aside system where these records are kept
	constitutes DNSSEC deployment.

	end point visability or use of this chain of custody is 
	immaterial to DNSSEC deployment.

	Is that really what you are trying to say?

> actually do is currently at variance with my interpretation, however.

	I think the problem occurs when you have -two- paths to
	validation and the answers conflict.

--bill

-- 
--bill

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 28 Nov 2008 12:28:24 -0500

> 	Is that really what you are trying to say?

Maybe sort of.  My point is that I don't think it's obviously bad if
we have no DNSSEC-aware applications or if end points on the network
start seeing lookup failures due to DNSSEC validation getting a bogus
result, and returning SERVFAIL to the end node.  In one way of looking
at things, people not being able to reach a site _at all_ because it
looks like there is a MiTM attack going on is a step forward.  It
will, however, be at least frustrating.

Immaterial, however, might be going too far, for at least these reasons:

1. DNSSEC-enabled operation is somewhat more fragile than the
operation to which we have become accustomed.  (Note that other tricks
travelling under the guise of additional forgery resilience, changing
the way caches are populated, are also likely to increase that
fragility.)  So we'll see more failures than are actually warranted by
attacks.  That makes me unhappy.

2. Failures of the sort in (1) may mean that people will decide DNSSEC
is too risky, and turn it off.

3.  Overloading SERVFAIL as a response means debugging will be
painful.  It's also ugly, because it takes a response code that used
to mean one thing, and makes it mean two (see other rants about
overloading data types for why I hate this).

The fact is, however, that we're attempting to graft some data
assurances onto a distributed, loosely-cohernet database designed with
extremely naive assumptions about data validity from the network.  If
we want that feature, and we don't want to have to wait until the
entire Internet upgrades its infrastructure, we will have to live with
some very unhappy compromises, while noting that if you replace all
your infrastructure, you get a greater benefit.  That seems to me to
be the only realistic deployment strategy.  And I sure think it's time
we deploy our own stuff: that I couldn't get proper responses from
`dig +dnssec` in Minneapolis is, I think, a serious failure of the
IETF to eat its own dog food.

> 	validation and the answers conflict.

Right, but my _personal_ reading of the RFCs is that they are
perfectly clear on how this is supposed to work.  As it happens, they
don't have a feature that many people seem to want.  Pity that feature
request didn't come in sooner, but I guess we'll have to come up with
something to accommodate it.

A

---

From: Steve Crocker <[email-masked]>
Date: Thu, 27 Nov 2008 13:55:11 -0500

1. Signing ietf.org

Steve

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Nov 2008 12:39:33 -0500

Andrew,

I don't want to stretch this discussion out too much because I
think the point has been made, but a few comments below.

--On Friday, 28 November, 2008 10:58 -0500 Andrew Sullivan
<[email-masked]> wrote:

>> ones) are the most likely targets of attacks.  If they are,
>> then having DNSSEC verification only to those servers, with
>> client machines trusting the nearby caching servers without
>> DNSSEC protection, provides very little protection at all.
>> Put differently, if we cannot extend DNSSEC protection and
> This doesn't actually follow, because there could be another
> way to validate the link between the end host and the
> validating recursive resolver.  For instance, we could use
> TSIG between a non-validating stub resolver and a validating
> recursive resolver in order to ensure that attacks between
> those two points aren't successful.  If I know I have the
> right node doing the validation for me, then attacks against
> the ISP's validating recursive resolver require complete
> takeover of that machine: by no means impossible, for sure,
> but a bigger deal than just spoofing answers to a stub
> resolver.

Sure.  But I suspect that the number of systems that fully
support TSIG that do not support client validation are few.  I'd
be happy to be proven wrong about that.  One could also run the
DNS queries  between stub resolver and validating recursive
resolver over a properly-validated and secured tunnel, but the
number of those isn't huge either.   We could also debate what
is, and isn't difficult -- depending on network topology and
operations quality, it is often much easier and more effective
in practice to mount an attack against a server than against the
network.

> That said, I don't want to make light of the end-point
> problem, since TSIG between a stub and a recursor isn't a
> trivial problem today either.  Moreover, since end nodes in
> many environments get their recursor's address(es) via DHCP,
> and since that path is pretty easy to compromise, the whole
> edifice rests on a sandy foundation.

Exactly.

> Nevertheless, I just want
> to be clear that having every end node in the world doing RFC
> 4035-and-friends validation is not the only path to useful
> DNSSEC.

I would never go so far as to say "only path to useful...".
I'm actually a big believer, in the present environment, in
LAN-local validating caching resolvers.  But that is not a
popular setup, especially for the residential, SOHO, and small
business setups, that are often at the greatest risk.  But,
unless one can either take advantage of special cases or harden
the servers and data paths well past current norms, I don't see
the potential of DNSSEC living up to the expectations and hype
unless one has end node (or at least end-network) validation.

> "doesn't work" in a security-aware context could include
> "validated or insecure delegation" and "bogus delegation"
> respectively.  In my opinion, any plans that involve users
> making sensible security trade-offs due to validation failures
> will get us right back where we are with self-signed or
> expired (or both) certificates for https.  It seems a
> perfectly good idea to me that "bogus" means exactly the same

We are in agreement about end users doing security validation
and decision-making.   But, unless you can deploy DNSSEC, with
signing of all relevant zones, on a flag day basis, the end user
software needs to be able to distinguish between "address
validated with DNNSEC" and "address accepted because no
signatures are present".  Otherwise, one has to treat every
address as equally untrusted and that is more or less equivalent
to DNSSEC not being present.

Whether it is appropriate to treat "failed validation" was
equivalent to "no domain" or "no server response" is a much more
subtle question, one I'm much more comfortable trying to answer
with a signed root and tree than I am with lookaside.

>...
>> the middlebox problem, with servers not under the user's
>> control making decisions about whether or not particular
>> strings are resolved or reported to the user machine as
>> non-existent.   I have not been following the DNSSEC protocol
>> work closely enough to be sure, but my impression is that
>> such protocol work has not even been started, much less
>> concluded and standardized.
> 
> You have exactly two options: allow the recursive server to
> make the decisions you seem to dislike -- and I think people
> who like that approach think it's a feature, not a bug -- or
> else to do validation out at the end nodes.  The end node gets
> a bit to tell upstream validators that it is going to do all
> validation itself, and those upstream systems are required to
> pass along all the data necessary for such validation.  So
> it's still possible to do everything at the end node.

I don't either like or dislike that recursive server model.  I
just think that the quality of security/trust improvement it
provides is questionable given current operational realities
and, perhaps more important, that only a very small number of
successful attacks on such servers that people are depending on
could bring the whole DNSSEC concept into serious disrepute.

> This is quite independent of the question of whether
> applications have the ability to understand the results from
> the validator.  I agree that OS APIs seem to be missing.  I'm
> not sure that's something the IETF ought to be solving, but
> I'd happily entertain arguments either way.

IMO, the dividing line is precisely between doing validation at
the endpoints and doing it somewhere else.  If the answer is
"endpoints", then it is perfectly sensible and consistent with
IETF history to say "local problem".  On the other hand, if
validation is at the caching resolver, then it seems to me that
the model for communicating between the stub resolver and that
system is precisely an IETF problem (again, if only to be sure
that the application can tell the difference between "validated"
and "unsigned".

> My personal reading of the current specifications is that, if
> you have at least one path to validation, then validation is
> supposed to work. So search rules ought not to be needed.
> What the implementations actually do is currently at variance
> with my interpretation, however.

Again, I'm much more concerned about the current operational
practice and how it is evolving than I am about the theory in
the specs.  I know that, in any situation like this, "single
authoritative tree" is a lot easier, and a lot harder for either
a bad guy or carelessness to diddle in subtle ways without being
caught and held accountable, than having multiple arrangements.
And it is quite clear that we don't have that tree today.

To paraphrase Bill, if there are two possible validation paths,
using two different sets of lists on different servers, there is
the possibility of different answers on different paths.  And,
precisely because this mechanism is supposed to provide security
and trust validation, playing "see no evil, hear no evil,
anticipate no evil" with that particular risk is wildly
inappropriate.

I'm in favor of getting things signed just as quickly as that is
feasible -- either from the root down or using look-aside
mechanisms that are, themselves, fully validated and with good
tools for dealing with potential conflicts.   But my reading of
Russ's proposed experiment had to do with demonstrating that
DNSSEC is actually useful in dealing with threats and plausible
attack scenarios, not just demonstrating that one can safely
sign zones and deploy validating software in some places on the
network.  For that demonstration of effectiveness, we are not,
IMO, quite there yet and it is frightening that we are only
having the discussion now (from that point of view, the proposed
experiment has already succeeded because we [finally] are having
the discussion).

    john

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Nov 2008 14:41:33 -0500 (EST)

> the world doing RFC 4035-and-friends validation is not the only path

It's worse. Before you can start validating on your own, or use some
trusted remote TSIG accessable resolver, you are likely to need
to accept some spoofs to get past the hotspot authentication.

Then you need prevent your browser from caching them too much (they
do fastflux protection), and your own potential resolver needs to
dump the answers once it has a real IP link to the real world.

I don't know of any method to both allow hotspot access and fully
use DNSSEC.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Sat, 29 Nov 2008 08:20:30 +1100

In message <[email-masked]>, Paul Wout
> to accept some spoofs to get past the hotspot authentication.

	Which is something the IETF should be providing / promoting
	a standard alternative for.  At present normal protocol
	operations are being hijacked to do this.

	Browsers could then have a "HOTSPOT" button which just looked
	up this information, for example.

	Mark

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Nov 2008 16:50:58 -0500 (EST)

> 	up this information, for example.

I'd be very interested in trying to come up with something for this
within the IETF to standarize hotspot cooperation.

Paul