Re: [Trans] DNSSEC also needs CT

On 22 May 2014 18:32, Osterweil, Eric <eosterweil@verisign.com> wrote:

>
> On May 22, 2014, at 1:21 PM, Stephen Kent <kent@bbn.com>
>  wrote:
>
> > Nico,
> >> DNSSEC is a PKI [of sorts; please, no need to pick nits about that].
> > agreed.
> >> It stands to reason that DNSSEC should have similar trust problems as
> >> PKIX.  I believe it does indeed.
> > PKIX, per se, does not have the trust problems that seem to motivate
> > CT; the Web PKI does. That PKI has always had a serious problem because
> > any TA can issue a cert for any Subject, irrespective of the Subject
> name.
> > because DNSSEC intrinsically incorporate the equivalent of PKIX Name
> > Constraints, it does not suffer from that specific problem. That's not to
> > say that mis-issuance is not possible in DNSSEC, but rather that its
> > effects are more limited.
> >> It follows that things like CT that we're applying to PKIX should be
> >> applied to DNSSEC as well, where possible.
> > maybe.
> >> I don't see any reason why CT couldn't be extended to DNSSEC.  IMO, it
> >> should be done.
> > I'll defer to DNS experts on that.
>
> Without implying an presumption of expertise on DNS, I would argue that
> DNSSEC avoids the problems CT seems to be trying to solve by coupling its
> key learning (and verification) methods to the hierarchical namespace.  As
> Steve said (I believe) PKIX != Web PKI, and the problems addressed by CT
> seem to be focused more on the latter.  I don't think there is a key
> learning/verification dilemma in DNSSEC that CT is appropriate for.
>

I disagree: the purpose of CT is to ensure that those who can mess with the
signing chain are monitored for correct behaviour. How people get into the
signing chain does not alter the need to monitor their correct behaviour.

>
> Eric
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>

-- 
Certificate Transparency is hiring! Let me know if you're interested.