On Mon, 15 Feb 2016, Stephen Farrell wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
- In section 3 you promised me privacy considerations in section
8 but I didn't find any there. That was almost a DISCUSS, but
since fixing it is easy and I assume won't be controversial I
can stick with a YES ballot:-)
- I would suggest that you do note in section 8, that the fqdn
in the CHAIN option could allow an attacker to (re-)identify a
client. E.g. if the attacker sees that you have validated
tetbed.ie before that could single you out, even if you have
changed your n/w, cilent IP address etc. Presumably that would
be a relatively long lasting concern as well, as RRSIG expiry
tends to be weeks ahead. I think just noting that and maybe
saying that DPRIVE is a likely mitigation would be a good thing
to do.
I have added the following two sections to the security considerations.
Let me know if that addresses your concerns:
8.1. Additional work and bandwidth
Producing CHAIN answers incurs additional load and bandwidth on the
Recursive Resolver. At any time, a Recursive Resolver may decide to
no longer answer with CHAIN answers and fall back to traditional DNS
answers.
[8.2 was the original section regarding Amplification]
8.3. Privacy Considerations
A client producing CHAIN queries reveals a little more information
about its cache contents than regular DNS clients. This could be
used the fingerprint a client across network reconnections. If DNS
privacy is a concern, a CHAIN query client MAY try to use a DNS
transport that provides privacy, such as [DNS-over-TLS] or a trusted
DNS server that is contacted through a VPN connection such as IPsec.
I believe that resolves the "promises" in Section 3.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
