Re: [dnsext] URI RRTYPE review - Comments period end Aug 15th

Phillip Hallam-Baker <hallam@gmail.com> Wed, 13 October 2010 18:06 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 046B03A69F5; Wed, 13 Oct 2010 11:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.272
X-Spam-Level:
X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 446viumJ7F+l; Wed, 13 Oct 2010 11:06:11 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E12683A69CD; Wed, 13 Oct 2010 11:06:10 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1P65ch-000CvF-Lh for namedroppers-data0@psg.com; Wed, 13 Oct 2010 18:00:23 +0000
Received: from mail-fx0-f52.google.com ([209.85.161.52]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <hallam@gmail.com>) id 1P65cT-000CuU-QN for namedroppers@ops.ietf.org; Wed, 13 Oct 2010 18:00:09 +0000
Received: by fxm16 with SMTP id 16so2974167fxm.11 for <namedroppers@ops.ietf.org>; Wed, 13 Oct 2010 11:00:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=fWVUC4hJD0zyMK1RUSN7LQuo/lfXU+DQWz2Xy9pajgw=; b=TLyY7WvFL7NWmNRmwfCjHuRXnLgaELyV+A9IC0ZiLzlAG1u3OmiHmvVBn+Gb7KSsXJ g1alAG4P89uVJdSVfE8ga+B7l0chIm8QE4xpzuBZ64FfltVbGusDTwsVYn8C7nnHrg9B nTCdaKGFYdQfEHWPoEYzk4D+OfgBMD8E8sv2M=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cMBZb1at/feC2jmX/BeVGhljHeDKamZi4DgxoN6CYV3iQknKFnWw3l+Ba91Qy1j0cZ q5HTH9pO+hbVJPSrjnFsRVotFhXG9z6n/4tNaGpsx8xWsL4FlidzEqouT3E1q/i/GaQa cKy/ieNxzuwbCmx+8p2ynJHkLf3GG/Y4Q16cw=
MIME-Version: 1.0
Received: by 10.239.180.140 with SMTP id i12mr611127hbg.140.1286992804005; Wed, 13 Oct 2010 11:00:04 -0700 (PDT)
Received: by 10.239.156.141 with HTTP; Wed, 13 Oct 2010 11:00:03 -0700 (PDT)
In-Reply-To: <B65EFD00-6580-4379-B586-F08F4500B381@cisco.com>
References: <20100725184119.GA42253@registro.br> <AANLkTikLbJwMLjzgyhFZ+fcc63-6wo0ccBb_CRgL2hw2@mail.gmail.com> <8E0002DF-09C9-46CD-AB1B-6DE946E3D0DC@cisco.com> <AANLkTinuNGYU_eoh5-Y=XJwmeo6psU_vPYt1vFAjq+Kk@mail.gmail.com> <C9DE16B6-3740-4670-955A-60448A14A7E8@cisco.com> <AANLkTi=W_6vP2wOfE0eiBNWviRXqHnKFuqNnOtt2Vwen@mail.gmail.com> <0058A35A-86AB-4BC8-A9C0-2DD92CA04265@cisco.com> <AANLkTimnZDATPy5Angw8o6rFQrmiQhfyvBNCjfTwV1KO@mail.gmail.com> <B65EFD00-6580-4379-B586-F08F4500B381@cisco.com>
Date: Wed, 13 Oct 2010 14:00:03 -0400
Message-ID: <AANLkTimjwgC+x_V8o1PFGUD_7FwnALmJ=phf690+W85r@mail.gmail.com>
Subject: Re: [dnsext] URI RRTYPE review - Comments period end Aug 15th
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "Patrik Faltstrom (pfaltstr)" <pfaltstr@cisco.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, Frederico A C Neves <fneves@registro.br>, namedroppers@ops.ietf.org
Content-Type: multipart/alternative; boundary=001485f2c18ce9490e0492835cb3
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

DDDS is a feature that can only be realistically added to a specification at
the time that the protocol is first defined. It is the same problem with SRV
and pretty much every other expanded discovery mechanism.

The point I am making about security policy is that security policy is a
feature that we can realistically retro-fit to existing protocols. We have
already applied security policy to SMTP via DKIM. We can usefully apply
security policy in many other contexts.


