Subject: [dane] Fwd: SecDir Review of draft-ietf-dane-protocol-19

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Apr 2012 14:29:20 -0700

Begin forwarded message:

> Resent-From: [email-masked]
> From: Catherine Meadows <[email-masked]>
> Subject: SecDir Review of draft-ietf-dane-protocol-19
> Date: April 26, 2012 1:08:48 PM PDT
> To: [email-masked], [email-masked], [email-masked]
> Cc: Catherine Meadows <[email-masked]>
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> 
> This draft gives the specification of a method for DNS-based authentication of named entities (that is public key certificates) for
> TLS.  The draft is written in response to a perception of the risk involved in the current use of multiple Certificate Authorities (CAs)
> to issue certificates.  Because CAs are large, they make inviting targets, and because different CAs may be sign the same certificate,
> compromise of even one CA could allow it to issue a replacement certificate with a bogus key that would replace the legitimate certificate
> signed by the honest CAs.  This has led to some incidents involving
> compromise of major web sites involving millions of users.
> 
> Another approach is  to make use of the DNS infrastructure instead of public CAs: keys are associated with domain names, and can only be signed
> with a key associated with the parent of the domain name.  The keys would be managed by the same entities that manage the domain name.
> This has the advantage that an untrustworthy signer can only compromise keys in its own subdomains, so the advantage of to an attacker
> of compromising a single CA is lessened.  
> 
> This document describes a TLSA Resource Record  that is used to associate a certificate with the domain name where the record is found and
> specifies its use in TLS.  This requires changes to the client software so that clients are able to interpret the records, but no change to the server software.
> 
> The security considerations section is thorough and well-thought out.  It consists of three parts.  The first part describes security risks not necessarily (to my knowledge) related
> to the choice of DNS domains rather than CAs, and describes possible mitigations.  The second gives a comparison of the
> security issues involved in relying on DNS domains rather than CAs; the authors make it clear that this is not an open-and-shut case either
> way, and that much is still unknown.  The third describes, and suggests mitigations against, some security risks that are specific to DNS, having to do with attacks based on deliberate mis-association
> of TLSA records and DNS names.
> 
>  I only  have a couple of minor questions.  First,  the authors contrast the number of certificates signed by the  CAs and by the DNS domains.  However, it would
> appear that as get closer to the root of the domain name tree, number of certificates would get large, and that some domains, such as .com, would
> be more likely to have certificates that are attractive to attackers than others.  However, I don't know how large CAs get by comparison; if there are some
> figures available, that would help.  Secondly, it appears that all the risks described in the first part of the security considerations apply equally as well to the
> current CA-based system as well, except that the risks attributed to rogue DNS administrators would
> instead be attributed to rogue CA's.   If that is so, it would be good to have a sentence saying so.  On the other hand, if some of the risks apply only to the new
> system and not the current one, it would be good to know about these too.  
> 
> Finally, a nit: what are the A/AAAA records referred to in the first part of the security considerations section?  I could not find a definition in the document.
> 
> Cathy Meadows
> 
> 
> Catherine Meadows
> Naval Research Laboratory
> Code 5543
> 4555 Overlook Ave., S.W.
> Washington DC, 20375
> phone: 202-767-3490
> fax: 202-404-7942
> email: [email-masked]
> 

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 26 Apr 2012 18:51:44 -0400 (EDT)

On Thu, 26 Apr 2012, Paul Hoffman wrote:

>  I only  have a couple of minor questions.  First,  the authors contrast the number of certificates
> signed by the  CAs and by the DNS domains.  However, it would
> appear that as get closer to the root of the domain name tree, number of certificates would get
> large, and that some domains, such as .com, would
> be more likely to have certificates that are attractive to attackers than others.  However, I don't
> know how large CAs get by comparison; if there are some
> figures available, that would help.

A straight count comparison is not very meaningful.  If the com zone is
compromised, modified NS records, in combination with a single compromised
CA would result in all TLS being compromised. This is the same as .com
being compromised, and modifying DS records. In both cases the real
devestating compromise is the .com zone NS records.

What is however a fair new risk is the compromise of a registrar that
can update DS records of their registrants. It is a true concern, and
such compromise would almost be equal to a CA compromise, but there
is an important difference. A CA compromise can be used in a localised
targeted attack, but can remain hidden, as we saw in the Iran/chrome
case.

A compromised registrar attack however, changes the DNS view globally,
and anyone monitoring their own domains would instantly be aware of
this compromise.

>  Secondly, it appears that all the risks described in the first
> part of the security considerations apply equally as well to the
> instead be attributed to rogue CA's.

