On Thu, Apr 23, 2020 at 7:09 AM Vladimír Čunát <vladimir.cunat+i...@nic.cz> wrote:
> On 4/22/20 9:32 PM, Shumon Huque wrote: > > Since delegation records and glue address records are unsigned, they > > can be spoofed, and DNSSEC should really allow us to detect such > > spoofing once a resolver sees referral data. > > I wouldn't put much energy into improving this part in *this* draft. > No worries! As I said at the DNSOP interim meeting yesterday, we are *not* planning to take that problem on in this draft at all. That was more of a side conversation because the topic has come up. You can also argue that this is not technically a security issue, since the misdirection is detected later on. So this is an issue of efficiency and early detection, that arguably is not critical. Even DNSSEC-validated NSs and IPs aren't sufficient to ensure privacy, > so I'd rather kill this problem by proper encrypted protocol towards > authoritatives (in current dprive charter). > DNSSEC of course does not address privacy, that much is clear. But I don't think I agree that encrypted transport addresses the data authentication issue here. In the general case, the DNSSEC security model does not rely on the security of the authoritative servers themselves, but on the entities that perform the signing. Encrypted and authenticated transport can verify that you are obtaining the DNS response unmolested from the correct authority server, but it doesn't protect you against compromise of the server itself. DNSSEC protects you against this, if the signing system is separately secured, as is the case with the DNS root, many of the TLDs, and many enterprise deployments that use hidden and inaccessible signing masters. This is of course not true for the various online signing deployments. In those cases, transport security is a more complete solution (because the signing keys are already exposed at the edges of the authority server network). Shumon Huque
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop