On Mon, Aug 02, 2010 at 11:39:44AM +0200, Stefan Winter wrote: > Hi, > > > Well that, and SRVName. There are many other custom types > > defined by specific applications but those aren't the focus > > of this document. > > > > a closely related question to that. In one of my drafts, SRVNames are > used, but not directly. > > There is a S-NAPTR based algorithm which first tries to find a specific > S-NAPTR, and then follows the results from there (typically, via SRVName > to hostname to IP addresses). > If there is no S-NAPTR, a SRV query is tried. > > In the latter case, matching between the SRV record in DNS vs. > SAN-SRVName can be done, and the server id can be verified. > But in the former case, if S-NAPTR in DNS is forged, it is well possible > to drive the querying peer to a bogus SRV record, and an attacker can > have a (unrelated) certificate for this other SRVName. That was, the > querying host can be tricked into initiating a connection to a false > peer because it cannot verify that the NAPTR -> SRV step was correct. > > I've been thinking about a workaround for that. As much as I know, there > is no subjectAltName for NAPTR verification. So my only conclusion so > far is: using NAPTR can only work securely if requiring DNSSEC; so that > the NAPTR can't possibly be forged.
Stefan, Yes, I think I agree with your analysis. And even if there were a subjectaltname for NAPTR services, it appears that the components of the (service specific) identity you want to verify are in the RDATA of the NAPTR record, rather than the owner name of the record, so you need to secure the DNS mapping. > I wonder: is there another way of securing server discovery in the > presence of a NAPTR -> SRV redirection? Besides DNSSEC, or some other secure mapping service, I can't think of an obvious one. You'd need to figure out how to encode the service identity in the DNS query name, which is precisely the thing the S-NAPTR lookup is trying to find. > > And do you consider disususing this issue in your draft? > Are you proposing to just discuss this issue, or that we should try to find a solution to the problem? -- Shumon Huque University of Pennsylvania. _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
