Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "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.





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]