From nobody Thu Sep 3 08:36:28 2015 Return-Path: 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 E49131B3157 for ; Thu, 3 Sep 2015 08:36:20 -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 tO-0WYPcLRR4 for ; Thu, 3 Sep 2015 08:36:17 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92EB71B324B for ; Thu, 3 Sep 2015 08:36:13 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id Cfc91r00810HQrX01fcA9e; Thu, 03 Sep 2015 17:36:11 +0200 Message-ID: <55E868E8.6050504@openfortress.nl> Date: Thu, 03 Sep 2015 17:36:08 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: dnsext@ietf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 15:36:21 -0000 Hello, I am working on an I-D that allocates a new RRtype in DNS, named KREALM. This RR is meant to store Kerberos realm descriptions in DNS; this has hitherto been desired but impossible to do securely, but nowadays the broad acceptance of DNSSEC permits this facility. Please let me know if you have any feedback or questions! Cheers, Rick van Rein for ARPA2.net > A new version of I-D, draft-vanrein-dnstxt-krb1-02.txt > has been successfully submitted by Rick van Rein and posted to the > IETF repository. > > Name: draft-vanrein-dnstxt-krb1 > Revision: 02 > Title: Kerberos Realm Descriptors in DNS (KREALM) > Document date: 2015-09-03 > Group: Individual Submission > Pages: 15 > URL: https://www.ietf.org/internet-drafts/draft-vanrein-dnstxt-krb1-02.txt > Status: https://datatracker.ietf.org/doc/draft-vanrein-dnstxt-krb1/ > Htmlized: https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-vanrein-dnstxt-krb1-02 > > Abstract: > This specification defines methods to determine Kerberos realm > descriptive information for services that are known by their DNS > name. Currently, finding such information is done through static > mappings or educated guessing. DNS can make this process more > dynamic, provided that DNSSEC is used to ensure authenticity of > resource records. > From nobody Thu Sep 3 15:14:21 2015 Return-Path: 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 A8FEF1B3DE2 for ; Thu, 3 Sep 2015 15:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 BGzgWxx6Ab1w for ; Thu, 3 Sep 2015 15:14:18 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B511B3CD2 for ; Thu, 3 Sep 2015 15:14:17 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 417381FCBDE; Thu, 3 Sep 2015 22:14:14 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7135B160052; Thu, 3 Sep 2015 22:15:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5FA3416008F; Thu, 3 Sep 2015 22:15:35 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qnV1z323PjCy; Thu, 3 Sep 2015 22:15:34 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 96A1A160052; Thu, 3 Sep 2015 22:15:34 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8405236BD3C5; Fri, 4 Sep 2015 08:14:10 +1000 (EST) To: Rick van Rein From: Mark Andrews References: <55E868E8.6050504@openfortress.nl> In-reply-to: Your message of "Thu, 03 Sep 2015 17:36:08 +0200." <55E868E8.6050504@openfortress.nl> Date: Fri, 04 Sep 2015 08:14:10 +1000 Message-Id: <20150903221410.8405236BD3C5@rock.dv.isc.org> Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 22:14:19 -0000 If you only want the AD bit to be returned then set AD=1 in the query not DO=1. See RFC 6840. Modern versions of DiG do this by default. If the resolver or the path to it is not trusted then you need to specify DO=1 and perform local validation as you can't rely on the AD bit. Don't put the base64 in quotes. Do specify that the base64 encoding may be broken up by white space and may be over multiple lines using the standard DNS mechanisms for doing this. There is no need for it to be a single lexographic token. This needs to be clear as registrars stuffed up DS handling by only coding for a single lexographic token in DS despite it being specified as allowing multiple tokens. Add some examples where the base64 is split into multiple tokens. Mark In message <55E868E8.6050504@openfortress.nl>, Rick van Rein writes: > Hello, > > I am working on an I-D that allocates a new RRtype in DNS, named > KREALM. This RR is meant to store Kerberos realm descriptions in DNS; > this has hitherto been desired but impossible to do securely, but > nowadays the broad acceptance of DNSSEC permits this facility. > > Please let me know if you have any feedback or questions! > > Cheers, > > Rick van Rein > for ARPA2.net > > > A new version of I-D, draft-vanrein-dnstxt-krb1-02.txt > > has been successfully submitted by Rick van Rein and posted to the > > IETF repository. > > > > Name: draft-vanrein-dnstxt-krb1 > > Revision: 02 > > Title: Kerberos Realm Descriptors in DNS (KREALM) > > Document date: 2015-09-03 > > Group: Individual Submission > > Pages: 15 > > URL: https://www.ietf.org/internet-drafts/draft-vanrein-dnstxt-k > rb1-02.txt > > Status: https://datatracker.ietf.org/doc/draft-vanrein-dnstxt-krb1/ > > Htmlized: https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1-02 > > Diff: https://www.ietf.org/rfcdiff?url2=draft-vanrein-dnstxt-krb1 > -02 > > > > Abstract: > > This specification defines methods to determine Kerberos realm > > descriptive information for services that are known by their DNS > > name. Currently, finding such information is done through static > > mappings or educated guessing. DNS can make this process more > > dynamic, provided that DNSSEC is used to ensure authenticity of > > resource records. > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Sep 3 23:38:35 2015 Return-Path: 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 234081B3815 for ; Thu, 3 Sep 2015 23:38:34 -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 n0baKfosrrtU for ; Thu, 3 Sep 2015 23:38:31 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30911B3802 for ; Thu, 3 Sep 2015 23:38:29 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id CueQ1r00T10HQrX01ueSaS; Fri, 04 Sep 2015 08:38:27 +0200 Message-ID: <55E93C5F.5080704@openfortress.nl> Date: Fri, 04 Sep 2015 08:38:23 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Mark Andrews References: <55E868E8.6050504@openfortress.nl> <20150903221410.8405236BD3C5@rock.dv.isc.org> In-Reply-To: <20150903221410.8405236BD3C5@rock.dv.isc.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 06:38:34 -0000 Hi Mark / others, Thanks for your reading & commenting! As for base64, I was also considering to adopt the hexadecimal notation used for Unknown RRtypes [RFC 3579]; ASN.1 data is quite readable in hexdump form, and absolutely not in base64 form. Do you have any ideas if that would be considered silly or awkward? > If you only want the AD bit to be returned then set AD=1 in the > query not DO=1. See RFC 6840. Modern versions of DiG do this by > default. If the resolver or the path to it is not trusted then you > need to specify DO=1 and perform local validation as you can't rely > on the AD bit. Thanks for pointing that out, I was indeed following older specs. Changed for -03: To give one possible implementation, a Kerberos client may send DNS queries with the Authentic Data (AD) bit set to enable DNSSEC [Section 5.7 of [RFC6840]], and require that the Authenticated Data bit is set in the response to indicate [RFC3655] the Secure state for answer and authority sections of the response. When the DNS traffic to and from the validating resolver is protected, for instance because that resolver is reached over a loopback interface, then the Kerberos client has implemented the requirements for Secure use of the answer and authority sections in DNS responses. > Don't put the base64 in quotes. I changed the examples accordingly in -03. > Do specify that the base64 encoding may be broken up by white space > and may be over multiple lines using the standard DNS mechanisms > for doing this. There is no need for it to be a single lexographic > token. This needs to be clear as registrars stuffed up DS handling > by only coding for a single lexographic token in DS despite it being > specified as allowing multiple tokens. Add some examples where the > base64 is split into multiple tokens. > Added to -03 [...] The base64-represented data may be interspersed with white space, including even line breaks if the usual DNS zone file notation with parenthesis is used. I also demonstrated the line breaks in an example: www.example.com. IN KREALM ( ME8xTTAOFgdzZXJ2aWNlDANmdHAwDxYH c2VydmljZQwESFRUUDAUFgVyZWFsbQwL RVhBTVBMRS5DT00wFBYFcmVhbG0MC0VY QU1QTEUuT1JH ) Thanks! -Rick From nobody Sun Sep 6 07:08:55 2015 Return-Path: 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 8707D1B468C for ; Sun, 6 Sep 2015 07:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 bJR-xvMcULZw for ; Sun, 6 Sep 2015 07:08:52 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE391B452A for ; Sun, 6 Sep 2015 07:08:51 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id Dq8m1r00H10HQrX01q8o7D; Sun, 06 Sep 2015 16:08:50 +0200 Message-ID: <55EC48ED.30909@openfortress.nl> Date: Sun, 06 Sep 2015 16:08:45 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: dnsext@ietf.org References: <55E868E8.6050504@openfortress.nl> <20150903221410.8405236BD3C5@rock.dv.isc.org> <55E93C5F.5080704@openfortress.nl> In-Reply-To: <55E93C5F.5080704@openfortress.nl> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 14:08:54 -0000 Hello DNSEXT, FYI, I have updated mu draft to follow up with Mark Andrews' remarks. One more DNS-related change is that the reliance of the type bit map in NSEC/NSEC3 now has a fallback procedure of explicitly requesting SOA if a client cannot get hold of the denial itself. The new version is https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1-03 The changes are: * DNSEXT: RFC 6840: Set AD=1 instead of DO=1 in the query * DNSEXT: base64 without quotes and possibly with whitespace and std line breaks * Made SOA through type bit maps an optional path, explicit SOA query is OK too * Introduced the "admin" tag to specify administrator principal names * Clarified references from non-home records to srv + home records Thank you, -Rick From nobody Fri Sep 11 01:58:29 2015 Return-Path: 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 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Fri Sep 11 02:03:22 2015 Return-Path: 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 918081B32B6 for ; Fri, 11 Sep 2015 02:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7hqp2tDacNqu for ; Fri, 11 Sep 2015 02:03:19 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40.csi.cam.ac.uk [131.111.8.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5BC1B3C57 for ; Fri, 11 Sep 2015 02:03:16 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:51821) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1ZaKEl-0002T2-ja (Exim 4.86_36-e07b163) (return-path ); Fri, 11 Sep 2015 10:03:15 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1ZaKEl-0008VQ-1F (Exim 4.72) (return-path ); Fri, 11 Sep 2015 10:03:15 +0100 Date: Fri, 11 Sep 2015 10:03:15 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Rick van Rein In-Reply-To: <55E868E8.6050504@openfortress.nl> Message-ID: References: <55E868E8.6050504@openfortress.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 09:03:20 -0000 Rick van Rein wrote: > > I am working on an I-D that allocates a new RRtype in DNS, named > KREALM. This RR is meant to store Kerberos realm descriptions in DNS; > this has hitherto been desired but impossible to do securely, but > nowadays the broad acceptance of DNSSEC permits this facility. Why not use the HINFO RDATA format to store the tag/value pairs? No need for embedding the sequence in the RDATA since RRsets already provide that. No need to embed a version number since RRtypes provide that. Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or moderate, but rough in southwest Viking. Showers later. Good, occasionally poor later. From nobody Fri Sep 11 02:58:46 2015 Return-Path: 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 D28C61B4272 for ; Fri, 11 Sep 2015 02:58:44 -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 zjBTEMum04Pw for ; Fri, 11 Sep 2015 02:58:42 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D10E1B2B07 for ; Fri, 11 Sep 2015 02:58:42 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id Flye1r00E10HQrX01lyf5S; Fri, 11 Sep 2015 11:58:40 +0200 Message-ID: <55F2A5CC.1080409@openfortress.nl> Date: Fri, 11 Sep 2015 11:58:36 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Tony Finch References: <55E868E8.6050504@openfortress.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 09:58:45 -0000 Hi Tony / list, > Why not use the HINFO RDATA format to store the tag/value pairs? No need > for embedding the sequence in the RDATA since RRsets already provide that. > No need to embed a version number since RRtypes provide that. Interesting suggestion, I wasn't aware of this possibility. Indeed, a binary string with prefixed length should work, I see that escaping has been arranged in RFC 1035 and 255 data bytes isn't a strange upper limit for a string. I can't seem to find a tag/value definition format for HINFO though; can you give me a reference? I wanted to avoid requesting a parser that specific, but if it's already there then it's certainly a good idea. Note that ASN.1 is a home game to Kerberos, so from that perspective the wire format makes a lot of sense, I think. You are not proposing to change the wire format, right? Thanks -Rick From nobody Fri Sep 11 03:18:29 2015 Return-Path: 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 A9AC61B3AE1 for ; Fri, 11 Sep 2015 03:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 G4QPCvseYlOE for ; Fri, 11 Sep 2015 03:18:26 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40.csi.cam.ac.uk [131.111.8.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58051B37FF for ; Fri, 11 Sep 2015 03:18:25 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:54137) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1ZaLPU-00082a-jg (Exim 4.86_36-e07b163) (return-path ); Fri, 11 Sep 2015 11:18:24 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1ZaLPT-0005NJ-TL (Exim 4.72) (return-path ); Fri, 11 Sep 2015 11:18:23 +0100 Date: Fri, 11 Sep 2015 11:18:23 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Rick van Rein In-Reply-To: <55F2A5CC.1080409@openfortress.nl> Message-ID: References: <55E868E8.6050504@openfortress.nl> <55F2A5CC.1080409@openfortress.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 10:18:27 -0000 Rick van Rein wrote: > > I can't seem to find a tag/value definition format for HINFO though; can > you give me a reference? I wanted to avoid requesting a parser that > specific, but if it's already there then it's certainly a good idea. HINFO is just a pair of strings. (Similar to a TXT record, except a TXT record can have any number of strings.) https://tools.ietf.org/html/rfc1035#section-3.3.2 > Note that ASN.1 is a home game to Kerberos, so from that perspective the > wire format makes a lot of sense, I think. You are not proposing to > change the wire format, right? Yes, I think the wire format and presentation format should be native DNS not ASN.1. Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or moderate, but rough in southwest Viking. Showers later. Good, occasionally poor later. From nobody Fri Sep 11 04:05:03 2015 Return-Path: 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 3AF071B29C9 for ; Fri, 11 Sep 2015 04:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 Rj3lGxnBBQyY for ; Fri, 11 Sep 2015 04:05:00 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4982F1B48E2 for ; Fri, 11 Sep 2015 04:04:59 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id Fn4v1r00310HQrX01n4wB4; Fri, 11 Sep 2015 13:04:57 +0200 Message-ID: <55F2B555.4050105@openfortress.nl> Date: Fri, 11 Sep 2015 13:04:53 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Tony Finch References: <55E868E8.6050504@openfortress.nl> <55F2A5CC.1080409@openfortress.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 11:05:02 -0000 Hi Tony, > Yes, I think the wire format and presentation format should be native DNS > not ASN.1. Ah. That would call for more complex parsing. I hadn't expected that to be preferred by the DNS community, over simplicity. Is the reason readability of zone files? HINFO uses precisely 2 strings, with KREALM it'd be variable, but could be done with something like @ IN KREALM ( "realm=EXAMPLE.COM" "realm=EXAMPLE.ORG" admin=carl "admin=mary" service=HTTP "service=imap" ) The parser then MAY check the presence of an = sign in the string but otherwise keep tag and value together. Each of these strings would then independently translate to a separate , namely 12 72 65 61 6c 6d 3d 45 58 41 4d 50 4c 45 2e 43 4f 4d 12 72 65 61 6c 6d 3d 45 58 41 4d 50 4c 45 2e 4f 52 47 0b 61 64 6d 69 6e 3d 63 61 72 6c 0b 61 64 6d 69 6e 3d 6d 61 72 79 0d 73 65 72 76 69 63 65 3d 48 54 54 50 0d 73 65 72 76 69 63 65 3d 69 6d 61 70 But that's a variable number of strings in the textual format *and* in the RDATA format. The RDATA is preceded by RDLENGTH, so it would be possible, but I am hesitant about such new approaches to DNS. Alternatively, we could incorporate separator characters such as comma's but that would constrain the possible string values (and call for even more escaping and another level, which isn't my favourite place to go). I expect an uproar from both alternatives to be honest. Or not? -Rick From nobody Fri Sep 11 04:09:22 2015 Return-Path: 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 9904F1B29CD for ; Fri, 11 Sep 2015 04:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ADohM5-0XPRt for ; Fri, 11 Sep 2015 04:09:19 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477D51A1BEC for ; Fri, 11 Sep 2015 04:09:19 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:35765) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1ZaMCj-0000Oi-WQ (Exim 4.86_36-e07b163) (return-path ); Fri, 11 Sep 2015 12:09:17 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1ZaMCj-0000q4-07 (Exim 4.72) (return-path ); Fri, 11 Sep 2015 12:09:17 +0100 Date: Fri, 11 Sep 2015 12:09:16 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Rick van Rein In-Reply-To: <55F2B555.4050105@openfortress.nl> Message-ID: References: <55E868E8.6050504@openfortress.nl> <55F2A5CC.1080409@openfortress.nl> <55F2B555.4050105@openfortress.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 11:09:20 -0000 Rick van Rein wrote: > > @ IN KREALM ( "realm=EXAMPLE.COM" "realm=EXAMPLE.ORG" > admin=carl "admin=mary" > service=HTTP "service=imap" ) I was thinking @ KREALM "realm" "EXAMPLE.COM" KREALM "realm" "EXAMPLE.ORG" KREALM "admin" "carl" KREALM "admin" "mary" KREALM "service" "HTTP" KREALM "service" "imap" Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or moderate, but rough in southwest Viking. Showers later. Good, occasionally poor later. From nobody Fri Sep 11 04:14:44 2015 Return-Path: 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 E7A771B3B16 for ; Fri, 11 Sep 2015 04:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, 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 jCdC20-ogQuW for ; Fri, 11 Sep 2015 04:14:39 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF131B3447 for ; Fri, 11 Sep 2015 04:14:38 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id FnEb1r00c10HQrX01nEcmV; Fri, 11 Sep 2015 13:14:37 +0200 Message-ID: <55F2B79A.3010701@openfortress.nl> Date: Fri, 11 Sep 2015 13:14:34 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Tony Finch References: <55E868E8.6050504@openfortress.nl> <55F2A5CC.1080409@openfortress.nl> <55F2B555.4050105@openfortress.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 11:14:43 -0000 Hi Tony, Thanks for thinking along! > I was thinking > > @ KREALM "realm" "EXAMPLE.COM" > KREALM "realm" "EXAMPLE.ORG" > KREALM "admin" "carl" > KREALM "admin" "mary" > KREALM "service" "HTTP" > KREALM "service" "imap" That would make it impossible to express everything that is desired. The level of alternation that you are using here has been reserved for independent statements; the combined tag=value statements form a cross-product; for example all the realms mentioned combine with all the admins mentioned in the same RDATA portion. If another realm has another admin set it will be specified in a separate KREALM. This is why I end up with a variable list of tag=value assignments under one KREALM, and as explained that strikes me as an oddball solution in DNS. Do you agree? Note that more base64 data is incorporated into DNS already, for instance certificates (where, I admit, there is no choice due to the tightness of the signatures). -Rick From nobody Fri Sep 11 06:40:23 2015 Return-Path: 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 7F5471B4014 for ; Fri, 11 Sep 2015 06:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, 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 0fNQbeZDCpel for ; Fri, 11 Sep 2015 06:40:15 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20581A1B6C for ; Fri, 11 Sep 2015 06:40:14 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so58829903wic.1 for ; Fri, 11 Sep 2015 06:40:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:date:message-id:to:cc:subject:in-reply-to :references:user-agent:mime-version:content-type :content-transfer-encoding; bh=LEEg9f8Zk+K582teAOCRIot09biF5Ru0m9dXzO6mMZA=; b=OkhE+ST12FBw9+4MaTrdhnX5yC6mvje7xrdq/7SgOnTLxMtFJOLrpQSz0gzRO9GZed O49CVE0tJAFdfS5PupIqw1b07DDvkVjaSKxDKxcGghyIs9oZgOjM1mEslWDiXyBSo6kO 7TuH0ryGeZvfn55QLxwTXhIE4VCK8u+PXRY/+LJdlI35QD+01CQ5TtVD7wCT1HlQD1TE 8gplh7qnoZMIkliac4Pn2x66CrupAZMOaPomY3GNzTlAV+2LxEmxrhkVnXdXrkzUIw2n 5oaNMqmO+8KQYBfhHIkvLWf2Rhq+2Q8Mhovv54NgdreduiNVcj5i0JZhq9O3xzz9azbI 5tcw== X-Gm-Message-State: ALoCoQmCzeX0l18dZmvx7oV6WeifYEDOs9VUmUcMUwpPZYo4aoMU0PkPIZrevxT6irBVi7dEoP2O X-Received: by 10.180.37.76 with SMTP id w12mr4878387wij.0.1441978813414; Fri, 11 Sep 2015 06:40:13 -0700 (PDT) Received: from dhcp-162.wlan.no8.be.ucd.ie ([2001:770:13f:1:982e:1026:6ec6:8956]) by smtp.gmail.com with ESMTPSA id pu6sm429404wjc.34.2015.09.11.06.40.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Sep 2015 06:40:12 -0700 (PDT) From: "Niall O'Reilly" X-Google-Original-From: Niall O'Reilly Date: Fri, 11 Sep 2015 14:40:11 +0100 Message-ID: To: Rick van Rein In-Reply-To: <55F2B79A.3010701@openfortress.nl> References: <55E868E8.6050504@openfortress.nl> <55F2A5CC.1080409@openfortress.nl> <55F2B555.4050105@openfortress.nl> <55F2B79A.3010701@openfortress.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 13:40:21 -0000 On Fri, 11 Sep 2015 12:14:34 +0100, Rick van Rein wrote: Hi, Rick. > Hi Tony, >=20 > Thanks for thinking along! >=20 > > I was thinking > > > > @ KREALM "realm" "EXAMPLE.COM" > > KREALM "realm" "EXAMPLE.ORG" > > KREALM "admin" "carl" > > KREALM "admin" "mary" > > KREALM "service" "HTTP" > > KREALM "service" "imap" >=20 > That would make it impossible to express everything that is desired.=20 > The level of alternation that you are using here has been reserved for > independent statements; the combined tag=3Dvalue statements form a > cross-product; for example all the realms mentioned combine with all the > admins mentioned in the same RDATA portion. If another realm has > another admin set it will be specified in a separate KREALM. Don't you end up with a potentially large but sparse matrix of valid tag/value pairs in this model, Rick? Would a two-stage representation of the data you need work? I'm thinking of normalization and foreign keys. Here's an example below. ; advertise realms to which $ORIGIN belongs ; so that clients can perform discovery ; this RRset is the REALM-SET @ KREALM "realm" "EXAMPLE.COM" @ KREALM "realm" "EXAMPLE.ORG" ; ; for each realm at $ORIGIN, advertise its attributes ; ; this RRset is the ATTRIBUTE-SET for realm "EXAMPLE.COM" at $ORIGIN EXAMPLE.COM._realm KREALM "admin" "carl" EXAMPLE.COM._realm KREALM "service" "HTTP" ; ; this RRset is the ATTRIBUTE-SET for realm "EXAMPLE.ORG" at $ORIGIN EXAMPLE.ORG._realm KREALM "admin" "mary" EXAMPLE.ORG._realm KREALM "service" "imap" =20 If the realm isn't really "at" $ORIGIN, a CNAME reference might be appropriate. If this approach risks string overflow in the owner names, an alternative might be to use @ KREALM for the REALM-SET, and use the same handle in composing the owner name of the ATTRIBUTE-SET, so: @ KREALM "r1" "EXAMPLE.COM" @ KREALM "r2" "EXAMPLE.ORG" r1._realm KREALM "admin" "carl" ; ... r2._realm KREALM "admin" "mary" As I write, it occurs to me that it may be more "natural" to assign the RDATE fields in the REALM-SET in the reverse order. That's a detail which just needs to be unambiguously specified. 8-) This-all seems to keep the option of re-using HINFO as Tony suggested. ATB Niall =20 From nobody Sun Sep 13 05:55:58 2015 Return-Path: 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 E3D9F1B493E for ; Sun, 13 Sep 2015 05:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.899 X-Spam-Level: * X-Spam-Status: No, score=1.899 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_35=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 zWrjzOo6odlJ for ; Sun, 13 Sep 2015 05:55:53 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DEC1B48F5 for ; Sun, 13 Sep 2015 05:55:52 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id Gcvn1r00B10HQrX01cvon4; Sun, 13 Sep 2015 14:55:51 +0200 Message-ID: <55F57251.5010707@openfortress.nl> Date: Sun, 13 Sep 2015 14:55:45 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Niall O'Reilly References: <55E868E8.6050504@openfortress.nl> <55F2A5CC.1080409@openfortress.nl> <55F2B555.4050105@openfortress.nl> <55F2B79A.3010701@openfortress.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 12:55:57 -0000 Hello Niall / Tony / list, Good post, thanks! > Don't you end up with a potentially large but sparse matrix of > valid tag/value pairs in this model, Rick? > No, it's not supposed to be sparse. If things belong together you put them in the same KREALM record. If they don't belong together you put them in separate ones. The idea is to capture what belongs together by putting them in the same KREALM record, for brevity of DNS data. For instance, "service" declarations would be part of a hostname, together with the "realm" declarations supported; chances are that www.example.com has realm "EXAMPLE.COM" and "EXAMPLE.ORG" and service "HTTP" defined, and perhaps also "host" (for remote login) and "cifs". This gives rise to all combinations HTTP/www.example.com@EXAMPLE.COM HTTP/www.example.com@EXAMPLE.ORG host/www.example.com@EXAMPLE.COM host/www.example.com@EXAMPLE.ORG cifs/www.example.com@EXAMPLE.COM cifs/www.example.com@EXAMPLE.ORG Since this is located at the server name (www) rather than the DNS-mapped realm name (example.com and example.org) this is not as sparse as you are thinking, if I guess correctly. The reason for keeping those within one KREALM RDATA structure is that it enables me to specify one KREALM that definces service=HTTP for both realms, and the other two could only be made available to one of the realms. Note that there is no explicit name for that distinction, but we could wonder if the realm name would be the prime cause of wanting to make such distinctions, and that is what you are addressing below. > Would a two-stage representation of the data you need work? > I'm thinking of normalization and foreign keys. > Very interesting idea. In fact I was already doing that somewhat, with a KREALM "reference record" at the service name (www) that points to the "home record" where a more elaborate KREALM "home record" is located. The "admin" tag would be typically something to find near the "home record", which is indeed what I specified. Still, you are making it more explicit, which is indeed useful. You are triggering a lot of thoughts with this, which is good, but it'll need some time for me to think them over. I started responding in detail (left below) but it's unfinished. It'll will take a few walks in nature and probably lead to a modified proposal, possibly different on details. My start should be to clearly state the use cases for the KREALM record, and finding the best ways of embedding that into DNS. Thanks a lot so far! -Rick > Here's an example below. > > ; advertise realms to which $ORIGIN belongs > ; so that clients can perform discovery > ; this RRset is the REALM-SET > @ KREALM "realm" "EXAMPLE.COM" > @ KREALM "realm" "EXAMPLE.ORG" Here, $ORIGIN as you call it would be the hostname for the service, so "www.example.com" for a service like HTTP/www.example.com > ; > ; for each realm at $ORIGIN, advertise its attributes > ; > ; this RRset is the ATTRIBUTE-SET for realm "EXAMPLE.COM" at $ORIGIN > EXAMPLE.COM._realm KREALM "admin" "carl" > EXAMPLE.COM._realm KREALM "service" "HTTP" > ; > ; this RRset is the ATTRIBUTE-SET for realm "EXAMPLE.ORG" at $ORIGIN > EXAMPLE.ORG._realm KREALM "admin" "mary" > EXAMPLE.ORG._realm KREALM "service" "imap" > And this too would fall under that hostname "www.example.com" and add details. There are two things that you've triggered. The things I described as "home tags" are properties of the realm; the "admin" tag is the running example. That would not be defined for individual services, but under the DNS-mapped realm name (which is just reading a DNS-formatted realm name with ignored case sensitivity). So I would suggest to write those simply as example.com. KREALM "admin" carl" example.org. KREALM "admin" "mary" Now, the service tags could be stored underneath the _realm subname. Interestingly, this enables wildcard notation *._realm as well, for example example.org._realm KREALM "service" "imap" example.com._realm KREALM "service" "host" *._realm KREALM "service" "HTTP" I do like this. And although the mapping to DNS names as done here looses the case of the realm, it is no problem, because RFC 4120 prescribes in 7.2.3.1 that "it is necessary that only one of the possible combinations of upper- and lowercase characters be used in realm names." -- so the case-sensitive realm name mapped to a case-insensitive DNS-name as you do it here is supported by the Kerberos specification. Note my assumption -- you meant to lookup realm names under _realm rather than the hostname of a server. The cost of this is one more DNS query, but targeted at the precise thing we're looking for, so no search pattern. Defining a "service" tag in this manner makes it impossible to have a catchall "realm" tag for an entire domain and apply it to everything. But that was also the case with the initial proposal I made. Drop "service" tags and it does become possible. We could debate whether it is a good idea to always specify the "service" tag and not make the upward search that I've been looking to settle securely. I suppose maximum flexibility is desirable here; especially because the Kerberos client is built into a protocol-specific client, so it'll know if the service is available. That in fact enables another approach, which is to use service names as the index instead of realm names. ; Alternative approach HTTP._ksvc KREALM "realm" "EXAMPLE.COM" HTTP._ksvc KREALM "realm" "EXAMPLE.ORG" imap._ksvc KREALM "realm" "EXAMPLE.ORG" The client could now lookup the service that it knows it should use, under the server's name. So http://www.example.com would query for KREALM at HTTP._realm.www.example.com -- again a pattern that won't work well with wildcards that capture an entire domain, and again that's related to defining a service in the first place; a wildcard KREALM would refer everything but this record might be overridden for services, which feels right. Notes: I'm not sure if case distinction is getting a problem here. I'm assuming the service name doesn't need an underscore prefix, but I don't know the habits here, SRV does it of course. > If the realm isn't really "at" $ORIGIN, a CNAME reference might be > appropriate. > Hmm, that sounds like a nest of hornets to me, but it might work. I'm not sure it is the best way though; references should contain their KREALM explicitly and point at the realm name, and KREALM records defining a home location for kerberos are always going to be local to the DNS-name that they sort-of claim to hold. > If this approach risks string overflow in the owner names, an > alternative might be to use > > @ KREALM > > for the REALM-SET, and use the same handle in composing the owner > name of the ATTRIBUTE-SET, so: > > @ KREALM "r1" "EXAMPLE.COM" > @ KREALM "r2" "EXAMPLE.ORG" > r1._realm KREALM "admin" "carl" > ; ... > r2._realm KREALM "admin" "mary" > > As I write, it occurs to me that it may be more "natural" to assign > the RDATE fields in the REALM-SET in the reverse order. That's a > detail which just needs to be unambiguously specified. 8-) > > This-all seems to keep the option of re-using HINFO as Tony suggested. > > ATB > Niall > > Rick van Rein > 11 September 2015 13:14 > Hi Tony, > > Thanks for thinking along! > > > That would make it impossible to express everything that is desired. > The level of alternation that you are using here has been reserved for > independent statements; the combined tag=value statements form a > cross-product; for example all the realms mentioned combine with all the > admins mentioned in the same RDATA portion. If another realm has > another admin set it will be specified in a separate KREALM. > > This is why I end up with a variable list of tag=value assignments under > one KREALM, and as explained that strikes me as an oddball solution in > DNS. Do you agree? > > Note that more base64 data is incorporated into DNS already, for > instance certificates (where, I admit, there is no choice due to the > tightness of the signatures). > > -Rick > Tony Finch > 11 September 2015 13:09 > > I was thinking > > @ KREALM "realm" "EXAMPLE.COM" > KREALM "realm" "EXAMPLE.ORG" > KREALM "admin" "carl" > KREALM "admin" "mary" > KREALM "service" "HTTP" > KREALM "service" "imap" > > Tony. > Rick van Rein > 11 September 2015 13:04 > Hi Tony, > > > Ah. That would call for more complex parsing. I hadn't expected that > to be preferred by the DNS community, over simplicity. Is the reason > readability of zone files? > > HINFO uses precisely 2 strings, with KREALM it'd be variable, but > could be done with something like > > @ IN KREALM ( "realm=EXAMPLE.COM" "realm=EXAMPLE.ORG" > admin=carl "admin=mary" > service=HTTP "service=imap" ) > > The parser then MAY check the presence of an = sign in the string but > otherwise keep tag and value together. > > Each of these strings would then independently translate to a separate > , namely > > 12 72 65 61 6c 6d 3d 45 58 41 4d 50 4c 45 2e 43 4f 4d > 12 72 65 61 6c 6d 3d 45 58 41 4d 50 4c 45 2e 4f 52 47 > 0b 61 64 6d 69 6e 3d 63 61 72 6c > 0b 61 64 6d 69 6e 3d 6d 61 72 79 > 0d 73 65 72 76 69 63 65 3d 48 54 54 50 > 0d 73 65 72 76 69 63 65 3d 69 6d 61 70 > > But that's a variable number of strings in the textual format *and* in > the RDATA format. The RDATA is preceded by RDLENGTH, so it would be > possible, but I am hesitant about such new approaches to DNS. > > Alternatively, we could incorporate separator characters such as > comma's but that would constrain the possible string values (and call > for even more escaping and another level, which isn't my favourite > place to go). > > I expect an uproar from both alternatives to be honest. Or not? > > -Rick > Tony Finch > 11 September 2015 12:18 > Rick van Rein wrote: >> I can't seem to find a tag/value definition format for HINFO though; can >> you give me a reference? I wanted to avoid requesting a parser that >> specific, but if it's already there then it's certainly a good idea. > > HINFO is just a pair of strings. (Similar to a TXT record, except a TXT > record can have any number of strings.) > > https://tools.ietf.org/html/rfc1035#section-3.3.2 > >> Note that ASN.1 is a home game to Kerberos, so from that perspective the >> wire format makes a lot of sense, I think. You are not proposing to >> change the wire format, right? > > Yes, I think the wire format and presentation format should be native DNS > not ASN.1. > > Tony. From nobody Sun Sep 13 06:55:19 2015 Return-Path: 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 953111A87EC for ; Sun, 13 Sep 2015 06:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 LdK8RVPJoYvo for ; Sun, 13 Sep 2015 06:55:17 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7171A89B4 for ; Sun, 13 Sep 2015 06:55:16 -0700 (PDT) Received: by wicge5 with SMTP id ge5so111818511wic.0 for ; Sun, 13 Sep 2015 06:55:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:date:message-id:to:cc:subject:in-reply-to :references:user-agent:mime-version:content-type :content-transfer-encoding; bh=jLIuEYABlGpf8koA8MT6yAYp1uPfn5hpX8+y6+9xQm8=; b=TR4mMkMpinfS5EJ1UzqIFIBkVAyp5+zoS9M2Bdel6HQISv+m0LhNRjRUsUXTpvpwur 5ZSXqLRgZIi8MoiwwEyMtI/n8NI2GeZ3L4C3r7fIYaauj5bzJoHPXwtuV8t3giVnj0U4 kBOYmkSwQUNj0KqVsiUU62KyN9b24mBqUJElQIGbZTxETsbO4KuAWo90n7FRP3pCHrL3 EVEfhrw9sU60bwjRcUiIq1VE1R2UitvS6J/hGgFKSx42v9NjzS3D8vJKKzezfAbWMyIt Hk09tS7COfBHoeYX2JnXekN3B+d2L5xdM20q43HWiw+S7tSwDAzkxy5avDptyF/XoxdD H0Gg== X-Gm-Message-State: ALoCoQkInha0X6QGASCK96ger0uxltXvC+x82k3cIbIUSCgVagncKqpMYdPRUbI6o1JeNEcLaRCj X-Received: by 10.180.85.74 with SMTP id f10mr15984748wiz.45.1442152515371; Sun, 13 Sep 2015 06:55:15 -0700 (PDT) Received: from dhcp-162.wlan.no8.be.ucd.ie ([2001:770:13f:1:35f1:8414:aaa7:9e14]) by smtp.gmail.com with ESMTPSA id s16sm9245738wik.13.2015.09.13.06.55.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Sep 2015 06:55:14 -0700 (PDT) From: "Niall O'Reilly" X-Google-Original-From: Niall O'Reilly Date: Sun, 13 Sep 2015 14:55:11 +0100 Message-ID: To: Rick van Rein In-Reply-To: <55F57251.5010707@openfortress.nl> References: <55E868E8.6050504@openfortress.nl> <55F2A5CC.1080409@openfortress.nl> <55F2B555.4050105@openfortress.nl> <55F2B79A.3010701@openfortress.nl> <55F57251.5010707@openfortress.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 13:55:18 -0000 On Sun, 13 Sep 2015 13:55:45 +0100, Rick van Rein wrote: [...] > Here, $ORIGIN as you call it would be the hostname for the service, so > "www.example.com" for a service like HTTP/www.example.com I'm just borrowing a notation from the zone-file '$ORIGIN' directive, which (some?) zone parsers use to adjust the current value to be substituted for '@'. =20 [...] > > And this too would fall under that hostname "www.example.com" and add > details. Or perhaps just under "example.com", depending on the use case. [...] >=20 > Note my assumption -- you meant to lookup realm names under _realm > rather than the hostname of a server. =20 Like the service tags in the owner name of the SRV record. >=20 > The cost of this is one more DNS query, but targeted at the precise > thing we're looking for, so no search pattern. And (IIUC) no scanning of the RDATA to discard the parts of the blob that are irrelevant to the instant context. [...] >=20 > > If the realm isn't really "at" $ORIGIN, a CNAME reference might be > > appropriate. > > > Hmm, that sounds like a nest of hornets to me, but it might work. I'm > not sure it is the best way though; references should contain their > KREALM explicitly and point at the realm name, and KREALM records > defining a home location for kerberos are always going to be local to > the DNS-name that they sort-of claim to hold. I wasn't sure that such administrative proximity (propinquity?) was to be counted on. Heel veel succes verder! Niall =20 From nobody Sun Sep 13 07:17:23 2015 Return-Path: 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 B6B3B1B2B55 for ; Sun, 13 Sep 2015 07:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.838 X-Spam-Level: * X-Spam-Status: No, score=1.838 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, J_CHICKENPOX_54=0.6, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 uNm2id60x4zr for ; Sun, 13 Sep 2015 07:17:19 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B481B2B49 for ; Sun, 13 Sep 2015 07:17:19 -0700 (PDT) Received: from [172.20.8.159] (rrcs-74-87-33-234.west.biz.rr.com [74.87.33.234]) by mail.frobbit.se (Postfix) with ESMTPSA id 8D44020203; Sun, 13 Sep 2015 16:17:16 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Rick van Rein" Date: Sun, 13 Sep 2015 07:17:14 -0700 Message-ID: <8A56371C-2D1C-4E22-B543-5AA2A0C9C04A@frobbit.se> In-Reply-To: <55F2B555.4050105@openfortress.nl> References: <55E868E8.6050504@openfortress.nl> <55F2A5CC.1080409@openfortress.nl> <55F2B555.4050105@openfortress.nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_A79E5803-8954-4F04-8D69-9F745ED72BD3_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.2r5107) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 14:17:20 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_A79E5803-8954-4F04-8D69-9F745ED72BD3_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 11 Sep 2015, at 4:04, Rick van Rein wrote: > HINFO uses precisely 2 strings, with KREALM it'd be variable, but could= be done with something like > > @ IN KREALM ( "realm=3DEXAMPLE.COM" "realm=3DEXAMPLE.ORG" > admin=3Dcarl "admin=3Dmary" > service=3DHTTP "service=3Dimap" ) Can you explain what you try to express with the statement above? Specifi= cally when two attribute/value pairs are not quoted, but others are. And be VERY specific and explain what data whoever has that looks up this= record. What data do the party have and what data do the party want. What we have somewhat bad experience with is to have selections made on t= he RDATA side of resource records (see NAPTR) and instead (as laid out in= RFC5507 and RFC6950). It sounds to me that the one looking for the record know it has domain na= me and service and looks for realm and admin? Where the two last ones can= be multiple. Or is the service also unknown and one want to know what se= rvices orb can be used? A subset of services available at this domain? In the draft I see: Two mappings are needed for the given scenario. One is a mapping from the FQDN of a service to its realm name; the other is a mapping from the realm name to the Kerberos-specific services such as the KDC. The latter mapping is published in SRV records [RFC4120] and such traffic is protected by the Kerberos protocol itself. The first mapping however, has hitherto not been standardised and is ill- advised over unsecured DNS because the published information is then neither validated by DNS nor does it lead to a protocol that could provide end-to-end validation for it. I though service+fqdn -> realm was using SRV, but the text here say that = that is what you try to fix with this new spec. Or is my english failing = me? Patrik --=_MailMate_A79E5803-8954-4F04-8D69-9F745ED72BD3_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlX1hWoACgkQrMabGguI181MCQCdF4uM0+KL7uSeEExqCFnygpAn bCYAn0tdV/H84NHA4aNVXpoSyqNjbK8p =Jk06 -----END PGP SIGNATURE----- --=_MailMate_A79E5803-8954-4F04-8D69-9F745ED72BD3_=-- From nobody Mon Sep 14 00:35:08 2015 Return-Path: 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 03D2E1A8932 for ; Mon, 14 Sep 2015 00:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 5A-ALK_A-XEN for ; Mon, 14 Sep 2015 00:35:04 -0700 (PDT) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8C21B5FED for ; Mon, 14 Sep 2015 00:35:03 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id Gvb01r00210HQrX01vb1NE; Mon, 14 Sep 2015 09:35:01 +0200 Message-ID: <55F678A2.6050101@openfortress.nl> Date: Mon, 14 Sep 2015 09:34:58 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Niall O'Reilly , Tony Finch References: <55E868E8.6050504@openfortress.nl> <55F2A5CC.1080409@openfortress.nl> <55F2B555.4050105@openfortress.nl> <55F2B79A.3010701@openfortress.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 07:35:07 -0000 Hi all, Clearly, I should take care of readable / writeable KREALM records, rather than stuffing things in base64. Very well... 1. I propose to introduce a "groupname" in each KREALM, used to group various records together like I wanted to do with KREALM records before. Where I wrote KREALM "realm=A,realm=B,realm=C,service=S,service=T" KREALM "realm=D,service=S" I was avoiding spelling out a cartesian product; the above was describing the realm-service combinations A-S, B-S, C-S, A-T, B-T, C-T, D-S An explicit group (arbitrary byte string that matches[*] to keep data together like the RDATA above did) can be used as a first argument like in KREALM 1 realm A KREALM 1 realm B KREALM 1 realm C KREALM 1 service S KREALM 1 service T KREALM 2 realm D KREALM 2 service S This enables the same compact notation to describe cartesian products, it lets us define alternate groups of those to handle exceptions and as a way to specify one-on-one definitions, and it fits into a fixed RDATA form that can be read and written by DNS admins without base64 tools. It also exploits existing DNS structures to manage data lists. [*] Don't know what "match" means yet. We might go for something kinky with wildcards, but that would complicate the data, complicate using it, and interpret the byte sequence in a particular manner, so my current gut feeling is to avoid being fancy and just use strcmp() 2. There are three or four use cases that I see as valuable at this time: 2a. Kerberos client (or his KDC) knows service name + hostname, and wants to find a realm name 2b. Kerberos node wants to find the case-sensitive realm name for a DNS name, in a secure manner 2c. Kerberos node wants to find manual contact information for a realm administrator (possibly "admin" pointers to a defining DNS node with RP, CERT, ...) 2d / optional. Kerberos client wants to perform service discovery under a realm and/or at a DNS name Based on these, I should be able to formulate the keys and search patterns for the data. It will probably also help me further materialise the home record distinctive feature. It will take me some time to collect my thoughts on this. Also, I intend to discuss it at the Kitten WG. Thanks! -Rick