Re: Services and top-level DNS names (was: Re: Update of RFC 2606
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Services and top-level DNS names (was: Re: Update of RFC 2606
On Mon, Jul 07, 2008 at 12:25:09PM -0400, John C Klensin wrote:
>
>
> --On Monday, 07 July, 2008 10:30 +1000 Mark Andrews
> <Mark_Andrews at isc.org> wrote:
>
> >...
> > If / when MIT stop using ai.mit.edu, "user at ai" will not longer
> > mean user at ai.mit.edu. This will mean that any configuration
> > file that has "user at ai" will now, suddenly, get a different
> > meaning. This is a latent security issue.
>
> Mark,
>
> While I'm basically sympathetic to the position you are taking
> on this, we have recommended for years and years (since the CS.
> incident, if not earlier), that things like configuration files
> use FQDNs and only FQDNs. SMTP imposes the same requirement on
> addresses in MAIL and RCPT commands.
>
> If user at ai is in a config file with the intent of identifying
> user at ai.mit.edu then the config file is broken. Conversely,
> if the config file format is intended to permit references to
> TLDs, I would hope that it would be possible to write "ai." if
> the TLD were intended.
>
> Personally, I'm very concerned about what users type and what
> happens after that. For configuration files and the like, I
> believe that we have a case of bad design if the interpretation
> of the configuration is dependent on things outside the scope of
> that file and, in particular, if there is a dependency on DNS
> search procedures rather than one explicit FQDNs.
>
> Quoting from youFrom ietf-bounces at ietf.org Mon Jul 7 12:10:07 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id C5E6C3A6AC4;
Mon, 7 Jul 2008 12:10:07 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 7039E3A6ACB
for <ietf at core3.amsl.com>; Mon, 7 Jul 2008 12:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Mt3HgMhLSYvE for <ietf at core3.amsl.com>;
Mon, 7 Jul 2008 12:10:04 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
by core3.amsl.com (Postfix) with ESMTP id 832C43A6AC4
for <ietf at ietf.org>; Mon, 7 Jul 2008 12:10:04 -0700 (PDT)
Received: from boreas.isi.edu (localhost [127.0.0.1])
by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m67J8X6Y029922
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Mon, 7 Jul 2008 12:08:34 -0700 (PDT)
Received: (from bmanning at localhost)
by boreas.isi.edu (8.13.8/8.13.8/Submit) id m67J8Vfc029901;
Mon, 7 Jul 2008 12:08:31 -0700 (PDT)
Date: Mon, 7 Jul 2008 12:08:31 -0700
From: Bill Manning <bmanning at ISI.EDU>
To: John C Klensin <john-ietf at jck.com>
Subject: Re: Services and top-level DNS names (was: Re: Update of RFC 2606
Message-ID: <20080707190831.GA26531 at boreas.isi.edu>
References: <200807070030.m670UIR1073241 at drugs.dv.isc.org>
<41C0AA5BE72A51344F410D1E at p3.JCK.COM>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <41C0AA5BE72A51344F410D1E at p3.JCK.COM>
User-Agent: Mutt/1.4.2.2i
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: bmanning at boreas.isi.edu
Cc: Mark Andrews <Mark_Andrews at isc.org>, ietf at ietf.org
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org
On Mon, Jul 07, 2008 at 12:25:09PM -0400, John C Klensin wrote:
>
>
> --On Monday, 07 July, 2008 10:30 +1000 Mark Andrews
> <Mark_Andrews at isc.org> wrote:
>
> >...
> > If / when MIT stop using ai.mit.edu, "user at ai" will not longer
> > mean user at ai.mit.edu. This will mean that any configuration
> > file that has "user at ai" will now, suddenly, get a different
> > meaning. This is a latent security issue.
>
> Mark,
>
> While I'm basically sympathetic to the position you are taking
> on this, we have recommended for years and years (since the CS.
> incident, if not earlier), that things like configuration files
> use FQDNs and only FQDNs. SMTP imposes the same requirement on
> addresses in MAIL and RCPT commands.
>
> If user at ai is in a config file with the intent of identifying
> user at ai.mit.edu then the config file is broken. Conversely,
> if the config file format is intended to permit references to
> TLDs, I would hope that it would be possible to write "ai." if
> the TLD were intended.
>
> Personally, I'm very concerned about what users type and what
> happens after that. For configuration files and the like, I
> believe that we have a case of bad design if the interpretation
> of the configuration is dependent on things outside the scope of
> that file and, in particular, if there is a dependency on DNS
> search procedures rather than one explicit FQDNs.
>
> Quoting from your commenr comment about Firefox, "Two wrongs don't make
> a right. They just make two things that need to be fixed."
>
> john
>
>
> _______________________________________________
> Ietf mailing list
> Ietf at ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
John, do you beleive that DNS host semantics/encoding that form the bulk
of the IDN work (stringprep, puny-code, et.al.) are applicable -only- in
the context of zone file generation or are they also applicable in
configuration and acess control for DNS?
path/alias expansion/evaluation will be interesting if "." is not what
7bit ASCII thinks of as "."
--
--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).
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
t about Firefox, "Two wrongs don't make
> a right. They just make two things that need to be fixed."
>
> john
>
>
> _______________________________________________
> Ietf mailing list
> Ietf at ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
John, do you beleive that DNS host semantics/encoding that form the bulk
of the IDN work (stringprep, puny-code, et.al.) are applicable -only- in
the context of zone file generation or are they also applicable in
configuration and acess control for DNS?
path/alias expansion/evaluation will be interesting if "." is not what
7bit ASCII thinks of as "."
--
--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).
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
