On Apr 29, 2020, at 8:01 PM, Shumon Huque <shu...@gmail.com> wrote: > > On Wed, Apr 29, 2020 at 7:30 PM Ted Lemon <mel...@fugue.com > <mailto:mel...@fugue.com>> wrote: > The question is, if the stub resolver can validate, and has been asked to > validate, in that case what do we do if the CNAME is not in a secure zone? > Your response makes it sound like you know the answer, but I don’t think it’s > specified anywhere. So I’m asking (a) if anybody knows that is specified > somewhere, and if so where, and (b) if it is not specified, what do we all > think the correct answer is. > > If there is an unsigned CNAME (or DNAME) in the path the answer, then I'm > 100% sure that the answer cannot be deemed authenticated. You may be right > that this case is not clearly explained in the spec (I can't recall really, > maybe some else can quote specific text if they know). But conceptually, > DNSSEC requires you to prove an unbroken chain of authenticated signatures > from the queried name back to the trust anchor (including paths redirected > via aliases). Otherwise attackers have a trivial points (the unsigned > aliases) at which to spoof answers.
I don’t think that’s the issue in this case. The CNAME wasn’t signed, so there was never any question of the answer being protected from spoofing. Your conclusion seems unassailable—this answer can’t be called authentic. > The answer obtained is still viable, just insecure. Downstream clients of the > stub that need confirmed authenticated answers (e.g. DANE) could determine > this by inspecting the AD bit in the response from the stub. > > Your answer actually brings up a second, also interesting, question: if a > stub resolver sets the DO bit, and the CNAME is not in a secure zone, but the > answer is in a secure zone, do we set the AD bit? It looks like according to > RFC4035, section 3.2.3, we do not. So in that case, is the resolver obliged > to validate the answer it gets by following the CNAME? It can’t set the AD > bit in this case, right? > > It definitely can't set the AD bit. So, I suppose your argument is why bother > authenticating the target. That's a defensible question. It might be > reasonable behavior if the stub has no cache. But I'd expect validating stubs > to have some sort of cache to amortize the cost of extra queries and > computation. If it's caching, then the unvalidated target cannot reasonably > be returned if a subsequent query comes directly for the target, so why would > it not bother to validate it earlier. To be clear, I think that if we’ve been asked to do DNSSEC, we should always validate what we can when the answer includes some data that is provably insecure and some data that is provably secure and can be validated. I just don’t think the specs explicitly say that, so I’m wondering if people agree with me on this.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
