Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

[John C Klensin <[e-mail]>]

--On Friday, March 06, 2015 07:28 +0100 Patrik Fältström
<[e-mail]> wrote:

> Thanks for the comments. While digesting them, I have one
> comment:
> 
>> On 6 mar 2015, at 07:14, John C Klensin <[e-mail]>
>> wrote:
>> 
>> Generally, while I think you should warn that URI records may
>> cause some risks that do not exist with, e.g., conventional
>> name to address mappings (note that the "downgrade attack or
>> not" considerations above would apply equally well to:
>> 
>>  foo.example.com.  IN A 10.2.0.44
>> being diverted into a response of
>>  foo.example.com.  IN A 10.0.0.6
>> 
>> (which would be, historically, a likely upgrade attack, but it
>> has nothing to do with URI records but is equally preventable
>> by an integrity check.))
>> 
>> As long as there is a warning, I really don't care very much
>> what you say, but whatever you do say should be as accurate as
>> possible.
> 
> I also see tons of zeroconf stuff (Apple Bonjour) using DNS
> already today in the geographically local context without much
> DNSSEC.

I think that strengthens the argument for some Applicability
Statement action about DNS-related threats, trust models, and
attacks that integrity checks do or do not protect against
rather than trying to push too much off on this particular
document.  I still don't have a strong opinion about where the
optimal boundaries lies, but I don't think it is rational for
the IETF to not do the A/S work but then hold up individual
documents because they don't contain all of the discussion that
A/S might contain.

That said, if the IETF considers it to be a valid implementation
of DNSSEC to have the closest-to-user validating system be an
ISP-based forwarder rather than a machine on the user's LAN,
there isn't a lot of point in building DNSSEC capability into
zeroconf stuff that is mostly applicable intra-LAN or otherwise
within a trust perimeter that the DNSSEC validator is outside of.

Put differently, any time a DNSSEC-based trust model comes down
to "trust your ISP", then it is pointless overhead for any of us
who already know our ISPs can't be trusted.  And _that_ is why
I'm reluctant to see it oversold in circumstances like the
current document.

    john