Ok, I understand what you are saying. The changing of the origin that gets validated is the fundamental no no. Eliot On 2/27/15 4:18 PM, Sam Hartman wrote: >>>>>> "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. > >
Attachment:
signature.asc
Description: OpenPGP digital signature