Since the additional functionality NAPTR provides over SRV is very similar
to the functionality that can be usefully added to a security policy
mechanism, there is probably not a great deal of milage in having a security
policy record that contains a flag saying 'you can get there better using
NAPTR'. But there is certainly a lot of value in a flag that says 'you can
get there better using SRV or URI'.

The way I think this would be presented to an application programmer would
be a replacement for gethostbyname where the caller specifies a DNS name, a
DNS protocol prefix, a default port number (optional) and a minimum set of
security criteria (optional) and the routine then returns the best
connection possible to a host providing the service.

So in this model the application programmer's mental model would not change
very much from gethostbyname.

If we later define new discovery mechanisms they can be used by any client
that has the appropriate library support.



On Wed, Oct 13, 2010 at 10:51 AM, Patrik Faltstrom (pfaltstr) <
pfaltstr@cisco.com>; wrote:

> On 13 okt 2010, at 15:13, "Phillip Hallam-Baker" <hallam@gmail.com>; wrote:
>
> Unfortunately, NAPTR does not have the ability to specify security policy
> information so the deployment incentives don't work the same.
>
>
> NAPTR only exists within a DDDS context, so that is up to your definition
> of the algorithm that uses the NAPTR.
>
> So I do not understand the above. Please expand.
>
>    Patrik
>
> SRV has existed for a decade now, yet we still cant get applications to
> bother to check it for no-brainer applications such as imap.
>
>
> If people care about security (an unproven hypothesis unfortunately) and
> are thus willing to check a DNSSEC signature chain, then I have to hope that
> they are willing to do an extra lookup to actually give that DNSSEC lookup a
> point.
>
> The biggest security hole in the Internet at the moment is the fact that
> security is an optional afterthought. So sites have to rely on people
> noticing the dorky padlock icon which means only that the communication was
> encrypted.
>
>
> DNSSEC deployment might not require an out of pocket cost, but that does
> not mean that the cost of deployment is 'free'. Just the fact that DNSSEC
> means that DNS deployment has to be done right means several hours extra
> work a year and that translates into higher administration costs.
>
> There has to be a compelling value provided by DNSSEC and merely defeating
> the Kaminsky attack on its own isn't enough.
>
> Provide protection against the downgrade attack however and suddenly you
> have a very compelling value with an immediate value to the client that
> cannot be realized any other way.
>
>
> An e-commerce site does not need to be very large for the value of a
> security policy record to be in the hundreds of dollars. For the major
> phishing targets it is in the hundred of thousands or millions.
>
> Making a case for better discovery techniques on their own is much harder
> since the cost of bandwidth continues to fall and the application providers
> have not seen a benefit to date.
>
>
> Which is why I think that a flag in the security policy record that says
> 'hey there is also a better discovery mechanism' is more powerful as a
> deployment strategy than a flag in the discovery record saying to use https.
>
>
> 2010/10/12 Patrik Fältström < <paf@cisco.com>paf@cisco.com>
>
>> On 12 okt 2010, at 21.30, Phillip Hallam-Baker wrote:
>>
>> > For example it
>> > could tell the client that it can use SRV or NAPTR or URI for enhanced
>> > discovery.
>> >
>> > <http://example.com>example.com  ESRV "prefix=_http._tcp,_imap._tcp"
>> > _http._ <http://tcp.example.com>tcp.example.com ESRV "tls=required
>> disc=srv"
>> > _http._ <http://tcp.example.com>tcp.example.com SRV 1 1 80
>> <http://site1.example.com>site1.example.com
>> > _http._ <http://tcp.example.com>tcp.example.com SRV 1 1 80
>> <http://site2.example.com>site2.example.com
>>
>> For me this is what NAPTR does...
>>
>>  <http://example.com>example.com. NAPTR 20 0 "s" "http" "" _http._<http://tcp.frobbit.se>
>> tcp.frobbit.se.
>>  <http://example.com>example.com. NAPTR 20 0 "s" "imap" "" _imap._<http://tcp.frobbit.se>
>> tcp.frobbit.se.
>> _http._ <http://tcp.example.com>tcp.example.com. SRV 1 1 80
>> <http://site1.example.com>site1.example.com.
>> _http._ <http://tcp.example.com>tcp.example.com. SRV 1 1 80
>> <http://site2.example.com>site2.example.com.
>>
>>   Patrik
>>
>>
>
>
> --
> Website: <http://hallambaker.com/>http://hallambaker.com/
>
>


-- 
Website: http://hallambaker.com/