From owner-freebsd-security@FreeBSD.ORG Tue Sep 10 02:14:21 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3DD32C20 for ; Tue, 10 Sep 2013 02:14:21 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D16CA2249 for ; Tue, 10 Sep 2013 02:14:20 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r8A2EHgD055240; Mon, 9 Sep 2013 22:14:17 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r8A2EHeR055237; Mon, 9 Sep 2013 22:14:17 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21038.32889.46054.73649@hergotha.csail.mit.edu> Date: Mon, 9 Sep 2013 22:14:17 -0400 From: Garrett Wollman To: "Poul-Henning Kamp" Subject: Re: Anything in this story of concern? In-Reply-To: <95933.1378712057@critter.freebsd.dk> References: <20130909144142.J99094@sola.nimnet.asn.au> <94943.1378706943@critter.freebsd.dk> <0EEF6678B3EEC94B9AE44705DF224D023D48BF92@G9W0725.americas.hpqcorp.net> <95933.1378712057@critter.freebsd.dk> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Mon, 09 Sep 2013 22:14:17 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu X-Mailman-Approved-At: Tue, 10 Sep 2013 03:28:16 +0000 Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 02:14:21 -0000 < said: > And as Garrett Wollman correctly pointed out on twitter: It remains > yet to be seen if any implementation of SSL/TLS can be non-crap, > given that they are stuck with X.509. I should say, by the way, that X.509 is not an inherent requirement of SSL/TLS, *but* it's what the clients implement. You can do GSSAPI authentication for the TLS key exchange, but there's little benefit in doing that versus just doing straight GSSAPI sign/seal and leaving TLS out of it completely. (Plus, there are only two options for GSSAPI; one of them doesn't work at Internet scale and the other is back to X.509 again.) You can also do OpenPGP-style Web of Trust authentication for the TLS key exchange, but that doesn't work at Internet scale either. GnuTLS supports both, however. What would work, would be better than the X.509 CA infrastructure we have now, and has been demonstrated experimentally, is using DNSsec to publish server public keys -- but that's hardly reducing the size of the TCB, and it would significantly worsen the impact of bugs in validating DNSsec implementations. The likely result, if browsers and servers began to support this as a legitimate option, would be that the existing rents collected by X.509 CAs would instead by paid to domain registries and registrars instead. (On the other hand, it seems unlikely that registries could get away with charging the same premium for a secure delegation as CAs now do for a wildcard certificate -- and the latter is a horrible idea anyway.) -GAWollman