Re: [Trans] EXTERNAL: DNSSEC also needs CT

[Tao Effect <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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:[e-mail]] On Behalf Of Nico Williams
>> Sent: Friday, May 09, 2014 4:31 PM
>> To: [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trans
>> 
>> _______________________________________________
>> Trans mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trans
> 
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans