Subject: Last WG call for draft-ietf-dnsop-root-opreq-02.txt.

From: Lars-Johan Liman <[email-masked]>
Date: Wed, 01 Dec 1999 15:20:16 +0100

Folks,

The author and I think it is time to push
draft-ietf-dnsop-root-opreq-02.txt forward, and I hereby issue a
working group last call.

I suggest requesting from IESG to publish it as a BCP.

If you have any final comments, let's hear them before December 16.

				Best regards,
				  /Liman

---

From: Randy Bush <[email-masked]>
Date: Wed, 01 Dec 1999 07:49:23 -0800

> draft-ietf-dnsop-root-opreq-02.txt

steve bellovin had some comments which have caused an -03 version which i
will be sending in later today.  the changes are minor.

***************
*** 233,242 ****
               as http, telnet, rlogin, ftp, etc.  The only login accounts
               permitted should be for the server administrator(s).
               "Root" or "privileged user" access MUST NOT be permitted
!              except through an intermediate user account.  If remote
!              access is required for administration and maintenance then
!              the login MUST be protected by a secure means that is
!              strongly authenticated and encrypted.
  
         3.2.2 Root name servers SHOULD NOT trust other hosts, except
               secondary servers trusting the primary server, for matters
--- 233,248 ----
               as http, telnet, rlogin, ftp, etc.  The only login accounts
               permitted should be for the server administrator(s).
               "Root" or "privileged user" access MUST NOT be permitted
!              except through an intermediate user account.
! 
!              Servers MUST have a secure mechanism for remote
!              administrative access and maintenance.  Failures happen;
!              given the 24x7 support requirement (per 4.5), there will be
!              times when something breaks badly enough that senior
!              wizards will have to connect remotely.  Remote logins login
!              MUST be protected by a secure means that is strongly
!              authenticated and encrypted, and sites from which remote
!              login is allowed MUST be protected and hardened.
  
         3.2.2 Root name servers SHOULD NOT trust other hosts, except
               secondary servers trusting the primary server, for matters
***************
*** 248,254 ****
         3.2.3 The LAN segment(s) on which a root server is homed MUST NOT
               also home crackable hosts.  I.e. the LAN segments should be
               switched or routed so there is no possibility of
!              masquerading.
  
         3.2.4 The LAN segment(s) on which a root server is homed SHOULD
               be separately firewalled or packet filtered to discourage
--- 254,263 ----
         3.2.3 The LAN segment(s) on which a root server is homed MUST NOT
               also home crackable hosts.  I.e. the LAN segments should be
               switched or routed so there is no possibility of
!              masquerading.  Some LAN switches aren't suitable for
!              security purposes, there have been published attacks on
!              their filtering.  While these can often be prevented by
!              careful configuration, extreme prudence is recommended.
  
         3.2.4 The LAN segment(s) on which a root server is homed SHOULD
               be separately firewalled or packet filtered to discourage
***************
*** 268,289 ****
               attempts, etc.  Servers SHOULD log in GMT to facilitate log
               comparison.
  
         3.2.7 Server logging SHOULD be to separate hosts which SHOULD be
               protected similarly to the root servers themselves.
  
         3.2.8 The server SHOULD be protected from attacks based on source
!              routing.
  
         3.2.9 The network on which the server is homed SHOULD have in-
               addr.arpa service.
  
     3.3 Protocol authentication and security are required to ensure that
         data presented by the root servers are those created by those
         authorized to maintain the root zone data.
--- 277,299 ----
               attempts, etc.  Servers SHOULD log in GMT to facilitate log
               comparison.
  
         3.2.7 Server logging SHOULD be to separate hosts which SHOULD be
               protected similarly to the root servers themselves.
  
         3.2.8 The server SHOULD be protected from attacks based on source
!              routing.  The server MUST NOT rely on address- or name-
!              based authentication.
  
         3.2.9 The network on which the server is homed SHOULD have in-
               addr.arpa service.
  
     3.3 Protocol authentication and security are required to ensure that
         data presented by the root servers are those created by those
         authorized to maintain the root zone data.
