Incidentally, DNSChain + DNSCrypt/DNSCurve is a simple and actually secure solution to not just the problems DNSSEC tried to solve, but the ones CT tried to solve as well (and without the additional problems that CT creates anew).
-- Please do not email me anything that you are not comfortable also sharing with the NSA. On May 9, 2014, at 5:13 PM, Tao Effect <[email protected]> wrote: > 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 > > _______________________________________________ > 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
