Right - It doesn't matter who takes over the log. Either the certificate is present in the log or it isn't.
From: [email protected] [mailto:[email protected]] On Behalf Of Ben Laurie Sent: Tuesday, July 23, 2013 6:47 AM To: Frederico A C Neves Cc: IETF DANE WG list Subject: Re: [dane] [[email protected]] New Version Notification for draft-dukhovni-dane-ops-01.txt On 23 July 2013 13:44, Frederico A C Neves <[email protected]> wrote: On Tue, Jul 23, 2013 at 12:19:24PM +0100, Ben Laurie wrote: > On 16 July 2013 17:01, Viktor Dukhovni <[email protected]> wrote: > > > > It would help because if I don't follow your SHOULD NOT, then I would > > > decline that certificate. As we have said before, we cannot allow DANE > > > to do an end-run around CT. There is no point in finding a way to fix > > > the problem with one set of trusted third parties only to reintroduce > > > it via another set of trusted third parties. > > > > You would decline all DANE self-signed 3 1 1 certificates. None > > of them can be verified via CT. This removes one of the primary > > use cases for DANE. So I stand by the observation that you basically > > don't trust DANE (at least in its present form) regardless of CT. > > > > This seems to me to miss the point. The problem is that if we allow DANE to > verify self-signed certs, what stops an attacker from taking over DNS and > using it to certify a self-signed cert for google.com? How is this different from taking over the CT "information publisher" point/process? CT is an untrusted, verifiable service.
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
