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

From: Ondřej Surý <[email-masked]>
Date: Thu, 3 May 2012 17:47:43 +0200

John,

you have raised this issue several times and yet I haven't seen
a supportive message from other WG members.  On the other hand
Jim Schaad[1] and me have opposed your view of the issue.

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

Chairs think the text is fine as it is.  If the other WG members
disagree, please speak now.  And again I would like to see a modified
text if you are going to support the assertion that we favor CAs
(Type 0/1).

O.
P.S.: Also again I would like you to refrain from ad hominem attacks.

On 12. 4. 2012, at 21:03, John Gilmore wrote:

> 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
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 3 May 2012 18:11:35 +0200

Just to be explicit, I consider that there was no consensus for a change.

---

From: Scott Schmit <[email-masked]>
Date: Thu, 3 May 2012 23:12:22 -0400

> text if you are going to support the assertion that we favor CAs

I'll express support for John's technical arguments against section 8.1.
I don't have a strong position about the paragraph in section 8, but I
think we can improve it by changing this:

   The client's full trust of a certificate retrieved from a TLSA record
   with a certificate usage of 2 or 3 may be a matter of local policy.
   While such trust is limited to the specific domain name for which the
   TLSA query was made, local policy may deny the trust or further
   restrict the conditions under which that trust is permitted.

to this:

   Generators of TLSA records should be aware that the client's full
   trust of a certificate association retrieved from a TLSA record may
   be a matter of local policy.  While such trust is limited to the
   specific domain name, protocol, and port for which the TLSA query was
   made, local policy may deny to trust the certificate (e.g., due to
   weak cryptography), just as with PKIX trust anchors.

Rationale behind the changes:
* Local policy could disable the TA or an intermediate certificate that
  is being used for type 0 or 1, too, though I guess you could argue
  that that's not new to DANE.

* I'm not sure how you can meaningfully "further restrict" the
  conditions of use the conditions of use that isn't already applicable
  to PKIX.  DANE already restricts conditions of use to the
  name/proto/port tuple.

* One of the defenses of the paragraph was that clients can already
  disable PKIX trust anchors, so I made that comparison explicit.

This seems to be more accurate, at the least, and may be more acceptable
to John.

As for section 8.1, I agree that it's incorrect technically.  Martin Rex
has also expressed agreement:
https://www.ietf.org/mail-archive/web/dane/current/msg04649.html
I didn't chime in at the time because I assumed that John and Martin's
technical arguments made the case adequately that section 8.1 makes an
invalid comparison--but evidentally not, so I'll throw my arguments into
the ring:

