Re: [kitten] Fwd: New Version Notification for draft-vanrein-dnstxt-krb1-05.txt

Rick van Rein <rick@openfortress.nl> Fri, 25 September 2015 15:49 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 483941A8FD5 for <kitten@ietfa.amsl.com>; Fri, 25 Sep 2015 08:49:23 -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 BOUWi8dqcqiW for <kitten@ietfa.amsl.com>; Fri, 25 Sep 2015 08:49:21 -0700 (PDT)
Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A8F1A6FF8 for <kitten@ietf.org>; Fri, 25 Sep 2015 08:49:20 -0700 (PDT)
Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id MTpG1r00a10HQrX01TpH15; Fri, 25 Sep 2015 17:49:17 +0200
Message-ID: <56056CFA.2000609@openfortress.nl>
Date: Fri, 25 Sep 2015 17:49:14 +0200
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>
References: <20150915143628.21162.89108.idtracker@ietfa.amsl.com> <55F82DA5.10504@openfortress.nl> <alpine.GSO.1.10.1509172254390.26829@multics.mit.edu> <55FBF0C8.6090904@openfortress.nl> <20150918140247.GB13294@localhost> <20150918153219.GP21942@mournblade.imrryr.org> <55FC4A37.9020305@openfortress.nl> <55FD5F8B.8050807@openfortress.nl> <55FD8806.5070909@mit.edu> <560136F2.3010509@openfortress.nl> <56016C88.6060708@mit.edu> <56054183.6010401@openfortress.nl> <5605628C.2000201@mit.edu>
In-Reply-To: <5605628C.2000201@mit.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/apjQOll_Kv2kTg2NIvfdFZN4CcA>
Cc: kitten@ietf.org
Subject: Re: [kitten] Fwd: New Version Notification for draft-vanrein-dnstxt-krb1-05.txt
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: Fri, 25 Sep 2015 15:49:23 -0000

Hello Greg,

> To be clear, I wasn't arguing that we can't do case correction of realm
> names.  I was arguing that we would need to extend RFC 4120 to allow
> case correction TGT responses, and require that clients implement this
> extension if they implement PTR realm lookups.

Yes, you were clear and quite helpful, in pointing out both a practical solution and explaining where precisely it clashes with current RFC 4120 practice.  Thank you!

> I have no strong opinion on whether the extra work of extending RFC 4120
> is worth it.

I have no idea of the extra work involved; or the time delays?  Its only benefit would be that we would use PTR instead of TXT.  I am willing to put some effort in either way, but also feel this relatively simple first step shouldn't drag on for too long; there are others things I would like to put my energy in, such as KRB5-KDH, TLS-KDH and DANE-based realm crossover.

Benjamin said that anything that overrides RFC 4120 ought to be a WG effort, but if it is limited to just this than we could also consider that path, if others prefer that over documenting _kerberos TXT under DNSSEC.  From what I've sampled so far, everyone considers TXT to be a suitable alternative.

Meanwhile, I found in RFC 4846 that the intention of an Independent Submission is to propose alternatives to IETF work, which is okay as long as it is perfectly clear that it is an alternative.  But a WG document, or a solution that doesn't interfere with existing WG documents, is still preferred I think, in light of getting things actually used in software.

Cheers,
 -Rick