***************
*** 300,306 ****
               when supported.
  
         3.3.3 Transfer of the root zone between root servers MUST be
!              authenticated and be as secure as reasonably possible.
               Servers MUST use DNSSEC to authenticate root zones received
               from other servers.  It is understood that DNSSEC is not
               yet deployable on some common platforms, but will be
--- 310,317 ----
               when supported.
  
         3.3.3 Transfer of the root zone between root servers MUST be
!              authenticated and be as secure as reasonably possible.  Out
!              of band security validation of updates MUST be supported.
               Servers MUST use DNSSEC to authenticate root zones received
               from other servers.  It is understood that DNSSEC is not
               yet deployable on some common platforms, but will be
***************
*** 422,428 ****
     Singel 258
     NL-1016-AB Amsterdam
     Netherlands
!    EMail: [email-masked]
  
     Mark Kosters
     Network Solutions
--- 432,438 ----
     Singel 258
     NL-1016-AB Amsterdam
     Netherlands
!    EMail: [email-masked]
  
     Mark Kosters
     Network Solutions
***************

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 02 Dec 1999 10:19:23 +0100

>!              of band security validation of updates MUST be supported.

I don't understand what the second sentence means, which may mean that I 
didn't listen carefully enough, or that another sentence is needed.

I assume that "Update" in this context means copying a changed version of 
the root zone from one root server to another, since the actual changing of 
the root zone is not dealt with in this paragraph.

I assume also that "out of band" means "by means not part of the Update 
transaction itself". Does this mean that signed AXFR or FTP transfer of PGP 
signature files is not enough?
(If not, what is?)

Or does it mean that signed files with out of band exchange of keys 
(exchange of document cases at midnight) is the Right Thing?

(I found the rest of the changes to be really sensible and informative, BTW)

                        Harald
                       ignorant
--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Thu, 02 Dec 1999 03:03:24 -0800

> I don't understand what the second sentence means

that an operator should be able to verify that the updated data they have
received is authentic data by means of an information channel separate from
the one by which they received it.

an example might be to be able to request a fax of an md5 checksum of the
root zone.

randy

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 02 Dec 1999 23:40:58 +0100

>an example might be to be able to request a fax of an md5 checksum of the

oh - I see.
Suggested replacement language:

"An operator of a root zone server MUST be able to get proof of the 
correctness of a zone file from the authority responsible for updating it 
by means not involving DNS operations, for example by telephone, fax, 
signed email with a trusted signature or other means".

Never hurts to be explicit....except that the document gets long.....

                               Harald A

---

From: Randy Bush <[email-masked]>
Date: Thu, 02 Dec 1999 15:28:01 -0800

> signed email with a trusted signature or other means".

the target audience is not non-operators.  that would make the document 200
pages.  <g>

randy

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 3 Dec 99 9:22:26 JST

Harald;

> signed email with a trusted signature or other means".

No.

You are saying that telephone and fax were more serure than unsigned
email.

							Masataka Ohta

---

From: [email-masked]
Date: Thu, 2 Dec 1999 19:50:57 -0500 (EST)

> You are saying that telephone and fax were more serure than unsigned

Telephone is secure only in it's billing, and fax is only as secure
as telephony. Caller-ID and other signal messaging functions are
also not guaranteed.

Anyone could call or fax and say they are someone that they 
are not.

I think this is a little vague for a security measure.

-M

---

From: Kent Crispin <[email-masked]>
Date: Thu, 2 Dec 1999 17:56:14 -0800

> I think this is a little vague for a security measure.

Yes, it is vague, but that's the way it is.  "Security" isn't exactly
the characteristic being looked for in any case.  "Authenticity" gets
it a little better.  Obviously, a telephone conversation with someone
you know personally gives you *far* more assurance than an unsigned
email from that same person. 

-- 
Kent Crispin                               "Do good, and you'll be
[email-masked]                           lonesome." -- Mark Twain

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 3 Dec 99 11:24:03 JST

