Subject: Re: Addition for Section 11

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 04 Oct 2002 11:34:11 -0500

Jeffrey Altman wrote:
> 
> Doug:
> 
> We are well aware of this attack. 

I know, as you stated this in the <draft-ietf-krb-wg-krb-dns-locate-03.txt>
which I included in my note. 

> Hoewver, the reality is that in an
> environment in which you do not have the ability to securely
> distribute host to realm mappings, the only way to distribute this
> information is via DNS.

The considerations section of the Clarifications is there to spell out these
risks so a site can decide for itself if it can live with it. Even if there
was no <draft-ietf-krb-wg-krb-dns-locate-03.txt> the Clarifications should
include this concern, as  the concern is not just DNS, but any untrusted
source for the mapping.   

The risk from this will rise as we start to move toward larger communities 
of realms with cross realm trust, the level of trust between individual realms 
may vary greatly, and situations like I described may be come more common.   
PKCROSS may make it even worse as cross realm will be easier. 

> 
> In order for the attack to succeed, the B Realm KDC must either meet
> one of the following two conditions:
> 
>  . The B KDC is owned by the attacker and the attacker knows the
>    end user's password
> 
>  . The B realm is trusted by the A realm and has been compromised
>    by the attacker.
> 
> These are risks that many people are willing to take because the cost
> of distributing host to realm information is simply too high.  This is
> the reason we published the KRB DNS SRV draft in the first place.
> 
> The reason that REALM to KDC mapping info is in clarifications but
> HOST to REALM is not is because most people are not comfortable with
> the HOST to REALM mappings and we do not have consensus on it.

Correct, so we should state in Clarification that there ia a risk of using
untrusted external services like DNS.
 
> 
>  - Jeff
> 
> > On the way home, after thinking about the cross realm trust discussion we
> > had at the meeting, we should consider adding a consideration about determining
> > the realm of a host as well. Suggested wording is:
> >
> > Implementations of Kerberos must not use untrusted DNS to determine the
> > realm of a host. Such use would allow a compromise of the DNS to result
> > in a client obtaining the wrong realm and the wrong address for the host.
> > Thus allowing one to steer the user to a trojan host in the wrong realm.
> >
> >
> > A possible exploit: Consider realms A and B with B being the high school.
> > Cross realm is setup between them. User U@A visits high school with laptop
> > and uses High school DNS maybe via DHCP. U wants to contact host H which is
> > officially in realm A, but B's DNS says its in realm B at a new address.
> > User then gets ticket for H@B, and logs on, and forwards ticket. The
> > students now have Users ticket. Students could even make H@B a
> > man-in-the-middle using forwarded ticket to log user in to real H@A.
> > User may not notice the realm is wrong in the cache. (If there are many
> > realms participating, it would be even harder for the user to notice
> > the wrong realm.)
> >
> >
> > <draft-ietf-krb-wg-krb-dns-locate-03.txt> does state this as an attack:
> >
> >    However, when cross-realm
> >    trusts are used it is possible to redirect a client to use a comprom-
> >    ised realm.
> >
> >    What this implies is that it is possible to cause a client to be
> >    authenticated to a host other than the one desired by the end user.
> >    In a single realm scenario a spoofed DNS response can cause a client
> >    to be redirected to an attacker's host, but the authentication would
> >    fail.  However, in the cross-realm scenario an attacker who has
> >    administrative control over a realm that has a cross-realm trust
> >    established with the local realm, the attacker can redirect the
> >    client to a host for which valid credentials would be issued by the
> >    attacker's KDC.  Since the credentials are valid there are no authen-
> >    tication failures and the client believes they are connected to the
> >    desired host.
> >
> > --
> >
> >  Douglas E. Engert  <[email-masked]>
> >  Argonne National Laboratory
> >  9700 South Cass Avenue
> >  Argonne, Illinois  60439
> >  (630) 252-5444
> >
> 
>  Jeffrey Altman * Sr.Software Designer     Kermit 95 2.0 GUI available now!!!
>  The Kermit Project @ Columbia University  SSH, Secure Telnet, Secure FTP, HTTP
>  http://www.kermit-project.org/            Secured with MIT Kerberos, SRP, and
>  [email-masked]               OpenSSL.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 4 Oct 2002 13:32:01 -0400 (EDT)

