Florian Weimer wrote:

> The document lacks a clear threat model and problem statement. As a
> result, is not possible to check whether the proposed protocol actually
> solves anything.

I had several things listed but they were removed by suggestion of Paul
Vixie as he felt the conversation would be distracted by that rather
than the draft or similar proposal.

> Sections 2 and 3 do not really describe the on-the-wire protocol.

What was lacking?

> CERT Glue records (section 4) won't work without changing all recursors
> (and probably authoritative servers, too). This means that this
> proposal has near zero chance of deployment.

With all the changes needed to facilitate DNSsec, and people still
pushing ahead trying to get it deployed I fail to see why this would be
a sticking point.

I've had a rethink on this due to hitting 512 byte boundaries today with
mutliple host keys causing issues for cache servers that don't speak
EDNS and listing the fingerprint seems to be a better idea, especially
since OpenPGP keys can be cached, there will be a small delay the first
time a key needs to be found but after that the local keyring could be used.

> As far as I can see, the proposed protocol, if worked out in full,
> solves two problems (data leaks across the hierarchy and eavesdropping
> on the wire) but doesn't do anything about enumeration and information
> leaks from caching resolvers.

There is no way this would prevent enumeration any more than SMTP-TLS
prevents spam, brute force attacks can be dealt with on the server by
tracking IPs and/or sequential requests, but this wouldn't prevent a
very clever attacker that has a large bot net that does a distributed
brute force attack in a non-sequential manner.

As for information leaking from caching resolvers, that depends on the
programmers of the software in question and how well they implement
things to prevent such leaks occurring, and/or local caching
implementing something similar for end to end encryption by passing
caches in the middle altogether, it really depends on how secure you
need to be for your application. Not everything needs to be 100% secure
all the time, although that would be nice.

Thanks for your feed back.


Best regards,

to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.