Subject: [saag] : DNSSEC PKI semantics and risks (was tangentially: Last Call: <draft-dukhovni-opportunistic-security-01.txt>)

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Aug 2014 22:54:36 +0000

On Wed, Aug 06, 2014 at 06:39:37PM -0400, John C Klensin wrote:

> The other end is equally bad.  DNSSEC protects the integrity of
> data already stored in the DNS.  But, if the proverbial Bad Guy
> can compromise a domain name registrar and register a name that
> is misleading or otherwise problematic, certificates tied to
> that name may not be very useful, especially as assertions of
> good and upright behavior associated with, e.g., mail traffic.
> Whether DANE-type certificates that depend on DNSSEC and
> registrar integrity are more of less trustworthy than PKI-type
> certificates that depend on certificate chains,
> low-assertion-quality certificates, and CA integrity is an
> interesting question... but one that might easily be resolved by
> a race to the bottom.

If folks want to continue this nuanced tangential discussion,
perhaps a separate thread on saag, or on Perry's cryptography list
would be more appropriate.  I'm having a hard enough time keeping
track of all the on-topic LC mail.

I am Redirecting replies to saag only, and changing the subject.
With any luck I've also removed the "References:" header, thus
severing the new thread from the original.

[ For what it is worth, I for one, don't expect certificates to
warrant trustworthy or upright counterparty behaviour.  I only
expect them to ensure channel integrity for my connection to
whichever deviant fraudster I've chosen to connect to. :-)  Please
express any disagreement or agreement or disagreement with that
sentiment in another thread.  Thanks. ]

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Aug 2014 18:42:09 -0500

On Wed, Aug 06, 2014 at 10:54:36PM +0000, Viktor Dukhovni wrote:
> > [MITM attack by compromised DNS registrar text elided.]
> 

DNSSEC is a PKI, with all that that implies, yes.

Mitigations for PKI's compromised-issuer MITM vulnerability:

 - Strong naming constraints

   Check!  The most important mitigation is already there.  DNSSEC has
   and necessarily had to have strong naming constraints from the get
   go.

 - CT

   CT for DNSSEC should fall squarely into trans WG's remit (if not now,
   then after a charter update to make it so).

   Trans WG already has been discussing CT for DNSSEC!

 - Pinning

   Pinning of services' public keys/intermediate issuer at the
   application layer is completely orthogonal to DNSSEC.  If you're
   already pinning, then you are already mitigating this problem.

 - Things like Perspectives (which IIUC is not being pursued any longer).

Nico
--

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Aug 2014 11:56:27 +0100

>    and necessarily had to have strong naming constraints from the get

Sort-of related to this is the concept of delegation-only zones. If you
get a signature for www.example.dodgy from the .dodgy keys rather than the
example.dodgy keys, you know something is not right. DNSSEC can sometimes
spot this if the validator has previously cached the zone cut. The idea of
enforcing delegation-only zones is somewhat contentious and it causes
interoperability problems in practice - and AFAIK the existing
delegation-only code only constrains resolution not validation.

(Historical note: I believe early versions of DNSSEC did not have such
strong coupling between the naming hierarchy and the signing hierarchy.
See RFC 3008.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Thames: Variable 3, becoming east 4 or 5. Slight, occasionally moderate later.
Rain later. Good, occasionally poor later.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 7 Aug 2014 14:12:22 +0000

> strong coupling between the naming hierarchy and the signing hierarchy.

Another option may be to encourage TLDs and any other zones that
correspond to public domain registries (the same ones to which one
might apply delegation-only) to implement RFC 5011 signed key
rollover (that is in a manner compatible to what we expect from
the root zone some day).

That way a nameserver (that supports RFC 5011 for more than just
the root zone) could seed trust anchors for some set of such zones
and track key rollover independently of any root zone signatures.
Thus further reducing the ability of an active attacker in possession
of the root key to MiTM domains in any TLD.

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Aug 2014 13:57:46 -0400

The reason TRANS does not currently appear to be relevant to the
DNSSEC advocates is that they are simplifying the PKI problem to
exclude consideration of the entire class of attacks that TRANS is
designed to control.

In the real world, excluding consideration of a problem does not make
it go away. So TRANS is very useful and relevant to DNSSEC.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Aug 2014 14:02:54 -0400 (EDT)

On Thu, 7 Aug 2014, Phillip Hallam-Baker wrote:

<trans wg cochair hat on>

> exclude consideration of the entire class of attacks that TRANS is

We have had only very preliminairy TRANS DNSSEC discussion so far.

I am not aware of anything being excluded at this point. Some concerns
raised do relate to the sheer size of DNS and what to log and what not
to log to keep the log servers alive.

What do you believe has already been excluded from TRANS with respect to
DNSSEC by DNSSEC advocates?

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Aug 2014 08:04:05 -0400

> DNSSEC by DNSSEC advocates?

That is not what I wrote.

What I was saying is that the need for TRANS is not going to be
understood by people who believe that the 500+ DNS registrars are all
trustworthy and that the mechanisms that the now 300+, soon to be
1,000s of registries deploy to ensure that keys are only introduced by
the authorized party will all work without any possibility of error or
attack.

TRANS is the way to deploy DNSSEC.

CAs will be doing CT, the Google has told us we will.

CAs have the infrastructure to walk people through deployment of
cryptographic apparatus.