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

[Phillip Hallam-Baker <[e-mail]>]

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) <
[e-mail]> wrote:

> On 13 okt 2010, at 15:13, "Phillip Hallam-Baker" <[e-mail]> 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 < <[e-mail]>[e-mail]>
>
>> 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/