Nico
On Friday, March 6, 2015, John C Klensin <john-ietf@xxxxxxx> wrote:
On Friday, March 6, 2015, John C Klensin <john-ietf@xxxxxxx> wrote:
--On Friday, March 06, 2015 07:28 +0100 Patrik Fältström
<paf@xxxxxxxxxx> wrote:
> Thanks for the comments. While digesting them, I have one
> comment:
>
>> On 6 mar 2015, at 07:14, John C Klensin <john-ietf@xxxxxxx>
>> 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