Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

Olafur Gudmundsson <ogud@ogud.com> Mon, 08 November 2010 22:47 UTC

Return-Path: <ogud@ogud.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5CEC3A6904 for <keyassure@core3.amsl.com>; Mon, 8 Nov 2010 14:47:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T944iYnZSEMP for <keyassure@core3.amsl.com>; Mon, 8 Nov 2010 14:47:09 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 015953A68FF for <keyassure@ietf.org>; Mon, 8 Nov 2010 14:47:08 -0800 (PST)
Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id oA8MlSwr005762 for <keyassure@ietf.org>; Mon, 8 Nov 2010 17:47:29 -0500 (EST) (envelope-from ogud@ogud.com)
Message-ID: <4CD87E00.1090906@ogud.com>
Date: Mon, 08 Nov 2010 17:47:28 -0500
From: Olafur Gudmundsson <ogud@ogud.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: keyassure@ietf.org
References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <p0624084ec8ef630fbae1@10.20.30.151> <4CC9E7AB.1030501@cs.tcd.ie> <p0624086dc8ef9feba340@10.20.30.151> <B6CEBA10-0198-4AB3-B6D4-E7D835FD47F1@princeton.edu> <AANLkTin-CqduBX5ibUCb0+1Lr-GXJ-KGd8YxzjUTPEO7@mail.gmail.com> <CA58B286-8F9D-423D-B9BF-91347F6FD960@Princeton.EDU> <1288462840.1977.4.camel@mattlaptop2.local> <69345A7D-4834-40E4-99C2-EDF3FC2DDEB3@Princeton.EDU> <1288469609.1977.178.camel@mattlaptop2.local> <EAC89FC3-184C-449C-AE5B-E3950578ED30@Princeton.EDU> <1288477403.1977.319.camel@mattlaptop2.local> <m3wroz6x81.fsf@jhcloos.com> <B255379A-6B1A-4E0B-AC66-EAD8F4B62040@kumari.net>
In-Reply-To: <B255379A-6B1A-4E0B-AC66-EAD8F4B62040@kumari.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Nov 2010 22:47:11 -0000

On 10/30/2010 09:02 PM, Warren Kumari wrote:
>
> On Oct 30, 2010, at 8:07 PM, James Cloos wrote:

> Another option (which has some (IMO) of the elegance retained, but
> probably has scalability and leakage issues) is
> foo.example.com <http://foo.example.com> IN A 192.0.2.1
> IN KIDNS 443 545254634563546354
> IN KIDNS 993 435245243523452345
> IN KIDNS 5222 23452345435234545
> ) -- basically, have the records for foo.example.com
> <http://foo.example.com> (or just exmaple.com <http://exmaple.com>) all
> at the same level, but have the ports included in the response.
>
>>
>> Or both, preferring the more specific if both exist?
>
> Oooh, that's interesting -- to be honest I hadn't thought of that... One
> huge consideration is minimizing the number of DNS lookups needed to
> make all the magic happen -- if this system requires lots of lookups,
> the browser folk will be unwilling to implement as the user experience
> will be horrendous....
>
>>
>> The more specifc option permits different certs for, eg, _http._tcp
>> vs _smtp._tcp vs _sip._tcp, but also means maintaining probably
>> identical RRs for eg _sip._tcp, _sip._udp and _sip._sctp.
>>
>> I can see how each might be perceived as necessary, but also how each
>> might be perceived as undesirable.
>
> Yes, both are (IMO) sub-optimal -- my *personal* view of the world

Rule #1 in DNS land: Do not optimize until you know exactly what the 
problem is as most "design" optimization have turned out to be bad
for protocol or operations.

> involves having unique names for each service (www.example.com
> <http://www.example.com>, imap.exmaple.com <http://imap.exmaple.com>,
> jabber.example.com <http://jabber.example.com>) which sidesteps this
> issue, but enough folk have raised this issue that it needs to be
> addressed....
>
>

There are multiple ways to address this, in general DNS people recommend 
strongly against "sub-typing" i.e. having multiple different protocols 
share the same RRset.
There are number of issues here to think about:
	size of the RRset
	Number of foot prints per protocol/port
	How is/are the RRsets are maintained, in particular is
		dynamic update used.

Think about operations for a minute, if the 'web' team has write access 
via dynamic update to the web KIDNS rrset then they maintain it without
involving the 'dns' team.
Now having the 'mail', 'web' and other protocols share one set then all 
of them either need write access or to involve the 'dns' team for 
arbitration.

As Chome has demonstrated there it is not that hard to have multiple 
queries in flight at the same time, in general the rule should be
"prefer more specific".

Additionally there may be different ways to reach the same service,
like www.foo.bar and foo.bar. are then two copies of KIDNS records 
stored or does the protocol need KIDNS_ALIAS [<port>] <name> that has
pointer to the real set?

I want to emphasize Jakob's point that it is important to differentiate 
between where service is described (MX) and where it is provided (A 
records).

	Olafur

	Olafur