> >  . The B realm is trusted by the A realm and has been compromised

Let's phrase this differently.  BOTH of the following must be true:

- The B KDC is owned or has been compromised by the attacker.
- The attacker knows the end-user's password, or the A and B realms have
  exchanged keys for cross-realm authentication.  Please keep in mind
  that key exchange does _NOT_ imply trust.

> > the HOST to REALM mappings and we do not have consensus on it.

The realm-to-KDC mapping described in clarifications is subject at worst
to a denial of service attack, which would be possible at the IP layer
even without using DNS to find KDC's.  This is because the user shares
with the KDC a secret unknown to the attacker.

The reason people are "uncomfortable" with the host-to-realm mapping is
because it is insecure -- it is easy for an attacker to trick you into
authenticating with the wrong realm.  In some environments, or with
DNSSEC, people may feel that the benefits outweigh the risks (note that
even with DNSSEC there may be risks, as the DNS operator may be an idiot).
Thus, the draft describing the mechanism is not inappropriate, but it
shouldn't be (and isn't) in clarifications.

> untrusted external services like DNS.

I agree -- we should state that there is a risk, using text similar to the
first paragraph of what Doug proposed.  I don't feel it's necessary in
clarifications to describe the attack in detail, though it might be
appropriate to do so in the DNS draft, in the context of a more in-depth
discussion of the risks and benefits intended to educate people trying to
decide whether to use DNS-based host-to-realm mappings.

-- Jeff

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 04 Oct 2002 13:22:32 -0500

> decide whether to use DNS-based host-to-realm mappings.

I only meant the one paragraph to be in clarifications. And maybe it should read
something like: 

Implementations of Kerberos should not use untrusted directory services to locate
the realm of a host. Such use would allow a compromise of the directory service 
or response from the directory service to result in a client obtaining the wrong 
realm for the host. Thus allowing one to redirect the user to a trojan host in 
the wrong realm.

--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Oct 2002 11:47:46 -0700 (PDT)

> realm for the host. Thus allowing one to redirect the user to a trojan host in 

   In order to achieve this hijacking, the client would
   need to have a relationship with the KDC in some
   way, lest mutual auth fail. To my mind, this is much
   more likely to lead to a DoS attack rather than a
   bogus redirection attack. There's a fair amount of
   appeal for configurationless bootstrapping and not
   requiring DNS+PKI. Accepting this risk doesn't seem
   entirely unreasonable to me.

	    Mike

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Oct 2002 15:18:45 -0400

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:

    Michael>    In order to achieve this hijacking, the client would
    Michael> need to have a relationship with the KDC in some way,
    Michael> lest mutual auth fail. To my mind, this is much more
    Michael> likely to lead to a DoS attack rather than a bogus
    Michael> redirection attack. There's a fair amount of appeal for
    Michael> configurationless bootstrapping and not requiring
    Michael> DNS+PKI. Accepting this risk doesn't seem entirely
    Michael> unreasonable to me.

There are a lot of realms out there that will exchange cross-realm
keys (which I cannot stress enough imply no trust what soever) with
anyone at their users' convenience.  I.E. if I'm working on a project
and want to put a user on an ACL, I can get a cross realm key set up
with that user's realm.

We're hoping this will become even more common as pkcross is deployed.

In my mind, the risk is fairly clearly unacceptable.  That said, I do
not believe we will reach consensus on this issue as we have failed to
do so in the past.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Oct 2002 12:27:06 -0700 (PDT)

> and want to put a user on an ACL, I can get a cross realm key set up

   Except... the client still talks to local KDC
   since it doesn't have a relationship with the
   cross realm KDC's. However, if you're implying
   that KDC's shouldn't trust DNS responses for
   realm information, I can understand that
   argument.

	Mike

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 7 Oct 2002 15:06:37 -0400 (EDT)

>    way, lest mutual auth fail. To my mind, this is much

