Subject: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt

From: John Gilmore <[email-masked]>
Date: Thu, 12 Apr 2012 12:03:56 -0700

The last graf of section 8, and the whole of section 8.1, seem
designed to prop up CA-based businesses, by fragmenting and
disparaging the security of the DANE protocol that the RFC proposes.

Our job as a committee was to design something that would be MORE
secure than CA-based TLS.  If the committee truly believes that it
can't tell whether DANE for TLS will be more secure or less secure
than CA-based TLS (which is what draft-19 now says in brand-new text
inserted in Section 8.1), then IETF should avoid standardizing DANE
for TLS, and disband the committee as incompetent.

Instead, many on the committee have proposed that DANE for TLS become
a Proposed Standard.  That means that we *do* think that it will
produce better security than the status quo.  Therefore, we should
remove the sections from the document that inappropriately bash the
security of DANE for TLS.  And we should remove the suggestion that
because certain mandatory-to-implement TLSA records don't happen to
support CA-based business models, implementors should provide local
options to reject those TLSA records.

The newly inserted Section 8.1 needs serious work.  It was
inappropriate to insert this inflammatory section into the document
immediately before Last Call, with little mailing list discussion
beforehand.  Again, it is an inappropriate attack on non-CA-based
DANE.

I would be happy to work with the committee on text for this
Internet-Draft (or Proposed Standard RFC) that would contrast the
security of DANE-for-TLS with the security of the status-quo-ante TLS,
either for a single secure website, or for the Internet as a whole, or
both.  The text that's in Section 8.1 is not accurate, and is slanted
to inappropriately favor particular market participants.  If the
committee is interested in a "quick fix" so we can rush the RFC into
print, I would be happy with removing the entire misleading section
8.1, and removing the MUST-undermining last paragraph of section 8.

Now for the details:

Section 8, last paragraph:

The last paragraph should be removed, because it is designed to
fragment the market for DANE for TLS by encouraging implementers to
"locally" disable the mandatory-to-implement certificate usage types 2
and 3.  It was inserted without discussion in draft-18 and was
objected to at that point, but has been retained in "last call"
draft-19.

It is part of the design of DANE that if it is widely implemented
among clients, then TLS servers can rely solely on keys stored in
their DNS zone, avoiding the use of CAs.  Section 6 of the draft uses
a MUST to require implementation of DANE's certificate usage types 2
and 3, which provide non-CA-based key certification, but this
paragraph of small print deliberatly seeks to take away what the large
print grants, undermining that MUST by encouraging a "local policy" of
denying these usage types.  (A local policy to "deny the trust" of
these keys is equivalent to not implementing them at all.)

I claim that this paragraph is not motivated by actual security
concerns, but by competitive business concerns.  Certifying
Authority-based businesses want usage types 2 and 3 to become unusable
in some significant percentage of clients, because if that came about,
every TLS server would continue to be required to pay some CA-based
business money every year for a certificate.  If usage types 2 and 3
are as widely implemented as usage types 0 and 1, then TLS servers
would be free to stop paying CAs annually.  This paragraph and Section
8.1 are the CAs' weapons in that market struggle.  They are welcome
to compete in the security market, but it is not the job of IETF RFCs
to help them retain their oligopoly in that market.

I sent an email yesterday about this concern, before draft-19:

  https://www.ietf.org/mail-archive/web/dane/current/msg04609.html

I raised the details of my objections in -18 in an earlier message here:

  https://www.ietf.org/mail-archive/web/dane/current/msg04565.html

Section 8.1, entire section:

The whole section compares apples to oranges by comparing "a DNSSEC
validator" not with "a certificate-chain constructor and validator"
but with unspecified single CAs.  To compare apples to apples, it
would compare an unspecified single CA with an unspecified single
domain administrator.

It claims to be "Comparing DANE to Public CAs", but it doesn't even
attempt to do that.  Instead it cherry-picks the most problematic
parts of DANE security in misleading comparisons.  It doesn't even note
that DANE is designed to increase the security of CA usage for users
who want them, while also offering high security to users who for any
reason want to avoid CAs.

If the intent of the section is to discuss the effect of DANE on the
security of the whole Internet, then a system-level look at both the
status quo's and DANE's security is required, not a patchwork
comparison of individual elements of that security.  If the intent is
merely to discuss the effect of DANE on the security of an individual
service that uses TLS (such as a single secure web site), then a
system-level look at that individual service is required.  Section 8.1
has not provided either one; it makes unsupported assertions about one
element of CA-based TLS, while making other unsupported assertions
about a different element of DANE-based TLS.

