Re: [Trans] EXTERNAL: DNSSEC also needs CT

Tao Effect <contact@taoeffect.com> Fri, 09 May 2014 22:13 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 0C6221A0118 for <trans@ietfa.amsl.com>; Fri, 9 May 2014 15:13:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.334
X-Spam-Level:
X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Spz4M9HdnVFZ for <trans@ietfa.amsl.com>; Fri, 9 May 2014 15:13:46 -0700 (PDT)
Received: from homiemail-a14.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 5276B1A010D for <trans@ietf.org>; Fri, 9 May 2014 15:13:46 -0700 (PDT)
Received: from homiemail-a14.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTP id 4A3C1392076; Fri, 9 May 2014 15:13:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=5IzDrxlyNRPD9+TCV WW1lJxCc84=; b=X0d63WCY/x0vDgH81uIZg1LfsI73QuTYfLmXna90i7DWwbS9+ xl2CKrrVXAVL0T2l9bkzlbzA9HFfYDsPw+VdXt4QoVx49cBxPXiC3eI/GMd+KY7A 3lZnF4SbvuOvX8dhyw/bzCSdIZvZbZfUQMAAS8xKMXfo3fBkJK5bXUfWnU=
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-a14.g.dreamhost.com (Postfix) with ESMTPSA id 41BCE39206D; Fri, 9 May 2014 15:13:40 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_305E70B0-259D-47B5-801A-364EAB217050"; 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: <19075EB00EA7FE49AFF87E5818D673D41110CD50@PRODEXMB01W.eagle.usaa.com>
Date: Fri, 9 May 2014 17:13:37 -0500
X-Mao-Original-Outgoing-Id: 421366417.513644-b64096aee58d7394958914ae964f890b
Message-Id: <5241C11D-BD9B-4946-BB84-B0AE754DFA9B@taoeffect.com>
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <19075EB00EA7FE49AFF87E5818D673D41110CD50@PRODEXMB01W.eagle.usaa.com>
To: "Mehner, Carl" <Carl.Mehner@usaa.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/IwLqIiArdwnbQ2Ya_SGyRnmoPAE
Cc: Nico Williams <nico@cryptonector.com>, "trans@ietf.org" <trans@ietf.org>
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:13:49 -0000

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