Yes, it would.  Such as a cross-realm relationship, which is becoming more
common and will become even more common with PKCROSS.  The existence of a
cross-realm relationship does not imply trust, so any argument based on an
assuption that untrusted attackers will not have a relationship with the
client's real KDC that allows them to authenticate as some service is
flawed.

>    entirely unreasonable to me.

The redirection attack is considerably more serious than a simple DoS; it
represents the ability of an unknown attacker to hijack a connection
without the client's knowledge, and thereby potentially obtain sensitive
information from the client, such as passwords, or deny access to a
service in such a way that the client does not know it has happened.

Automatic configuration is great, but one must be very careful when
sacrificing security in the name of expedience, especially on behalf of
customers and users who lack the knowledge and expertise to make an
informed decision.  Worse, it's not even necessary in this case -- it is
possible to envision a world in which clients can function without local
host->realm mapping configuration, by accepting authenticated cross-realm
referrals from the "local" (to the user) KDC.  We already have a working
group concensus _not_ to include this new feature in clarifications, but
it is likely to appear in kerberos-extensions.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 7 Oct 2002 15:44:43 -0400 (EDT)

>    realm information, I can understand that

That's correct; the KDC should not trust insecure DNS responses for realm
information.  But neither should clients -- if as an attacker I can make
you think that the right realm for host foo.example.com is BLACKHAT.ORG,
then you will request a host/[email-masked] ticket, and
proceed to use it to try to talk to foo.example.com, which connection I
can now intercept without notice.  Note that in the most common scenario,
you won't ask your KDC for that ticket -- you'll ask for a cross-realm TGT
krbtgt/[email-masked], which you'll then present to _my_ KDC to
request a service ticket.  So your KDC doesn't even get to look at your
request and warn you of the attack.

For this reason, the client should never depend on insecure DNS for
host->realm mappings.  Instead, it should rely on local configuration, or
authenticated cross-realm referrals from its own KDC, or even properly
secured DNS.

While the content of the document is a result of group concensus, the
realities of the situation are a matter of fact, not opinion.  The simple
fact is:  "IF you depend on an untrusted source such as insecure DNS for
host->realm mappings, THEN you are vulnerable to a redirection attack of
the form described above."

In my opinion, we have an obligation, both as security protocol designers
and under the IESG mandate that all standards-track documents discuss
security considerations, to point out this fact so that potential users of
the protocol do not inadvertently leave themselves vulnerable to this
attack.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Oct 2002 12:55:50 -0700 (PDT)

> request and warn you of the attack.

   Uh, how exactly did we mutually authenticate in step 2?
   I can maybe see the attack with PKINIT, but this seems
   pretty far fetched with symmetric key Kerberos. Even
   with PKINIT, BLACKHAT would still need to be named
   in the same rooted space as what the client trusts. If
   we had pervasive PKI's with very few roots, I guess this
   could be problem, but we don't, and it seems easy enough
   to work around anyway.

   To my mind, all this really says is complete
   PNP is incompatible with strong
   authentication. Film at 11 and all of that.

		   Mike

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 07 Oct 2002 15:55:27 -0400

>client's real KDC that allows them to authenticate as some service is

While _I_ understand that, I deal with a large number of people who
will only cross-realm with other sites after they have exchanged a
Memoramdum of Understanding, or some equivalant Official Document
saying that they're going to cross-realm, our KDCs meet some minimum
level of security, and we won't do anything bad to each other.  While I
have repeatedly told those sites that cross-realm does not imply any
trust, their position is there is no way anyone could attack them via
cross-realm if there IS no cross-realm, and that's the way it's going
to stay unless there's a strong need otherwise ("strong" meaning
millions of dollars of funding are at stake).  Obviously, these sites
would never participate in PKCROSS, no way, no how.

The issue here is that whether or not to cross-realm with another site
is not always a technical one; it is many times a political one, and
thus technical arguments do not always apply.

--Ken

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 07 Oct 2002 15:58:11 -0400

>the protocol do not inadvertently leave themselves vulnerable to this

