> The IETF does not create standards for APIs. So a validating stub resolver is > > not really something that can be defined, because it is not a protocol.
I beg to differ here. It may not be strictly part of the DNS protocol, but then this logic needs to be a part of every single protocol dependent on DNS. Consider e.g. IMAP, something which clearly is a network protocol. There is a very convenient RFC 6186, specifying how to use DNS to locate an IMAP service. Even if you would not call this a network protocol, it clearly is within IETF scope (and on Standards Track). TL;DR: The TLS-secured IMAP server for localp...@domain.tld is whatever the SRV record at _imaps._tcp.domain.tld points at, and you can proceed sending localpart's password there in an attempt to authenticate. It should be clear that there are problems which may arise in this protocol if the used SRV records' targets can be influenced by an attacker. To do some damage control, RFC 6186 thus specifies: > In the absence of a secure DNS option, MUAs SHOULD check that the target FQDN returned in the SRV record matches the original service domain that was queried. If the target FQDN is not in the queried domain, MUAs SHOULD verify with the user that the SRV target FQDN is suitable for use before executing any connections to the host. What exactly does "secure" mean here? Which SRV records are to be investigated exactly? Most protocols do not tell, instead referring to the DNS. If effect, this gap between protocols is what leads to problems, and there is no specification that seems to have adequate security considerations addressing these points. Keep in mind, IMAP is only an example here. To ensure the security of network protocols all throughout the IETF (and beyond), there has to be a clear API. Not for applications, but for other protocols. As a related example: HKDF defines an API, which most client libraries do not copy exactly. This is fine, but the clear definition allows e.g. TLS to depend on HKDF, and be a verifiably secure protocol. The same should apply to DNS and its interaction with the wider internet. -- Thomas
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
