Re: [dnsext] New RRtype "KREALM" in draft-vanrein-dnstxt-krb1-02.txt

Rick van Rein <rick@openfortress.nl> Fri, 11 September 2015 08:58 UTC

Return-Path: <rick@openfortress.nl>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0911B3B0E; Fri, 11 Sep 2015 01:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDefhoPg2UpK; Fri, 11 Sep 2015 01:58:24 -0700 (PDT)
Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228671B3B52; Fri, 11 Sep 2015 01:58:23 -0700 (PDT)
Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id FkyL1r00U10HQrX01kyMGS; Fri, 11 Sep 2015 10:58:21 +0200
Message-ID: <55F297AA.10304@openfortress.nl>
Date: Fri, 11 Sep 2015 10:58:18 +0200
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: dns-rrtype-applications@ietf.org
References: <55E868E8.6050504@openfortress.nl> <20150903221410.8405236BD3C5@rock.dv.isc.org> <55E93C5F.5080704@openfortress.nl> <55EC48ED.30909@openfortress.nl>
In-Reply-To: <55EC48ED.30909@openfortress.nl>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsext/K7EnvyAo7QKYgWq9t8s53KzoM8c>
Cc: dnsext@ietf.org
Subject: Re: [dnsext] New RRtype "KREALM" in draft-vanrein-dnstxt-krb1-02.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2015 08:58:28 -0000

   DNS RRTYPE PARAMETER ALLOCATION REQUEST

   A. Submission Date: September 11, 2015.

   B.1 Submission Type:  [X] New RRTYPE  [ ] Modification to RRTYPE
   B.2 Kind of RR:  [X] Data RR  [ ] Meta-RR

   C. Contact Information for submitter (will be publicly posted):
      Name: Rick van Rein              Email Address: rick@openfortress.nl
      International telephone number: +31.53.4782239
      Other contact handles: Haarlebrink 5, 7544 WP  Enschede, The
Netherlands

   D. Motivation for the new RRTYPE application.

      Kerberos lacks a mechanism to find a realm name for a given domain
name
      or host name.  This was never defined due to insecurity of DNS.  With
      DNSSEC broadly deployed, we can now safely lookup realm
descriptions for
      DNS names, and this RRtype captures such realm descriptions.  The new
      facility can help to realise new Kerberos use cases such as
Internet-wide
      realm crossover.

   E. Description of the proposed RR type.

      https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1

   F. What existing RRTYPE or RRTYPEs come closest to filling that need
      and why are they unsatisfactory?

      TXT might have worked, but would require "educated guessing" on the
      semantics (not ideal from a security perspective) and is advised
      against by DNS experts; a new RRtype was suggested in its place.

   G. What mnemonic is requested for the new RRTYPE (optional)?

      KREALM (short for Kerberos Realm Descriptor)

   H. Does the requested RRTYPE make use of any existing IANA registry
      or require the creation of a new IANA subregistry in DNS
      Parameters?  If so, please indicate which registry is to be used
      or created.  If a new subregistry is needed, specify the
      allocation policy for it and its initial contents.  Also include
      what the modification procedures will be.

      From the 04 version of the I-D we quote:

       This specification defines a new "Resource Record (RR) Type", to be
       registered in the IANA registry of Domain Name System (DNS)
       Parameters".  The name of the RRType is KREALM, its value is TBD1 and
       its meaning is "Kerberos Realm Descriptor".

       This specification establishes a new registry with IANA, whose
       entries are subject to expert review and whose definition must be
       described in a publicly available specification.  The new registry
       will be known as the "Kerberos Realm Descriptor Tag Registry".  Each
       entry must provide a Yes/No flag to indicate if the tag is a Home
       Tag, meaning that it may only be interpreted as part of Home Records.

       The initial entries for this new registry introduced by this
       specification are:

                    +----------+-----------+-----------------+
                    | Tag name | Home Tag? | Definition      |
                    +----------+-----------+-----------------+
                    | realm    | No        | [TBD:THIS-SPEC] |
                    | service  | No        | [TBD:THIS-SPEC] |
                    | admin    | Yes       | [TBD:THIS-SPEC] |
                    +----------+-----------+-----------------+

       Tag names are case-sensitive.  Registration of new tags is subject to
       expert review, and a specification must be created as part of its
       definition.

       DISCUSS: Suggestions on the submission process for new tags are
       requested.

       In addition to the foregoing, tag names starting with "x-" are
       reserved for local and experimental use, for which registration is
       neither possible nor required.  These unregistered tags will not be
       protected from name clashes.

   I. Does the proposal require/expect any changes in DNS
      servers/resolvers that prevent the new type from being processed
      as an unknown RRTYPE (see [RFC3597])?

      No, the unknown RRTYPE from RFC3597 can handle KREALM.

   J. Comments:

      The I-D for this RRtype has been proposed on the DNSEXT list and
      suggestions for improvement were supplied by Mark Andrews on Sep
4, 2015.
      These suggestions have all been incorporated into version 03 and
shared
      back with Mark and the DNSEXT list on Sep 6, 2015.  There have been no
      further comments on the proposal.

      New RRtype "KREALM" in draft-vanrein-dnstxt-krb1-02.txt