>>>>> "Eliot" == Eliot Lear <lear@xxxxxxxxx> writes: I don't understand your statement. What's a decision process? Your DNS libraries definitely have a different trust validation process than your application TLS libraries. Your application is probably not entirely aware of its use of DNS; that's how we write apps today. Let's take a concrete example. I felt greate unease when I heard Patrik talk about getting support for the URI record added to libcurl. Imagine that's done, and by default libcurl will follow a URI RR redirection if it's DNSSec validated. I am using libcurl to talk to some cloud service. I've carefully configured libcurl's TLS parameters because I know exactly what I'm expecting. Let's say that I've done so in a way that's site specific. If libcurl is fetching the URI https://cloud.example.com/ then my validation rules apply. (I believe that libcurl has sufficiently rich callback interfaces to support this, but I get the various HTTP library capabilities confused) I have a fairly strict set of trust anchors for that URI because I know exactly what to expect. however, an attacker has managed to steal example.com's DNS registry account password and has compromised their zone. With a version of libcurl that does not support the URI rr, my application is vulnerable to a denial of service attack if they mess up the DNS zone, but I am not vulnerable to an attack on integrity of my interactions with the cloud services. However, now that libcurl follows the URI RR, since the attacker has compromised example.com's DNS zone, they can now redirect me elsewhere. And since the URI RR draft specifies we're going to do our TLS validation based on the target of the redirection rather than the source, my validation rules for cloud.example.com no longer apply, and so my security is likely weak enough to attack if the attacker can get a cert for a domain controlled by the attacker. OK, so perhaps libcurl should not default to following URI RR redirects. Fine. But we as standards authors need to help application authors understand the implications of turning on the URI RR. You probably don't want to follow URI RR if you're supplying a non-default TLS trust anchor set, pinning to a specific certificate or the like unless you're somehow supplying specific acceptable DNSSec trust anchors for the zones in question and not trusting the root trust anchor. Note, however that application TLS libraries ar much more customizable in their validation than application-layer DNSSec libraries. In practice TLS allows application security policy to be specified, but DNSSec seems to use one global security policy. I understand that's not inherent in the standards, although the way the two standards are written does contribute to it. It does seem true in the code for TLS and DNSSec I'm aware of, and it is to the best of my understanding a practical reality for authors of applications.