Kent;

> email from that same person. 

Your wrong assumption is that operators always have personal relationship
between them.

With such an assumption, email conversation works almost as good as
phone one (though it takes longer to exchange several mails).

						Masataka Ohta

---

From: Kent Crispin <[email-masked]>
Date: Thu, 2 Dec 1999 19:20:08 -0800

> Your wrong assumption is that operators always have personal relationship

There is no such assumption implied by my words.  In fact I made no
claims whatsoever concerning whether operators know each other.  The
meaning of my statement was: IF the operators know each other, THEN a
telephone call gives better assurance. 

> phone one (though it takes longer to exchange several mails).

With such an assumption unathenticated email is nowhere near as
assured -- email allows a man in the middle who can intercept and edit 
the messages; practically speaking, telephone does not.

Kent->MITM: "the md5 is X"

MITM->Masataka: "the md5 is Y"

Surrounding that bit of crucial information with all kinds of
personal information that is passed unobstructed won't help.  The
only thing that would help is if you actually used some form of
informal crypto.

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 02 Dec 1999 22:53:08 -0500

I believe that experience indicates that confirmation via independent
transmission routes, even if each is "insecure", substantially
increates reliablity of the result over a single insecure
transmission.

Donald

From:  [email-masked]
Message-Id:  <[email-masked]>
To:  [email-masked] (Masataka Ohta)
Date:  Thu, 2 Dec 1999 19:50:57 -0500 (EST)
Cc:  [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To:  <[email-masked]> from "Masataka Ohta"
 at Dec 3, 99 09:22:26 am

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 3 Dec 99 13:45:33 JST

Kent;

> telephone call gives better assurance. 

FYI, "IF" is a phrase to introduce an assumption.

Note also that Harald's paragraph does not have such an assumption.

> the messages; practically speaking, telephone does not.

As I noted, it is merely an issue of timing. Man in te middle can
replace spoken MD5 numbers something else, if he can react quickly
enough.

> only thing that would help is if you actually used some form of

That is, the assumption you introduced: "IF the operators know each
other", is not very useful.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 3 Dec 99 13:57:53 JST

Donald;

> increates reliablity of the result over a single insecure

Yes. Harald could have said just "email", instead of giving false
impression that unsigned emails are less secure than telephone
or fax.

							Masataka Ohta

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 05 Dec 1999 16:36:46 +0100

> > >> > signed email with a trusted signature or other means".

All I was trying to do was to make what the document said clear.

We already have the document saying that such a communications channel is a 
MUST requirement.

If we want the document to require a cryptographically secured non-DNS 
channel for verifying the content of a root zone file, and the only one we 
can think of at the moment is signed email with preverified keys, we'd 
better make sure the document says exactly that.

If we don't want the document to require that, we'd better put in language 
that says that this isn't required.

Otherwise we'll be back over this issue in 6 months' time.

                  Harald A

---

From: Randy Bush <[email-masked]>
Date: Sun, 05 Dec 1999 09:11:44 -0800

> that says that this isn't required.

the document makes the leap of presuming the root server operators are
competent operations folk.  it mandates that they have an oob channel by
which they can verify the content of the file.  there are many possible
and reasonable ways to do this.  mandating which one would be ephemeral
and unnecessary.

randy

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 05 Dec 1999 22:26:37 +0100

>and reasonable ways to do this.  mandating which one would be ephemeral

point taken - I guess the concept "out of band channel" is well enough 
understood by the operator crowd not to need further clarification, then.

and of course, the decision on this is ultimately taken by the people 
responsible for the master root name server, unlike most of the rest of the 
doc, where all the root name server operators have to make decisions.

The OOB channel will be what it will be.

                  Harald

---

From: Randy Bush <[email-masked]>
Date: Sun, 05 Dec 1999 14:09:31 -0800

> responsible for the master root name server, unlike most of the rest of
> the doc, where all the root name server operators have to make decisions.

actually, i could easily see different operators using different oob
channels, a paranoid operator using more than one channel, ...

but yes, the draft wording assumes operators have a general concept of 'out
of band' data exchange.  i just feared wording such as "a method other than
those of the dns protocols, e.g. axfr, ixfr, etc." was as much, or more, of
a rathole as assuming "oob" was an understood term.

i probably am forgetting something significant in some relevant document,
but how is end of line encoded in a zone file?  if one is to compare hashes,
either the hash must ignore line ends (which might offer a security
vulnerability) or there must be a common understanding of the value of a
line end.

randy

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 05 Dec 1999 23:42:47 +0100

>vulnerability) or there must be a common understanding of the value of a

