Re: [kitten] Finding Kerberos Realm Descriptors in secure DNS

Rick van Rein <rick@openfortress.nl> Wed, 16 September 2015 06:52 UTC

Return-Path: <rick@openfortress.nl>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351951B37A3 for <kitten@ietfa.amsl.com>; Tue, 15 Sep 2015 23:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.601
X-Spam-Level:
X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 CIdqtXrnk4q5 for <kitten@ietfa.amsl.com>; Tue, 15 Sep 2015 23:52:04 -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 B1E151B37A9 for <kitten@ietf.org>; Tue, 15 Sep 2015 23:52:01 -0700 (PDT)
Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id Hiry1r00p10HQrX01irzVQ; Wed, 16 Sep 2015 08:51:59 +0200
Message-ID: <55F9118C.3050407@openfortress.nl>
Date: Wed, 16 Sep 2015 08:51:56 +0200
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: kitten@ietf.org
References: <55F686EA.30206@openfortress.nl> <55F6EA7C.8070608@mit.edu> <20150914161100.GC13294@localhost> <55F6F843.2070609@openfortress.nl> <55F7C3FA.5090802@openfortress.nl> <20150915073030.GD21942@mournblade.imrryr.org> <55F7CB98.6060300@openfortress.nl> <20150915144724.GJ21942@mournblade.imrryr.org>
In-Reply-To: <20150915144724.GJ21942@mournblade.imrryr.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/NiAGEjmLuh_DWbQdUUHCmuxJY5g>
Subject: Re: [kitten] Finding Kerberos Realm Descriptors in secure DNS
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2015 06:52:06 -0000

> The value of PTR records is
> returned verbatim by nameservers.  What's case insensitive is
> lookups derived from that name when you use it in a query string.

Below is why I believe that PTR can mangle the case of letters; both
from the specs and a practical demonstration.


Section 4.1 of RFC 4343:

No "case conversion" or "case folding" is done
during such output operations, thus "preserving" case.  However, to
optimize output, indirect labels may be used to point to names
elsewhere in the DNS answer.  In determining whether the name to be
pointed to (for example, the QNAME) is the "same" as the remainder of
the name being optimized, the case insensitive comparison specified
above is done.  Thus, such optimization may easily destroy the output
preservation of case.

Section 3.3 of RFC 1035:

The following RR definitions are expected to occur, at least
potentially, in all classes.  In particular, NS, SOA, CNAME, and PTR
will be used in all classes, and have the same format in all classes.
Because their RDATA format is known, all domain names in the RDATA
section of these RRs may be compressed.

<domain-name> is a domain name represented as a series of labels, and
terminated by a label with zero length.  <character-string> is a single
length octet followed by that number of characters.  <character-string>
is treated as binary information, and can be up to 256 characters in
length (including the length octet).

[...]

3.3.12. PTR RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   PTRDNAME                    /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

PTRDNAME        A <domain-name> which points to some location in the
                domain name space.


I've put this to the test, which turned out even more liberal; I defined
under $ORIGIN vanrein.org:

$ORIGIN vanrein.org.
_kerberos.mixedcase.ptrdemo     3600    IN      PTR    
MiXeDcAsE.VaNrEiN.OrG.
_kerberos.uppercase.ptrdemo     3600    IN      PTR    
UPPERCASE.VANREIN.ORG.
_kerberos.lowercase.ptrdemo     3600    IN      PTR    
lowercase.vanrein.org.

Passing this through ods-signer (from OpenDNSSEC) already maps the PTR
values to lowercase, probably as part of name canonicalisation in
preparation of signing.  Manually editing the ods-signer output to mixed
and uppercase again, reloaded it into the NSD name server... and again,
the PTR values are mapped to lowercase.

-Rick

P.S. If you want to query this for yourself, then note that the DNSSEC
chain isn't complete for this zone, so you won't get AD set in responses.