Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery?

Jeffrey Altman <jaltman@secure-endpoints.com> Tue, 17 May 2016 21:09 UTC

Return-Path: <prvs=1945b5244a=jaltman@secure-endpoints.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB8612D615 for <kitten@ietfa.amsl.com>; Tue, 17 May 2016 14:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level:
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=secure-endpoints.com
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 1RJT-3RqONbX for <kitten@ietfa.amsl.com>; Tue, 17 May 2016 14:09:02 -0700 (PDT)
Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B3E12D1DF for <kitten@ietf.org>; Tue, 17 May 2016 14:09:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1463519319; x=1464124119; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:From:Openpgp:Organization:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; bh=rV5RtfKaSRER1sbm8TJ2F5 xF1LqP7lEyRyAtVFHx+bA=; b=dnFx9seqAuu9nsk2pAItwsrorOGhym7sqRM1ZJ nrOWbLI4m5VT/fI37ydx6Wdh4Upfl1XGw/QkGaqabsEBBb4+8JYjChhlFo3ar7qI xSI+5EygJ9GUwrZXIWcuqgLDv8d+gtvuOSjYfUdmeq1SIykF18XKELY+IGvjo9ju L2C9w=
X-MDAV-Result: clean
X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Tue, 17 May 2016 17:08:39 -0400
X-Spam-Processed: sequoia-grove.secure-endpoints.com, Tue, 17 May 2016 17:08:39 -0400
Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v16.0.2) with ESMTPSA id md50001089594.msg for <kitten@ietf.org>; Tue, 17 May 2016 17:08:39 -0400
VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org;
X-MDArrival-Date: Tue, 17 May 2016 17:08:39 -0400
X-Authenticated-Sender: jaltman@secure-endpoints.com
X-Return-Path: prvs=1945b5244a=jaltman@secure-endpoints.com
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: kitten@ietf.org
To: Nathaniel McCallum <npmccallum@redhat.com>, kitten@ietf.org
References: <1463500163.2432.9.camel@redhat.com> <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> <1463517801.2432.24.camel@redhat.com>
From: Jeffrey Altman <jaltman@secure-endpoints.com>
Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu
Organization: Secure Endpoints Inc.
Message-ID: <490bd7aa-81ca-9199-6687-222bb65caddf@secure-endpoints.com>
Date: Tue, 17 May 2016 17:08:32 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <1463517801.2432.24.camel@redhat.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070801070004010306000700"
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/d84pOpvfeTAFZ0_J4x58RFf3P54>
Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery?
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 17 May 2016 21:09:03 -0000

On 5/17/2016 4:43 PM, Nathaniel McCallum wrote:
> We will need to add at least one more DNS query to support MS-KKDCP
> (two if we have to treat http and https as separate queries). This is
> unavoidable. While it is true that this will result in a 50% increase
> in DNS queries, using my URI scheme means that a simple administrator
> configuration can turn this 50% increase into a 50% decrease in queries
> over the existing implementations. This is a win.

As an implementer I can tell you that it would be more than a decade
before I would ever be able to remove existing lookup methods and
possibly even longer than that.

As a deployer of a realm I can tell you that I have no control over
updates of Kerberos libraries in the clients.  Clients are deployed long
after the 10 year lifetimes of the operating systems and new features
such as this are not backported into prior OS distributions.
As such I would be unable to rely upon URI as a replacement for SRV for
more than 10 years.  I would be required to publish both URI and and SRV
lookup records forever.

You have described a reason why URI lookups are necessary for MS-KKDCP.
Please restrict your draft to that case.

Sincerely,

Jeffrey Altman