> On 26 Jul 2024, at 04:41, Bellebaum, Thomas > <thomas.belleb...@aisec.fraunhofer.de> wrote: > >> 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?
DNSSEC signed and validated as secure. > Which SRV records are to be investigated exactly? From the example above the ones returned by the query for _imaps._tcp.domain.tld. If the target in the SRV records rdata do not end in the labels domain.tld then ask the user if we should trust this response. If the target was imap.domain.tld then the IMAP client doesn’t have to ask the user. There is some risk here as the additional A and AAAA records could be compromised. Additionally if there is a CNAME returned the target of that need to be below domain.tld or raise a flag. This applies to the whole CNAME chain. Now the IMAP client could as the user whenever the DNS response was not signed and validated as secure but the above was a pragmatic response to the slow deployment of DNSSEC. Remember the IMAP client can use DNSSEC to verify the answers returned. That is the desired end state for DNSSEC. Having resolvers verify answers is just protecting the caches from garbage. > 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. DNSSEC’s job is to ensure the client can verify the answers it receives are as they where entered. If the answers are provably not signed you are running on a wing and a prayer. If you don’t bother to check if they are signed you are running on a wing and a prayer. > 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. People have been told to sign their zones and to verify the answers. We have millions of resolver out there that are trying to verify as secure every response they get. > > -- Thomas > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
