Re: [Trans] EXTERNAL: DNSSEC also needs CT

Tao Effect <contact@taoeffect.com> Fri, 09 May 2014 22:52 UTC

Return-Path: <contact@taoeffect.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B641A0118 for <trans@ietfa.amsl.com>; Fri, 9 May 2014 15:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddrAnd1vAVGc for <trans@ietfa.amsl.com>; Fri, 9 May 2014 15:52:41 -0700 (PDT)
Received: from homiemail-a8.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 32AAF1A00F6 for <trans@ietf.org>; Fri, 9 May 2014 15:52:41 -0700 (PDT)
Received: from homiemail-a8.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a8.g.dreamhost.com (Postfix) with ESMTP id 36313D22070; Fri, 9 May 2014 15:52:36 -0700 (PDT)
Received: from [192.168.1.5] (173-17-72-87.client.mchsi.com [173.17.72.87]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a8.g.dreamhost.com (Postfix) with ESMTPSA id EA5ABD22069; Fri, 9 May 2014 15:52:34 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_187DF914-3AC6-450A-95D8-B10B7D2DABD4"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
X-Pgp-Agent: GPGMail 2.1 (525b9ae)
From: Tao Effect <contact@taoeffect.com>
In-Reply-To: <5241C11D-BD9B-4946-BB84-B0AE754DFA9B@taoeffect.com>
Date: Fri, 9 May 2014 17:52:32 -0500
X-Mao-Original-Outgoing-Id: 421368752.664473-e23d2383c2d5259b8aa9d4f553cccd7e
Message-Id: <E158035C-3B2A-46AB-847F-985256E9FFC8@taoeffect.com>
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <19075EB00EA7FE49AFF87E5818D673D41110CD50@PRODEXMB01W.eagle.usaa.com> <5241C11D-BD9B-4946-BB84-B0AE754DFA9B@taoeffect.com>
To: Tao Effect Support <contact@taoeffect.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/RCv1QhM-h96UfJx0ER3waJ7VTi0
Cc: Nico Williams <nico@cryptonector.com>, "trans@ietf.org" <trans@ietf.org>, "Mehner, Carl" <Carl.Mehner@usaa.com>
Subject: Re: [Trans] EXTERNAL: DNSSEC also needs CT
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2014 22:52:43 -0000

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 <contact@taoeffect.com> 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 <Carl.Mehner@usaa.com> 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:trans-bounces@ietf.org] On Behalf Of Nico Williams
>> Sent: Friday, May 09, 2014 4:31 PM
>> To: trans@ietf.org
>> 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
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>> 
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
> 
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans