Re: [dane] Behavior in the face of no answer?

[Ondrej Mikle <[e-mail]>]

On 05/10/2012 11:41 AM, Tony Finch wrote:
> Ondrej Mikle <[e-mail]> wrote:
>> On 05/08/2012 09:46 PM, Tony Finch wrote:
>>> Ondrej Mikle <[e-mail]> wrote:
>>>>
>>>> From the ongoing scan, out of 70M currently finished .com domains,
>>>> SERVFAILs appeared for ~8.6M distinct domains.
>>>
>>> We're running validating resolvers and we haven't noticed that level of
>>> failure. What proportion of authoritative servers with working DNSSEC
>>> return SERVFAIL for what QTYPEs?
>>
>> The scans finished, here is a breakdown of what those SERVFAILs represented.
>> Short summary: As I expected, most of the domains are most likely
>> parked/unmaintained/speculative (by some whois queries, still SERVFAIL etc.)
>> Thus no reason for admin to care about them - that also means users won't ask
>> for them either.
> 
> For our purposes we need a breakdown of the "other RR" cases. The fact
> that 10% of domains have broken delegations is sad but it isn't going to
> confuse a DANE implementation into thinking there is an attack.

Sorry for the confusion, turns out the idea of posting the numbers before
everything is polished was not that great.

Don't get me wrong, I want to get DANE working as soon as possible. I even think
having some brokeness is not that bad (SW vendors may likely disagree). Many of
the scenarios described in this thread cause DoS with hard-fail, otherwise cause
downgrade attacks. But what about asking "how much" brokeness is there and "how
much" brokeness due to forcing hard-fail is "tolerable"? (so that we don't have
to make binary DoS-xor-downgrade-attack choice).

Simple proposal complementary to probing authNSs: TLSA will be implemented as
soft-fail at first, followed by a "TLSA day" (analogy of IPv6 day) where for
instance Google will place a small piece of code to test users' resolvers
(Google has unique position of having interest in TLSA and capability to do the
measurement of clients' resolvers).

The above paragraph is an engineering solution, not suitable as text for RFC,
but I fail to see any better alternative to binary option
hard-fail/downgrade-attack.


<apologies beforehand for following rant>

It's been the same with CRL and OCSP (hard fail - possible DoS, otherwise no
effect). In every client that supports it, I set OCSP to be required. Errors are
rather rare.

Unfixable exceptions which I'd just mark "problem of somebody else - we don't care":
- captive portals - central idea of being built on MitM is broken on so many
levels (why not just 802.1x? - I had always less problems with that)
- broken DNS resolver implementations - I've always seen them exclusively with
captive portals, but there few other "plastic home router boxes" for sure

If we keep piling up workarounds/special-code-branches for thoroughly broken
infrastructure pieces instead of showing error, things will get even more messy
and exploitable.
Take "transvalid" certificates as an example - TLS server doesn't send complete
chain, works for admin, works for most users, but not users with clean browser
profile. Hard to debug even for seasoned admins (who may be not experts in PKIX
implementation quirks). Too permissive protocol handling has track record of
leading towards vulnerabilities (OID decoder permitting leading 0x80 bug for
instance).

Solution (big maybe): software should _point_fingers_ with as
end-user-readable-messages-as-possible at whoever is responsible - resolver fail
at ISP/captive portal, CA for OCSP responder, etc.

There have been couple of attempts to detect such broken-by-design elements like
captive portals (e.g. ooni-probe). Brokeness should be pushed away, not worked
around - maybe some "You-misunderstood-Jon-Postel"-protocol-fascists action is
in order :-) (like the campaign against IE6)

</end rant>

Ondrej Mikle