Subject: [saag] Will DNSSEC need something like CT?

From: Nico Williams <[email-masked]>
Date: Thu, 8 May 2014 10:41:58 -0500

I think so.

DNSSEC is a PKI after all.  If we need CT (certificate transparency)
for PKIX, why wouldn't we also need it for DNSSEC?

I think the answer is that we will need CT for DNSSEC.

What would CT look like for DNSSEC?

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 May 2014 16:55:25 +0100

Hi Nico,

> What would CT look like for DNSSEC?

We have a WG (trans [1]) that is chartered to do CT but
also to consider whether there are further uses for that
kind of log. I'd say that list might be better for this
discussion, but maybe check with the chair (Melinda, cc'd)
to see if she'd prefer have that discussion now or after
some more of the initial work is done.

Cheers,
S.

[1] https://tools.ietf.org/wg/trans/

> 
> Nico
> --
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
> 
>

---

From: Nico Williams <[email-masked]>
Date: Thu, 8 May 2014 11:10:33 -0500

> kind of log. I'd say that list might be better for this

I figured TRANS would be appropriate, but I thought I should check
here first just in case.

> some more of the initial work is done.

OK.  Thanks,

Nico
--

---

From: Warren Kumari <[email-masked]>
Date: Thu, 8 May 2014 14:48:10 -0400

> I think the answer is that we will need CT for DNSSEC.

About to get on a plane, but I chatted with Ben Laurie about this a while
ago, and it is something on his radar...

W

---

From: Melinda Shore <[email-masked]>
Date: Thu, 08 May 2014 11:36:47 -0800

> some more of the initial work is done.

Things are going smoothly and quietly enough that I think
it wouldn't be disruptive to start a discussion of new
CT applications, and we've actually talked briefly about
logging DNSSEC in another project I'm on, so sure, it'd
be fine to start a discussion on the trans mailing list.

Melinda

---

From: Nico Williams <[email-masked]>
Date: Thu, 8 May 2014 15:04:25 -0500

> be fine to start a discussion on the trans mailing list.

Thanks.  I will!

While we're at it I suppose I should explain why I think we need this:

a) because DNSSEC is a PKI and so it follows that we should want CT
for it for the same reasons as for PKIs,

and

b) DANE bypasses PKI even when DANE is used with PKI, since DNSSEC
could be MITMed by a zone in the path to the target.

And I really like DANE.  For DANE to really take off I think we're
likely need CT!

Nico
--

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 9 May 2014 11:36:13 -0400

> for it for the same reasons as for PKIs,
DNSSEC is not a PKI it is a method to protect the information in DNS.

DNSSEC validated data can be leveraged to act like a keying provider 
as DANE or SSHFP are doing. 

> And I really like DANE.  For DANE to really take off I think we're

Questions: Do you need DNSSEC-CT for all uses of DNSSEC or only when it is used
to provide Keying information  ?

	Olafur

---

From: Nico Williams <[email-masked]>
Date: Fri, 9 May 2014 10:55:19 -0500

> DNSSEC is not a PKI it is a method to protect the information in DNS.

It's a hierarchical public key distribution mechanism: it distributes
zone public signing keys and so on.  It most certainly is a PKI.  It
only isn't PKI in the sense of using certificates and certification
authorities and other PKIX things.

I don't really care for an argument about whether we should call
DNSSEC a PKI though.  I care about arguments as to whether or not we
need CT for it, and if we agree that we need it, how to go about
getting it.

> as DANE or SSHFP are doing.

Sure, but even without those it distributes zone public keys.  DANE
and such are trivial/minor (and long-envisioned) uses of DNSSEC.

> to provide Keying information  ?

The former.  The point of CT is to keep CAs (PKIX) / delegation
signers (DNSSEC) honest, so they don't MITM users.

CT becomes more important when end-points' public keys are distributed
via DNSSEC, a-la DANE, but it was always going to be necessary.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 9 May 2014 16:15:31 +0000

> > And I really like DANE.  For DANE to really take off I think we're

I think that for DANE to take off we need DNSSEC deployment, thus
ongoing user-interface improvements in tools to manage and register
DNSSEC zones, plus progress on DNSSEC last-mile issues.  Lack of
CT is far from a significant barrier to DANE adoption.  The barriers
are:

    * DNSSEC last mile issues
    * DNSSEC is not widely adopted
    * Security toolkits lack DANE verification code.

So far, we only have a few initial implementations:

    * SSHFP RRs.
    * DANE TLSA for SMTP (so far just Postfix, draft basically done)
    * DANE TLSA for XMPP (so far implementations only support DANE-EE(3)
      and opportunistic security model not spelled out in draft).

> Questions: Do you need DNSSEC-CT for all uses of DNSSEC or only when it
> is used to provide Keying information  ?

It is not clear to me whether, how or when CT might work for DNSSEC.
What is clear, is that waiting for DNSSEC CT is not a sound reason
to delay DANE implementation.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Fri, 9 May 2014 11:22:19 -0500

On Fri, May 9, 2014 at 11:15 AM, Viktor Dukhovni
<[email-masked]> wrote:
> [...]

Eh, that was true of PKI too.

> to delay DANE implementation.

Agreed, but note that no one said or implied that adoption/deployment
of DANE and such should be delayed until we have DNSSEC CT!

Nico
--

---

From: Melinda Shore <[email-masked]>
Date: Fri, 09 May 2014 10:12:04 -0800

On 5/9/14 8:15 AM, Viktor Dukhovni wrote:
> CT is far from a significant barrier to DANE adoption.  

I don't think it's any barrier to DANE adoption - we've had
nearly ubiquitous adoption of TLS without CT.  And at the risk
of shooting off my own foot, CT is not the only approach to
addressing problems around certificate misissuance.

You've touched on one of the issues around DNSSEC (non-)
deployment, which is the lack of validators.  We're hoping to
ease that process with getdns (http://getdnsapi.net).  I'm
in the process of reworking the Python bindings but even in
their current state retrieving a TLSA record, pulling out the
certificate, and doing something with it is just a few lines
of code.  At a hack battle at TNW Europe a couple of weeks
ago one of the teams put up http://dnssec-name-and-shame.com/
using the getdns Node.js bindings.

At any rate, bring the DNSSEC and DANE discussions over to the
trans mailing list and let's see whether or not there's interest
and energy to move the work along.

Melinda