We're in violent agreement here, aren't we?  I mean, I was one of the
people who thought up this crazy scheme, and _I_ think we should include
a detailed warning explaining the vulnerabilies you can encounter when
using this protocol.  Is anyone saying that we shouldn't?

--Ken

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 07 Oct 2002 15:19:25 -0500

> using this protocol.  Is anyone saying that we shouldn't?

I agree, we need the warning. Others can then choose to accept the risk, or
to take steps to cut thier risks. That is the point of the Section 11.

--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Oct 2002 13:28:54 -0700 (PDT)

> client's real KDC that allows them to authenticate as some service is

   Sure, but I wasn't arguing that point. There's
   no reason to expect a KDC to need/want autoconf.
   In fact, that would probably be a pretty stupid
   thing to do. But an autoconf client probably only
   trusts a small set of namespaces and it seems
   fairly easy to structure the namespace such
   that it's fairly unlikely that an attacking KDC
   would be part of it. Case in point, Packetcable 
   uses a rooted namespace which Cablelabs
   owns. The namespace for the KDC's is limited
   to cable operators. While it's *possible* that
   an unscrupulous MSO might play BLACKHAT, it
   seems pretty unlikely and easy to detect. As
   such, even where there are possible cross-realm
   issues with a shared namespace it seems to me
   that risk can be mitigated to a large degree.
   And this problem basically goes away when the
   trusted namespace is localized (eg, attackers
   shouldn't be enrolled anyway).

 > it is likely to appear in kerberos-extensions.

   Well, we also have to keep in mind the state
   of authentication infrastructure that is really
   out there too. As in, pathetically little. Placing
   the bar too high when there's reasonable risk
   mitigation does not move us forward; it
   propogates the status quo.

       Mike

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Oct 2002 16:43:32 -0400

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:

    Michael>    Uh, how exactly did we mutually authenticate in step
    Michael> 2?  I can maybe see the attack with PKINIT, but this
    Michael> seems pretty far fetched with symmetric key
    Michael> Kerberos. 

You attempt to connect to bar.example.com.  I spoof your DNS response,
giving you an A record for bar.blackhat.org and telling you that
bar.example.com is in the BLACKHAT.ORG realm.

bar.blackhat.org is a special machine that has a key for
host/[email-masked].

You request krbtgt/[email-masked] from the EXAMPLE.COM kdc;
since the sysadmins at example.com sometimes get exploits uploaded by
people at BLACKHAT.ORG they set up a cross-realm key for secure ftp.

So, you get that ticket and then request
host/[email-masked] from the BLACKHAT.ORG KDCs; since
you have a valid TGT, you get that ticket as well.

Now, you try to authenticate to bar.blackhat.org using the
host/[email-masked] ticket you have.  That host
conveniently has the key iand is happy to pretend to be
host/[email-masked] so mutual auth is successful.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 7 Oct 2002 17:24:01 -0400 (EDT)

On Mon, 7 Oct 2002, Michael Thomas wrote:

>    I must be completely dense here, but how did my
>    client come to share a key with BLACKHAT's KDC?
>    For that matter, my client would use the key
>    for EXAMPLE.COM's KDC, not BLACKHAT's, so the
>    only way to have BLACKHAT issue a TGT directly
>    is to have the client's EXAMPLE.COM key.
>
>    I must be missing something here. Is this *explicitly*
>    related to a cross realm exploit?

Yes.  Your _client_ doesn't share a key with BLACKHAT.ORG; the EXAMPLE.COM
KDC does.  (particularly, the key for krbtgt/[email-masked]).
This shared key enables cross-realm authentication whereby a client
principal in EXAMPLE.COM, such as [email-masked], can authenticate to a
service in another realm, like host/[email-masked].  This
shared key (or the use of PKCROSS) provides the ability to authenticate to
services in the other realm, but does not imply any form of trust or
authorization.

The attack we're talking about is part of a class of attacks whereby an
attacker convinces you to authenticate to the wrong service, where the
attacker knows the key for the wrong service but not for the legitimate
one.  In this particular case, the attacker convinces you to authenticate
to a service that differs from the correct one only in the realm name, by
spoofing DNS-based host-to-realm mappings to convince you that the service
belongs in a realm whose KDC the attacker controls, rather than in the
service's real realm (which may or may not be the same as the client's
realm).  The solution is to either know the host-to-realm mappings
yourself (i.e. local configuration from a trusted source), or to only
trust mappings that result from authenticated cross-realm referrals given
by your KDC (again, this is a feature not present in clarifications).

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Oct 2002 18:01:58 -0400

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:

    Michael>    Sure, but I wasn't arguing that point. There's no
    Michael> reason to expect a KDC to need/want autoconf.  In fact,
    Michael> that would probably be a pretty stupid thing to do. But
    Michael> an autoconf client probably only trusts a small set of
    Michael> namespaces and it seems fairly easy to structure the