If using email, I'd suggest sending a complete zone file and signing it.
Sidesteps the issue by pushing it down to the MIME level.

Apart from that, see the Content-MD5 RFC (RFC 1864) for some discussion and 
a possible way to do it (mandate CRLF *for calculating the checksum*).

                             Harald

---

From: Randy Bush <[email-masked]>
Date: Sun, 05 Dec 1999 14:56:54 -0800

> Sidesteps the issue by pushing it down to the MIME level.

the problem is that i am comparing the hash of the emailed zone file with
the hash of the zone file as stored on my system.

> Apart from that, see the Content-MD5 RFC (RFC 1864) for some discussion
> and a possible way to do it (mandate CRLF *for calculating the checksum*).

this is what i expected to find, a canonic representation of line ends in a
zone file in an axfr, in 1034-5.  i did not find it.

randy

---

From: [email-masked]
Date: Mon, 06 Dec 1999 11:29:24 +1100

> zone file in an axfr, in 1034-5.  i did not find it.

	The master file format doesn't need to know how end of line is
	represented.  It just needs to know where it is.

	All this however is irrelevent to verifing you have a valid root
	zone, specially when it has been AXFR'd.  

	Comparing straight md5 checksums of what BIND has written to disk
	with the original master zone file will never work.  What is
	needed is a tool that takes a master zone file, make it cannonical
	and then produces (several different) checksums.

	What we care about is that the data had remained in tact.  Not
	whether we used one or two spaces between fields, or whether 
	case has been preserved in domainnames.

	Mark
--
Mark Andrews, Internet Engines Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 6 Dec 99 9:38:24 JST

Randy;

> a rathole as assuming "oob" was an understood term.

Such wording is meaningless rather than a rathole, because the DNS protocol 
allows any method for in-band zone transfer.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 6 Dec 99 9:45:33 JST

Harald;

> better make sure the document says exactly that.

Be consistent.

Or, are you saying phone or fax, which you mentioned with signed email,
cryptographically secured?

Wiesel wording is not effective on me.

							Masataka Ohta

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 06 Dec 1999 08:09:35 +0100

>Wiesel wording is not effective on me.

I have not stated the security characteristics of email, fax or phone.
Merely that they are out of band from the DNS transfer.

My personal opinion is that an attacker who has managed to damage a zone 
transfer is more likely to be able to damage your unsigned email than to be 
able to damage your phone conversations.

That does not make an ordinary phone "secure" in a cryptographic sense.

I'll stop replying to your mails on this subject now, Ohta.

                          Harald A

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 8 Dec 99 20:39:01 JST

Harald;

> I have not stated the security characteristics of email, fax or phone.

Right. You effectively have stated nothing meaningful.

> That does not make an ordinary phone "secure" in a cryptographic sense.

Thank you for another meaningless statement.

> I'll stop replying to your mails on this subject now, Ohta.

That's your problem.

							Masataka Ohta

---

From: Edward Lewis <[email-masked]>
Date: Fri, 10 Dec 1999 10:44:07 -0500

>If you have any final comments, let's hear them before December 16.

After reading the -03 draft, I think the document is fine as is.  Refining
any point in the document would defeat its generality.

Count this as a hummm for sending the document onward.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda

Opinions expressed are property of my evil twin, not my employer.