The more-direct parallel to be drawn between CAs and DANE is the DNSSEC
signing chain itself -- the DS + KSK DNSKEY records for a domain form
the equivalent of a name-constrained PKIX CA certificate, and ZSK DNSKEY
records are equivalent to PKIX self-issued certificates. (Where
"certificate" is defined as a binding of a name and a key. Obviously,
PKIX certificates allow significantly more information to be included
into the signed content.) TLSA records are like name-constrained PKIX
certificates as well (though bound to a specific protocol/port, which
I'm not sure if PKIX can do).

Despite this, Section 8.1 compares PKIX CAs to external DNSSEC
validators.  That's not unlike comparing DNSSEC records to web browser
PKIX certificate validation software (though at least web browsers run
on the same machine).

IIUC, section 8.1 was added to compare the risks of the PKIX CA security
model as typically implemented (large trust anchor list) to DANE, but
IMHO fails to do so for the reasons stated above.

To be charitable, perhaps it was thought that external validation is how
DNSSEC is typically implemented today, so it makes for a fair
comparison.  That said, with DANE, the client can simply eliminate all of
the risks of external validation on the DANE side of the comparison by
being implemented differently. The same cannot be said, in practice, for
PKIX CAs.  One could make the comparison to a compromise of .com's
DNSKEYs, but section 8.1 doesn't even address that risk.

If the above, and the technical arguments from John and Martin remain
unconvincing, I'd like you to please explain your position.

If you accept the above, the next question is what to replace it with.
I think this outline covers the ground:

* The risk of compromise
  * Number of keys that can be compromised to achieve the desired effect
  * Likelihood of being a target of attack
  * Security measures in place to prevent attack success (HSM, access to
    key, authentication of data to be signed)
  * Qualifications/experience of people securing the keys
  * ...Other??
* The impact of such a compromise (#s of names affected)
* The likelihood of detection
* ...Other??

I could propose some text to flesh out the outline (except the "other"s,
as I don't know what they are yet :-) ), but before I start, I'd like to
know that I wouldn't be wasting my time.

-- 
Scott Schmit

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 4 May 2012 12:27:35 -0700

The changes to the paragraph in section 8 are fine with me.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Scott Schmit
> Sent: Thursday, May 03, 2012 8:12 PM
> To: [email-masked]
> Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt
> 
> On Thu, May 03, 2012 at 05:47:43PM +0200, Ondrej Sur  wrote:
> > John,
> >
> > you have raised this issue several times and yet I haven't seen a
> > supportive message from other WG members.  On the other hand Jim
> > Schaad[1] and me have opposed your view of the issue.
> >
> > text if you are going to support the assertion that we favor CAs (Type
> > 0/1).
> 
> I don't have a strong position about the paragraph in section 8, but I think we
> can improve it by changing this:
> 
> This seems to be more accurate, at the least, and may be more acceptable to
> John.
> 
> 
> As for section 8.1, I agree that it's incorrect technically.  Martin Rex has also
> expressed agreement:
> invalid comparison--but evidentally not, so I'll throw my arguments into the
> ring:
> 
> signing chain itself -- the DS + KSK DNSKEY records for a domain form the
> equivalent of a name-constrained PKIX CA certificate, and ZSK DNSKEY
> records are equivalent to PKIX self-issued certificates. (Where "certificate" is
> defined as a binding of a name and a key. Obviously, PKIX certificates allow
> significantly more information to be included into the signed content.) TLSA
> records are like name-constrained PKIX certificates as well (though bound to
> a specific protocol/port, which I'm not sure if PKIX can do).
> 
> Despite this, Section 8.1 compares PKIX CAs to external DNSSEC validators.
> That's not unlike comparing DNSSEC records to web browser PKIX certificate
> validation software (though at least web browsers run on the same
> machine).
> 
> model as typically implemented (large trust anchor list) to DANE, but IMHO
> fails to do so for the reasons stated above.
> 
> DNSSEC is typically implemented today, so it makes for a fair comparison.
> That said, with DANE, the client can simply eliminate all of the risks of
> external validation on the DANE side of the comparison by being
> implemented differently. The same cannot be said, in practice, for PKIX CAs.
> One could make the comparison to a compromise of .com's DNSKEYs, but
> section 8.1 doesn't even address that risk.
> 
> I could propose some text to flesh out the outline (except the "other"s, as I
> don't know what they are yet :-) ), but before I start, I'd like to know that I
> wouldn't be wasting my time.
> 
> --
> Scott Schmit

---

From: James Cloos <[email-masked]>
Date: Mon, 07 May 2012 09:05:37 -0400

>>>>> "SS" == Scott Schmit <[email-masked]> writes:

SS> I'll express support for John's technical arguments against section 8.1.
SS> I don't have a strong position about the paragraph in section 8, but I
SS> think we can improve it by changing this:
...
SS> As for section 8.1, I agree that it's incorrect technically.  Martin
SS> Rex has also expressed agreement: ...  I didn't chime in at the time
SS> because I assumed that John and Martin's technical arguments made
SS> the case adequately that section 8.1 makes an invalid comparison--
SS> but evidentally not, so I'll throw my arguments into the ring:

I also fell into that trap.  Since no one objected at the time, it
didn't seem like there were any need further to <aol/>.  

Scott's analysis is well though and his suggested revisions look
reasonable.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 May 2012 16:31:35 +0100

> Scott's analysis is well though and his suggested revisions look

<nohat>

I'd like to see the resulting text if possible - I do think that
its valid to make some comparisons here and while that may or may
not suit different folks' positions, the technical points remain
valid - if you use an external validator for DNSSEC then that
puts the TLS client back into a place with only subtle differences
compared to the current TLS client depending on the current
X.509 PKI and public CAs. Since those subtitles might not be
obvious to implementers I think they deserve a mention.

</nohat>

As AD, I'll not try hold up progress regardless of what the WG do
with this, so long as what's done has rough WG consensus according
to the chairs (so no news there then:-)

S.

---

From: John Gilmore <[email-masked]>
Date: Mon, 07 May 2012 16:08:12 -0700

> if you use an external validator for DNSSEC then that

I hope I'll have time to draft some wording later this week.  But as
y'all think about this section, I want to emphasize that my biggest
problem in the current text is that its title is "Comparing DANE to
Public CAs" but then it only addresses
DANE-with-an-external-validator.

I expect external validators to be a relatively niche scenario
(requiring a whole separate secured channel in order to even be
possible).  Having a validator that runs on the same machine as the
browser, or directly inside the browser, will be much simpler to
administer, plus more secure and with fewer moving parts.  Once one
guy writes a reliable internal one in portable free software, it will
work everywhere without needing system administration, and is thus
very likely to become the norm.

Section 8.1 doesn't even address the security of that "norm" scenario
at all, which is why I originally viewed that text as a CA scare
tactic.  But actually it was a response to a specific question, which
just got a too-broad and thus misleading title.  It's fixable if
we put in the work.

	John

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 9 May 2012 13:27:29 +0200

>   weak cryptography), just as with PKIX trust anchors.

LGTM

> know that I wouldn't be wasting my time.

I would certainly accept a better text.  I share the position with Stephen,
that we need some text, so if we have one which is better and technically
more correct, I would be very happy.

O.

---

From: Scott Schmit <[email-masked]>
Date: Wed, 9 May 2012 07:56:26 -0400

> more correct, I would be very happy.

Ok, I'll work on writing this up

-- 
Scott Schmit

---

From: Scott Schmit <[email-masked]>
Date: Sun, 13 May 2012 13:58:39 -0400

> Ok, I'll work on writing this up

This is intended to replace the -20 section 8.1:

8.1.  Comparing DANE to Public CAs

   The security of the DNS RRtype described in this document relies on
   the security of DNSSEC to verify that the TLSA record has not been
   altered.

[The above paragraph is moved from section 8, as it seems to fit here
better.]

   DNSSEC forms certificates (the binding of an identity to a key) by
   combining a DNSKEY, DS, or DLV RR with an associated RRSIG record.
   These records then form a signing chain extending from the client's
   trust anchors to the RR of interest.

   Though the DNSSEC protocol doesn't enforce it, DNSKEYs are often
   marked with a SEP flag indicating whether the key is a Zone Signing
   Key (ZSK) or a Key Signing Key (KSK).  ZSKs protect records in the
   zone (including DS and DLV records), and KSKs protect ZSK DNSKEY
   records.  This allows KSKs to be stored offline.

   The TLSA RRtype allows keys from the DNSSEC PKI hierarchy to
   authenticate keys wrapped in PKIX certificates for a particular host
   name, protocol, and port.

   With the exception of the DLV RRtype, all of these certificates
   constrain the keys they identify to names that are within the zone
   signing the certificate [RFC 4033].  For a domain's DLV RRs to be
   honored, it must be configured as a DLV domain, and the domain's
   DNSKEYs must be configured as trust anchors or be authentic [RFC
   5074].

   The mapping between DNSSEC RRtypes and the analogous PKIX certificate
   type is shown in the following table:

   +----------------+------------------+---------------+
   | DNSSEC RRtype  |  Analogous PKIX  | Name-         |
   | + RRSIG        |   Certificate    | Constrained?  |
   +----------------+------------------+---------------+
   | DNSKEY (KSK)   | CA Certificate   | Yes           |
   +----------------+------------------+---------------+
   | DNSKEY (ZSK)   | CA Certificate   | Yes           |
   |                | (w/ DS/DLV RRs)  |               |
   |                +------------------+---------------+
   |                | EE Certificate   | Yes           |
   |                | (w/o DS/DLV RRs) |               |
   +----------------+------------------+---------------+
   | DS             | CA Certificate   | Yes           |
   +----------------+------------------+---------------+
   | DLV            | CA Certificate   | No            |
   +----------------+------------------+---------------+
   | TLSA           | CA Certificate   | Yes           |
   +----------------+------------------+---------------+

8.1.1.  Risk of Key Compromise

   The risk that a given certificate is fake despite having a valid
   signing chain is related to the number of keys that can contribute to
   the validation of the certificate, the quality of protection each key
   receives, the value of each key to an attacker, and the value of
   falsifying the certificate.

   DNSSEC allows any set of domains to be configured as trust anchors
   and/or DLVs, but most clients are likely to use the root zone as its
   only trust anchor.  Also, because a given DNSKEY can only sign RRs
   for that zone, the number of keys capable of compromising a given
   TLSA RR is limited to the number of zones between the TLSA RR and the
   nearest trust anchor, plus any configured DLV domains.  Typically,
   this will be six keys--half of which will be KSKs.

   PKIX only describes how to validate a certificate based on a
   client-chosen set of trust anchors, but says nothing about how many
   trust anchors to use, how many, or how they are constrained.  That
   said, as currently deployed, PKIX clients typically use a large
   number of trust anchors provided with the client or operating system
   software.  These trust anchors are selected carefully, but with a
   desire for broad interoperability.  The trust anchors and CA
   certificates for public CAs rarely have name constraints applied.
   Recent efforts to determine how many keys are trusted by a typical
   client estimate the number to be around 1482. [SSLObs]

[SSLObs = https://www.eff.org/files/DefconSSLiverse.pdf ]

   A combination of technical protections, process controls, and
   personnel experience contribute to the quality of security that keys
   receive.

   The security surrounding DNSSEC DNSKEYs varies significantly.  The
   KSK/ZSK split allows the KSK to be stored offline and protected more
   carefully than the ZSK, but not all domains will do so.  The security
   applied to a zone's DNSKEYs will be proportional to the value of the
   domain.

   For example, the root DNSKEY has protections and controls comparable
   to or exceeding that of public CAs [Root-DPS].  On the other end of the
   spectrum, small domains might provide no more protection to their
   keys than they do to their other data.

[Root-DPS = https://www.iana.org/dnssec/icann-dps.txt]

   The security surrounding public CAs also varies.  However, due to
   financial incentives and standards imposed by clients for acceptance
   into their trust anchor stores, CAs generally employ security experts
   and protect their keys carefully, though compromises are not unheard
   of.

8.1.2.  Impact of Key Compromise

   The impact of a key compromise differs significantly between the two
   models.

   Public CAs are not typically constrained in what names they can sign,
   and therefore a compromise of even one CA allows the attacker to
   generate a certificate for any name in the DNS.  A domain holder can
   get a certificate from any CA, or even multiple CAs simultaneously,
   making it impossible for a client to determine whether the
   certificate it is validating is legitimate or fraudulent.

   DNSKEYs are inherently limited in what they can sign, so a compromise
   of the DNSKEY for example.com provides no avenue of attack against
   example.org.  Even the impact of a compromise of .com's DNSKEY, while
   considerable, would be limited to .com domains.  Only the compromise
   of the root DNSKEY would have the equivalent impact of an
   unconstrained public CA.

   Because a TLS certificate association is constrained to its
   associated name, protocol, and port, the PKIX certificate is
   similarly constrained, even if its public CAs signing the certificate
   (if any) are not.

8.1.3.  Detection of Key Compromise

   If a key is compromised, rapid and reliable detection is important in
   order to limit the impact of the compromise.  In this regard, neither
   model prevents an attacker from near-invisibly attacking their
   victim, provided that the necessary keys are compromised.

   If a public CA is compromised, only the victim will see the fraudulent
   certificate, as there is typically no publically-accessible directory
   of all the certificates issued by a CA that can be inspected.  DNS
   RRs are typically published publically.  However, the attacker could
   also allow the uncompromised records to be published to the Internet
   as usual but provide a compromised DNS view to the victim to achieve
   the same effect.

8.1.4.  Spoofing Hostnames

   Some CAs implement technical controls to ensure that certificates are
   not issued to domains that with names similar to popular &
   prone-to-attack domains.  Of course, an attacker can attempt to
   circumvent this restriction by finding a CA willing to issue the
   certificate anyway.  However, by using DNSSEC and TLSA, the attacker
   can circumvent this check completely.

8.2.  External DNSSEC Validators

   Due to a lack of DNSSEC support in the most commonly-deployed stub
   resolvers today, a number of ISPs have begun checking DNSSEC in the
   recursive resolvers they provide to their customers, setting the AD
   flag as appropriate.  DNSSEC-aware clients could use that data,
   ignoring the fact that the DNSSEC data has been validated externally.
   Because there is no authentication of the AD flag, this can be
   trivially spoofed by an attacker.

   However, even with secure communications between a host and the
   external validator, there is a risk that the external validator could
   become compromised.  Nothing prevents a compromised external DNSSEC
   validator from claiming that all the records it provides are secure,
   even if the data is falsified, unless the client checks the DNSSEC
   data itself (rendering the the external validator unnecessary).

   For this reason, it is RECOMMENDED that DNSSEC validation always be
   performed on-host, even when a secure path to an external validator
   is available.

Hope this helps.

-- 
Scott Schmit

---

From: Ben Laurie <[email-masked]>
Date: Sun, 13 May 2012 21:39:10 +0100

> This is intended to replace the -20 section 8.1:

Not sure I understand the table, but the rest seems like an excellent
summary to me.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 13 May 2012 13:58:27 -0700

> This is intended to replace the -20 section 8.1:

I think most of the text is clear and correct, but inappropriate for this document. It is about comparing DNSSEC to PKIX, not TLSA to PKIX. It would make a great stand-alone Informational RFC (possibly expanded even further), but isn't about TLSA.

I attempted to pull out just the TLSA-related text, and it doesn't hang together at all, unfortunately. Someone else might be able to do a better job of that than me, however.

--Paul Hoffman

---

From: Scott Schmit <[email-masked]>
Date: Mon, 14 May 2012 01:44:59 -0400

On Sun, May 13, 2012 at 01:58:27PM -0700, Paul Hoffman wrote:
> I think most of the text is clear and correct, but inappropriate for
> this document. It is about comparing DNSSEC to PKIX, not TLSA to PKIX.
> It would make a great stand-alone Informational RFC (possibly expanded
> even further), but isn't about TLSA.
> 
> I attempted to pull out just the TLSA-related text, and it doesn't
> hang together at all, unfortunately. Someone else might be able to do
> a better job of that than me, however.

I'm not sure I understand your criticism.  TLSA has no security
mechanism of its own--its security is wholly dependent on that of DNSSEC
(as stated in the first paragraph of -20's section 8), so the only way
to compare DANE's security model to PKIX is to compare DNSSEC (and the
new implications due to TLSA) to PKIX.  Personally, I think that's the
reason you were unable to separate the two.

I'll admit that I spend more time than I'd like describing DNSSEC in
terms of certificates, but the only way to compare DANE to PKIX is to
put them into like terms, and DNSSEC is not described that way in RFCs
4033-4035.  IMHO, it's this certificate interpretation that DANE is
bringing to DNSSEC.

Even then, that only affects the first part of section 8.1, and I'm not
sure how to interpret your criticism for the rest of the text.

-- 
Scott Schmit

---

From: Scott Schmit <[email-masked]>
Date: Mon, 14 May 2012 01:46:56 -0400

On Sun, May 13, 2012 at 09:39:10PM +0100, Ben Laurie wrote:
> On 13 May 2012 18:58, Scott Schmit wrote:

Is there something specific about the table that's confusing you?

-- 
Scott Schmit

---

From: Ben Laurie <[email-masked]>
Date: Mon, 14 May 2012 11:39:50 +0100

> Is there something specific about the table that's confusing you?

a) "CA certificate" is quite broad - what about DV and EV?

b) What is name-constrained?

Also, does anyone use DLV?

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 May 2012 07:52:15 -0700

> reason you were unable to separate the two.

Hrm. I see that, but I'm still having a hard time internalizing it. It is just as true for TLSA records as for all current DNS RRtypes. TLSA isn't the first RRtype since DNSSEC to have these properties.

> 4033-4035.  IMHO, it's this certificate interpretation that DANE is

DANE most recently, but other RRtypes before. I suspect that DANE is the first to get sufficient review, however.

> sure how to interpret your criticism for the rest of the text.

Good point. I think I got lost after the first part and didn't see the second bits as really being focused on DANE.

Proposal: strengthen the lead-in paragraph to this section as:
  The security of the DNS RRtype described in this document relies on
  the security of DNSSEC to verify that the TLSA record has not been
  altered. This section describes where the security of public CAs
  and the security of TLSA are similar and different. This section
  applies equally to other security-related DNS RRtypes such as
  keys for IPsec and SSH.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 14 May 2012 12:39:34 -0400 (EDT)

> Also, does anyone use DLV?

Fedora/RHEL if you use unbound (and/or dnssec-trigger)

There are still plenty of TLDs that are not signed. There are also plenty
of people that cannot or will not move to a Registrar that supports
DNSSEC within org/com/net.

Paul

---

From: Scott Schmit <[email-masked]>
Date: Tue, 15 May 2012 09:46:52 -0400

>   applies equally to other security-related DNS RRtypes such as

That works for me.

-- 
Scott Schmit

---

From: Scott Schmit <[email-masked]>
Date: Tue, 15 May 2012 10:04:49 -0400

On Mon, May 14, 2012 at 11:39:50AM +0100, Ben Laurie wrote:
> On 14 May 2012 06:46, Scott Schmit wrote:

PKIX doesn't talk about DV/OV/EV -- that's a CA/B Forum standard.
It's probably most analogous to a DV cert.

> b) What is name-constrained?

See RFC 5280 (search for "name constraint")

> Also, does anyone use DLV?

IIRC, Fedora still enables it by default in both bind & unbound--in
fact, fedoraproject.org is only validated via dlv.isc.org.

-- 
Scott Schmit

---

From: Ben Laurie <[email-masked]>
Date: Tue, 15 May 2012 15:24:19 +0100

> It's probably most analogous to a DV cert.

Then I guess CAs don't use PKIX :-)

If you want to compare TLSA to CA certificates, then don't you have to
use whatever standards they use?

> See RFC 5280 (search for "name constraint")

Heh - I know what it means, it wasn't clear to me what had the property...

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 May 2012 07:41:16 -0700

> use whatever standards they use?

No. There is not even vaguely an equivalent in the DNSSEC world for EV certs, nor for validation that gets you the equivalent of the green bar.

--Paul Hoffman

---

From: Ben Laurie <[email-masked]>
Date: Tue, 15 May 2012 16:44:27 +0100

> No. There is not even vaguely an equivalent in the DNSSEC world for EV certs, nor for validation that gets you the equivalent of the green bar.

Exactly!

---

From: John Gilmore <[email-masked]>
Date: Tue, 15 May 2012 19:45:40 -0700

> This is intended to replace the -20 section 8.1:

I tried to interact off-list with Scott on this text over the weekend,
but he was apparently unable to receive emails from me.  (They may be
in his spam folder -- or may just have been thrown away by his email
provider.)  Luckily, the IETF mailing lists aren't censoring their
incoming email, and Scott's provider's likely email censorship is
almost certainly based on shooting the messenger, not the message --
thus you-all and Scott can see *this* message.

Unfortunately I don't have finished text to propose for this long
section 8.  I was traveling and will be traveling again, likely
without Internet, thru next Tuesday.

Here are my unseen offlist emails, containing comments on his text,
plus some new text that's unfinished but which I think presents a
better flow of concepts for the reader to understand.

	John

Message-Id: <[email-masked]>
To: Scott Schmit <[email-masked]>, James Cloos <[email-masked]>,
   John Gilmore <[email-masked]>
Subject: Re: [dane] [OFFLIST] Revising section 8.1 
In-reply-to: <[email-masked]> 
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Comments: In-reply-to John Gilmore <[email-masked]>
   message dated "Fri, 11 May 2012 18:50:08 -0700."
Date: Sat, 12 May 2012 20:38:07 -0700
From: John Gilmore <[email-masked]>

Here is some more text for section 8.1.  It is unrelated to the text
that you sent me.  It's more about how I would start to explain it.
It's still pretty rough but perhaps you can see more of where I'm
going.  It turns out that this is quite a complicated topic, since
DANE is so flexible and since there are so many options, both for the
deployer and for the attacker.

I'm traveling this weekend and only getting to work intermittently,
so you'll see more intermediate forms than usual, since I'm sending them
even in rough form, when I get into a time period where I can't work
on it for some hours.

Thank you for the collaboration.

	John

Comparing DANE to Public CAs

Deploying the DANE TLS protocol to replace the classic TLS protocol in
a system (such as in a network of secure web browsers) changes the
system's security and availability tradeoffs.

Throughout the following, we assume that traditional TLS is deployed
with a wide variety of PKIX CAs as trust anchors, as is common in
today's secure Web browsers.  We also assume that DANE TLS is deployed
with a single DNSSEC trust anchor at the root zone (trusting one
public key, or perhaps two keys for rollover).

DANE TLS is a flexible system that can be deployed on each TLS server
in a variety of configurations.  For security and availability purposes,
these break down to two basic configurations: with PKIX CAs and
without them.

A TLS server whose domain name uses TLSA records with certificate
usages 0, 1, or 2 (XXX) use PKIX CAs.  The DANE TLSprotocol is designed
such that these servers will have higher security and lower availability.
Some circumstances in which an insecure connection would be permitted
by traditional TLS will instead cause DANE TLS to block connectivity.

These situations include many circumstances in which a "man in the
middle" has gained access to the connection.  Some of these are malicious
attacks; others are intentional configurations (such as a 
connection proxied through a corporate firewall via a "wildcard" CA
certificate).  In addition, the DANE TLS connection can also be disrupted
by various DNS or DNSSEC failures that would not have prevented the 
traditional TLS connection.

A TLS server whose domain name uses TLSA records with certificate
usage 3 does not use PKIX CAs.  For such servers, DANE TLS eliminates
the security risks and availability issues of PKIX.  The security and
availability of any resulting DANE TLS connections will all be derived
from the security and availability of DNS and DNSSEC.

In one expected deployment scenario, a secure web site that currently
uses traditional TLS will add a DANE certificate usage 3 record.  This
would allow traditional TLS clients to access it via the network of
PKIX CAs, while only allowing DANE TLS clients to access it via
DNSSEC.  This configuration provides the high availability and low
security of PKIX for traditional clients, while offering high security
with lower availability for DANE TLS clients.  (The same web site may
also be accessible using HTTP without TLS, giving clients an even
higher availability access path with very little security.)

Message-Id: <[email-masked]>
To: Scott Schmit <[email-masked]>
cc: John Gilmore <[email-masked]>, James Cloos <[email-masked]>
Subject: Re: [dane] [OFFLIST] Revising section 8.1 
In-reply-to: <[email-masked]> 
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Comments: In-reply-to Scott Schmit <[email-masked]>
   message dated "Thu, 10 May 2012 09:37:31 -0400."
Date: Fri, 11 May 2012 18:50:08 -0700
From: John Gilmore <[email-masked]>

I have provided revised text below.  The edits are relatively minor
unless marked by commentary in the left margin.  

I have started with your text and done an edit pass over it.  But I 
think it doesn't really present concepts in an easy to understand
order.  I would like a shot at writing it more clearly...but am sending
you this now to keep things moving.

	John

   DNSSEC binds an identity to a key by combining a DNSKEY record with
   an associated RRSIG record.  One or more associated DS records then
   form a signing chain extending from the client's trust anchors to
   the RR of interest.

   Though the DNSSEC protocol doesn't enforce it, DNSKEYs are often
   marked with a SEP flag indicating whether the key is a Zone Signing
   Key (ZSK) or a Key Signing Key (KSK).  ZSKs protect records in the
   zone (including DS records), and KSKs protect ZSK DNSKEY
   records.

   All of these records
   constrain the keys that they identify to names that are within the domain
   signing the certificate.

[DLV is defined in a pair of Informational RFCs, is not part of the
standards track, and should not be mentioned by standards track RFCs.
It was a circumvention used by a few bleeding edge folks until the
root zone was signed.  It's signed now.]

  [Is it legal for a parent zone to sign records for which there is a subdomain
  DS/NS/DNSKEY? I'd imagine not, but need to check the DNSSEC RFCs.]

[No, it's invalid.  The parent zone can only make RRSIGs for records
in its zone.  Subdomains with NS's have their own separate zones.]

[I'm not sure what the point of including this table is.  I'd remove
it.  (Delete the DLV mentions if you keep it.)]

   DNSSEC allows any set of domains to be configured as trust anchors,
   but most clients are likely to use the root zone as its
   only trust anchor.  Also, because a given DNSKEY can only sign RRs
   for that zone, the number of keys capable of compromising a given
   TLSA RR is limited to the number of zones between the TLSA RR and the
   nearest trust anchor.  Typically,
   this will be six keys--half of which will be KSKs.

Don't use the acronym KSK, expand it and explain it.  The DNSSEC RFCs are
obtuse on this topic, even if people read them.

   PKIX [RFCxxxx?] only describes how to validate a certificate based on a
   client estimate the number to be around 1500. [Quora]

[Quora =3D http://www.quora.com/SSL-Certificates/How-many-intermediate-Cert=
ificate-Authorities-are-there]

[Root-DPS =3D https://www.iana.org/dnssec/icann-dps.txt]

   The security surrounding public CAs also varies.  However, due to
   financial incentives and standards imposed by client software
   maintainers for acceptance into their set of trust anchors, CAs
   generally employ security experts and protect their keys carefully,
   though compromises are not unheard of.

[I don't know what that paragraph means.  What is a "TLS certificate
association"?  Do you mean a TLSA certificate association, or something
from vintage TLS?]

I'm not sure of the point of this paragraph; I would delete it.

   However, even when there is secure communication between a host and an
   external validator, there is a risk that the external validator could
   become compromised.  Nothing prevents a compromised external DNSSEC
   validator from claiming that all the records it provides are secure,
   even if the data is falsified, unless the client receives and checks the DNSSEC
   data itself (rendering the the external validator unnecessary).

> Thanks in advance for your help!

You're welcome.

	John

---

From: Scott Schmit <[email-masked]>
Date: Wed, 16 May 2012 00:16:48 -0400

On Tue, May 15, 2012 at 03:24:19PM +0100, Ben Laurie wrote:
> On 15 May 2012 15:04, Scott Schmit wrote:

No, they do, but EV certs are PKIX certificates with a particular
CA-specific certificate policy from client-approved trust anchors.

> Heh - I know what it means, it wasn't clear to me what had the property...

Using DNSSEC, while example.org can sign RRs for example.org or
sub.example.org, it can't sign RRs for org, ., example.net, etc.
Also, if it delegates sub2.example.org, it can't sign RRs for that
either.

-- 
Scott Schmit