But again, the scope is very different. a rogue DNS admin can change their
own domain contents. A rogue CA van vouch for other people's domains.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Fri, 27 Apr 2012 11:12:56 +1000

Using A/AAAA to refer to A and AAAA records is bad.  Additionally the
first paragraph did not make sense.

Old:
   The security of the DNS RRtype described in this document relies on
   the security of DNSSEC as used by the client requesting A/AAAA and
   TLSA records.

   A DNS administrator who goes rogue and changes both the A/AAAA and
   TLSA records for a domain name can cause the user to go to an
   unauthorized server that will appear authorized, unless the client
   performs PKIX certification path validation and rejects the
   certificate.  That administrator could probably get a certificate
   issued by some CA anyway, so this is not an additional threat.

   If the authentication mechanism for adding or changing TLSA data in a
   zone is weaker than the authentication mechanism for changing the
   A/AAAA records, a man-in-the-middle who can redirect traffic to their
   site may be able to impersonate the attacked host in TLS if they can
   use the weaker authentication mechanism.  A better design for
   authenticating DNS would be to have the same level of authentication
   used for all DNS additions and changes for a particular domain name.

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

   A DNS administrator who goes rogue and changes the A, AAAA and
   TLSA records for a domain name can cause the user to go to an
   unauthorized server that will appear authorized, unless the client
   performs PKIX certification path validation and rejects the
   certificate.  That administrator could probably get a certificate
   issued by some CA anyway, so this is not an additional threat.

   If the authentication mechanism for adding or changing TLSA data in a
   zone is weaker than the authentication mechanism for changing the
   A and AAAA records, a man-in-the-middle who can redirect traffic to their
   site may be able to impersonate the attacked host in TLS if they can
   use the weaker authentication mechanism.  A better design for
   authenticating DNS would be to have the same level of authentication
   used for all DNS additions and changes for a particular domain name.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Fri, 27 Apr 2012 12:07:16 +0100

> and anyone monitoring their own domains would instantly be aware of

The other difference is that a registrar has a contractual relationship
with its customers who will be affected if the registrar is compromised.
Domain registrants can increase their security by careful choice of
registrar.

The victims of a compromised CA typically have no relationship with the
CA. You can't meaningfully increase your security by carefully choosing
which CA to buy a certificate from.

So DNSSEC has stronger legal and economic backups to its technical
security mechanisms.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
West Bailey: Northerly 4 or 5, becoming variable 3 or 4, then southwesterly 4
or 5, occasionally 6 later. Rough becoming moderate. Fair. Good.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Apr 2012 07:50:50 -0400

A rogue DNS registrar can change anything in the system that is not
nailed down. That is a fact of the current system and domain hijacking
is a daily event.

therpf.com has just recovered from a domain hijacking. It is not
directly relevant to DANE but had the EFF 'sovereign keys' proposal
been deployed the attacker could have permanently disabled the site's
ability to use SSL. Any practical scheme has to balance risks rather
than pretend that some can be ignored by declaring them out of scope.

There are controls in the DNS system that can be used to 'lock'
domains. But we have no information on how they are implemented, what
the security policy is or whether an audit exists for that part of the
system. And nobody accepts liability if those controls fail.

On Thu, Apr 26, 2012 at 6:51 PM, Paul Wouters <[email-masked]> wrote:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

-- 
Website: http://hallambaker.com/

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 27 Apr 2012 12:28:33 -0400

On Fri, Apr 27, 2012 at 07:50:50AM -0400, Phillip Hallam-Baker wrote:
> domains.

If this is supposed to be the (near-) TLD-regisrtars' ability to put
various restrictions on the registration, then they're no help for
most of the "hijack" cases, and can't possibly be.  In EPP, in fact,
they're not called "LOCK", but are instead various prohibitions
(clientUpdateProhibited, clientTransferProhibited,
clientDeleteProhibited, and maybe clientRenewProhibited; there are
server-side versions of these too).  The repository sponsor (which we
usually call a registrar) can, of course, modify these settings.  So,
if the domain name registrant's account with a registrar is subverted,
the settings can of course be removed and then the changes can happen.

(Off topic: There doesn't seem to be any practical way to fix this.  I
continue to believe that there could be a market for very secure
domain name registration service, but I suspect it's mostly out of
hope rather than evidence.)

With all of that in mind, I fail to see what the TLSA document is
supposed to say more about this topic.  It already says that if you
can get hold of the registration, then you hold the keys.  The point
in using DANE/TLSA is that that's _already the case_ with the
traditional CA market; so this opens no new attack, and closes one
(since the CA doesn't have to be involved).  I thought the draft was
clear about this.

Best,

A

-- 
Andrew Sullivan
[email-masked]