The 1st graf of 8.1 makes little sense to me.  It claims that a DANE
client using an external DNSSEC validator is "as vulnerable as" a TLS
client of today.  It states a tautology by saying that any client that
relies on any external source of trust can be fooled by relying on an
untrustworthy source.  But then it bootstraps that into misleadingly
saying that DANE is "as vulnerable" as current TLS.  This is wrong,
because a TLS client of today is vulnerable to compromise from
hundreds of trusted entities, most or all of which the client has no
contractual relationship with, and most or all of which were never
explicitly configured or examined by the user of the client.  A DANE
client using an exernal DNSSEC validator is vulnerable to compromise
from a single trusted entity, that validator, plus another small
number of trusted entities which provide domain name service for the
domains that the client accesses.  There are no pre-configured
external DNSSEC validators in TLS client software, as there are with
trust anchors, so any exernal DNSSEC validator would have to be
configured manually by the user of the client, requiring explicit
action to configure it insecurely.  Also, the client's user probably
has a contract or other close relationship (such as being in the same
corporation) with an entity that provides it with an external DNSSEC
validator, so the user can more easily monitor its trustworthiness.
For example, the user's ISP might provide external DNSSEC validation,
as they today provide recursive DNS service, and most users have a
contract with their ISP.  But the whole graf is mostly irrelevant,
because external DNSSEC validators running on other peoples' machines
are only expected to be used by a small fraction of the DANE clients.

The second graf makes an unsupported assumption ("If it is less likely
that a user will hear about...") to produce a scare quote ("could be
worse off than a current TLS client").

Similarly, the 3rd graf seems to be unsupported by facts.  It says
"Current public CAs are assumed to have better defenses than current
DNSSEC validators", but I don't think that there are any current
DNSSEC validators to compare current public CAs to.  "Better defenses"
is ipso facto a misleading phrase unless it specifies against what
threat model it is defending.  Furthermore, some current public CAs
have been proven to have poor defenses, since they have issued invalid
certificates used in mass man-in-the-middle attacks against the
population of entire countries.  Since some current public CAs are
known to be untrustworthy, it's hard to support saying that "current
public CAs" in general are assumed to have good defenses.  It then
goes on to say that "this perception" can't be proven one way or the
other.  Barrooms, not RFCs, are the place for such poorly supported
statements.

The first two grafs discuss "external DNSSEC validators", but the
third and final graf slyly shifts the ground to "DNSSEC validators" in
general, without making this change obvious.  And, again
validators are only a small part of the DANE ecosystem, but this
section doesn't go into any other part, while claiming to compare
the totality of DANE's security.

I believe that today's "internal" DNSSEC validators are considered as
trustworthy as today's "internal" certificate-chain constructors and
validators as used today in TLS.  These are both cryptographic libraries
that have undergone substantial testing and widespread deployment over
a period of many years.  

I believe that if the RFC is going to make statements about the
relative security DANE and of CA-based TLS, we should clearly state
that many well-qualified security experts and network administrators
have serious concerns about the security of CA-based TLS.  I would be
happy to provide citations for some such statements, that the RFC
could reference as informative.  We should also state that the only
reason for the continued widespread use of CA-based TLS is that there
is no credible alternative ready for mass market use.  (The role of
this committee is to produce such an alternative -- not to undermine
its new alternative.)

The draft currently states in Section 1.1 that the actual security in
practice of traditional TLS CAs has been demonstrated to vary widely
among different CAs, from completely trustworthy to completely
untrustworthy.  We all know that more than a few CAs have had their
trust anchors removed from popular TLS software due to public
breaches.  A few other CAs who suffered breaches required specific
software patches in mass market TLS software such as browsers, because
their certificates were too widely used to allow their trust anchors
to be removed due to a single breach that issued a small number of
invalid certificates.  We all fervently hope that that CA won't allow
another breach to occur, but such a history does not give us great
confidence.

I believe it is too early to say anything about the actual security in
practice of TLSA-protected domain names, since there is no operational
history to guide us.  We don't even have an RRTYPE for TLSA yet!  It
is *designed* to be secure, but so was CA-based TLS designed to be
secure, and yet CA-based TLS has not always been secure.  We have
designed DANE to be MORE secure than CA-based TLS, for specified
reasons.  Only time will tell.

The conclusion of section 8.1 "Thus, it is difficult to foresee which
system has a higher risk." is invalid.  As Steve Kent pointed out, and
as our document now states, DANE for TLS incorporates the principle of
least privilege, which fixes the largest vulnerability in CA-based
TLS.

	John Gilmore

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Apr 2012 21:37:12 +0100

So I think that section 8.1 was added as a result of
some discussion arising from my AD review.

A couple of things wrt that and John's mail:

- The WG should feel entirely free to do what's right,
don't treat this text specially bacause it came about
as a result of an AD review.
- The comment that gave rise to this was only about
comparing a current-PKI client against a DANE client
that uses an external DNSSEC validator. There are
certainly better ways to use DANE than that, but I
think the external validator is a interesting point of
comparison that does show that there are non-obvious
trade-offs here. It could well be 8.1 isn't clear
enough that its only the external validator case
that being compared.
- I also agree that 8.1 isn't all encompassing nor
a full analysis. But then it doesn't have to be to
be useful.
- Fixing/improving stuff like this at IETF LC seems
like a fine thing. (I just hope it doesn't take too
many mails:-)

S.

On 04/12/2012 08:03 PM, John Gilmore wrote:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>