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

Rick van Rein <rick@openfortress.nl> Fri, 04 September 2015 06:38 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 234081B3815 for <dnsext@ietfa.amsl.com>; 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 <dnsext@ietfa.amsl.com>; 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 <dnsext@ietf.org>; 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 <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Mark Andrews <marka@isc.org>
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: <http://mailarchive.ietf.org/arch/msg/dnsext/V74OTC-NCbN5kJbh0goEgwNRXOs>
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, 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