Kerberos does not have a concept of namespace, especially not a
concept of rooted namespace.  Can you please rephrase your argument in
terms of the protocol under discussion?  I think we're all confusing
each other by using different terms.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Oct 2002 15:06:11 -0700 (PDT)

> each other by using different terms.

   I was talking specifically about an attack
   against a PKI based namespace where there
   really are roots. Sorry for the confusion.

	  Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Oct 2002 14:09:08 -0700 (PDT)

Mike

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Oct 2002 17:26:05 -0400

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:

    Michael>    I must be completely dense here, but how did my client
    Michael> come to share a key with BLACKHAT's KDC?  For that
    Michael> matter, my client would use the key for EXAMPLE.COM's
    Michael> KDC, not BLACKHAT's, so the only way to have BLACKHAT
    Michael> issue a TGT directly is to have the client's EXAMPLE.COM
    Michael> key.

Well, your client started with a ticket for
krbtgt/[email-masked] and used that ticket to obtain
krbtgt/[email-masked],allowing you to authenticate to
BLACKHAT.ORG services.

Yes, Kerberos implementations do support this; it is called
cross-realm authentication, your client will do it and it is an
important part of the protocol.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Oct 2002 15:24:14 -0700 (PDT)

Jeffrey Hutzelman writes:
 > KDC does.

   OK, I see where my confusion comes from. I think
   I agree for the most part with Ken's comments
   re: politics. As such I think that MUST NOT is
   definitely overboard, and that an unconditional
   SHOULD NOT might be a little too strong as it
   implies that out of band trust (eg MOU's) is
   still pretty suspect. I find that a little 
   presumptuous.

	Mike

---

From: "Tim Bass" <[email-masked]>
Date: Mon, 7 Oct 2002 19:13:28 -0400

This is a good discussion; I agree with the comments that
there seems to be confusion between discussing the Kerberos protocol
and use of DNS to acquire public keys.   In my simple "lurking in
the background of the WG" mind I agree that there is unacceptable
risk in using public DNS for any cross-realm trust relationships
(i.e. to share keys for cross-domain trust).

Cross-domain trust should be established by POLICY and the sharing
of keys based on a trusted administrative procedure(s).  (certainly
not DNS !!  yikes!!)  

It concerns me that we might be damaging the public's confidence
in Kerberos (and some very large orgs are moving to Kerberos for 
cross-realm authentication) if our technical mavins attempt to use
PKI and DNS in ways that harm the 'perception of trust' of the
Kerberos protocol.

Our clients are using PKI for authenticating users at their workstation
with PKI-based smartcards and then using proxied Kerberos cross realm
authentication do to the back-office 'heavy lifting'.  I would advise
them strongly NOT to use PKI to establish cross-realm trust, but to
rely on a proven and traceable administrative process to share secrets 
between KDCs.

In retrospect, my comments seem to amplify the thoughts of an early
WG voice in this thread.   Time to go back to the background and mutate
into a WG wallflower again :)

Finest Regards, Tim
www.silkroad.com

---

From: Matt Crawford <[email-masked]>
Date: Tue, 08 Oct 2002 08:59:36 -0500

>    client come to share a key with BLACKHAT's KDC?

Your own EXAMPLE.COM KDC gave it to you, and you gave the other copy
to BLACKHAT.ORG in the cross-realm TGT you presented when you asked
it for the host/[email-masked] service cred.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 Oct 2002 15:42:57 -0400

