Sent from my iPhone
> On Nov 1, 2019, at 4:27 PM, Ted Hardie <[email protected]> wrote:
>
>
> (cutting a good bit)
>
>> On Fri, Nov 1, 2019 at 12:54 PM Brian Dickson
>> <[email protected]> wrote:
>>
>>
>> If the attacker does not have access to the timing data, IMHO the R2A
>> queries expose no PII, since the query data cannot be associated with an
>> originating client.
>
> In the cases where EDNS Client Subnet is used, it does seem to associate the
> query with a pool of potential clients even when there is no timing data;
> depending on the size of that pool, this could easily represent a loss of
> privacy.
Yes, ECS adds a whole extra dimension to the problem space. The particular
issue arises entirely due to the source of the need for ECS.
It is an additional argument against centralization, at least from the
perspective of comparing no-ECS to ECS. I think this was already telegraphed by
Mozilla’s TRR requiring encryption to auth for use of ECS.
The degree of information leakage is probably some function of the granularity
of ECS prefixes and the number of active clients on each ECS subnet, on a per
name basis.
>
>> In this case, an on-path active attacker isn't actually a threat (!!).
>>
>
> Even without EDNS Client subnet, the active attacker now has access to new
> targeting data. Let us say that the active attacker sits in front of
> vlogsite.example. If the attacker sees a query for
> free-disputed-territory.vlogsite.example, the information that specific
> recursives are seeing that traffic may be of interest to one or more of the
> parties disputing the territory.
I think you mean the attacker sits in front of the nameserver for
vlogsite.example?
Maybe, but that prerequisite location is relative to the recursive and
authoritative. In some cases, that may be a tautology (recursive is inside a
given region, where all traffic exiting is known to be monitored, and the
authoritative is outside). There may not be a privacy solution available at
all, or not legally permitted.
I don’t doubt the interest of the attacker. I question whether additional DNS
protocol stuff to address that specific issue has value if the eventual data
traffic isn’t equally protected from detection (eg SNI), or whether that
particular problem might be addressed better with a non-DNS-only solution.
>
>
>> If this strategy is used, this creates an interesting side effect. On a
>> busy enough resolver, the regular cache refresh traffic may be significant
>> enough to negatively impact timing attacks against encrypted C2R traffic in
>> determing IP/QNAME matches, even if port 853 is blocked and all traffic is
>> on port 53.
>
>
> This is similar to the logic this working group used to conclude that doing
> the client-to-recursive first was the right choice. I don't think the fact
> that it is still true when port 853 is blocked refutes the advantages of
> encrypting recursive to authoritative traffic.
>
Me neither. The point was more about the fact that an active attacker needs to
reveal her existence, and the above assertion was that the attacker’s goal
would not be guaranteed (and thus affecting the risk/reward math, possibly
enough to discourage the attempt).
>
>> This risk needs to be given context, specifically where are the client, the
>> recursive, and authoritative, and whether an attacker is able to block port
>> 853 to cause the downgrade?
>> The current passive attack does not require the attacker to expose her
>> existence, while port blocking reveals the existence (if not the identity)
>> of the attacker.
>
> I think Eric's point is different from a standard downgrade by port blocking.
> If the attacker is on path and there is no authentication of the
> authoritative server, then a back-to-back user agent can be used to eavesdrop
> on the query traffic. Your recursive makes a TLS connection to the attacker
> and sends a query; the attacker reads it and retrieves the answer from the
> authoritative server in order to provide you a reply. You get the right
> answer (and can even use DNSSEC to check it), but the query stream still
> leaked to the attacker. This is an active attack (because the attacker
> terminates the TLS connection and starts a new outbound connection), but the
> result is equivalent to what a passive attacker would get from port 53 data.
Yes. So doing DoT without DNSSEC to protect against name tampering could allow
an active attacker to MITM.
That point should be part of the operational recommendations: sign the name and
addresses and ideally use TLSA.
(It also puts similar requirements on resolvers to validate the same data).
Regards,
Brian
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
