Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19

From: Mark Andrews <[email-masked]>
Date: Tue, 01 May 2012 10:14:39 +1000

In message <[email-masked]>, Martin Rex writes:
> Tony Finch wrote:
> > 
> > Martin Rex <[email-masked]> wrote:
> > 
> > > > > The security properties of any MX, CNAME, A or AAAA lookups during
> > > > > connection establishment with that server are irrelevant for DANE
> > > > > (and invisible to PKIX).
> > > >
> > > > RFC 6125 allows for secure name indirections.
> > >
> > > Which _secure_ name indirections are you thinking of?
> > 
> > RFC 6125 says:
> > 
> >    The client might need to extract the source domain and application
> >    service type from the input(s) it has received.  The extracted data
> >    MUST include only information that can be securely parsed out of the
> >    inputs (e.g., parsing the fully qualified DNS domain name out of the
> >    "host" component (or its equivalent) of a URI or deriving the
> >    application service type from the scheme of a URI) or information
> >    that is derived in a manner not subject to subversion by network
> >    attackers (e.g., pulling the data from a delegated domain that is
> >    explicitly established via client or system configuration, resolving
> >    the data via [DNSSEC], or obtaining the data from a third-party
> >    domain mapping service in which a human user has explicitly placed
> >    trust and with which the client communicates over a connection or
> >    association that provides both mutual authentication and integrity
> >    checking).
> 
> 
> One should not confuse DNSSEC protection of DNS records (which provide
> only data integrity and data origin authentication) with the concept
> of a secure directory service providing name translations.

When you add a CNAME you are asserting that the canonical name for
the owner of the CNAME is the target of the CNAME.  CNAME does NOT
mean "hosted at" which is how HTTP{S} treat CNAME.  CNAME *really*
should change the expect name of any CERT, unfortunately nobody
asked for a "hosted at" record for HTTP{S} and the closest fit in
the existing records was CNAME.

> Sprinkling security equally across all DNS records also seems like
> a bad idea.  I think it would be much more sensible to limit the
> security-relevant DNS records (and indirections allowed for them)
> to _very_ few records, and preferably all _new_ records, because
> DNSSEC-less zones will be with us for many years to come, and
> 
> I believe it would be a really bad idea to change the sensitivity
> of existing DNS records underneath DNS registrar's feet.

All the records registrars handle require and always have required
protection from unauthorised updates.  DNSSEC has not changed that.
If your registrar is not performing that service properly pick a
different registrar.  The world is assuming that all registrars are
providing data protection for the records being added.

> For TLSA records it would be OK if DNS software (and DNS servers)
> performed some plausibility checks, e.g. warn prominently if TLSA
> records are present in a Zone but no DNSSEC is active for the zone.
> Something which does not make sense for any of the traditional
> DNS records.

The TLSA record is just ignored if it is insecure.  Note it can
be signed yet still be insecure as far as the client is concerned.

> Looking at the example from a previous post:
> 
> >
> > ;; QUESTION SECTION:
> > ;universalmusic.com.      IN  MX
> >
> > ;; ANSWER SECTION:
> > universalmusic.com.  3600 IN  MX   10 mail.global.frontbridge.com.
> 
> For regular DANE, it is sufficient if (but also necessary that)
> the DNS-Domain "universalmusic.com" has DNSSEC active in order to
> securely provide a TLSA record for
> 
> _25._tcp.universalmusic.com.
> 
> and simultaneously independent from the DNSSEC status of frontbridge.com.

And for STARTTLS you only need universalmusic.com MX record to be
secure and that mail.global.frontbridge.com have a CERT issued in
that name.  If you want to prevent downgrade attacks then you need
either a "Secure MX" record or _25._tcp.mail.global.frontbridge.com
to be signed with the appropriate TLSA record.

> If you want to allow DNS-based indirection, and in particular on existing
> DNS records, then you would have to enforce that *ALL* domains that
> are traversed during all possible DNS indirections have DNSSEC active
> and that all lookups are verified, and require that the SMTP-software
> aborts if DNSSEC verification of one of the indirections fails or
> is not possible, and it may be difficult to impossible for the DNS-Software
> (maintenance tools and DNS-Server) to help you maintaining consistency
> across all those possible indirections, and close to impossible for the
> DNS admins to understand the implications.

If a site cares about the security of the email being sent to it
then it signs its zones and adds relevent TLSA records to prevent
downgrade attacks or if email is being handled by a third party
that the relevent zones operated by the third party are signed.

Moving to "Secure MX" records would provide the signaling and
indirection with just one record.  You just don't have implict
"Secure MX" records, just implict MX records.

Mark

> -Martin
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]