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. I wonder: is there another way of securing server discovery in the presence of a NAPTR -> SRV redirection? And do you consider disususing this issue in your draft? Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
signature.asc
Description: OpenPGP digital signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
