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

["Patrik Faltstrom (pfaltstr)" <[e-mail]>]

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]>
> 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.
> >
> > example.com  ESRV "prefix=_http._tcp,_imap._tcp"
> > _http._tcp.example.com ESRV "tls=required disc=srv"
> > _http._tcp.example.com SRV 1 1 80 site1.example.com
> > _http._tcp.example.com SRV 1 1 80 site2.example.com
> 
> For me this is what NAPTR does...
> 
> example.com. NAPTR 20 0 "s" "http" "" _http._tcp.frobbit.se.
> example.com. NAPTR 20 0 "s" "imap" "" _imap._tcp.frobbit.se.
> _http._tcp.example.com. SRV 1 1 80 site1.example.com.
> _http._tcp.example.com. SRV 1 1 80 site2.example.com.
> 
>   Patrik
> 
> 
> 
> 
> -- 
> Website: http://hallambaker.com/
>