>>>>> "Tim" == Tim Bass <[email-masked]> writes:

    Tim> This is a good discussion; I agree with the comments that
    Tim> there seems to be confusion between discussing the Kerberos
    Tim> protocol and use of DNS to acquire public keys.  In my simple
    Tim> "lurking in the background of the WG" mind I agree that there
    Tim> is unacceptable risk in using public DNS for any cross-realm
    Tim> trust relationships (i.e. to share keys for cross-domain
    Tim> trust).

    Tim> Cross-domain trust should be established by POLICY and the

You keep using this word trust in association with the compound
cross-domain.  It's important to realize that the only trust involved
in setting up a cross-realm key is trust that the key is a secret and
is known by the two KDCs, is secret (not known by third parties) and
that the realm's names correspond to the entities implied by their
names (and thus the right KDCs know the key).

No additional trust is required until you actually put a foreign realm
principal on an ACL.  At that point, you need to trust that the
administrative staff of the foreign realm will not print tickets for
that principal except in accordance with the wishes of that principal.
You also need to trust that the name of the principal actually
corresponds with the entity with whom you wish to authenticate, which
may or may not involve trust of the foreign realm's administrators.

---

From: "Tim Bass" <[email-masked]>
Date: Tue, 8 Oct 2002 16:12:12 -0400

Yes, .... understand the technical aspects of a shared secret
key between two KDCs and how that establishes an authentication
cryptographic service.

"Trust" between domains, however, is a more complex (and comprehensive)
than the (simple) technical act of cryptographic authentication.   Trust

is established via an auditable trail of administrative processes that 
*lead* to the technical act of authentication (and the proper technical
execution of the process itself, in this case KV5 cross-realm
authentication.

It seems appropriate that since this thread was discussing mechanisms
that are a superset of cryptographic systems (PKI, KV5, DNS, etc.) that
the term "trust" is also used in context of a broader architectural
view.  (We also added common access cards and smart cards into the 
conceptual component mix.)

I agree that if the discussion was focused on only KV5 protocols, then
the narrow use of the term "trust" in context to how KV5 establishes
trust (as described in reply) is correct. 

On the other foot, my glimpse into this thread concluded that the
discussion
was germane to a larger architectural view, including the cooperative
interaction between KV5, DNS, PKI and other components; and in this
context, "trust" is established outside the genre of KV5, per se.

Hope this reply helps clarify my thoughts and also why the Pumpkin
turned
into Cinderella :) 

Finest Regards, Tim
www.silkroad.com

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Tuesday, October 08, 2002 3:43 PM
To: [email-masked]
Cc: 'Kerberos WG'
Subject: Re: Addition for Section 11

You keep using this word trust in association with the compound
cross-domain.  It's important to realize that the only trust involved in
setting up a cross-realm key is trust that the key is a secret and is
known by the two KDCs, is secret (not known by third parties) and that
the realm's names correspond to the entities implied by their names (and
thus the right KDCs know the key).

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 08 Oct 2002 18:18:51 -0400

>    still pretty suspect. I find that a little 

So you've got DNS that is not secured against spoofing but is still
considered trustworthy?  I'm skeptical, but to a large degree that's
because I don't know the architecture you're dealing with; maybe it is
trustworthy enough.  I wouldn't be averse to modifying the "insecure
DNS" part to reflect the possibility.  In fact, I think on some level
it's a question of terminology -- the lack of trustworthiness of the
DNS data is the real issue, and normal "insecure DNS" on open, general
purpose networks doesn't provide it.  Especially in a closed or highly
controlled system, there may be other means of providing that "trust"
or "security".

However, I think the recommendation on using DNS in situations where
it that doesn't provide that quality, whatever you want to call it,
should still be SHOULD NOT.  And it can't hurt to remind the reader
that that is the normal case for the Internet.  I don't think we need
to go out of our way to point out that other networks may not have the
same issues, but adjusting the phrasing of the recommendation to allow
for it is fine.

Oh, and the "Thus allowing..." part should be separated by a comma, not
made a separate sentence. :-)

Ken