DNSSEC is certainly broken, but the solution to have a Frankenstein on your hands isn't to staple another Frankenstein onto its body.
DNSSEC insecurities and problems are well documented in the resource on this webpage: http://ianix.com/pub/dnssec-outages.html The solution to DNSSEC is *no* DNSSEC. DNSCrypt, DNSCurve, and DNSChain are all better solutions. Likewise the solution to X.509 PKI problems is *no* X.509 PKI. X.509 is _fundamentally_ the wrong approach. CT doesn't fix X.509 PKI, it merely gives the illusion of a fix, and still maintains today's global mass-surveillance state and requires people to pay money for insecurity: http://lists.randombit.net/pipermail/cryptography/2014-April/006480.html Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. On May 9, 2014, at 4:58 PM, Mehner, Carl <[email protected]> wrote: > RFC6698 says: >> This chain is required to prevent a CA from avoiding blame >> by logging a partial or empty chain. (Note: This effectively >> excludes self-signed and DANE-based certificates until some mechanism >> to control spam for those certificates is found. The authors welcome >> suggestions.) > > I propose: > > To have a DANE certificate (not signed by a public CA) included into a CT log: > 1) a pre-certificate be created > 2) the pre-certificate submitted to a log > 3) the log will verify based on a valid DANE record of type PKIX-EE > 4) return a SCT to the submitter to include in the final certificate > > > Carl Mehner > 210.416.0942 > Info Security > > > -----Original Message----- > From: Trans [mailto:[email protected]] On Behalf Of Nico Williams > Sent: Friday, May 09, 2014 4:31 PM > To: [email protected] > Subject: EXTERNAL: [Trans] DNSSEC also needs CT > > DNSSEC is a PKI [of sorts; please, no need to pick nits about that]. > > It stands to reason that DNSSEC should have similar trust problems as > PKIX. I believe it does indeed. > > It follows that things like CT that we're applying to PKIX should be > applied to DNSSEC as well, where possible. > > I don't see any reason why CT couldn't be extended to DNSSEC. IMO, it > should be done. > > Note that DNSSEC needs CT independently of protocols like DANE, but > any protocol that allows a DNSSEC MITM to bypass PKIX CT (as DANE > effectively does) should increase the need for CT for DNSSEC. > > Note too that I'm not in any way saying that DANE and similar should > block on CT for DNSSEC. > > Sincerely, > > Nico > -- > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
